Une autorité de certification à l'EPFL

Jean-Jacques.Dumont@epfl.ch, SIC

Au moment d'envoyer ce numéro à l'imprimerie, l'information suivante a été publiée dans la presse:

Swisskey/Telekurs - A ce jour, la demande de certificats numériques n'a pas atteint le niveau attendu en Suisse; pour différentes raisons, ce niveau ne sera pas atteint dans un proche avenir. Sur le plan international également, il s'avère que la demande de certificats universels n'atteint pas suffisamment rapidement un volume permettant de couvrir les frais d'émission et de gestion des passeports pour le monde numérique. Pour toutes ces raisons, le prestataire de services Swisskey, filiale du groupe Telekurs cesse immédiatement l'émission de certificats numériques pour les particuliers et les organisations. Les certificats existants seront bloqués dès fin juin 2001.

Moralité:
nous avions bien raison de nous méfier des solutions fournies par des entrerprises privées.

Le SIC offre désormais la possibilité d'obtenir un certificat d'authenticité pour valider les accès aux services informatiques sécurisés, délivré par une autorité de certification (CA) propre à l'EPFL.

Mais de quoi s'agit-il exactement? Que puis-je faire de ces certificats et comment dois-je procéder en pratique pour les obtenir et les utiliser? Ce sont les questions auxquelles nous tenterons de répondre le plus clairement possible dans cet article.

Rappels

La problématique a été déjà énoncée par Martin Ouwehand dans son article Confidentialité et identité sur WWW ( FI-10-97, http://dit-archives.epfl.ch/FI97/fi-10-97/10-97-page4.html).

En résumé, la sécurisation des accès aux serveurs et le respect de la confidentialité des documents transmis sur Internet repose sur les systèmes de chiffrage de type RSA: comme les autres protagonistes, je possède une clef privée et une clef publique. J'encrypte mes messages en utilisant la clef publique de mon correspondant de façon à ce que lui seul puisse le décrypter par sa clef privée. Si j'encrypte un document avec ma clef privée, quiconque pourra le décrypter avec ma clef publique. On perd alors la confidentialité, mais tout le monde peut vérifier que je suis l'auteur du document (validation de la signature).

Toutefois, ce système est susceptible de subir des attaques par intermédiaires, agissant lors de l'échange de clefs publiques. La parade à ces attaques est la certification des clefs publiques par une autorité reconnue par tous les protagonistes. Son format exact est défini sur un plan mondial par la norme X.509v3 proposée par l'ISO. L'infrastructure permettant de gérer l'ensemble des clés et des certificats pour un ensemble donné d'applications et d'utilisateurs a été affublée par nos collègues anglo-saxons du doux nom de PKI (Public Key Infrastructure). Pour plus de détails, veuillez svp consulter le FI-spécial été 2000, particulièrement: Les clés en cryptographie, http://dit-archives.epfl.ch/FI00/fi-sp-00/sp-00 -page5.html par Lionel Vallet, et Signatures, http://dit-archives.epfl.ch/FI00/fi-sp-00/sp-00-page7.html par Claude Lecommandeur.

Un certificat est un document électronique contenant l'identification d'une personne et sa clef publique, le tout signé par la clef privée de l'autorité de certification.

Utilité des certificats à l'EPFL

Applications SSL (Secure Socket Layer)

Applications mail

La clef publique certifiée peut être stockée dans l'application mail (Netscape, Outlook ou Eudora) et communiquée aux correspondants qui demandent la confiden-tialité. L'application pourra alors

Autorités de certification

Etant donné les énormes enjeux politico-commerciaux, de nombreux organismes et entreprises tentent par tous les moyens, souvent en misant sur l'ignorance du public, de conquérir une situation de monopole pour la distribution de certificats. Les plus connus d'entre eux sont: American Express, GTE Cybertrust, Global Sign, VeriSign et Swisskey (lire encadré) sur un plan plus local. Tous évidemment facturent leurs services de certification, mais aucun n'a d'autre reconnaissance que celle achetée au prix fort à Netscape et Microsoft. Aucun non plus n'accepte les éventuelles responsabilités juridiques imposées par exemple par les Ordonnances du Conseil Fédéral du 12 avril 2000 en Suisse (voir Problèmes juridiques liés à la sécurité des transactions sur le réseau par Michel Jaccard, FI-spécial été 2000, http://dit-archives.epfl.ch/FI00/fi-sp-00/sp-00-page13.html ).

En 1998, le SIC a mis en place la partie logicielle implémentant une autorité de certification à l'EPFL (voir http://certauth.epfl.ch/CA ). Comme pour toute autre CA, le problème principal n'est pas tant le logiciel que la validation des requêtes de certificat. Elle suppose en effet que les requérants se présentent en personne et exhibent leurs documents d'identité (passeports,) au responsable de l'autorité de certification, ce qui impose une importante charge administrative.

Mais il se fait que l'EPFL dispose d'un outil permettant de contourner cet écueil: nous parlons des bornes interactives OSCAR, qui peuvent valider les requêtes après lecture de la carte CAMIPRO de la personne requérante. La signature effective des certificats ne représente plus alors que quelques minutes de travail par jour.

Choix de la CA pour l 'EPFL

On voit donc que deux voies sont possibles pour fournir ce maillon manquant dans le système de sécurisation des applications sur le réseau de l'EPFL:

C'est aussi la première conclusion tirée du Workshop organisé par Switch en novembre dernier (voir http://www.switch.ch/aai/ws2000/ où l'on trouvera toutes les présentations, y compris celle de l'EPFL). Switch souhaite en effet homogénéiser les mécanismes d'identification des personnes appartenant au domaine académique en Suisse, faute de standardisation sur une échelle plus globale, comme une prise en charge par l'Etat par exemple.

Ces travaux étant toujours préliminaires, et en l'absence de toute prise de position politique, la Commission Technique Informatique de l'EPFL a récemment adopté la proposition du SIC de répondre sans retard aux besoins de sécurisation de notre site en exploitant notre CA (Certification Autorithy) locale. En effet:

En pratique, comment puis-je obtenir un certi ficat de l 'EPFL?

On trouvera les détails de la procédure et toutes les références utiles à une compréhension complète des mécanismes mis en jeu à l'adresse magique: cognac.epfl.ch/CA.

Pour résumer

Page d'accueil initiale de GASPAR, permettant de vérifier votre identité en l'absence de certificat Vous avez demandé l'accès aux prestations sécurisées et pami celles-ci sélectionné «demande de certificat». Vous avez cliqué sur «envoyer la demande». Vous êtes informé par e-mail que votre certificat a été crée et transmis à GASPAR
Vous vous êtes précipité vers GASPAR qui vous propose d'installer le certificat dans votre browser. Il suffit pour cela de cliquer sur «installation» comme indiqué Votre nouveau certificat figure maintenant dans la liste des certificats connus par votre browser Vous voulez accéder à un serveur Web authentifié à l'aide d'un certificat de l'EPFL. Voici comment il se présente, avec son «fingerprint» Vous avez accepté l'Autorité de certification de l'EPFL, et elle figure désormais dans la liste des CA connues de votre browser

Comment utiliser les certi ficats pour accéder à un serveur sécurisé?

Le protocole HTTPS utilise les fonctions offertes par SSL pour établir une connexion sécurisée entre le serveur et le client. Si le serveur est à l'EPFL et est certifié par la CA de l'EPFL, le client doit d'abord confirmer qu'il accepte cette CA, à moins qu'il l'ait définitivement reconnue selon la procédure décrite à l'adresse: cognac.epfl.ch/CA/cacert.html . Le serveur reconnaîtra à son tour la validité du certificat du client, et donc son identité. Le certificat joue ainsi un peu le rôle d'un cookie qui donne un accès personnalisé au serveur sans que l'utilisateur doive décliner son identité et son mot de passe. Lors de cette connexion, toutes les données échangées seront alors implicitement cryptées.

HTTPS et SSL étant des protocoles standardisés, Netscape et Internet Explorer sont censés se comporter exactement de la même façon. C'est effectivement le cas sous Windows, mais pas sur MacOS, où MS-Internet Explorer refuse de reconnaître le certificat des serveurs de l'EPFL, bien que ceux-ci soient totalement conformes aux spécifications X.509.

Comment utiliser les certi ficats pour échanger du courrier sécurisé?

Les principales application de mail utilisées à l'Ecole sont Netscape Communicator, Outlook (Express) et Eudora. Les deux premières ne nous posent aucun problème, car elles utilisent de façon native le protocole S/MIME pour la sécurisation de l'échange de messages (pour une explication détaillée, voir: http://ww.rsasecurity.com/standards/smime/faq.html). Eudora ne fournit malheureusement pas ces fonctionnalités. Il existe plusieurs produits commerciaux permettant de combler cette lacune sous forme d'un plug-in ajouté à l'Eudora de base, notamment le MailSecure de Baltimore Technologies ( http://www.baltimore.ie/products/mailsecure/). Le SIC pourra vous procurer ces plug-ins en cas de nécessité.

Le principe de S/MIME est le suivant

PGP (Pretty Good Privacy)

Il s'agit d'une alternative à S/MIME, développée depuis longtemps déjà par le célèbre Philippe Zimmerman, et disponible gratuitement depuis le site http://www.pgp.com . Cet accès libre valut d'ailleurs de gros problèmes à son auteur, qui fut poursuivi pour infraction aux lois limitant les exportations d'armes et de munitions par la justice américaine.

A part les détails d'implémentation, principalement au niveau des formats de stockage, le principe général des versions modernes de PGP est similaire à celui de S/MIME: PGPkeys crée une paire de clés stockées dans l'application, et optionnellement publie la clé publique à l'aide d'un annuaire accessible depuis l'application PGP. La différence fondamentale se situe au niveau de la validation des clés publiques: il n'y a pas de CA prévue, ni donc de certificats d'authenticité. Il n'y a donc a priori pas de garantie que les clés publiques découvertes sur un serveur ou obtenues par e-mail soient authentiques. C'est au propriétaire de la clé publique, ou à une autre personne considérée comme fiable, d'en confirmer la validité.

Cette caractéristique peut être considérée comme positive si l'on est un peu paranoïaque et que l'on veut éviter toute mainmise de big brother sur les CA, ou comme négative si l'on souhaite une sécurité maximum tout en évitant des contrôles fastidieux d'authenticité des clés. A vous de juger

L'option PGP étant celle des grands garçons et des grandes filles qui se débrouillent sans aide, le SIC ne supporte actuellement que l'option S/MIME.


retour au sommaire du Flash informatique du mois de mai 1
retour à la page principale des Flash informatique
Vos commentaires
© FI-5-1 du 22 mai 1