Certificats (lectroniques) Pourquoi ? Comment ?

Jean-Luc Archimbaud CNRS/UREC [jla] 22 dcembre 2000 (V3)

Ce document est disponible en ligne (avec une version peut-tre plus rcente) : http://www.urec.cnrs.fr/securite/articles/certificats.kezako.pdf De nombreux articles ont dj t crits au sujet des certificats, des autorits de certification, des infrastructures de gestion de cls, [Articles UREC]. Les uns sont techniques et supposent que le lecteur connat dj tous les mcanismes sous-jacents. Ils sadressent plutt aux spcialistes du domaine. Les autres, loppos, dcrivent les applications et les nouvelles fonctionnalits quapportent les certificats mais ne parlent ni des principes, ni de lenvironnement ncessaire. Comme toutes les nouveauts plutt complexes, ce domaine demande tre prsent sous plusieurs clairages. On tente ici un autre angle dapproche. Cet article essaie de rpondre de manire simple aux questions que peuvent se poser les personnes qui dsirent comprendre le sujet sans se plonger dans les dtails. Ce sont les dcideurs qui vont dfinir la manire dintroduire ces objets dans leur administration ou leur entreprise, les ingnieurs qui vont les mettre en place mais aussi les utilisateurs clairs qui veulent les utiliser bon escient. Il devrait rpondre deux questions : comment a marche ? A quoi a sert ? Les certificats sont la base des outils de scurit. Mal compris, mal conus, mal administrs, mal utiliss, ils peuvent donner un leurre de scurit sans en ajouter aucune, voire au contraire simplifier la vie des pirates. Donc le comment a marche ? est important pour tous les dcideurs et tous informaticiens qui les installeront et qui formeront les utilisateurs. Cet article tente donc dclairer le lecteur sur les principes des certificats et des mcanismes associs leur utilisation, des utilisations possibles de ces certificats, des infrastructures mettre en place pour les grer, des applications actuelles qui peuvent les utiliser, mais aussi des limites de tout cet ensemble. Ce document nest pas destin aux spcialistes de scurit et simplifie volontairement certains points pour les rendre plus accessibles tous.

(NDLR : Attention, le sujet nest pas trivial. Si vous ne vous tes jamais pench sur ces mcanismes et que vous comprenez sans effort lintgralit, bravo !).

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

1. Dfinitions des services de base en scurit

Dans ce document certains termes de scurit [Glossary] seront trs souvent utiliss. Il est ncessaire de les dfinir avec le sens dans lequel ils seront employs. Lauthentification est lassurance de lidentit dun objet, gnralement une personne, mais cela peut aussi sappliquer un serveur, une application, Dans la vie courante, la prsentation de la carte nationale didentit et la signature manuelle assurent un service dauthentification. Lintgrit dun objet (document, fichier, message ) est la garantie que cet objet na pas t modifi par une autre personne que son auteur. Sur une feuille de papier toute modification est visible dun simple coup dil. Sur un document lectronique (courrier lectronique, fichier Word, ) non scuris, cette dtection est impossible. Sur les documents lectroniques, la signature lectronique est un des mcanismes qui permet dassurer lauthentification de lmetteur et lintgrit de lobjet transmis. La confidentialit est lassurance quun document ne sera pas lu par un tiers qui nen a pas le droit. Les documents papiers qui doivent rester secrets sont gnralement stocks dans des coffres et sont transports sous plis cachets. Sur les documents lectroniques, le chiffrement permet dassurer la confidentialit. Une quatrime fonction de scurit est appele non rpudiation . Comme ce terme lindique, le but est que lmetteur dun message ne puisse pas nier lavoir envoy et le rcepteur lavoir reu. Les transactions commerciales ont absolument besoin de cette fonction. Le reu que lon signe au livreur, la lettre recommande sont des mcanismes de non rpudiation. Les certificats permettent dassurer ce service. Dans la communaut enseignement-recherche, cette fonction nest pas primordiale si ce nest pour certains actes administratifs (votes, notations, transferts de crdits, ). Pour allger le nombre de pages, nous ne dvelopperons pas cette fonction dans cet article. Ces besoins ont toujours exist pour les documents papier . Pourquoi y a-t-il un nouveau problme ? La nouveaut est que les documents manipuls sont maintenant lectroniques, ils se prsentent sous forme de fichiers stocks sur des ordinateurs. Situation aggravante pour la scurit, ils circulent en clair sur les rseaux informatiques. Or il est techniquement possible, pour une personne mal intentionne vis vis dune autre personne, daccder aux fichiers de celle-ci sur son poste de travail pour les lire ou les modifier, dcouter ses communications Internet ou Intranet, ... Si des protections nont pas t installes et certaines prcautions prises, ces infractions sont mme simples raliser. Il a donc t ncessaire de crer un ensemble de mcanismes pour assurer les 4 fonctions de scurit sur les documents et les nouveaux modes de communication lectroniques. Ceux-ci peuvent reposer sur les certificats. Noublions pas le dernier terme prfr du spcialiste scurit : le contrle daccs . On regroupe sous ce vocable, les mcanismes logiciels ou matriels qui permettent dautoriser ou pas laccs diffrentes ressources (messages, fichiers, bases de donnes, applications, machines, rseaux, ). Laccs peut tre autoris ou non suivant lutilisateur, la machine de lutilisateur, le rseau de lutilisateur, Les mcanismes de contrle daccs sont ainsi trs divers ; pour la scurit physique : serrure, lecteur de badge, ; pour la scurit logique : filtres dans les quipements de communication pour laisser passer ou non certains trafics rseau, mot de passe, carte puce, L aussi les certificats peuvent simplifier ces mcanismes. (NDLR : pour linstant cest plutt simpliste comme article)
Certificats (lectroniques) : Pourquoi ? Comment ? JL Archimbaud CNRS/UREC 2

2. Quelques lacunes des applications rseau actuelles

Si lon prend comme exemple le CNRS [CNRS], les 1300 laboratoires de cet organisme sont connects lInternet par Renater [Renater]. Nanmoins, toutes les communications qui pourraient emprunter cet outil trs performant et conomique, en particulier celles avec un caractre officiel, ne passent pas par le rseau. Pourquoi ? Prenons quelques exemples, dans les applications de gestion mais aussi dans linformatique scientifique. Au CNRS, la diffusion des notes officielles se fait uniquement sous forme papier, via le courrier postal. Pourquoi, alors que chaque directeur dunit et mme chaque personnel a une adresse lectronique ? Simplement parce que les applications de messagerie couramment utilises au CNRS, qui sont celles utilises dans lInternet, nassurent aucune des 4 fonctions de base de scurit : lauthentification de lmetteur du message, lintgrit et la confidentialit du message transmis, la non-rpudiation. Il est ainsi trs facile de se faire passer pour quelquun dautre et dmettre un message en prenant son identit. Cette grave lacune est connue, mais chaque agent CNRS utilise nanmoins la messagerie lectronique, loutil est vraiment trop pratique. Dans un usage courrant, il y a peu de risque dusurpation didentit car pour un pirate le jeu nen vaut pas la chandelle. Mais on ne peut pas prendre ce risque avec les documents officiels signs par le directeur gnral ou par un dlgu rgional. Ce serait de linconscience. Les notes officielles ne demandent gnralement que lauthentification de lmetteur, la signature, et lintgrit du contenu comme services de scurit. Dautres documents pourraient circuler sur le rseau si on pouvait garantir en plus la confidentialit. Ce sont par exemple les documents utiliss pour les lections , les notations et plus globalement la gestion du personnel et la gestion financire . Actuellement la transmission de ces documents se fait videmment par courrier postal. Comme tout organisme, la gestion du CNRS repose sur de nombreuses applications de gestion (financire, comptable, ). Chaque application a son propre contrle daccs, souvent avec un compte et un mot de passe pour chaque utilisateur. Ce systme est lourd car il multiplie ladministration des comptes par le nombre dapplications de gestion. Il engendre aussi une grosse faille en scurit. En effet, beaucoup de gestionnaires accdent plusieurs applications et doivent donc se souvenir de plusieurs mots de passe. De peur de les oublier, ils notent ces mots de passe prs de leur poste de travail avec les dangers que cela reprsente. Une des caractristiques du CNRS est dtre un organisme ouvert au sens o il est form dunits de recherche propres, uniquement CNRS, mais surtout de nombreuses units associes (aux universits, autres organismes de recherche, ). Il est ainsi impossible de dlimiter le contour gographique prcis du CNRS et de construire un rseau priv informatique regroupant tous les ordinateurs du CNRS , comme le font les entreprises dans leur Intranet. Dans lIntranet dune entreprise toutes les machines sont facilement identifiables. Elles sont numrotes (avec une adresse IP) dans des intervalles connus (les adresses de rseau) et nommes avec un suffixe identique (le nom de domaine). Cet Intranet est connect avec lInternet en un ou deux points avec des contrles daccs trs stricts. Dans cette configuration il est trs simple de limiter les accs des informations (pages Web, bases de donnes, logiciels, ). Il suffit de vrifier ladresse IP ou le nom des machines qui essaient dy accder. Au CNRS les machines sont numrotes dans des plages dadresses trs varies qui souvent appartiennent aux universits et des noms aussi trs divers, souvent des domaines

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

universitaires. Le suffixe cnrs.fr est utilis uniquement par les services administratifs et certaines units propres. Il ne peut pas en tre autrement daprs la dfinition des units associes et la technologie Internet. Ainsi le CNRS est priv de toutes les possibilits dun Intranet : Il est impossible de mettre sur des serveurs Web des informations rserves aux agents CNRS car on ne sait pas en restreindre laccs ceux-ci. Dans les entreprises, le contrle daccs simple avec un Intranet est utilis pour la diffusion de logiciels achets avec une licence entreprise ou pour contrler laccs des bases de donnes payantes. Au CNRS, sans Intranet, il faut par exemple refaire un contrle avec le nom dutilisateur et son mot de passe pour la diffusion de logiciels achets via le ministre MENRT, de mme pour laccs via lInstitut de lInformation Scientifique et Technique (INIST) aux publications scientifiques en ligne de lditeur ELSEVIER. Dans les deux cas, le CNRS est li par un contrat qui limite lutilisation ou laccs son personnel. Il faut donc quil mette en place les contrles ncessaires pour respecter ses engagements. Il est trs difficile de crer sur des serveurs des espaces de libres changes lectroniques de documents pour des groupes de travail ou des communauts

Sur un autre registre, un problme perdure depuis longtemps : la transmission du mot de passe en clair sur le rseau. Ainsi de nombreux chercheurs en mission lextrieur et qui se sont connects sur une machine de leur laboratoire ont eu leur mot de passe dcouvert par des pirates qui avaient install des logiciels dcoute sur le rseau local de leur lieu de mission. Ce mot de passe sert ensuite au pirate se connecter sur la machine du chercheur. La parade est de trouver une authentification des utilisateurs diffrente du simple mot de passe ou de faire circuler celui-ci chiffr sur le rseau, mais elle demande des logiciels spcifiques. Une nouvelle fonctionnalit de scurit apparat maintenant comme une priorit dans les projets CNRS de grilles de calcul et de donnes [Datagrid] qui visent construire une toile plantaire regroupant des capacits de calcul, de mmoire, de stockage, de visualisation de donnes, ... Ces projets vont ncessiter des contrles daccs labors que lon ne sait pas rsoudre actuellement. Ces projets prfigurent certainement de nombreuses autres applications distribues qui demanderont toute personne dun laboratoire CNRS de pouvoir sauthentifier. On pourrait trouver une solution sur mesure chacun des problmes ci-dessus. Mais chacune ne rsoudrait quun seul problme tout en tant grosse consommatrice de ressources humaines pour la mise en place et ladministration. Une autre stratgie est davoir une fondation commune qui va permettre de combler toutes ces lacunes. Ce sont les certificats. (NDLR : Le chapitre 7 dveloppe comment ceci va tre possible).

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

3. Chiffrement, empreinte, signature, certificats : principes

Ce paragraphe tente dexpliquer simplement, les mcanismes logiques qui permettent de raliser les fonctions de scurit : authentification, intgrit, confidentialit, avec des certificats. Il est destin aux personnes qui ne connaissent pas le domaine de la scurit informatique.

3.1 Chiffrement
Pour assurer la confidentialit dun document lectronique, on chiffre le texte du document. Cette opration consiste appliquer une fonction mathmatique (en fait cest un ensemble de fonctions) avec des caractristiques trs particulires sur le texte. Cette fonction utilise une variable, la cl de chiffrement, qui est une suite de bits quelconque. Une fois le texte chiffr, il est illisible. Pour obtenir la version lisible, il faut le dchiffrer, cest dire appliquer une autre fonction mathmatique, compatible avec la premire, avec une autre variable, la cl de dchiffrement. Ces 2 fonctions mathmatiques sont appeles algorithmes de chiffrement. La valeur de la cl de dchiffrement dpend videmment de la valeur de la cl de chiffrement et uniquement le possesseur de la cl de dchiffrement peut dchiffrer le texte. Lorsque lon dsire transmettre un document confidentiel un correspondant travers le rseau, on chiffre le document sur son poste de travail avec une cl de chiffrement et on envoie la version chiffre. Le destinataire dchiffre le document sur son poste de travail avec la cl de dchiffrement, quil est le seul connatre. Si une troisime personne intercepte le texte durant le transfert, il ne pourra pas le dchiffrer car il ne connatra pas la valeur de la cl de dchiffrement. Il faut noter que les algorithmes de chiffrement, cest dire les formules mathmatiques, sont publics et ont fait lobjet de standardisation. Cest le secret de certaines cls qui permet ces algorithmes dassurer le service de confidentialit. Voici les tapes de la transmission dun texte confidentiel de Philippe Nicole.
Cl de chiffrement

TE TEX ir cla en

Algorithme de chiffrement

Philippe

Internet

TE TEX ir cla en

Algorithme de dchiffrement

Nicole
Cl de dchiffrement

Figure 1 : chiffrement

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

Il y a deux grandes familles dalgorithmes de chiffrement : symtriques et asymtriques.

3.1.1 Algorithmes symtriques

Dans les algorithmes symtriques, aussi appels algorithmes cl secrte, la cl de chiffrement est la mme que la cl de dchiffrement. De ce fait, pour que le texte chiffr ne soit lisible que par le destinataire, la valeur de cette cl doit tre un secret partag entre lmetteur et le destinataire uniquement. Ceci explique le qualificatif de cl secrte . DES [DES] est lalgorithme symtrique historiquement le plus connu. Il utilise des cls (de chiffrement et de dchiffrement) qui font 56 bits (cest la taille rellement utilise). Une version amliore, qui le remplace maintenant, Triple DES [Triple DES] utilise des cls de 112 bits. Le prochain se nommera peut-tre Advanced Encryption Standard [AES]. Les premiers algorithmes symtriques datent de la fin des annes 70 et utilisent des fonctions mathmatiques simples . Lavantage est que les oprations de chiffrement et de dchiffrement sont rapides excuter sur des ordinateurs classiques. Par contre, le problme est la gestion des cls. En effet, chaque cl que lon utilise avec un correspondant doit tre secrte et unique. On a donc autant de cls que de correspondants et il faut trouver un moyen dchanger chaque cl secrte avec chaque correspondant de manire sre (pas question dutiliser le fax du secrtariat ou la messagerie lectronique non scurise). Si ceci est possible entre un groupe restreint de personnes, cest impossible plus grande chelle, par exemple pour changer des messages chiffrs avec tous nos correspondants sur lInternet.

3.1.2 Algorithmes asymtriques

Lautre ensemble dalgorithmes sont les algorithmes asymtriques ou cl publique. Ils ont t conus pour utiliser des cls qui possdent plusieurs proprits: La cl de chiffrement est diffrente de la cl de dchiffrement (do le terme asymtrique). Les 2 cls (une pour chiffrer, lautre pour dchiffrer) sont cres ensembles avec une fonction mathmatique. Elles forment un couple, lune ne va pas sans lautre, mais il est impossible avec une des cls de dcouvrir lautre. Tout texte chiffr avec une des cls (de chiffrement ou de dchiffrement) peut tre dchiffr avec lautre cl (de dchiffrement ou de chiffrement) et uniquement avec celle-ci. En pratique, pour utiliser ces algorithmes, il faut gnrer un couple de cls (lune pour chiffrer, lautre dchiffrer) pour chaque utilisateur. La personne le fera elle-mme sur sa machine ou quelquun de confiance le fera pour elle. Elle gardera sa cl de dchiffrement secrte, on lappellera ainsi cl prive. A linverse e rentra sa cl de chiffrement publique et lle la diffusera (on dit aussi la publiera) le plus largement possible. On la trouvera dans des annuaires lectroniques par exemple. Ainsi le couple de cls est form dune cl prive secrte pour dchiffrer et dune cl publique pour chiffrer. Maintenant quand Philippe voudra par exemple envoyer un message chiffr avec un algorithme asymtrique Nicole, son outil de messagerie cherchera dans un premier temps la cl publique de Nicole. Loutil interrogera un annuaire lectronique pour trouver cette cl. Layant trouve, il conservera sa valeur dans un rpertoire local pour les utilisations futures. Ensuite loutil chiffrera le texte du message avec la cl publique de Nicole. Ce texte illisible ne pourra alors tre dchiffr quavec la cl prive de Nicole, que Nicole est la seule connatre. Ainsi le message pourra transiter via le rseau sans risque dtre dchiffr. Arriv sur lordinateur de Nicole, le texte sera dchiffr avec la cl prive de Nicole. (NDLR : si, si, ce nest pas magique, cest logique et a marche)

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

Voici comme exemple, lmission par Philippe dun texte chiffr Nicole avec un algorithme de chiffrement asymtrique.
Cl publique de Nicole

E TEXT ir la en c

Chiffrement asymtrique

Philippe

Internet

TE TEX ir la en c

Dchiffrement asymtrique

Nicole
Cl prive de Nicole

Figure 2 : chiffrement avec algorithme asymtrique Dans lautre sens, quand Nicole enverra un texte chiffr Philippe elle le chiffrera avec la cl publique de Philippe. Celui-ci le dchiffrera avec sa cl prive. RSA [RSA], du nom des 3 inventeurs Rivest, Shamir, Adleman, est lalgorithme de chiffrement asymtrique le plus rpandu. Ce dcouplage entre cl publique et cl prive est trs utile pour une utilisation plantaire du chiffrement. Alors que les algorithmes symtriques obligent changer un secret, la cl secrte, avec chaque interlocuteur, l il suffit davoir un annuaire qui permette de trouver la cl publique de chaque internaute et ce systme peut fonctionner entre tous les internautes. Quand un utilisateur voudra envoyer un message chiffr un correspondant, il consultera lannuaire qui lui indiquera la cl publique de son correspondant. Avec cette cl, il chiffrera le message. Celui-ci ne pourra tre dchiffr quavec la cl prive du correspondant, donc que par le correspondant. Ainsi les proprits des algorithmes asymtriques, sans intrt au premier abord, vont permettre de saffranchir du problme de la gestion des cls et ainsi denvisager de dployer lutilisation du chiffrement trs grande chelle. Mais il reste un problme. Avec les algorithmes asymtriques, le temps pour les oprations de chiffrement et de dchiffrement est long. Ainsi sur un ordinateur courant, RSA (algorithme asymtrique) est de 100 1000 fois plus lent que le Triple DES (algorithme symtrique). La cl de session est un moyen pour attnuer ces mauvaises performances.

3.1.3 Cl de session
Pour entre autre, contourner les trs mauvaises performances en temps de traitement des algorithmes asymtriques, une astuce est couramment utilise dans les logiciels. Elle consiste

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

 utiliser les deux types de chiffrement, asymtrique et symtrique, lors du mme transmission. Pour envoyer un message chiffr, le programme metteur ne chiffrera pas le message complet avec un algorithme asymtrique. Il chiffrera en asymtrique, avec la cl publique du destinataire, uniquement un petit nombre alatoire (quelques dizaines de caractres) choisi par lui. Ce nombre servira de cl secrte qui sera utilise pour chiffrer de manire symtrique le texte. A larrive, le programme du destinataire dchiffrera cette cl secrte, chiffre en asymtrique , avec sa cl prive. Munie de la cl scrte ainsi dchiffre, il dchiffrera ensuite le message, chiffr en symtrique . Dans ce processus, lalgorithme asymtrique nest utilis que sur quelques dizaines de caractres, cette opration sera donc relativement rapide. Le message, q peut tre un fichier ui de plusieurs gigabytes, sera lui chiffr et dchiffr avec un algorithme symtrique. Le temps de traitement de lensemble sera donc du mme ordre que si lon avait utilis que du chiffrement symtrique. Dautre part, lintroduction du chiffrement asymtrique permet de saffranchir du problme de la gestion de la cl secrte des algorithmes symtriques. En effet cette cl secrte na pas besoin dtre connue avant la communication par le destinataire. Elle est choisie par lmetteur et le destinataire en prend connaissance en dchiffrant une partie de ce quil a reu. Ce processus a deux tapes est employ par les outils scuriss de messagerie, transfert de fichiers, navigation, La cl secrte ne servant que pour lopration en cours, est appele cl de session. Au prochain transfert le programme de lmetteur choisira une autre cl de session. Un intrus qui rcupre le document chiffr ne pourra pas dchiffrer la cl de session car il ne possde pas la cl prive du destinataire ; et sans cette cl de session, il ne pourra pas dchiffrer le texte du message. Exemple de transfert dun texte chiffr avec utilisation dune cl de session.
Cl publique de Nicole Cl de session Chiffrement
asymtrique

n Ee EXT ir T cla

TE TEX ir cla en

Chiffrement symtrique

n Ee EXT ir T cla

Internet

Philippe
Cl prive de Nicole Cl de session
Dchiffrement asymtrique

TE TEX ir la en c

Dchiffrement symtrique

n Ee EXT ir T cla

Nicole

Figure 3 : chiffrement avec cl de session (NDLR : une petite pause aprs la lecture de ce schma ?)

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

3.1.4 Longueur des cls

De nombreuses techniques ont t imagines pour essayer de dchiffrer un document chiffr sans connatre la cl de dchiffrement. Lopration sappelle dcrypter (bien que souvent par abus de langage dcrypter soit utilis la place de dchiffrer). Les militaires ont t traditionnellement les spcialistes dans ce domaine, le but tant dintercepter les transmissions chiffres de ladversaire et dessayer de les dcrypter. Il faut aussi savoir que le dcryptage est thoriquement toujours possible. Ce qui le rend en pratique trs difficile, voire impossible, est le temps qui est ncessaire pour arriver dcrypter un document chiffr. Si on disposait dordinateurs ultra rapides avec une puissance de calcul illimite , tous les textes chiffrs pourraient tre dcrypts. Mais ce nest pas le cas. Dautre part, plus la longueur (nombre de bits) de la cl est grande plus il est difficile de dcrypter un texte chiffr (concrtement il faut plus de temps de calcul) avec un algorithme de chiffrement solide (il faut aussi que lalgorithme soit mathmatiquement bon). La puissance des machines augmentant, pour garantir cette impossibilit de dcryptage, on utilise des cls de longueur de plus en plus grande. La lgislation franaise [Dcrets chiffrement] sest ainsi adapte pour autoriser lutilisation des produits de chiffrement avec des cls plus longues, de manire ce que lon puisse utiliser des produits relativement surs. La longueur de cl autorise pour une utilisation libre dun produit de chiffrement est passe en mars 1999 de 40 128 bits.

3.2 Signature lectronique

Les paragraphes prcdents ont dcrit comment est assure la fonction de confidentialit avec le mcanisme de chiffrement. La signature lectronique est un des mcanismes qui permettent dassurer les fonctions dauthentification et dintgrit. Il est utilis en particulier dans la messagerie lectronique. Pour gnrer une signature lectronique, il faut dans un premier temps utiliser une fonction de hachage. Cest une fonction mathmatique qui partir dun texte de nimporte quelle longueur gnre un nombre, suite de bits de taille fixe, bien infrieure la taille du texte initial. Cette fonction est telle que si un bit du texte dorigine est modifi, le rsultat de la fonction sera diffrent. Cette suite de bits est ainsi appele condens ou empreinte. MD5 (MD pour Message Digest) est une fonction de hachage trs rpandue, elle cre une empreinte de 128 bits [MD5]. SHA (Secure Hash Algorithm), autre fonction, cre des empreintes de 160 bits [SHA]. Avant denvoyer le message, loutil logiciel metteur calcule lempreinte du message, rsultat dune fonction de hachage applique au message. Il chiffre ensuite cette empreinte par un algorithme asymtrique avec sa cl prive. Ce rsultat est appel signature lectronique. Avant lenvoi, cette signature est ajoute au message, qui devient un message sign. Le logiciel du destinataire qui reoit lensemble dchiffre cette empreinte chiffre avec la cl publique de lmetteur. Puis il recalcule la fonction de hachage sur le message reu et compare le rsultat avec lempreinte dchiffre. Si les deux sont gaux, cela veut dire que le message na pas t modifi durant le transfert et que lmetteur est authentifi. En effet, si le message a t modifi, les 2 empreintes seront diffrentes. De plus, tre capable de dchiffrer, avec la cl publique dune personne, une empreinte chiffre, prouve que cette empreinte a obligatoirement t chiffre avec la cl prive de la personne, cl que seul possde lmetteur. Cela authentifie donc lmetteur. On peut rappeler quune des

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

proprits du couple cl prive - cl publique est que tout ce qui est chiffr avec une des cls peut tre dchiffr avec lautre cl et uniquement avec celle-ci. (NDLR : on espre que le schma suivant sera plus clair que ces explications tordues !)
Cl prive de Philippe

TE TEX i r la en c
Fct d e ha chag e

TE TEX en r clai
Em

pre

inte

Chiffrem ent Asy m

TE TEX en r clai

Philippe
TE TEX en r clai inte re
Em p

Internet

te ein mpr E

Fct de hachage

Dc hiffr eme nt Asy m

TE TEX en r c l a i

Nicole : galit ?
Cl publique De Philippe

Figure 4 : signature Nous avons dcrit sparment les mcanismes de chiffrement et de signature. Mais les logiciels courants peuvent cumuler les deux fonctions. Ils permettent par exemple de transmettre un message chiffr et sign. Les logiciels appliqueront alors gnralement la signature avant le chiffrement lmission, et le dchiffrement puis la vrification de la signature la rception. Mais ils peuvent aussi inverser lordre de ralisation de ces oprations.

3.3 Certificats
Nous avons dcrit les mcanismes qui permettent dassurer les 3 fonctions de base de scurit avec le couple de cls privepublique et les algorithmes de chiffrement asymtriques. Mais il y a une norme lacune dans les raisonnements prcdents. On a considr quun utilisateur connaissait la cl publique dune personne simplement en consultant un annuaire ou un serveur Web ou et ainsi il la considrait comme vraie. Mais quest-ce qui garantit que la cl publique de Philippe quun utilisateur a ainsi rcupre est la bonne ? Il ne faut pas oublier que tout ceci fonctionne de manire lectronique, sur lInternet, sans contact direct donc sans moyen visuel de reconnaissance dune personne. Un pirate, Franois, a pu modifier lannuaire ou le serveur Web qui contient la cl publique de Philippe. Il a pu par exemple remplacer la cl publique de Philippe par la sienne. Une fois cette mascarade commise, Franois pourra lire les courriers confidentiels destins Philippe et signer des messages en se faisant passer pour Philippe. (NDLR : les plus assidus peuvent dcouvrir eux-mme pourquoi, les autres peuvent lire la petite explication qui suit ). Ce sera la consquence si un utilisateur, Nicole, croit dtenir la cl publique de Philippe alors que cest celle de Franois. En effet, si Nicole envoie un message chiffr Philippe, elle va le chiffrer avec la cl publique de Philippe. Si celle-ci est en fait la cl publique de Franois, alors Franois pourra dchiffrer ce message destin Philippe avec sa cl prive. Franois pourra donc lire le courrier confidentiel de Philippe.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

10

Autre possibilit, Franois pourra envoyer un message sign Nicole avec une signature gnre avec sa cl prive et en se faisant passer pour Philippe. Nicole qui recevra le message vrifiera la signature du message avec ce quelle croit tre la cl publique de Philippe. La vrification sera correcte, donc Nicole pensera que le message vient de Philippe. (NDLR : il nest pas interdit de se faire des petits schmas pour mieux comprendre ). Il a donc fallu crer un mcanisme supplmentaire, le certificat lectronique, pour assurer la validit de la cl publique. Un certificat est lquivalent dune carte didentit ou dun passeport. Un passeport contient des informations concernant son propritaire (nom, prnom, adresse, ), la signature manuscrite, la date de validit, ainsi quun tampon et une prsentation (forme, couleur, papier) qui permettent de reconnatre que ce passeport nest pas un faux, quil a t dlivr par une autorit bien connue. Un certificat lectronique contient des informations quivalentes. Le format reconnu actuellement est le format X509V3 [X509V3]. (NDLR : lexplication du nom nous conduirait une poque que les moins de quarante ans ne peuvent pas connatre) Cest un petit fichier, qui contient au moins les informations suivantes :

Le nom de lautorit (de certification) qui a cr le certificat Le nom et le prnom de la personne Son entreprise (CNRS par exemple) Son service (au CNRS, le nom du laboratoire) Son adresse lectronique Sa cl publique Les dates de validit du certificat Des informations optionnelles Une signature lectronique Cette signature lectronique est calcule sur les informations contenues dans le certificat comme dans le cas dun message lectronique explicit ci-avant. La signature est lempreinte de ces informations chiffre avec la cl prive de lautorit de certification qui a dlivr ce certificat. Quest-ce quune autorit de certification ? Lquivalent de la prfecture pour un passeport. Cest une entit, structure technique et administrative, qui dlivre des certificats. Le chapitre 4 explicitera en dtails comment tout ceci fonctionne. Dans limmdiat, pour notre comprhension, on peut considrer que pour un organisme comme le CNRS, lautorit de certification est un service du CNRS qui dlivre des certificats aux personnes qui travaillent dans les laboratoires CNRS. Ce service a, pralablement toute action, gnr un couple de cls publique-prive pour lui-mme. Ensuite il a trs largement diffus la valeur de sa cl publique pour que tous les agents CNRS en aient connaissance. Concrtement, tous les programmes qui ont des fonctions de scurit sur les postes informatiques des laboratoires CNRS ont t configurs avec la cl publique de lautorit de certification CNRS en mmoire. Dans un troisime temps ce service peut alors commencer crer et dlivrer des certificats aux personnels des laboratoires, certificats signs avec la cl prive de lautorit de certification CNRS.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

11

Paralllement, les annuaires lectroniques CNRS accessibles par lInternet, sont mis jour pour contenir le certificat de chaque personnel. Quand Nicole veut communiquer de manire scurise avec Philippe qui travaille dans un laboratoire CNRS, par exemple lorsquelle veut lui envoyer un message chiffr, le logiciel de messagerie de Nicole a besoin de connatre la cl publique de Philippe. Si ce logiciel ne connat pas cette cl, il peut interroger lannuaire lectronique du CNRS pour rcuprer le certificat de Philippe. Ce certificat est sign par lautorit de certification CNRS. Le poste de Nicole contenant en mmoire la cl publique de cette autorit de certification, le logiciel de messagerie peut vrifier la signature de ce certificat pour sassurer que ce document a bien t cr par lautorit de certification CNRS et na pas t modifi. Avec cette assurance, le logiciel de messagerie peut rcuprer la cl publique de Philippe contenue dans ce certificat et lutiliser avec confiance. (NDLR : vous pouvez relire ce paragraphe plusieurs fois, faire une petite pause, ventuellement prendre un remontant ) . Voici schmatiquement la vrification du certificat de Philippe Cale avec extraction de la cl publique de ce dernier. Certificat de P. Cale
Autorit de certification : CNRS Prnom : Philippe Nom : Cale Organisation : CNRS Service : UREC Email : Philippe.Cale@urec.cnrs.fr Dates de validit : Du 11/08/00 au 11/08/01 Cl publique : A7:3F:F4::E1 . Signature : 7C:C1:55::C7

Fct de hachage

Empreinte 1

Certificat valide Certificat non invalide

Cl publique de lautorit de certification CNRS

Egalit ?

oui

Cl publique de P. Cale : A7:3F:F4::E1

Dchiffrement

Empreinte 2

Figure 5 : vrification de certificat rcupration de la cl publique Evidemment, les dates de validit du certificat sont aussi vrifies avant de le dclarer valide.

3.4 Annuaires
Comme nous lavons dj montr, il est ncessaire de connatre le certificat de son correspondant (qui renferme sa cl publique), pour communiquer de manire scurise avec lui. Les outils informatiques scuriss stockent les certificats quils utilisent (voir au chapitre 6, lexemple de Netscape). Ainsi ils nont besoin dobtenir le certificat dune personne quune seule fois. Ils intgrent aussi des mcanismes qui transmettent les certificats automatiquement. Si Philippe envoie un message sign Nicole, son outil de messagerie scuris enverra en mme temps le certificat de Philippe. Loutil de messagerie de Nicole le

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

12

rcuprera avec le message envoy et le stockera. Donc aprs quelques changes les outils de chaque utilisateur auront les certificats des principaux correspondants des utilisateurs. Nanmoins, on peut avoir besoin de communiquer avec des personnes avec lesquelles on na jamais chang. Pour cela il faut un annuaire. Ce besoin dannuaire est encore plus fondamental pour tous les serveurs rseaux (serveurs Web par exemple) qui voudront contrler les certificats des utilisateurs qui les accdent. Il est prfrable quils se rfrent une mme base dinformations jour qui contienne les certificats, un annuaire, au lieu que chaque serveur gre sa propre base de donnes locale de certificats. Le standard dannuaire reconnu et implment par les principaux outils est maintenant LDAP, Light Directory Access Protocol [LDAP]. Il intgre en standard dans le format de ses enregistrements un champ destin contenir les certificats dune personne. Il y a donc tous les lments ncessaires pour diffuser les certificats sur lInternet. Le chapitre 4 reviendra sur la mise en place dannuaires LDAP

3.5 Extension de ces mcanismes

Jusqu prsent les mcanismes de scurit ont t dcrits en prenant la messagerie lectronique entre personnes comme exemple. Mais ils peuvent sappliquer et ils sont utiliss par beaucoup dautres applications et dautres objets. Une application comme un service Web peut par exemple possder un couple de cls et un certificat. Cette application prsentera ce certificat tous les utilisateurs qui y accderont. Ceux-ci pourront ainsi tre assurs quils sont bien sur le bon serveur et la bonne application. Cela parat superflu pour un serveur dinformations mais quand le serveur permet deffectuer des transactions financires ou des achats, cest obligatoire. La cl publique du service Web pourra aussi tre utilise pour chiffrer tous les changes entre le client et le serveur. Pour ce faire, des mcanismes un peu diffrents de la signature, les applications HTTPS et SSL dcrites au chapitre 5, seront mis en uvre. Plus gnralement toute application qui utilise le rseau (transfert de fichiers, accs interactif, accs des bases de donnes, calcul distribu, ) pourra avoir un certificat et utiliser les mcanismes de scurit. Dautres objets peuvent aussi avoir des certificats. Ce sont les ordinateurs, les quipements rseau (routeurs ), les groupes de personnes, les listes de diffusion par exemple.

4. Autorit de certification et infrastructure de gestion de cls

Les mcanismes dcrits ci-avant utilisent des certificats. Mais o peut-on les acqurir ? Qui les cre ? Avec quelles informations ? Comment sont-ils grs ? (NDLR : un problme est peine rsolu que de nouvelles questions arrivent. Y aura-t-il une fin ?)

4.1 Quelle autorit de certification ?

De mme quune carte didentit ou quun passeport, un certificat est dlivr par une autorit, que lon qualifie de certification . Mais on est dans le monde de lInternet o tout est lectronique et plantaire, sans frontire ni gouvernement. Ainsi, techniquement, cette autorit peut tre nimporte quelle association, socit, organisme, individu, ... Actuellement il nexiste pas de gouvernement qui

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

13

dlivre des certificats, ni dorganisations structures et indpendantes comme celles qui affectent les numros IP ou les noms de domaine. Par contre de nombreuses socits commerciales se sont dj lances dans ce commerce qui sannonce trs lucratif. Ce sont elles qui vendent les certificats. La confiance que lon accordera un certificat va dpendre du srieux de lautorit qui laura dlivr. De plus, on voit trs bien le risque encouru par une entreprise ou un organisme dont la carte didentit des employs aurait t cre par une autorit ni habilite, ni contrle par elle-mme. Le choix de lautorit de certification dans une organisation ou une entreprise est une dcision stratgique . Le CNRS a ainsi dcid de crer sa propre autorit de certification qui pourra dlivrer des certificats toutes les personnes qui travaillent dans les units CNRS [CA CNRS].

4.2 Quelle infrastructure de gestion de cls ?

Quelle que soit lautorit de certification choisie, il faut faire dautres choix. Comme il existe un circuit de procdures et de vrifications, des personnes habilits, pour dlivrer les cartes didentit, il faut mettre lquivalent en place. Il faut ainsi dcider qui va recueillir et vrifier les informations donnes par une personne lorsquelle va demander un certificat, suivant quelles procdures, qui va crer le certificat, qui va le lui dlivrer, pour quelle dure, o va-t-il tre stock, o va-t-on pouvoir rcuprer les certificats dautres personnes, Il faut dfinir ce que lon appelle une architecture de gestion des certificats. IGC (Infrastructure de Gestion de Cls [IGC]), et PKI (Public Key Infrastructure) sont les deux sigles les plus connus pour la dsigner. Les normes internationales dcrivent les diffrents lments fonctionnels dune IGC. En simplifiant, larchitecture est constitue :

Dautorits denregistrement.

Ce sont les mairies ou les prfectures, cest dire les guichets auxquels sadressent les utilisateurs qui dsirent obtenir un certificat. Lautorit denregistrement vrifie lidentit du demandeur, sassure que celui-ci possde bien un couple de cls prive-publique et rcupre la cl publique du demandeur. Elle transmet ensuite ces informations (informations didentit du demandeur ainsi que sa cl publique) lautorit de certification. Une autorit denregistrement peut tre un secrtariat avec une personne habilite qui :

vrifie une pice didentit prsente par le demandeur (action 1 dans la figure 6 ci-

aprs)
cre un couple de cls pour lutilisateur (action 2 dans la figure 6). Ceci est ralis avec un logiciel spcifique sur un ordinateur ddi et dconnect du rseau (par prudence). remet une disquette lutilisateur qui contient la cl prive gnre (action 3) garde la cl publique de lutilisateur (action 3) transmet avec un message lectronique sign une demande de certificat (contenant les informations didentit et la cl publique du demandeur) lautorit de certification (action 4) La transmission des demandes doit se faire de manire scurise, personne ne doit pouvoir modifier la demande durant le transport par exemple. Pour ce faire, les autorits denregistrement ainsi que lautorit de certification ont des certificats et utilisent les mcanismes dauthentification, dintgrit et de confidentialit pour communiquer entre eux.

Ceci nest quun exemple de procdures, elles peuvent tre trs diffrentes selon lorganisation que lon met en place.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

14

Dune autorit de certification.

Celle-ci reoit les demandes de cration de certificats venant des autorits denregistrement. Elle vrifie la validit de la signature des messages reus, garantie de lintgrit de la demande et de lauthentification des metteurs. Elle cre les certificats et signe ces certificats en utilisant sa cl prive. Elle envoie les certificats aux utilisateurs et en parallle les transmet au service de publication. Une autorit de certification a donc un couple de cl prive-publique pour signer les certificats. Si la cl publique est le plus largement connue possible, la cl prive est au contraire ultra confidentielle et doit tre trs bien protge. Car si un tiers prend connaissance de cette cl, il pourra gnrer des faux certificats. Le travail de lautorit de certification peut tre assur par une personne habilite dun service central qui possde la cl prive de lautorit de certification ou plutt le mot de passe et la cl du coffre qui permet daccder et dutiliser cette cl. La gnration des certificats peut tre ralise par un logiciel spcifique sur un ordinateur portable entrepos dans un coffre fort. Sur cet ordinateur est aussi stocke la cl prive de lautorit de certification. La personne habilite autorit de certification reoit les demandes de certificat par messagerie lectronique sur un poste connect au rseau (action 4). A chaque demande, elle vrifie la signature lectronique de lautorit denregistrement et transfre les informations sur une disquette. Elle ouvre le coffre, dmarre lordinateur portable, insre la disquette (action 5), gnre le certificat avec une signature en utilisant la cl prive de lautorit de certification et transfre le certificat cr sur la disquette (action 6). Elle remet lordinateur dans le coffre et referme ce dernier. Avec la disquette, sur le poste connect au rseau, elle envoie par messagerie lectronique le certificat lutilisateur (action 7) et au service de publication (action 8). L encore ce nest quun exemple de procdures. Le choix et la mise au point de ces procdures, dont la description est fastidieuse (NDLR : a cest bien vrai !) est nanmoins fondamental pour la fiabilit de lensemble. Plus que les techniques de chiffrement, ce sont ces procdures qui sont un des talons dAchille des certificats. Car si ces procdures sont mal dfinies ou mal appliques, un intrus pourra par exemple semparer de la cl prive de lautorit de certification et gnrer des faux certificats qui feront crouler lensemble. Un groupe de travail inter-ministriel a dj tabli des recommandations prcises sur ces procdures qui devront tre suivies par toutes les administrations.

Dun service de publication.

Celui-ci rend disponible les certificats mis par lautorit de certification (action 9). Il publie aussi la liste des certificats valides et des certificats rvoqus (voir chapitre suivant). Concrtement ce service peut-tre rendu par un annuaire lectronique LDAP ou un serveur Web accessibles par lInternet.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

15

Autorit de certification
Demande de certificat
, , nom pr

Gnration du certificat

, nom ur : t sate ique li tori Uti publ lau l de c ure nat Sig

ent trem gis nre de

Rseau priv ou Internet

9

Annuaire LDAP

Cl publique Gnration dun couple de cls

2 8
Autorit de certification : XXX Nom : XXX Prnom : XXX . Cl publique : XXX Signature de lautorit de certification : XXX

Service de diffusion

Autorit denregistrement
1 3

Carte didentit

Cl prive
7

Certificat

Figure 6 : exemple dtapes pour la cration dun certificat (NDLR : une autre petite pause pour comprendre ce schma ?)

4.3 Dure de vie dun certificat

Lorsque lautorit de certification dlivre un certificat, celui-ci contient sa date de cration et une date de fin de validit. Gnralement, comme de nombreuses cartes professionnelles, un certificat de personne dans une entreprise a une dure de vie fixe par dfaut, un an par exemple. Si la personne est un stagiaire, un contractuel, un visiteur cette dure peut correspondre exactement la dure de sa prsence dans lentreprise. Mais cette date nest pas suffisante pour invalider un certificat dans certains cas. En effet, une personne peut quitter une entreprise ou changer de service ou se faire drober sa cl secrte. Dans ce cas il faut invalider son certificat courant. La mthode est la mme que pour les cartes bancaires. Chaque autorit de certification publie r gulirement la liste des certificats rvoqus, qui ne sont plus valides. Cette liste est gnralement dans un annuaire LDAP, accessible par le Web. Pour garantir son origine et son intgrit, elle est signe par lautorit de certification. De mme que les commerants rcuprent rgulirement la liste des cartes bancaires non valables, il faut que les outils scuriss chargent rgulirement, de manire automatique ou avec intervention de lutilisateur, cette liste de certificats rvoqus. (NDLR : ce chapitre est parfaitement clair. Est-ce normal ?)

4.4 Quelques questions et options

Lorsque lon dcide de mettre en place une Infrastructure de Gestion de Cls comme cest le cas au CNRS, il est ncessaire de rpondre de nombreuses questions fondamentales et prendre certaines options. Quelques exemples donneront une ide des problmes concrets sur lesquels il faut se pencher. Des certificats pour qui ? Se limite-t-on aux personnes rmunrs par le CNRS, les agents ? Sachant que le personnel des laboratoires nest jamais uniquement CNRS et que les autres employeurs comme les universits nont pas encore de plan pour mettre en place une IGC, ne serait ce pas trop rducteur ? Evidemment, il ne faut pas se limiter aux agents CNRS. Faut il des certificats par personne ou aussi par fonction ? Faut il plusieurs certificats par

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

16

personne ? Faut il aussi envisager des certificats pour les applications et les serveurs ? Oui, pour avoir des serveurs Web scuriss. Mais ceci ncessite une autorit denregistrement spcifique, laquelle ?
Quelle IGC mettre en place ? Certainement une autorit denregistrement dans chaque dlgation rgionale, mais quel service de la dlgation ? Faut-il une seule autorit de certification pour le CNRS ou plusieurs ? Faut-il dlivrer des certificats la demande ou doffice tout le personnel ? Quelles informations optionnelles doit contenir le certificat ? Se limiter au nom du laboratoire ou mettre le maximum dinformations : dpartement scientifique, dlgation, fonction, ? Quelle dure de validit pour un certificat ? Peut-tre un an pour le personnel permanent, pour le personnel temporaire (CDD, thsards, stagiaires, ) se limiter la fin de leur contrat ?

Comment grer la liste des certificats rvoqus ? O mettre cette liste ? Dans un annuaire LDAP ? Avec quelle priodicit la mettre jour ? Journellement ? Mais quelle dure de vie pour cette liste ? Comment les utilisateurs la rcupre-t-elle ? Avec quelle priodicit ? Assure -t-on un squestre ou une sauvegarde des cls prives ? En effet, si un utilisateur perd sa cl prive (elle est stocke dans un fichier qui donc peut tre dtruit accidentellement), il ne peut plus dchiffrer les documents quil avait chiffrs prcdemment. Il ne peut donc plus accder certains de ses propres documents. De plus une nouvelle loi demande de pouvoir fournir en cas denqute les cls prives permettant de dchiffrer certains documents. Pour ces 2 raisons il faut envisager de sauvegarder les cls prives de tous les utilisateurs. Si cest le cas, comment assure-t-on ce service ?
Des cls pour faire quoi ? En effet les experts recommandent dutiliser au moins 2 cls diffrentes : une pour signer (qui na pas besoin dtre sauvegarde) et une pour chiffrer (qui a le besoin inverse). Gnre-t-on u seul type de cl au dpart avec une seule fonction (la n signature par exemple) ? Ou les 2 types de cl ? Ou une cl multi usages ? On a besoin dun annuaire LDAP. Comment le mettre en uvre ? Doit il tre dcentralis ou centralis ? Quelles informations doit-il contenir ?

Quelles recommandations ou contraintes imposer aux utilisateurs pour quils protgent leur cl prive (ne la perdent pas, ne la divulgue pas, la protge contre le vol, ) ? Faut-il mettre en uvre des sauvegardes automatiques (ou squestre) de ces cls et des certificats ? Faut-il imposer que cette cl et le certificat soient sur une carte puce ? (NDLR : que de questions !) Rassurez vous, expliciter les rponses chacune de ces questions nest pas le sujet de cet article. Cette liste dailleurs trs incomplte ntait destine qu vous montrer que si lutilisation dun certificat parat simple et ses potentialits trs prometteuses, la mise en place de toute larchitecture est un projet denvergure . De plus, le domaine est encore mergent, lexprience est rare et parcellaire. Mais tout ceci est le problme des personnes charges de dfinir lIGC, et est totalement transparent pour lutilisateur.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

17

5. Quelques applications et standards

Regardons maintenant comment les mcanismes de scurit dcrits dans le chapitre 3 sont implments dans des applications courantes :

S/MIME pour la messagerie lectronique, HTTPS et SSL pour les communications Web, SSH et SSF pour des applications interactives, IPSec pour les communications entre quipements (de rseau ou stations).

5.1 S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions) est un standard de messagerie lectronique [S/MIME], implment entre autres par les outils de messagerie Netscape Messenger et Outlook (Internet Explorer). Un message lectronique non scuris est transport sur lInternet forme suivante (que nous avons simplifie pour une meilleure comprhension) : sous la

From : Philippe.Cale@urec.cnrs.fr To : Serge.Montau@cru.fr Date : 18 septembre 2000 Subject : CR runion Paris ********************** Je te joins le compte-rendu de la dernire runion. Philippe ********************** Type de fichier : Word Nom du fichier : CR.doc <Fichier Word contenant le compte-rendu> **********************

Ce message est envoy par Philippe Cale Serge Montau le 18/09/00. Il a pour sujet CR runion Paris . Il contient 2 lignes de message ainsi quun fichier (attach) Word, appel CR.doc. Les toiles sont des caractres de sparation des diffrentes parties du message.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

18

S/MIME permet de signer un message. Avec une signature, le message transport prend alors la forme :

From : Philippe.Cale@urec.cnrs.fr To : Serge.Montau@cru.fr Date : 18 septembre 2000 Subject : CR runion Paris Type de message : Sign au format PKCS7 ********************* Je te joins le compte-rendu de la dernire runion. Philippe ********************* Type de fichier : Word Nom du fichier : CR.doc <Fichier Word contenant le compte-rendu> ********************* Signature : MIIFsgYJKoZIhvc ... JTMQsCQYqsdQ *********************

Les outils de messagerie effectuent les oprations de cration et de vrification de signature dcrites dans un paragraphe prcdent sur la signature. Avant denvoyer le message loutil supplmentaires par rapport au prcdent : de messagerie ajoute 2 informations

. Type de message est un champ qui indique que le message est sign, avec un format de prsentation PKCS7 [PKCS7], jargon qui fait partie du standard S/MIME. . Signature : donne la valeur de la signature : MIIFsdQ. Pour calculer cette signature, sur le poste de Philippe Cale, une fonction de hachage a t applique sur le texte du message Je te joins Philippe ainsi que sur le contenu du fichier Word. Le rsultat a t ensuite chiffr avec la cl prive de Philippe Cale, pour donner la signature.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

19

Je te joins le compte-rendu de la dernire runion. Philippe ********************* Type de fichier : Word Nom du fichier : CR.doc <Fichier Word contenant le compterendu>

Fon ction de

hach age

Empreinte
nt me ffre chi
ale pe C p hili de P

MIIFsgYJKoZIhvc ... JTMQsCQYqsdQ

e de thm ori Alg

ive pr Cl

Figure 7 : gnration de signature S/MIME

A larrive le traitement suivant est effectu :

Je te joins le compte-rendu de la dernire runion. Philippe ********************* Type de fichier : Word Nom du fichier : CR.doc <Fichier Word contenant le compterendu> MIIFsgYJKoZIhvc ... JTMQsCQYqsdQ

Fonction de hachage

Empreinte 1

Egalit ?

Algorithme de dchiffrement

Empreinte 2

Cl publique de Philippe Cale

Figure 8 : vrification de signature S/MIME

Si lempreinte 1 et identique lempreinte 2, cela prouve que le texte du message et le fichier Word nont t modifis durant le transport (garantie de lintgrit) et que la signature a bien t chiffre au dpart avec la cl prive de Philippe Cale (authentification de lmetteur). On peut noter que S/MIME a t conu de manire ce que le message sign conserve les enttes standards de messagerie non scurise From, To, Ceci assure la compatibilit avec les outils qui ne comprennent pas S/MIME. Reu par de tels outils le message pourra nanmoins tre lu, mais sans garantie sur lidentit de lmetteur ni sur lintgrit du contenu.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

20

S/MIME permet aussi de chiffrer un message.

Le mme message dexemple chiffr prend la forme (simplifie ici) :

From : Philippe.Cale@urec.cnrs.fr To : Serge.Montau@cru.fr Date : 18 septembre 2000 Subject : CR runion Paris Type de message : chiffr au format PKCS7 MIAGCSqGSIb3DQEHA6CAMIACA g+h7gBDhCfCAAAAAAAAAAAAAA=

Type de message : chiffr au format PKCS7 indique que ce message est chiffr sous un certain format. MIAAA= est le rsultat du chiffrement du texte du message et du fichier Word avec la cl publique du destinataire Serge Montau. Uniquement celui-ci pourra ainsi dchiffrer ce message, avec sa cl prive, garantie de la confidentialit.

Au dpart, loutil de messagerie de Philippe Cale effectue le traitement suivant :

Je te joins le compte-rendu de la dernire runion. Philippe ********************* Type de fichier : Word Nom du fichier : CR.doc <Fichier Word contenant le compte-rendu>

MIAGCSqGSIb3DQEHA6CAMIACA g+h7gBDhCfCAAAAAAAAAAAAAA=

Algorithme de chiffrement

Cl publique de Serge Montau

Figure 9 : chiffrement S/MIME

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

21

A larrive loutil de messagerie de Serge Montau dchiffre le message avec sa cl prive :

Je te joins le compte-rendu de la dernire runion. Philippe ********************* Type de fichier : Word Nom du fichier : CR.doc MIAGCSqGSIb3DQEHA6CAMIACA g+h7gBDhCfCAAAAAAAAAAAAAA= <Fichier Word contenant le compte-rendu>

Algorithme de dchiffrement

Cl prive de Serge Montau

Figure 10 : dchiffrement S/MIME

S/MIME permet de combiner signature et chiffrement, cest dire denvoyer un message sign puis chiffr, les oprations se droulant dans ce sens. Le logiciel metteur effectue les 2 oprations reprsentes figure 7 (gnration de signature) puis figure 9 (chiffrement). Le logiciel rcepteur suit la chronologie : figure 10 (dchiffrement) puis figure 8 (vrification de signature). Par ces mcanismes S/MIME permet dauthentifier lmetteur dun message lectronique et garantit la confidentialit et lintgrit du message. Pour ce faire il faut que les 2 correspondants possdent chacun leur couple de cl publique -prive ainsi que la cl publique de lautre, cest dire le certificat de lautre .

5.2 SSL et HTTPS

SSL (Secure Socket Layer) est un protocole dvelopp par Netscape. La version 3 est en cours de standardisation par lIETF [SSL]. Dans une application en mode client-serveur, en utilisant les certificats, il permet dauthentifier les extrmits et dassurer la confidentialit et lintgrit des changes de donnes. Conceptuellement, il sinsre entre lapplication (http, telnet, ) et les couches logicielles rseau (TCP pour tre prcis). Lorsque la session est tablie entre le client et le serveur, toutes les donnes qui transitent sur le rseau sont chiffres et signes. HTTPS [HTTPS] est limplmentation de http ( le protocole Web ) avec SSL. Les pages Web sur un serveur HTTPS sont dsignes avec la chane https la place de http (exemple : https://www.services.cnrs.fr/csec/). HTTPS avec SSL sont souvent utiliss en mode dissymtrique , o uniquement le serveur possde un certificat, le client nen possdant pas. Ce certificat du serveur permet de chiffrer (avec une cl de session) toutes les donnes transmises dans les 2 sens et dauthentifier le serveur. Pour authentifier le client, le serveur demandera classiquement un mot de passe ou un numro de carte bancaire ou au client. Lavantage est que ces

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

22

donnes dauthentification ne circuleront pas en clair sur le rseau, tous les changes tant chiffrs. Cest ainsi que fonctionne un serveur Web scuris, celui de votre banque peut-tre. Gnralement, lorsquun client avec son navigateur se connecte sur un serveur Web scuris, ce dernier lui envoie son certificat (pour f urnir sa cl publique ). Si ce certificat a o t dlivr par une autorit de certification reconnue par le navigateur du client, il est accept de manire transparente pour lutilisateur; sinon le navigateur demande lutilisateur sil accepte ce type de certificat. HTTPS et SSL peuvent aussi fonctionner de manire symtrique o la fois le serveur et le client ont un certificat. Dans ce cas, lauthentification du client pourra se faire avec le certificat de celui-ci, sans mcanisme supplmentaire de mot de passe Cela sera donc plus simple.

5.3 SSH et SSF

SSH (Secure Shell) [SSH] est un ensemble doutils qui permettent davoir entre autres des sessions interactives en mode telnet ou en mode X, des transferts de fichiers et des excutions de commandes distance, avec authentification forte de lutilisateur et du serveur et chiffrement des donnes transmises. Concrtement il remplace les commandes Unix rlogin, rcp, rsh et permet dtablir des sessions X chiffres. L'intrt premier est de se protger contre l'coute pirate des mots de passe circulant en clair sur les rseaux lorsque lon utilise les commandes telnet, ftp, depuis des sites extrieurs. SSH utilise les algorithmes de chiffrement asymtrique avec une cl de session. Chaque utilisateur gnre sur sa station, un couple de cls publique-prive. Il transmet sa cl publique au serveur sur lequel il accde distance. Ensuite SSH utilise les mcanismes classiques dcrits au chapitre 3 pour assurer authentification, intgrit et confidentialit des changes. SSH nutilise donc pas actuellement les certificats. Mais conceptuellement, il y aurait peu de dveloppement pour ajouter cette fonctionnalit. SSF (Secure Shell Franais) [SSF] est une adaptation de SSH crite par B. Perrot de lIN2P3, destine l'usage sur le territoire franais en conformit avec la lgislation franaise.

5.4 IPSec
Sur le rseau Internet et sur les rseaux informatiques en gnral, le flot des donnes est transport en paquets de quelques centaines de caractres. Outre les d onnes, chaque paquet contient des informations comme les adresses Internet (IP) de la machine origine et destinataire. Toutes ces donnes peuvent tre lues ou modifies par des pirates en coute sur les lignes du rseau. IPSec (IP Security) permet, avec des algorithmes de chiffrement et des cls, de chiffrer le contenu de ces paquets et dauthentifier les deux lments physiques qui dialoguent (routeur ou station, non pas les utilisateurs). Cest un protocole dfini par lIETF [Docs IPSec]. IPSec peut tre mis en oeuvre entre 2 quipements du rseau (routeur ou station). Il est totalement transparent pour les utilisateurs, ce sont les administrateurs des rseaux et des stations qui le mettent en place et ladministrent. Les algorithmes de chiffrement et les mcanismes utiliss peuvent tre divers dans IPSec. Ils sont ngocis au dbut de la connexion entre les quipements. Mais les algorithmes asymtriques, les fonctions de hachages, les couples de cls publique-prive et les certificats constituent le cur du systme. Avec IPSec, ce sont les quipements qui possdent des certificats.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

23

5.5 Diffrences entre ces applications

Les diffrentes applications et standards prsents prcdemment apportent les mmes fonctions de scurit : authentification, intgrit, confidentialit. Ces fonctions ntant pas utilises par les mmes objets, la scurit engendre ne touche pas les mmes domaines. IPSec par exemple apporte de la scurit entre des lments du rseau. Sil est utilis entre 2 routeurs, toutes les communications, do quelles viennent, qui transiteront entre ces routeurs seront chiffres donc confidentielles entre ces routeurs. Par contre, sur le rseau local, entre le routeur local et la station de lutilisateur, elles ne seront plus chiffres (sauf si IPSec va jusqu la station). De plus, IPSec nassurera pas lauthentification des utilisateurs ou des serveurs, il authentifiera uniquement les 2 routeurs (dans cet exemple). Diffremment, S/MIME entre 2 stations, authentifiera chaque utilisateur metteur de chaque message mais sera exclusivement limit la messagerie. Donc les autres applications (accs Web, telnet, ) entre les 2 stations ne bnficieront daucun service de scurit supplmentaire. Ainsi, ces services ne sont pas concurrents mais complmentaires. Selon les besoins, on peut choisir une des diffrentes applications scurises prsentes, souvent mme plusieurs.

6. Exemple dimplmentation des certificats dans Netscape

De mme que son concurrent Internet Explorer, Netscape, logiciel de navigation et de messagerie Internet, intgre en standard les certificats, S/MIME, HTTPS et SSL. Regardons rapidement travers Netscape, comment cela se concrtise sur le poste de travail dun utilisateur.

6.1 Fonctions de base

Certaines fonctions existent dans le logiciel Netscape. Elles permettent de : Gnrer un couple de cls prive-publique. Cette fonction est utilise quand lutilisateur cre lui-mme son couple de cls lors de sa demande de certificat. Stocker la cl prive et verrouiller son accs avec un mot de passe local. Quand lutilisateur voudra utiliser sa cl prive, il devra entrer ce mot de passe. On paramtre gnralement Netscape pour navoir entrer ce mot de passe quune fois par session Netscape. On pourra ensuite utiliser cette cl prive autant de fois que ncessaire pour la messagerie, HTTPS et SSL sans besoin de redonner ce mot de passe pendant la session. Exporter la cl prive et le certificat de lutilisateur dans un fichier accessible avec un autre mot de passe local. Ce fichier devra alors tre sauvegard (sage prcaution, car il ne faut surtout pas perdre sa cl prive !). Il pourra aussi tre copi sur une disquette par exemple, pour tre utilis sur un autre poste, ventuellement avec Internet Explorer, ... Ainsi une mme cl prive et le certificat associ peuvent tre utiliss sur une autre machine et avec un autre logiciel. Rcuprer sur un serveur Web le certificat dune autorit de certification, ce qui permet de rcuprer la cl publique de cette autorit. Ceci tant fait, Netscape fera confiance cette autorit et acceptera tous les certificats valides signs par cette autorit. Rcuprer partir dun serveur LDAP ou Web la liste des certificats rvoqus pour une autorit de certification.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

24

 Signer et chiffrer un message avant envoi. Dans Netscape Messenger, il suffit de slectionner signature ou/et chiffrement la cration dun message. On peut mme choisir que tous les messages que lon envoie soient signs, voire chiffrs par dfaut. Evidemment, pour signer il faut possder un certificat et une cl prive et pour chiffrer il faut avoir le certificat du destinataire (dans une table dcrite ci-aprs). Vrifier la signature dun message reu. Cette opration est ralise par lapplication Netscape de manire transparente pour lutilisateur. Le certificat de lmetteur est recherch dans une des tables Netscape. Lapplication sassure que celui-ci na pas t rvoqu en consultant la liste de certificats rvoqus de lautorit, puis extrait la cl publique de cet utilisateur. Avec celle-ci lapplication vrifie la signature. Sil y a chec, lutilisateur est averti par une icne rouge Signature invalide lorsque le message est affich. Dchiffrer un message reu. Cette opration ncessite un accs la cl prive de lutilisateur. Il y aura donc ventuellement une demande dentrer le mot de passe local. Si le dchiffrement se passe bien le message est affich en clair. Il est noter que le message reste stock chiffr dans la boite aux lettres. Passer en mode HTTPS-SSL. Ce passage se fait automatiquement pilot par le serveur auquel on accde ou ds que lURL commence par https : . Il se peut que ce mode entrane lutilisation de la cl prive. Dans ce cas il faudra ventuellement entrer le mot de passe local pour y accder comme dans le cas de la messagerie.

6.2 Gestion de tables

Pour raliser lensemble des fonctions prcdentes, Netscape gre aussi un ensemble de tables : Des autorits de certification auxquelles lutilisateur fait confiance. Cette table nest pas quune liste de noms, cest aussi une liste de certificats dautorit de certification, donc de cls publiques de ces autorits. Lutilisateur peut ajouter ou supprimer certaines autorits dans cette liste. Pour chaque autorit, une liste de certificats rvoqus peut aussi tre stocke. Attention, par dfaut, linstallation de Netscape cette table contient dj une liste copieuse dautorits (que je vous conseille de supprimer). Des certificats dutilisateurs rcuprs partir dun annuaire LDAP ou dans des messages signs reus prcdemment. Des certificats de serveurs Web accds en HTTPS-SSL. Des certificats de lutilisateur. Lutilisateur peut avoir plusieurs certificats ; il peut choisir dutiliser par dfaut un certificat diffrent pour la messagerie et pour accder un site Web. Les descriptions prcdentes montrent que le logiciel Netscape dispose de toutes les fonctions ncessaires pour utiliser les certificats. Pour vrifier, il ny a qu drouler le menu Security de la partie navigateur. Ainsi, lorsque lutilisateur a obtenu un certificat, rcuprer le certificat de son autorit de certification ainsi que la liste des certificats rvoqus, lutilisation de la signature, du chiffrement, est trivial. (NDLR : en place de toute cette description, ou pour mieux la comprendre, utiliser un certificat avec Netscape sur son poste de travail est recommand)

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

25

7. Comment combler les lacunes des applications rseau actuelles (dcrites dans le chapitre 2) ?
Lorsquune infrastructure de gestion de cls sera en place au CNRS, chaque personnel disposera dun certificat qui contiendra au moins son nom, prnom, laboratoire daffectation, adresse lectronique ainsi que sa cl publique. Associ cette infrastructure sera paralllement en place tout un systme dannuaires LDAP permettant de retrouver le numro dagent dune personne, sa fonction, son dpartement scientifique, sa branche dactivit professionnelle, sa dlgation, Tout le personnel du CNRS aura aussi mis jour son navigateur avec le certificat de lautorit de certification CNRS, pour faire confiance aux certificats mis par cette autorit. Dans cette configuration, si lon reprend les exemples du chapitre 2, dans lordre de ce chapitre : La diffusion des notes officielles pourra se faire par messagerie lectronique au standard S/MIME. Les messages seront signes lectroniquement par lmetteur (le Directeur Gnral, un Dlgu, ). Le rcepteur pourra vrifier automatiquement lorigine du message et son intgrit. Les votes, notations, qui demandent la fonction de confidentialit, pourront aussi se faire par messagerie lectronique S/MIME avec la fonction de chiffrement. Toutes les applications de gestion pourront baser leurs contrles daccs sur les certificats. Les utilisateurs nauront plus quun seul mot de passe connatre, celui permettant localement dutiliser leur cl prive, les services informatiques nauront plus grer des couples utilisateur-mot de passe. Les applications contrleront le certificat des utilisateurs et avec les informations complmentaires contenues dans les annuaires, en dduiront les droits daccs de ces utilisateurs. On pourra crer des Intranet logiques dans les laboratoires, les dlgations, au niveau de lorganisme Il suffira de c ontrler laccs aux pages Web, non pas sur le numro IP ou le nom de la station de lutilisateur, mais sur son certificat en utilisant HTTPS et SSL. On pourra par exemple choisir douvrir un ensemble de pages tous les utilisateurs qui possdent un certificat CNRS, ces pages seront en fait lIntranet CNRS gnral. De trs nombreuses autres combinaisons de contrles daccs seront possibles avec les informations contenues dans les certificats et les annuaires associs. On pourra par exemple autoriser laccs des pages uniquement aux directeurs de laboratoires dun dpartement scientifique. Il suffira que chaque directeur ait un certificat et que lon dispose dun annuaire avec la fonction et le dpartement de chaque personne. On pourra faire les mmes types de contrles mais pour accder des logiciels avec une licence organisme ou ministre, ou des bases de donnes lectroniques comme ELSEVIER. Lutilisation de certificats pourra aussi viter de transporter en clair sur le rseau les mots de passe lors daccs distance, en utilisant SSL.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

26

Enfin pour les applications avec des ressources totalement distribues, chaque lment pourra possder un certificat (utilisateur, machine, disque, ) et tous les contrles daccs pourront reposer sur cette carte didentit. A quand toutes ces applications ? Pas tout de suite. Tout ceci ne se mettra pas en place sans efforts. Il faudra effectuer certains dveloppements logiciels, peut-tre acheter des logiciels, mettre en place de nouvelles procdures, changer les anciennes, prendre de nouvelles habitudes, Cela prendra du temps avant de se gnraliser. (NDLR : tout a un prix) Mais si lon dispose dj dune base solide de certificats, toutes ces applications pourront progressivement se dvelopper en sappuyant sur ces lments de confiance. De plus, linformatique et les rseaux voluant la vitesse que lon sait, de nouvelles applications vont rapidement arriver qui intgreront en standard les certificats. Preuve que ce nest pas une vision trop utopique, la lgislation est dj prte dans ce domaine. En effet, une loi qui accepte la signature lectronique comme une preuve au mme titre que la signature manuelle a dj t vote et le dcret dapplication est en prparation [Dcret signature lectronique]. (NDLR : pourtant les lgislateurs prennent leur temps et sont souvent en retard dans le domaine des nouvelles technologies)

8. Ce que ne rsoudront pas les certificats

Comme ce document tente de lexpliquer, les certificats peuvent rendre de trs nombreux services. Nanmoins, il faut mettre quelques rserves. (NDLR : oui, aprs cet encensement des certificats, il faudrait peut-tre mettre des bmols) Dans les mcanismes des certificats tout nest pas rsolu. On peut citer comme exemples une lacune et un danger. La lacune est technique. La rvocation des certificats est base sur une liste quil faut concrtement tlcharger rgulirement. Ceci est contraignant et lourd. Des standards sont en cours dlaboration pour accder cette liste dynamiquement et automatiquement mais ils ne sont pas encore implments dans Netscape ou Internet Explorer. Le danger, beaucoup plus important, est le problme de la confiance. En effet, toute cette mcanique ncessite des procdures strictes et srieuses (dans la gestion des certificats, ) pour assurer les garanties qui sont affiches. Mais sil savre que ces procdures ne sont pas fiables, il y aura des malversations, des faux certificats, Si ces incidents sont trop nombreux, alors plus personne ne fera confiance aux certificats et ceux-ci nauront plus aucune valeur. Ce sera la mort des certificats. Ceci est dautant plus proccupant que tout ce secteur est totalement libralis, laiss aux entreprises prives. Or, celles-ci peuvent avoir tendance ngliger les procdures (coteuses) pour un profit court terme. Cest un peu comme si on laissait le soin aux multinationales de la grande distribution de dlivrer les cartes didentit et les passeports. Des certifications et des vrifications par des organismes gouvernementaux vont certainement se mettre en place dans certains pays, mais pas partout et ils tardent. Il ny a par exemple pas encore dautorit de certification gouvernementale franaise qui pourrait signer et certifier (aprs certains contrles) celle du CNRS.

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

27

Regardons maintenant du ct de la scurit informatique, telle quon la pratique aujourdhui. Dans ce domaine, les certificats ne vont pas rsoudre tous les problmes. En tant provocateur, on peut mme se demander, sils amlioreront rellement la scurit actuelle. Ce nest pas une consquence automatique. Les certificats sont de trs bons outils mais ce ne sont que des outils. Outre le problme des IGC mal conues et des certificats mal grs, il reste le problme de lutilisation. Car mal protge par les utilisateurs, la cl secrte (et le certificat associ) ne sera pas plus fiable quun mot de passe qui circule en clair sur le rseau ou qui est not sous le clavier. En effet, lensemble va reposer sur la confidentialit de la cl prive de lutilisateur. Si celui-ci la communique autour de lui (concrtement divulgue le mot de passe qui permet dy accder), celle-ci aura la mme valeur quun mot de passe partag par plusieurs personnes. Mais on peut penser que si lon explique aux utilisateurs que la cl prive sert non seulement accder des applications mais aussi prouver leur signature dans leurs messages qui auront un caractre officiel, avec preuve lgale, ils comprendront rapidement que cest un secret encore plus important que le code pour utiliser leur carte bancaire. Imposer de stocker cette cl et le certificat sur une carte puce avec un code daccs peut aussi aider mieux matrialiser ces lments et ainsi faire acqurir les bons rflexes aux utilisateurs. Mais finalement, ceci nest pas le problme des certificats. Cest un problme classique de scurit : la sensibilisation des utilisateurs. Elle devra tre faite ds les premires utilisations de certificats. Les certificats ne rsoudront pas non plus les problmes dintrusions ou de rupture de service par lutilisation de failles de scurit dans les logiciels, la prolifration de virus en tous genres, Il faudra toujours des architectures scurises, des contrles daccs dans ces architectures, des anti-virus, On peut prvoir aussi que les certificats comme tout nouveau service informatique apporteront leurs propres problmes de scurit. Mais ne noircissons pas trop le futur. Si lintroduction des certificats dans un organisme ou une entreprise est correctement ralise, avec professionnalisme et mthode, le gain en terme de scurit et de nouvelles facilits de contrles devrait tre trs important. On peut penser aussi que plus que lamlioration de lexistant en terme de scurit, lintrt des certificats rside dans les nouveaux services quil sera beaucoup plus facile de mettre en place, en particulier dans des structures trs clates gographiquement comme le CNRS. (NDLR : merci Marie-Agns, Marie-Claude, Nicole et Sophie pour leur relecture et leurs commentaires)

9. Rfrences

[AES] Advanced Encryption Standard : The block cipher Rijndael http://www.esat.kuleuven.ac.be/~rijmen/rijndael/index.html [Articles UREC] quelques articles sur le sujet des certificats http://www.urec.cnrs.fr/securite/certifications.html.
Certificats (lectroniques) : Pourquoi ? Comment ? JL Archimbaud CNRS/UREC 28

[CA CNRS] http://www.dsi.cnrs.fr/bo/2000/08-09-00/416-bo080900-dec000381bpc.htm [CNRS] Centre National de la Recherche Scientifique http://www.cnrs.fr [Datagrid] http://grid-france.in2p3.fr/ [DES] Data Encryption Standard http://www.itl.nist.gov/fipspubs/fip46-2.htm [Dcrets chiffrement] : Dcrets 99-199, 99-200 http://www.internet.gouv.fr/francais/textesref/cryptodecret99199.htm http://www.internet.gouv.fr/francais/textesref/cryptodecret99200.htm [Dcret signature lectronique] http://www.internet.gouv.fr/francais/textesref/pagsi2/signelect-projdecret/sommaire.htm [Glossary] RFC2828 : Internet Security Glossary http://www.pasteur.fr/infosci/RFC/28xx/2828 [HTTPS] RFC2817 : Upgrading to TLS Within HTTP/1.1 http://www.pasteur.fr/cgi-bin/mfs/01/28xx/2817 [IGC] http://www.scssi.gouv.fr/document/igc.html [IPSec] ensemble de documents sur IPSec http://www.hsc.fr/ressources/veille/ipsec/index.html.fr [jla] http://www.urec.cnrs.fr/jla [LDAP] : un ensemble de rfrences http://www.cru.fr/ldap/ [MD5] RFC1321 The MD5 Message-Digest Algorithm http://www.pasteur.fr/cgi-bin/mfs/01/13xx/1321 [PKCS7] RFC2315 : PKCS #7: Cryptographic Message Syntax Version 1.5 http://www.pasteur.fr/infosci/RFC/23xx/2315 [Renater] Rseau NAtional de la Technologie de lEnseignement et de la Recherche http://www.renater.fr [RSA] http://rsasecurity.com/rsalabs/ [SHA] Secure Hash Standard http://www.itl.nist.gov/fipspubs/fip180-1.htm [S/MIME] S/MIME Working Group http://www.imc.org/ietf-smime/ [SSF] serveur de documentations et de programmes sur SSH et SSF http://ccweb.in2p3.fr/securite/ssf/ [SSH] page daccueil pour la communaut des utilisateurs de SSH http://www.ssh.org/ [SSL] Introduction to SSL http://developer.netscape.com/docs/manuals/security/sslin/index [Triple DES] RFC 1851: The ESP Triple DES Transform http://www.pasteur.fr/infosci/RFC/18xx/1851 [X509V3] RFC2459 : Internet X.509 Public Key Infrastructure Certificate and CRL Profile http://www.pasteur.fr/cgi-bin/mfs/01/24xx/2459

Certificats (lectroniques) : Pourquoi ? Comment ?

JL Archimbaud CNRS/UREC

29