Laccs scuris aux donnes

Novembre 1999

Serge Aumont
Comit Rseaux des Universits, Rennes Serge.Aumont@cru.fr

Roland Dirlewanger
CNRS - Dlgation Aquitaine et Poitou-Charentes, Talence Roland.Dirlewanger@dr15.cnrs.fr

Olivier Porte
CNRS Direction des Systmes d'Information, Meudon Olivier.Porte@dsi.cnrs.fr

JRES 99

Les principes
1 2 Bref historique ..................................................................................................................... 6 Dfinitions et problmes ...................................................................................................... 7 2.1.1 Dfinitions .............................................................................................................. 7 2.2 Quelques principes dattaques dun systme base de chiffrement ........................... 13 3 Les mthodes de chiffrement ............................................................................................. 17 3.1 3.2 3.3 3.4 4 Le principe de la cl secrte ........................................................................................ 17 Le principe cl publique / cl prive ........................................................................... 23 Notarisation................................................................................................................. 28 Le positionnement du chiffrement dans les protocoles rseau.................................... 29

De la distribution des cls aux infrastructures cls publiques ........................................ 30 4.1 La gestion des cls prives.......................................................................................... 30 4.2 Les cas des cls publiques ........................................................................................... 31 4.2.1 Nature des cls et problmatique associe ........................................................... 31 4.2.2 Modle PGP et Autorits de Certification...................................................... 32 4.2.3 Le certificat X509 ................................................................................................. 35

Les applications du chiffrement

5 Le protocole SSL (Secure Socket Layer) .......................................................................... 38 5.1 Caractristiques du protocole SSL v2 ......................................................................... 38 5.1.1 Ouverture de la session......................................................................................... 38 5.1.2 Choix des algorithmes de chiffrement et d'empreintes ........................................ 39 5.1.3 Gnration des cls de session ............................................................................. 39 5.1.4 Authentification du client ..................................................................................... 40 5.1.5 Fin de la phase d'ouverture de la session.............................................................. 40 5.1.6 Le flux des donnes .............................................................................................. 41 5.2 Caractristiques du protocole SSL v3 ......................................................................... 41 6 Le protocole HTTPS .......................................................................................................... 42 6.1 Comment utiliser HTTPS ? ......................................................................................... 42 6.2 Dmarrer un serveur Apache avec mod_ssl................................................................ 42 6.2.1 installer OpenSSL................................................................................................. 43 6.2.2 installer mod_ssl dans les sources d'Apache ........................................................ 43 6.2.3 configurer Apache et mod_ssl.............................................................................. 43 6.2.4 gnrer et installer le certificat du serveur ........................................................... 44 6.2.5 installer les certificats des autorits de certification............................................. 45 6.3 Les autorisations .......................................................................................................... 46 6.3.1 Par mot de passe ................................................................................................... 46 6.3.2 En fonction du certificat du client ........................................................................ 47 6.4 Les scripts CGI et HTTPS........................................................................................... 48 6.5 HTTPS et les serveurs proxys ..................................................................................... 49 6.6 Une application : le Webmail...................................................................................... 49 7 8 SSL et la messagerie .......................................................................................................... 50 Le format S/MIME ............................................................................................................ 51 3

8.1 La signature d'un message ........................................................................................... 52 8.2 Le chiffrement d'un message ....................................................................................... 52 8.3 Le chiffrement et la signature...................................................................................... 53 8.4 Installation du certificat de l'utilisateur ....................................................................... 53 8.5 Comment obtenir le certificat d'un correspondant ? ................................................... 54 8.5.1 En recevant un message sign .............................................................................. 54 8.5.2 En interrogeant un annuaire.................................................................................. 54 8.6 Exporter un certificat................................................................................................... 54 8.7 S/MIME et les listes de diffusion................................................................................ 55 8.7.1 La signature .......................................................................................................... 55 8.7.2 La confidentialit .................................................................................................. 55 9 IP Security (IPSec) ............................................................................................................ 57 9.1 Fonctionnement dIPSec ............................................................................................. 57 9.1.1 Modes de fonctionnement .................................................................................... 57 9.1.2 Les Associations de scurit (SAs) ...................................................................... 58 9.1.3 IPSec et la gestion des cls ................................................................................... 60 9.1.4 Les modes de fonctionnement de IKE.................................................................. 63 9.2 Implmentations actuelles et exemple de mise en uvre avec des routeurs............... 64

Vers une infrastructure de gestion de clefs

10 Infrastructure de gestion de clefs.................................................................................... 74 10.1 Composantes et services dune PKI ........................................................................ 74 10.1.1 Autorit denregistrement ................................................................................. 74 10.1.2 Autorit de certification .................................................................................... 75 10.1.3 Service de publication ....................................................................................... 75 10.1.4 Service de rvocation........................................................................................ 75 10.1.5 Politique de certification ................................................................................... 76 10.1.6 Protection de la PKI .......................................................................................... 76 10.1.7 Interoprabilit et PKI....................................................................................... 76 10.2 Les navigateurs et serveurs HTTPS......................................................................... 78 10.3 Le projet OpenCA.................................................................................................... 78 11 12 Les volutions lgislatives.............................................................................................. 79 Des projets au sein nos administrations .......................................................................... 79

Introduction
Il nest plus dactualit aujourdhui de parler de la ncessaire intgration des rseaux informatiques dans les systmes dinformation : cest dsormais un fait acquis. Mais, faire ce constat ne suffit pas rsoudre les diffrentes problmatiques lies cette nouvelle dimension et, entre autre, la prise en compte des aspects scurit. Dans ce domaine, il y a, dune manire volontairement schmatique, deux composantes relativement aises distinguer : la scurit physique des quipements informatiques (protection contre les incendies, mise en place de politiques de sauvegarde des donnes, ...) et la scurit logique des systmes (vrification de lintgrit du systme, prcautions face lenvironnement extrieur, ...). Jusquici, cette dernire phase sest traduite principalement par la mise en uvre dune gnration doutils bien connus des administrateurs systmes et rseaux : COPS, Tcp_Wrapper, application de diffrentes Checklist Scurit sur les systmes ou les configurations rseau, etc. jusqu' la mise en place de systmes purement ddis la scurit comme les pare-feu par exemple. Ces outils rpondaient une double problmatique : permettre de manire sre aux utilisateurs autoriss daccder au systme dinformation et videmment den interdire laccs pour le reste du monde except pour un sous-ensemble matris de certaines informations. Sur ce dernier point concernant la visibilit de certaines informations, la tendance au niveau des moyens utiliss est actuellement clairement en faveur de la messagerie, du Web et des rseaux privs virtuels (VPN), sujets qui seront plus amplement dtaills dans la suite de ce document. Au dbut de intgration des rseaux dans les systmes dinformation, les outils classiques l de la scurit pouvaient pour une bonne part rpondre cette problmatique. Mais dsormais, le problme a chang dchelle et devant la multiplicit et la complexit des services mettre en uvre, les outils standards sont devenus pour une bonne part insuffisants. Sans aucunement remettre en cause leur utilit maintes fois prouve et toujours dactualit, il est ncessaire aujourdhui de dvelopper activement la mise en uvre de deux autres composantes importantes de la scurit bases sur des techniques de chiffrement travers dune part la gestion de la confidentialit et, dautre part, les mcanismes dauthentification. Cette dmarche est de plus encourage actuellement par un contexte lgislatif sur le chiffrement qui permet le dploiement de telles technologies sans trop de contraintes lies laugmentation de la taille des cls. Lauthentification et la confidentialit, quil est possible de dissocier fonctionnellement, reposent, comme il la t dit, entirement sur les concepts du chiffrement. Ces concepts sont lobjet du premier chapitre, consacr clairer quelques aspects sous-jacents incontournables dans ce domaine. Aprs avoir pos la problmatique du chiffrement, diffrents exemples illustreront son emploi dans les domaines du Web, de la messagerie et des rseaux privs virtuels (VPN). Le lecteur intress pourra se reporter avantageusement la bibliographie, non exhaustive ici tant la littrature sur le sujet est abondante et riche en articles et ouvrages. 5

Principes de base du Chiffrement

1 Bref historique

A lorigine, le chiffrement fut dvelopp dans un contexte militaire afin de pouvoir envoyer des messages sans quun ennemi potentiel ne puisse prendre connaissance du contenu. Dj, Jules Csar lui-mme envoyait des messages chiffrs ses correspondants par lintermdiaire de messagers en lesquels il navait aucune confiance. Son systme de chiffrement tait alors rudimentaire et consistait remplacer chaque lettre de lalphabet par une autre lettre avec un simple dcalage de trois caractres. Ainsi, il remplaa chaque A par un D, chaque B par un E, .... Plus tard, les systmes ne cessrent de se perfectionner. On peut citer pour servir dexemple deux systmes, qui sont celui dit des francs-maons et la technique dite du carnet de codes . Lillustration de ces exemples est inspire de [GARFINKEL1995]. Dans la technique dite des francs-maons , on considre la correspondance de code suivante, tablie selon des caractristiques graphiques :
A D G B E H C F I J K M L N Q T O R U P S V W X Z Y

Le mot secret devient alors avec cette technique :

La technique des carnets de codes encore appele chiffrement de Vernam a longtemps t utilise dans le domaine de lespionnage. Le principe est simple : consigner sur un carnet ou tout autre support une srie de nombres alatoires reprsentant le dcalage par rapport sa valeur de rfrence que doit subir une lettre pour obtenir son quivalent cod. Ainsi, en considrant au dpart les lettres : A 1 B 2 C 3 D .... et les codes qui leurs sont associes (arbitrairement) 4 ...

avec en plus sur un support la srie 3 2 3 ... gnre alatoirement (le fameux carnet de code), le message de dpart CDA, pris au hasard, devient FFD aprs chiffrement. Les deux parties ayant le mme carnet de code, il est alors facile de concevoir un dialogue scuris entre elles. Les codes de ce type sont inviolables la premire utilisation. Par contre, le fait de les utiliser deux fois permettrait de dceler les redondances, les caractres et leurs occurrences statistiques, ... et, enfin, de casser le principe du chiffrement. Il existe bien dautres techniques historiques de ce type dont la description exhaustive serait ici hors de propos.

Dfinitions et problmes
Dfinitions

2.1.1

Le chiffrement consiste transformer un texte en clair en un texte chiffr. Le dchiffrement, rciproquement, cest traduire un texte chiffr en clair en connaissant la cl de chiffrement. Dcrypter par contre consiste traduire un texte chiffr en clair tout en ne connaissant pas la cl de dchiffrement. Il est important de bien distinguer ces deux notions car tout lintrt de la cryptographie consiste rendre la premire opration facile et la deuxime difficile. Une mise au point sur la terminologie peut tre faite ici : les verbes crypter et encrypter ainsi que cryptage et dcryptage sont des anglicismes, leurs quivalents franais tant chiffrer , dchiffrer , .... Le principe de ce qui vient dtre nonc peut se rsumer ainsi :

Cl de chiffrement Cryptogramme afk mph dtoe

Cl de dchiffrement

Texte

chiffrement

dchiffrement

Texte

On conoit donc facilement que dans un environnement non sr o les usagers peuvent tre multiples, le chiffrement apporte un niveau de scurit supplmentaire. La scurit des communications, pourvu que la qualit du chiffrement soit suffisante, est alors garantie, mme si une tierce personne intercepte le trafic chang. Globalement, les objectifs de lutilisation du chiffrement sont les suivants : assurer la confidentialit des donnes : La confidentialit est la proprit quune information nest ni disponible ni divulgue aux personnes, entits ou processus non autoriss [daprs la norme ISO 7498-2 (ISO90)]. En gnral, linformation nest disponible et partage quentre les deux parties de confiance que sont lmetteur et le rcepteur dfinis dans le cadre dun change, assurer lintgrit des donnes : Lintgrit est la prvention dune modification non autorise de linformation [toujours daprs la norme ISO 7498-2 (ISO90)], assurer lauthentification : consiste vrifier lidentit des diffrentes parties impliques dans le dialogue. Lauthentification prserve de lusurpation didentit et participe de la confidentialit dans le sens o elle assure que celui qui met est bien lentit attendue, assurer la non rpudiation : permet de prouver quun message a bien t mis par son initiateur. Le message ne peut donc plus ensuite tre dni par celui qui la mis.

Concrtement, il existe deux types de cryptographie : la cryptographie cl secrte ou la cryptographie cls publiques et prives (on parle aussi de cryptographie symtrique et asymtrique, ce qui se justifiera plus loin). Dans les deux cas, la qualit dun systme de cryptographie repose sur le secret de la cl et non sur le secret de lalgorithme et cela aura des consquences dune part sur le choix du systme de chiffrement et dautre part sur la manire dont les cls sont gres, problme qui devra tre trait convenablement dans toute mise en uvre. Il est dailleurs possible de remarquer ce sujet quil est tout fait envisageable de pouvoir dchiffrer un texte chiffr sans pour cela connatre lalgorithme ayant servi au chiffrement. Baser la sret de la mthode de chiffrement sur le secret de lalgorithme parat donc totalement illusoire. Cette dernire rgle ne vaut dailleurs pas seulement pour le chiffrement : la scurit dun Systme dInformation qui reposerait uniquement sur le secret aurait rapidement faire face quelques dboires ! La caractristique essentielle dun bon systme de chiffrement rside dans le fait quil fait apparatre le texte obtenu comme alatoire pour les mthodes bases sur des tests statistiques. A cela sajoute que le systme de chiffrement reste fiable tant quaucune mthode simple et surtout rapide de casser le code na pas t mise en vidence. En effet, le chiffrement, tant bas sur des principes mathmatiques (thorie des grands nombres par exemple), reste sr tant quune thorie remettant en cause ces principes na pas t dcouverte. Or actuellement, il ny a aucun moyen de prouver quun systme de chiffrement ( cls secrtes ou cls publiques/prives) ne contient pas de failles de ce type. Des exemples clbres ont prouvs que casser un code pour un expert restait s ouvent du domaine du faisable (des exemples existent dans le domaine tlvisuel o de nombreuses chanes codes nont gard que trs peu de temps leur caractre confidentiel : cassage de lalgorithme de brouillage vido VC-I par exemple). En fait, la scurit du chiffrement repose totalement sur la nature et limplmentation des algorithmes, corrler avec les puissances de calcul disponibles actuellement. Ces deux domaines tant en perptuelle volution, une savante adquation doit tre faite entre la complexit du chiffrement utilis, le temps de calcul ncessaire casser le chiffrement et le temps estim pendant lequel les informations doivent tre gardes confidentielles. Lexemple peut tre le plus frappant sur le sujet concerne sans d oute le DES avec une cl de longueur de 56 bits qui a t dclassifi pour la dfense en 1988 alors quauparavant, il tait considr comme sr pour le domaine militaire. Autre signe des temps, des concours sont organiss pour casser les principales techniques utilises : on peut citer les divers Challenge RSA . Lobjectif affich est de tester la scurit des diffrents algorithmes de chiffrement autoriss par le gouvernement amricain. Le premier concours concernait une cl de 40 bits et le code a t cass en 3 heures environ avec une machine de puissance moyenne (1997). Dernirement, la factorisation de cls de 512 bits t ralise. Cette opration a vu la participation de six pays : Australie, Canada, Etats-Unis, France, Royaume Uni et PaysBas. Trois cents ordinateurs ont t ncessaires dont un Cray. Lopration sest droule en deux phases (choix des polynmes et factorisation proprement dite). La premire phase sest droule du 27 avril 1999 au 13 juillet 1999 et la deuxime du 14 juillet 1999 au 22 aot 1999. En terme de puissance de calcul, les moyens employs ont t importants : 8000 annes de MIPS soit 32 annes de calcul pour un processeur 250 MHz. 8

Mais le point essentiel considrer ici reste lillustration du fait quil est possible de remettre en cause la sret dune technique de chiffrement en intervenant dans le cas prsent sur les deux facteurs qui sont lvolution des puissances de traitement et les avances dans les thories sous-jacentes (Crible algbrique J Pollard 1988). Malgr tout et pour modrer quelque peu ce qui vient dtre dit, dans ltat actuel des connaissances et en sachant bien que les certitudes dans le domaine nexistent pas, il reste que les deux techniques, symtriques et asymtriques, si elles sont bien mises en uvre, restent une protection tout fait dissuasive contre lespionnage ou le piratage des changes informatiss en fonction du niveau de scurit attendu. De plus, les moyens mettre en uvre dans les exemples prcdents ne sont tout de mme pas la porte de nimporte quelle organisation.

Examinons maintenant plus en dtail les principes sous-jacents au chiffrement et les dfinitions qui en dcoulent. Le formalisme (simple) qui suit est emprunt aux mathmatiques pour exposer avec concision les notions en jeu tout en vitant de trop longues explications. le chiffrement consiste dterminer une fonction f qui dun texte clair P fournit un texte chiffr C laide dune cl E_K : fE_K : P C le dchiffrement permet de faire lopration inverse soit : fD_K : C P avec fD_K (fE_K (P)) = P Dit plus clairement, partir dun texte chiffr C et connaissant la cl de dchiffrement, on retrouve le texte en clair. Si, dans ce cas, E_K = D_K (mme cl pour le chiffrement et le dchiffrement) alors le systme est dit cls symtriques. Dans le cas contraire, le chiffrement est dit cls asymtriques. La fonction f utilise peut tre diffrente pour le chiffrement et le dchiffrement : cela dpend des cas (symtriques et asymtriques) et des algorithmes utiliss. Les proprits des modles symtriques et asymtriques sont les suivantes : Modle symtrique connaissant P et E_K la cl de chiffrement, il facile de calculer C, connaissant C et D_K (ou E_K puisque dans ce cas E_K = D_K), il est facile de calculer P, connaissant P et C, il est trs difficile de trouver E_K ou D_K. Le terme trs difficile (et par dduction facile ) dpend principalement de la taille de la cl comme cela sera illustr dans la suite (cas de lattaque brutale ). 9

 Modle asymtrique connaissant P et E_K, il est facile de calculer C, connaissant C et D_K, il est facile de calculer P, connaissant P et C, il est trs difficile de trouver E_K ou D_K, la connaissance de E_K n permet pas ou difficilement de connatre e D_K et rciproquement.

Dautres notions sont aussi trs importantes connatre en matire de chiffrement. Ces notions concernent les fonctions de hachage sens unique et les signatures numriques. Fonctions de hachage sens unique Ces fonctions, appeles aussi fonctions de condensation , condensent en quelque sorte les informations contenues dans un fichier de taille quelconque en un grand nombre qui se rvle alors tre lempreinte du fichier. Ces fonctions sont telles que si un seul bit du message dorigine est modifi, alors lempreinte obtenue change radicalement. Le principe est un peu le mme que pour la notion de checksum mais en beaucoup plus labor. Voyons quelles sont les caractristiques de telles fonctions de hachage : Considrons h = H(P) avec h : empreinte de longueur fixe H : fonction de hachage P : texte de longueur quelconque Les proprits sont les suivantes : connaissant P et H, il est facile de calculer h connaissant h et H, il est trs difficile de calculer P connaissant P, il est trs difficile de trouver P tel que H(P) = H(P) Les fonctions de hachage les plus connues sont MD2, MD4, MD5 ( MD pour Message Digest ), SHA (Secure Hash Algorithm) et SHS (Secure Hash Standard). Toutes ces fonctions sont quasiment similaires mais plus ou moins rapides. MD5 est plus robuste que MD4 mais environ 33% moins rapide. Actuellement, aucune attaque connue nest possible sur MD5, si ce nest la recherche exhaustive de cl, par principe totalement dissuasive. Concrtement, MD5 (cr par Ronald Rivest) renvoie une valeur de 128 bits sous forme de 32 chiffres hexadcimaux quelque soit le fichier dorigine. Une autre caractristique notoire de MD5 rside dans le fait que des donnes dentre identiques produisent toujours une mme empreinte. SHS, quant lui, fournit des empreintes de 160 bits. Sa structure est identique MD4 et MD5 mais environ 25% plus lent que MD5 (mais potentiellement plus fiable, la taille de la cl tant de 160 bits au lieu de 128 bits).

10

Il faut bien faire attention, lors de lutilisation dune fonction de hachage, dutiliser des messages suffisamment longs. Dans le cas contraire, une attaque utilisant le paradoxe des anniversaires , bien connu en probabilits, est toujours possible. Le paradoxe des anniversaires exprime le fait que dans un groupe de 23 personnes choisies alatoirement, il existe au moins une chance sur deux que deux dentre elles aient leur anniversaire le mme jour, alors que la probabilit est trs faible pour quune personne du groupe ait son anniversaire le mme jour que vous !! Do la ncessit, en appliquant ce constat au sujet qui nous intresse, de prendre en compte des messages assez longs (au minimum 120 bits) avant dappliquer une fonction de hachage avec un degr de scurit acceptable, cest--dire permettant dviter que deux messages collisionnent et aient donc le mme rsultat de hachage. Signature lectronique Bien que triviaux, il est bon de rappeler que les objectifs dune signature lectronique sont les suivants : vrifier lintgrit dun message : dtecter toute modification ventuelle authentifier de manire certaine la provenance du message Contrairement au chiffrement qui est utilis des fins de confidentialit, les signatures lectroniques sont, en quelque sorte, annexes aux donnes et laissent le texte qui vient dtre sign totalement en clair. Pour cela, les proprits suivantes doivent tre vrifies : une signature ne peut pas tre falsifie une signature donne nest pas rutilisable sur une autre document un document sign est inaltrable une signature ne peut pas tre renie

Le principe est le suivant : Signature Vrification de la signature : : C = Sign S (P) P = Verif T (C ) avec VerifT (Sign S (P)) = P et S et T des cls

On peut illustrer ici de manire trs schmatique quel est le processus complet de gnration dune signature lectronique :

11

Texte en clair gnr par un utilisateur Condens (MD5 ou autre)

Fonction de Hachage Texte en clair

Chiffrement du condens avec la cl prive de lexpditeur

Cl Prive Cl Publique

Signature Electronique

Adjonction de la signature lectronique au texte en clair Expdition du message au destinataire Vrification de la signature par le rcepteur avec la cl publique de lmetteur et avec ventuellement un certificat provenant dune autorit de certification

Expdition de la cl publique de lmetteur au destinataire soit dans le mme message soit dans un message part

Autorit de Certification

Vrification de la conformit du condens par rapport au message dorigine

Le mcanisme des cls publiques et des cls prives sera dcrit plus amplement dans la suite. Il existe actuellement beaucoup dalgorithmes de signature. Ces algorithmes sont souvent issus des fonctions de hachage dcrites prcdemment. On peut donc encore citer : MD4, MD5 (utilis par PGP), SHS, ... et DSS (Digital System Standard) dont le principe est bas sur le problme du logarithme discrtis (trouver lexposant x tel que y=gx mod p, ce qui est un problme considr comme difficile actuellement et dont lorigine remonte au projet CAPSTONE du gouvernement Amricain qui visait dvelopper des standards en matire de chiffrement (1987). Concrtement, ce quil faut retenir sur le mcanisme des signatures, cest que les algorithmes mis en uvre sont lents et que souvent la signature se fait en ralit sur un petit nombre de donnes reprsentatives. Enfin, il reste prendre en compte le problme de la non rpudiation. Ce problme a deux dimensions : lmetteur ne peut pas nier lenvoi dun message le rcepteur ne peut pas nier la rception dun message A cela, deux rponses sont envisageables et appartiennent plus au domaine juridique quinformatique : chacune des parties sengage (de manire contractuelle) garder secret le moyen daccs ou de chiffrement (avec conflit possible en cas de ddit de lune des parties) la notarisation : tous les changes sont consigns chez un tiers de confiance Dsormais, fort des principes de base qui viennent dtre noncs, il reste dterminer quels sont les types dattaques que lon peut faire subir un systme de chiffrement. 12

2.2 Quelques principes dattaques dun systme base de chiffrement

Modlisons ce que pourrait tre une attaque visant casser un code :
Variation de cl D_K

Texte en clair : P_1, , P_n

Texte quivalent chiffr : f E_K(P_1, , P_n)

Algorithme A dit dAttaque

A D_K (C_1, , C_n) = P_1, , P_n Lgalit se produit avec une probabilit p, p dpendant de la distribution du texte chiffr

En gnral, en connaissant ou non tout ou partie des textes dorigine en clair, un algorithme dattaque A fera varier la cl D_K sur les textes ou portions de texte chiffrs (C_1, ..., C_n) jusqu' retrouver le texte en clair (P_1, ..., P_n) et ceci avec une probabilit p plus ou moins lve. Avant toute description complte du principe des attaques , voyons ce quest un systme de chiffrement parfait. Dans ce type de systme, on considre le texte dorigine, le texte chiffr et les cls comme des octets ou des suites doctets de longueur m. La fonction de chiffrement peut se rduire dans ce cas un simple OU Exclusif entre le texte en clair Pet une cl K:

f E_K = K XOR P
Si la cl est distribue uniformment et que le message nest envoy quune seule fois dans ce mode, la cl ntant plus rutilise par la suite, il nexiste pas de moyen trivial de connatre le contenu du message chiffr. Mais, il est rellement impratif de toujours respecter les deux rgles suivantes : la cl nest utilise quune seule fois la distribution des cls doit tre uniforme et le gnrateur de nombres alatoires permettant de crer des cls uniformes doit tre le moins dterministe possible Ici, cette gnration de nombres alatoires revt toute son importance car dans le cas dune mauvaise distribution de la cl, il est possible de casser le code en utilisant des dictionnaires par exemple sil est connu que le chiffrement seffectue partir de mots de la langue courante. De mme, des mthodes statistiques peuvent tre utilises, mthodes se basant sur la frquence dapparition des caractres dans une langue donne. Le seul problme inhrent cette technique du OU exclusif rside dans la cl et surtout la dtermination et le nombre de cls utiliser (une par change). A cela sajoute que la perte ou la rupture de la squence dchange rompt compltement le processus de chiffrement. Pour mmoire, il est possible de mesurer la bonne distribution dune cl en calculant son entropie (lentropie rend compte de la quantit dinformation et est dautant plus leve la probabilit dapparition dune information est quiprobable). Par exemple, lentropie dune cl K sachant que sa probabilit est p vaut -p log (p) (logarithme base 2). 13

Voyons maintenant quels sont les types dattaques qui peuvent tre envisags sur un systme de chiffrement : Attaque brutale Dans ce type dattaque, il suffit de connatre un message chiffr et dessayer successivement toutes les combinaisons pouvant conduire dchiffrer le message : les textes chiffrs C_1, ... C_n sont connus et toutes les cls K sont essayes jusqu' lobtention dune texte en clair. Le problme principal dans ce cas concerne lefficacit de la technique mise en uvre laquelle sajoute la dfinition et la reconnaissance de ce que peut tre un texte en clair lorsque lon ne possde aucune information le concernant, et en principe cest le cas. Concrtement, la difficult dune telle opration est perceptible immdiatement : une cl de 128 bits offre 2128 cls possibles. Simplement, sur une cl de 64 bits il existe 1.844 * 1019 possibilits. En considrant un ordinateur testant 1 milliard de cls par seconde, il faudrait peu prs 584 ans pour trouver la cl avec certitude. Le problme de la longueur de la cl apparatra donc comme un lment essentiel lors du choix dun systme de chiffrement. Dailleurs, voici quelques caractristiques lies aux cls, caractristiques issues de [ROUSSEAU1996] : *- Nombre de cls possibles en fonction de la taille de la cl : Lettres minuscules (26) 4 octets 5 octets 6 octets 7 octets 8 octets 460 000 1.2 x 107 3,1 x 108 8,0 x 109 2,1 x 1011 Caractres alphanumriques (62) 1,5 x 107 9,2 x 108 5,7 x 1010 3,5 x 1012 2,2 x 1014 Caractres ASCII 8 bits (256) 4,3 x 109 1,1 x 1012 2,8 x 1014 7,2 x 1016 1,8 x 1019

Le calcul des valeurs de ce tableau se fait simplement. Considrons le cas des lettres minuscules sur 4 octets : pour le 1ier octet, il y a 26 possibilits de choix, et ainsi de suite pour les 3 octets suivants dou 264 soit 456976 possibilits au total. Dans ce tableau, les valeurs sont arrondies.

14

*- Temps de calcul ncessaire dans le cas dune recherche exhaustive avec la possibilit deffectuer un million de tentatives par seconde :

Lettres minuscules (26) 4 octets 5 octets 6 octets 7 octets 8 octets 0,5 s 12 s 5 min 2,2 h 2,4 j

Caractres alphanumriques (62) 15 s 15 min 16 h 41 j 6,9 ans

Caractres ASCII 8 bits (256) 1,2 h 13 j 8,9 ans 2300 ans 580 000 ans

Illustrons ces propos avec le fonctionnement du systme de mots de passe du systme Unix. Dans ce cas, le mot de passe est cod sur 8 caractres. Ce mot de passe est transform en une cl de 56 bits, cl utilise ensuite par lalgorithme du DES (dcrit plus loin). Un texte de 64 bits 0 est ensuite chiffr avec la cl de 56 bits. Lopration est rpte 25 fois sur chaque crypte obtenu successivement.

Le rsultat obtenu consiste en 11 caractres stocks dans un fichier (/etc/passwd en gnral). Lapplication dune variante de lattaque brutale sur les mots de passe Unix pourrait alors se traduire comme suit : 1)- rcupration du fichier /etc/passwd 2)- Utilisation dun ou plusieurs dictionnaires (mots usuels, prnoms fminins, ....) partir duquel on applique lalgorithme de chiffrement qui vient dtre voqu 3)- Comparaison du rsultat obtenu avec le c ontenu du fichier /etc/passwd. En cas dgalit, le mot de passe peut tre considr comme cass . Cela illustre le fait, si le besoin sen faisait encore sentir, quil faut absolument choisir avec prcaution un mot de passe et surtout mlanger lettres, chiffres et caractres spciaux sans que le rsultat napparaisse dans un dictionnaire. Attaque par squences connues Vu limpasse laquelle conduit la mthode prcdente ( moins dtre relativement chanceux), il est possible pour une tierce personne dsirant dchiffrer des communications de fixer un certain nombre de paramtres du message dorigine. Ainsi les enttes de message, les formatages de documents normaliss permettent daider la recherche de la cl. 15

 Attaques par squences forces Cette technique se base quelque peu sur les principes de lattaque par squences connues. Il suffit dans ce cas de faire en sorte que lmetteur chiffre son insu un bloc de donnes connu, bien entendu connu par celui qui veut casser le code. Pour contrer cette ventualit, la dtection de la modification des donnes peut alors se faire en compliquant le contenu des donnes envoyes en utilisant par exemple la technique suivante : T, f E_K(h(T Xor R Xor P),R,P) avec T : estampille de temps, h : fonction de hachage, R : nombre alatoire , : symbole de lopration de concatnation

Dune manire gnrale, tout ce qui est contrle de lintgrit dun flot de message (pas dajouts dans les messages existants, pas de rejeux danciens messages et pas de destruction de messages) peut se faire par lajout au minimum dune estampille constitue en rgle gnrale de la date et dun compteur. Attaque par analyse diffrentielle Cette attaque est encore une variante de lattaque par squences connues m cette fois ais lanalyse porte sur des textes chiffrs ne comprenant que de petites variations. Pour rsumer, les mthodes utilises en cryptanalyse se classent en deux types : idale : connaissance dune texte en clair et de son correspondant chiffr. Il reste ensuite rechercher la cl selon diverses techniques plus ou moins complexes pratique : vu le type de messages gnralement changs (lettre-type, messagerie,...) et la taille de ces messages, des segments de phrases ainsi que leur position peuvent tre devins, et ce, par des essais successifs. Il reste alors dduire la cl dans un nombre de cas relativement limit

Face ces diffrents types dattaques, il existe donc deux sortes dalgorithme de chiffrement : les algorithmes dits rsistants et les algorithmes dits friables . Notre intrt dans ce qui suit va se porter sur le premier type dalgorithme et les applications qui peuvent en tre faites dans le cadre de la scurisation du rseau.

16

Les mthodes de chiffrement

3.1 Le principe de la cl secrte

Ce principe de chiffrement est le plus ancien. Dans ce cas, toute la scurit du dispositif repose sur le secret de la cl. Cette cl est la mme pour le chiffrement et le dchiffrement.

Pirate passif ou actif

Lexpditeur envoie le message clair P

Algorithme de chiffrement

message chiffr par K

Algorithme de dchiffrement

Le serveur reoit le message clair P

Cl K

Cl K

Le message en clair est transform avec un algorithme de chiffrement paramtr par une ou plusieurs cls K. Ce chiffrement peut tre ralis par l'utilisateur, le systme opratoire, ou un circuit spcialis. Le message ainsi chiffr est inexploitable pour quelqu'un qui ne possde pas la bonne cl. Il existe de nombreux algorithmes cls secrtes. On peut citer : DES (Data Encryption Standard) Cest un standard amricain adopt en 1977 puis devenu standard ANSI X3.92 en 1981 sous lappellation DEA (Data Encryption Algorithm). La norme DES prend son origine dans lalgorithme LUCIFER dIBM. Elle utilise des cls de 56 bits. Cette mthode de chiffrement est actuellement considre comme peu sre pour une attaque disposant de trs gros moyens informatiques. Elle est tout de mme encore souvent utilise dans les milieux bancaires o le niveau de scurit apport par cette technique est jug suffisant. Triple DES Cette technique double la scurit offerte par le DES grce lutilisation de 3 passes du DES de base avec 2 cls distinctes (ou 3 cls selon l s implmentations). La longueur de la e cl passe dans ce cas 112 bits (2 x 56 bits). Les performances en vitesse de chiffrement sont bonnes et le niveau de scurit est suffisant pour des applications ne ncessitant pas un trs haut niveau de scurisation (de type militaire). Cette technique est actuellement trs utilise dans les milieux bancaires, surtout lorsque ceux-ci ont dj lexprience du DES ce qui conduit alors une volution lgre des systmes de chiffrement et des habitudes existantes. Il faut dire quune attaque brutale sur une cl de 112 bits ncessite dj quelques moyens pour le moins significatifs.

17

Pour illustration, la logique interne de DES est la suivante :

LOGIQUE INTERNE DE DES

Entre 64

Sortie 64

Cl 56 + 8

Permutation Initiale (IP) 32 Eclatement bits poids fort/poids faible 32

Permutation Finale (1/IP) 28 C : 28

Permutation et formatage de la cl (PC1) 28 Registres Dcalage circulaire D : 28

32

L : 32 32

R : 32 32

Concatnation de C et D (PC2) puis transposition pour gnrer 16 cls dites drives Gnration de Cl

Attente 32
32

Expansion de 32 48 bits Bloc de 16 cls sur 48 bits

XOR

Permutation 32

S B O X

Dcoupage en 8 blocs de 6 bits XOR 48

Applications des 16 cls aux blocs de 48 bits

Selection Box : S-Box

Le but ici nest pas de dcrire le fonctionnement prcis du DES mais de donner un aperu des techniques mises en uvre et de constater quelles reposent majoritairement sur des principes dont certains viennent dtre voqus. Globalement, lalgorithme fonctionne sur le principe de permutations, de substitutions et dadditions modulo 2. Le dchiffrement utilise le mme principe mais en ordre inverse. Les substitutions rpondant au standard DES sont connues sous le nom de S -BOX et sont dcrites par huit tables diffrentes. Ces S -BOX ont des entres de 6 bits et des sorties de 4 bits et effectuent des substitutions avec les donnes en entre :
R L

E x p a n s i o n

C l X O R

6 S 1 S 2 S 3 S 4 S 5 S 6 S 7 S 8

P e r m u t a t i o n

X O R

18

Les S-Box contiennent 8 tables de substitution prdfinies. Lors de larrive des 6 bits, les bits 1 et 6 slectionnent la ligne dans la table de substitution et les bits intermdiaires la colonne. Une autre technique mettant en uvre des permutations peut tre utilise. On parle alors de P-Box (Permutation Box). Il existe dans la pratique 4 manires diffrentes de chiffrer et de dchiffrer avec du DES : le traitement des donnes par bloc de 64 octets, ces blocs tant traits les uns aprs les autres (ECB : Electronic Code Book), lencodage du premier bloc de 64 octets commence par lapplication dun OU Exclusif sur le premier bloc chiffr avec un nombre gnr alatoirement, puis lapplication dun OU Exclusif entre chacun des blocs chiffrer venir et les blocs qui les prcdent avec enfin, pour chaque bloc, le chiffrement par lalgorithme du DES aprs lopration du OU Exclusif (CBC : Cipher Block Chaining), les modes OFB (Output Feedback) et CFB (Cipher Block FeedBack) plutt utiliss dans le cas o les blocs chiffrer sont dune taille infrieure 64 octets. La mthode ECB est utilise de prfrence lorsquil est ncessaire daccder des donnes sans liens avec les blocs prcdents. La mthode CBC est prfrable dans les autres cas.

En ce qui concerne le Triple DES et comme cela a dj t rapidement voqu, plusieurs techniques sont envisageables : appliquer 3 fois le DES sur les donnes dentre avec 3 cls diffrentes ou appliquer 2 fois le DES et une fois le DES invers avec 2 cls diffrentes. En gnral, cest la deuxime solution qui est employe :

Texte en Clair

DES Chiffrement avec cl 1

DES Invers Dchiffrement avec cl 2

DES Chiffrement avec cl 1

Texte Chiffr

Lors de la publication du DES en 1975, deux critiques avaient alors t formules son gard : la recherche exhaustive dune cl ( attaque brutale ) est envisageable, des faiblesses ont volontairement t introduites dans les S-Box par IBM sous la pression du Ministre de la Dfense Amricain (National Security Agency). 19

En ce qui concerne la premire assertion, elle est crdible pour des cls de 56 bits. Par contre, lutilisation du Triple-DES remet fortement en cause cette possibilit en portant la taille des cls 112 bits. La deuxime critique ne semble pas avoir t prouve formellement bien quun grand nombre dtudes aient t menes jusqu' maintenant sur le sujet. La polmique reste donc ouverte. Au niveau des performances, le DES est plus rapide que des systmes de chiffrement de type RSA ( cls publiques et prives). Les valeurs e stimes sont : 100 fois plus rapide que RSA dans le cadre dun chiffrement logiciel et environ 1000 fois plus rapide que RSA dans le cadre dune ralisation matrielle (donnes datant de 1993). En conclusion, le DES est probablement peu sr pour un attaquant ayant de gros moyens. La version Triple DES assure malgr tout au niveau de la scurit des performances acceptables. Au niveau des performances du chiffrement, lordre de grandeur est peu prs celui-ci : circuit lectronique ddi : environ 1 Gigabit/s chiffrement logiciel : de lordre du Megabit/s RC2 et RC4 Ces systmes sont tous les deux dus Ron Rivest. Ce sont des alternatives DES avec des fonctionnalits peu prs quivalentes. Le principe est bas sur un mcanisme cls variables de 1 1024 bits et un flux de nombres alatoires combins ensuite par un OU Exclusif . La fiabilit de lensemble est, bien entendu, fonction de la longueur de la cl choisie. IDEA (International Data Encryption Algorithm) Cet algorithme utilise des oprations arithmtiques telles que le OU Exclusif , laddition modulo 216 et la multiplication modulo 216 + 1. La taille des cls est de 128 bits. Lalgorithme, rcent (1990), a un degr de scurit pas encore estim compltement mais il nexiste pas actuellement de technique ou de machines capables de casser IDEA. Son principe est un peu similaire DES (fonctionnement en tages) et fonctionne aussi en mode bloc. Au niveau des performances [ ROUSSEAU1996] : logiciel : environ 300 Kbit/s sur Intel 80386 33 Mhz matriel ddi : 50 200 Mbit/s 25 Mhz Dune manire gnrale, le DES, le Triple DES, RC2, RC4 et IDEA font actuellement partie des algorithmes considrs comme srs et sont souvent utiliss. La dmarche AES (Advanced Encryption Standard) Lobjectif de la dmarche AES consiste fournir un algorithme de chiffrement pour protger les informations de nature gouvernementale (selon la terminologie anglosaxonne). Cet objectif vise remplacer le DES qui joue actuellement ce rle. Cest l NIST e (National Institute of Standards and Technology) qui a t en 1997 linitiateur de cette dmarche. 20

Les principales caractristiques attendues de ces algorithmes, outre bien sr leur robustesse aux diffrentes attaques, sont dune part la disponibilit de leurs spcifications pour la communaut internationale et dautre part leur utilisation libre de droits ainsi que la facilit de leur utilisation (chiffrement de blocs de diffrente taille, rapidit, utilisation dans des ASICs ou des cartes puce, etc.) La slection quant elle sest effectue et continue seffectuer au cours de sries de confrences (AES Candidate Conference). Quinze candidats se sont dclars au dpart et lissue de la troisime confrence , cinq candidats restent en liste la date de rdaction de ce document. Ces cinq algorithmes encore en comptition ainsi que quelques principes les caractrisant sont les suivants :

Algorithme Mars

Initiateur(s) IBM

RC6

RSA Laboratories Joan Daemen Vincent Rijmen

Rijndael

Serpent

Ross Anderson Eli Biham Lars Knudsen Bruce Schneier John Kelsey Doug Whitney David Wagner Chris Hall Niels Ferguson

Quelques principes de base S-Boxes, Xor, rotations, multiplications, etc. fonctions de la cl et des donnes Xor, Rotations fonctions des donnes (issu de RC5), etc. S-Boxes, multiplications, utilisation de polynmes, etc. Utilisation de S-Boxes, Xor, permutations, etc.

Longueur Rfrences de la cl 128 448 http://www.research.ib bits m.com/security/mars.ht ml

0 255 bits http://www.rsa.com/rsa labs/aes/ 128, 192, http://www.esat.kuleuv 256 bits en.ac.be/~rijmen/rijnda el/ 128, 192, http://www.cl.cam.ac.u 256 bits k/~rja14/serpent.html

Twofish

S-Boxes, permutations, 128, 192, http://www.counterpan matrices, etc. 256 bits e.com/twofish.html

Des informations complmentaires sont disponibles aux URL fournies en rfrence. Le finaliste devrait tre connu courant 2000 et alors officiellement utilis comme standard dans de nombreux protocoles comme SSL, IPSec, etc.

21

Problme de la gestion des cls

Une description plus dtaille de cette problmatique est fournie dans le paragraphe relatif la distribution des cls. Seul laspect croissance du nombre de cl en fonction du nombre de correspondants est trait ici. En effet, dans un systme cls secrtes, le nombre de cls augmente selon le carr du nombre de correspondants tablir : n(n-1)/2. Ceci est d au fait quil est ncessaire davoir une cl secrte par paire de correspondants puisque toute communication entre individus ou sites doit rester par principe secrte. Le tableau suivant illustre la croissance du nombre de cls en fonction du nombre de correspondants :

Nombre de correspondants Nombre de cls

2 1

3 3

4 6

5 10

6 15

7 21

8 28

9 36

10 45

15 105

20

50

190 1225

Dans un systme cls secrtes, le gestionnaire de cls doit donc tre un systme souple et dont les principales caractristiques doivent tre les suivantes : capacit grer un grand nombre de cls, gestion des cls de manire centralise, possibilit de grer un renouvellement frquent et automatique des cls, scurisation pousse du serveur, seul garant du secret des cls.

Evidemment, la mise en place dun tel gestionnaire ne rsout pas le problme de linitialisation du mcanisme et toute la difficult rside dans le fait de faire parvenir sans compromission possible la 1ire cl pour tablir le dialogue. Les principales implmentations industrielles du chiffrement cls secrtes concernent les botiers de chiffrements, les systmes dauthentification du type Kerberos et dautres applications rpondant des besoins ou cas de figure spcifiques.

22

3.2 Le principe cl publique / cl prive

Ce mode de chiffrement prend sa source au dbut des annes 1970. Son principe rvolutionne le mode de fonctionnement traditionnel cl secrte. Voici une illustration de ce mcanisme tel quil a t dcrit par ses concepteurs :

Cl publique

Cl prive

Algorithme de chiffrement Donnes dorigine Donnes chiffres

Algorithme de dchiffrement Donnes dorigine

De nombreux algorithmes utilisent ce principe dont le RSA invent en 1977 (par R. Rivest, A. Shamir et L. Adleman). Historiquement, ce sont les travaux de Whitfiels Diffie et Martin Hellman qui furent la base du principe de la cl publique mme si le fondement mathmatique de la mthode tait diffrent. Le principe de calcul tait bas sur lexponentiation de grands nombres et un calcul de congruence modulo un nombre premier. Dans ce cas lexponentiation est relativement facile mais linverse est complexe. Le mcanisme des algorithmes de type RSA est relativement simple et le suivant : choisir 2 grands nombres premiers trs grands p et q (100 chiffres minimum), calculer le produit n = p * q, n tant appel le modulo de chiffrement, choisir un nombre e, plus petit que n et premier avec ((p-1) * (q-1)), on calcule ensuite d tel que d * e = 1 mod ((p-1) * (q-1)). d est calcul avec lalgorithme dit dEuclide tendu (algorithme dEuclide tendu : cet algorithme permet de calculer le PGCD entre 2 nombres et lalgorithme tendu permet, lui, de calculer linverse dun nombre modulo n, le cas qui nous proccupe ici). e et d sont respectivement les composants publics et privs. d est linverse de e dans larithmtique modulo (p-1)(q-1), la cl publique est donne par le couple (n,e) et la cl prive par d. p et q doivent tre tenus secrets ou dtruits. Ici, on suppose quil est difficile de retrouver la cl prive d partir de la cl publique (n,e). La fiabilit du systme est base sur ce principe. Le chiffrement dun message est alors relativement simple : dcouper le message en blocs de mme longueur n (en pratique 200 octets ou plus) e chiffrer en utilisant la formule : c = m mod n o c correspond au bloc chiffr et m au bloc dorigine pour dchiffrer, il suffit de faire m=cd mod n

23

Voici une illustration simple du principe : soit 2 valeurs pour p et q : 47 et 59. Ici les valeurs sont faibles et ne correspondent pas de grands nombres entiers pour faciliter la comprhension on calcule dabord le produit n = p * q soit 47 * 59 = 2773 on choisit ensuite une cl e, premire par rapport au produit n. Par exemple, e=17 on calcule ensuite d (par lalgorithme dEuclide tendu ) tel que d * e = 1 mod ((p1)(q-1)), soit d = 157. Il est possible de le vrifier en faisant : 17*157=2669 puis en vrifiant que 2669 mod (46 * 58) = 1 on a donc une cl publique (17,2773) et une cl prive (157,2773). Cette dernire doit tre conserve labri de toute indiscrtion Dsormais, il est possible de chiffrer un message. En prenant par exemple les 4 chiffres 0003, le chiffrement de cette valeur donne (000317 ) mod 2773 soit 1553. On peut remarquer ici que le chiffrement sest fait avec la cl publique et que donc seul le dtenteur de la cl prive peut retrouver le message dorigine. Cest ce que lon vrifie en faisant : (1553157 ) mod 2773 qui donne 3, le message de dpart. En ce qui concerne lalgorithme dEuclide tendu , cet algorithme est bas sur lalgorithme dEuclide classique . Cet algorithme est un algorithme permettant de trouver le plus grand commun diviseur entre deux nombres entiers (PGCD). Le principe de base est assez simple : si a et b avec a,b et b < a ont un diviseur commun d alors a-b, a-2b, ... sont aussi divisibles par d. Le cas o a - nb = 0 signifie que a est divisible par b, ce qui rsout le problme. La proprit se traduit ensuite par le fait que lon prend n comme quotient entier de la division de a par b et (a -nb) est alors le reste. Prenons un exemple : dterminer le PGCD de 522 et 453. Cela donne : (a) 522 (b) 453 (c) 522 - 453 = 69 (d) 453 - 6*69 = 39 (e) 69 - 39 = 30 (f) 39 - 30 = 9 (g) 30 - 27 = 3 (h) 9 - 9 = 0

(a - b) (b - 6c) (c - d) (d -e) (e - 3f) (f - g)

La valeur 0 arrte lalgorithme et 3 se trouve donc tre le PGCD. Lalgorithme dEuclide tendu consiste utiliser lalgorithme dEuclide classique pour trouver x tel que a * x = 1 mod n. Voici un exemple avec les mmes valeurs que celles prises pour RSA, savoir d * 17 = 1 mod 2668, 2668 correspondant au produit (p-1)(q-1). Quel est dans ce cas la valeur de d ?

Et bien, comme prcdemment, on a : 24

(a) 2668 (b) 17 (c) 2668 - 2652 = 16 (d) 17 - 16 = 1

0 1 (a - 156 b) (b - c) -156 157

La valeur 1 arrte lalgorithme et la valeur de d vaut alors 157. Posons-nous maintenant une question toute lgitime : pourquoi RSA fonctionne ? Ce paragraphe, un peu thorique, nest pas fondamental pour la comprhension de lensemble mais illustre malgr tout les principes sous-jacents au RSA. Avant de commencer, rappelons tout dabord deux notions essentielles la dmonstration : Fonction dEuler : Soit (n) le nombre dentiers infrieurs n et premiers avec n Dans ce cas, si n est premier . alors (n) = n - 1 et si n = p * q avec p et q premiers alors (n) = (p-1) * (q-1). Petit thorme de Fermat gnralis par Euler : Si a et n sont premiers entre eux alors a(n) mod n = 1. Fort de cela et en nommant E la fonction de chiffrement et D la fonction de dchiffrement, vrifions que lon a bien : D(E(M)) = M. On a : soit D(E(M)) = ((M)e mod n)d mod n D(E(M)) = (Me)d mod n = Med mod n

On peut noter ici que D(E(M)) = E(D(M)). Or, do car e.d = 1 mod ((p-1)(q-1)) soit e.d 1 + j*z avec z = (p-1)(q-1) Med = Mjz * M mod n = M mod n Mjz mod n = (Mz)j mod n = 1j = 1 en appliquant le thorme dEuler

Lalgorithme RSA est donc bien rversible et permet de faire deux choses essentielles : chiffrer un message avec une cl publique : seul le dtenteur de la cl prive associe pourra alors lire le message chiffrer un message avec une cl secrte : tous les possesseurs de la cl publique associe pourront alors lire le message mais auront en plus la certitude que seul le possesseur de la cl prive a pu chiffrer le message Au niveau des performances, un algorithme de type RSA est environ 1000 fois moins rapide que DES. Pour 512 bits, lordre de grandeur est de 64 Kbit/s et les 1 Mbit/s sont envisageables court ou moyen terme. Cette mcanique est trs importante comprendre car elle est la base de systmes tels que PGP ou SSL, ce dernier systme tant utilis actuellement dans les navigateurs Web ou la messagerie scurise par exemple. Voici un exemple dutilisation de cls asymtriques tel quil est utilis dans PGP et combin avec des cls symtriques : 25

Texte chiffr avec une cl K de type IDEA ou DES

La cl K est chiffre selon le principe RSA avec la cl publique E du destinataire

Le message est compos de la cl K chiffre selon RSA et dun texte chiffr selon un algorithme IDEA ou DES

Le message est transmis au destinataire La cl K est dchifre grce la cl prive D selon RSA

Le texte est dchiffr en utilisant un algorithme de type IDEA ou DES avec la cl K

Une autre proprit utilise par PGP mrite dtre mentionne : le principe de la signature dj voqu. Ce principe consiste : Gnrer d'un code qui identifie, par un nombre de taille fixe, le texte lui-mme Chiffrer cette valeur par RSA avec la cl prive de l'expditeur, permettant ainsi aux correspondants de vrifier la validit avec la cl publique de l'expditeur. Un autre algorithme d Diffie et Hellman (1976) et historiquement le premier algorithme traitant du chiffrement cls asymtriques est fort intressant tudier. Son principe peut se schmatiser de la manire suivante :

Entit A

A et B se mettent daccord sur 2 nombres q et trs grands

Entit B

Choix, au hasard, dun grand nombre X a Calcul de Ya = X a mod q Envoi de Ya lentit B Calcul de K ab = (Yb ) Xa mod q soit K ab = ( )XaXb mod q

Choix, au hasard, dun grand nombre X b Calcul de Y b = X b mod q Envoi de Y b lentit A Calcul de K ab = (Ya )Xb mod q soit K ab = ( )XaXb mod q

Kab devient dsormais la cl de session entre les entits A et B. Cet algorithme est bas sur la difficult calculer des logarithmes discrets. En effet, un tiers connaissant q et et interceptant Ya connat alors Ya = Xa mod q. La difficult consiste alors calculer Xa ! 26

Pour rsumer, les avantages et inconvnients du chiffrement asymtrique sont les suivants : difficult trouver de grands nombres premiers, ncessit de choisir des cls secrtes et publiques assez longues, difficult raliser des oprations modulo n rapidement, complexit algorithmique de la mthode, malgr tout, solution assez gnrale et sre si la longueur des cls et les prcautions demploi sont respectes.

La sret dun algorithme de type RSA dpend en fait de 3 facteurs : la non divulgation des nombres p et q, la difficult quil existe factoriser des grands nombres, labsence de mthodes mathmatiques actuellement connues permettant de calculer la cl prive d partir du couple (n,e), savoir la cl publique. Les deux dernires remarques sont importantes car actuellement il existe beaucoup de tentatives concernant le cassage de ce type de chiffrement. La technique la plus prometteuse est base sur la factorisation des grands nombres. Mais la solution reste encore hors de porte pour des longueurs de cl suffisantes. A titre dexemple, une cl de 1024 bits ncessiterait environ 280 000 ans de calcul pour un ordinateur ayant une puissance de traitement de 10 000 MIPS [GARFINKEL1995].

27

3.3 Notarisation
Le rle de la notarisation consiste viter un dni de responsabilit au cours dun change entre deux entits. Cet aspect peut tre essentiel dans certains domaines tels que le milieu bancaire par exemple. Pour viter tout dni, il existe deux types de rponses : la responsabilit du secret des cls : entirement bas sur la bonne foi des intervenants. Dans ce cas, les conflits ne peuvent se rgler en gnral que devant la justice, la notarisation. Le premier cas ne concerne pas rellement le cadre de notre propos. Le fonctionnement du deuxime cas, quant lui, peut tre illustr comme suit :

Entit A
Cl Prive : P A Cl Publique : KA

Notaire N
Cl Prive : P N Cl Publique : KN

Entit B
Cl Prive : P B Cl Publique : KB

P A(A,B,M) A veut envoyer M B. Le tout est chiffr avec PA N journalise la transaction T, gnre une cl de session K Session et chiffre M avec K Session PN(K Session(M),T)

A retransmet le message B

P N(K Session(M),T) B ne peut rien faire du message. Il lui faut demander la cl de session au notaire

PB (T) Le notaire renvoie Ksession. Ici, il est sr que B a demand lire le message : P N(K Session) difficile de rpudier ensuite !

Le message M peut tre lu. Renvoie dun acquittement ventuel au notaire PB (ACK(M))

Le passage par un tiers, le notaire, permet de consigner les changes. Cette notarisation est plutt fiable, sous rserve davoir pleine confiance en le notaire qui traite tous les changes !

28

3.4 Le positionnement du chiffrement dans les protocoles rseau

Les principes de chiffrement symtrique et asymtrique qui viennent dtre dcrits peuvent tre utiliss plusieurs niveau dans les couches protocolaires. Lemploi du chiffrement un niveau donn dpend la fois des performances et des caractristiques attendues. Ainsi, des vitesses de chiffrement leves sont requises pour la construction dun quipement destin un VPN alors que pour de la messagerie scurise, des aspects plus fonctionnels sont indispensables. Globalement, il existe quatre possibilits pour mettre en uvre du chiffrement au niveau des coches protocolaires :

au niveau matriel, au niveau des couches rseau, au niveau transport, au niveau application.

Le schma qui suit illustre les diffrentes possibilits avec quelques protocoles classiques :

Commerce lectronique : Set, C-Set S-HTTP Telnet PGP - S/MIME SMTP SSL TCP IPSec : AH + ESP Couches basses IPv4 IP (VPN matriels et logiciels) AH : Authentication Header ESP : Encapsulating Security Payload

Un constat important dans cette rpartition est que plus le chiffrement est ralis dans les couches basses, plus ce chiffrement est transparent pour les applications. A contrario, plus le chiffrement est positionn dans les couches hautes, plus le niveau de fonctionnalit apport est potentiellement important mais au dtriment de la transparence.

29

De la distribution des cls aux infrastructures cls publiques

Une infrastructure cls publiques (PKI) permet de mettre en uvre une scurisation des changes sur un rseau public ou priv dont la scurit, la base, nest pas garantie. Dans ce contexte, le principe consiste employer des techniques de chiffrement asymtrique dont les cls publiques sont certifies par une autorit de certification. Un mode de chiffrement symtrique peut aussi tre utilis (cls de session) mais une fois la session tablie par le mode asymtrique (et cela pour des raisons qui vont tre dtailles dans la suite). Pour rpondre la problmatique, une PKI doit alors fournir des certificats numriques contenant des cls publiques et un service de stockage, de diffusion et de rvocation des cls qui sont employes. Fonctionnellement, une PKI est donc, de base, constitue des lments suivants :

une autorit de contrle charge de vrifier la lgitimit dune demande de certificat

avant dlivrance (niveau organisationnel), une autorit de certification avec un gestionnaire de certificats (moyen logiciel) charge de gnrer et vrifier les certificats (niveau mise en uvre), un ou plusieurs annuaires (ou tout autre moyen de diffuser les certificats) dont le rle consiste stocker et diffuser les certificats (niveau organisationnel et mise en uvre). Il est important de noter ici que la problmatique de dpart laquelle rpond une PKI rside dans la gestion des cls, leur diffusion et le contrle de leur validit. La gestion des cls est une composante dlicate de la mise en uvre de techniques de chiffrement. Cest pourtant un lment sur lequel repose une bonne partie de la fiabilit du dispositif. Dans ce qui suit, ces lments sont repris, brivement dans le cas des cls symtriques, et plus amplement dans le cas des cls asymtriques, principe au cur du fonctionnement dune PKI.

4.1 La gestion des cls prives

Comme il la dj t montr ce sujet, le nombre de cls grer en mode symtrique croit en fonction du carr du nombre de liaisons. Pour cette raison et de part le fait que la cl doive rester strictement secrte, sa distribution est rellement problmatique. La mthode la plus sre consiste videmment dlivrer physiquement les cls sur chaque entit concerne, sans passer par le support dun rseau informatique. Mais, cette mthode devient trs vite inoprante en tenant compte de la possibilit daugmenter le nombre des entits devant changer et le ncessaire renouvellement des cls intervalles rguliers en fonction de lusure de cette cl. Diverses autres solutions plus opratoires existent pour rsoudre ce problme. Elles passent toutes par la mise en place dune centre de distribution des cls. Kerberos est un exemple dimplmentation souvent utilis dans le cas des cls secrtes. Schmatiquement, le principe dun centre de distribution des cls (CDC) est le suivant : 30

Entit A
A, K A(B,KS) Initiative de la connexion

Centre de Distribution des Cls

Entit B

Transmission lentit B de la requte de A

K B(A,K S)

Dialogue maintenant possible avec la cl KS

Lentit A voulant dialoguer avec B en utilisant la cl de session KS commence par envoyer sa demande au CDC avec la cl secrte K connue seulement de lentit A et du CDC. Le A CDC transmet alors la demande lentit B avec la cl secrte KB. A lissue de ces deux changes, les entits A et B peuvent dialoguer avec la cl de session KS. Ainsi, chaque entit ne connat rellement quune cl : celle qui permet de dialoguer avec le CDC. La charge de la connaissance de toutes les cls est reporte sur le CDC. Dans ce schma un peu idalis , il existe une faille classique qui consiste pour lattaquant se faire passer pour un tiers au niveau des changes entre entits : lattaque du passeur de seau . Cette attaque peut tre vite en rendant impossible le rejeu des connexions, ce qui se traduit en fait par une cl de session KS ayant la proprit dtre unique. Les techniques les plus utilises dans ce cas sont lestampillage de la cl de session par horodatage et ajout dune valeur alatoire spcifique la session (avec un grand espace de numrotation pour rendre trs problmatique le rejeu). Ce schma mettant en uvre un CDC est la base de toutes les solutions concernes par le sujet de la distribution des cls symtriques.

4.2 Les cas des cls publiques

4.2.1 Nature des cls et problmatique associe

Il est possible de distinguer deux types de cls aux vocations diffrentes :

les cls court terme : utilise une seule fois, pour une session ou pour un
seul message et ayant pour vocation dtre ensuite dtruites (en gnral, ce sont tout de mme des cls de session symtriques qui sont utilises dans ce cas), les cls long terme : utilise pour la confidentialit ou lauthentification. Dans la catgorie des cls long terme, il est aussi possible de faire la distinction entre les cls de chiffrement et les cls destines lauthentification. Lutilisation respective de ces cls fait que lusure de chacune est diffrente. Ainsi la cl de chiffrement est beaucoup plus souvent utilise que la cl dauthentification et donc en principe renouveler une frquence plus leve. 31

4.2.2
4.2.2.1

Modle PGP et Autorits de Certification Le modle PGP

Plusieurs solutions sont envisageables pour traiter les problmes qui viennent dtre numrs relativement la gestion des cls publiques, leur validit et au degr de confiance associ. Il existe tout dabord les solutions bases sur le modle PGP (Pretty Good Privacy) qui consiste construire un modle de certification mutuelle dont la fiabilit repose sur la confiance rciproque dune chane de certification. Ce modle peut tre illustr par lexemple suivant :

Relation de confiance

Paul

Jacques

Pierre

Roger Marcel

PGP Web of Trust

Si dans lexemple prcdent, Jacques connat Paul et Roger qui connaissent eux-mmes Marcel et Pierre, alors, dans la logique du modle, Jacques est sr de la cl publique de Pierre ! Il accepte cette cl publique car il a confiance en Paul et Roger. Mais comment qualifier cette confiance ? La nature mme de cette chane de fiabilit btie sur un principe de confiance rciproque fait que ce modle est difficilement recevable dans une perspective qui se veut plus gnrale alors quil peut savrer acceptable pour un petit nombre dindividus. De plus, PGP est lorigine trs orient vers la scurisation dans un contexte de messagerie (bien que dsormais des extensions existent pour le chiffrement de disques durs et une mise disposition facilite des cls publiques). Les PKI nintgrent donc pas les principes de PGP dans leur mode de fonctionnement.
4.2.2.2

Les autorits de certification

32

Une autre solution consiste utiliser une autorit de certification (CA : Certificate Authority). Par dfinition, une autorit de certification se pose comme garante de la prennit du lien entre une cl publique et une entit quelconque propritaire de ladite cl publique (personne physique, organisme, serveur, etc.). Pour rpondre au problme dchelle que peut poser le nombre dentits pouvant possder un certificat (point dachoppement du chiffrement symtrique et du modle PGP), le principe de la mise en place dune hirarchie d'autorits de certification est prvue et permet de garantir, en cascade, la validit du lien entre une cl publique et son dtenteur. Dans ce cas, l'autorit au sommet de la hirarchie valide aprs avoir pris toutes les prcautions ncessaires les cls des autorits immdiatement subordonnes et ainsi de suite pour chaque tage de dlgation des autorits de certification. Globalement, une autorit de certification permet donc dassurer lauthentification dun serveur ou dun utilisateur par exemple via une cl publique certifie et contenue au sein dun certificat X509. Historiquement, les certificats taient utiliss pour protger laccs des annuaires de type X500.
Country C=FR

Organisation C=FR, O=CNRS

Organisational Unit C=FR, O=CNRS, OU=DSI

Common Name C=FR, O=CNRS, OU=DSI, CN=PORTE Olivier

Le DN (Distinguished Name) pour PORTE Olivier est unique : C=FR, O=CNRS, OU=DSI, CN=PORTE Olivier

De ce fait, la structure dun certificat X509 reflte travers ses composantes, son lien avec X500. Au niveau du nomage par exemple, X509 utilise le mme nomage que X500 travers la notion de DN (Distinguished Name) qui garantit lunicit du nomage. Voici un exemple de nommage au niveau X500 (et donc X509) pour ce qui concerne le DN de lun des rdacteurs de ce document :

Le DN se retrouve aussi au niveau du certificat X509 dans les champs relatifs lautorit de certification et au propritaire du certificat. Malgr tout, il est possible de remarquer que la difficult avec un modle arborescent de ce type consiste rendre compte concrtement, selon les cas, du DN dune personne au sein dune organisation. 33

Comment, par exemple, signifier quune personne puisse appartenir deux entits fonctionnelles diffrentes ou une entit fonctionnelle et une entit gographique ? Actuellement, la meilleure rponse ce type de question consiste crer plusieurs vues organisationnelles limage de ce qui suit :

Autorit de certification 1 Vue organisationelle 1

Autorit de certification 2 Vue organisationelle 2

Autorit racine

Serveurs de certificat Dlgation dautorit

Dlgation dautorit

Par extension et concernant le problme relatif au stockage des cls, on peut comprendre que le choix du nommage dans le mode X500 influence voire impose la manire dont le stockage des cls peut tre envisag ds maintenant et avec certitude dans le court terme. Actuellement, ces cls se retrouvent souvent dans des fichiers plats , dans des bases de donnes relationnelles, dans des registres de type Windows ou dans des bases de donnes propritaires. Lintrt dun nommage de type X500 est alors de pouvoir grer le stockage et la diffusion des cls via des annuaires de type X500 avec un protocole daccs comme LDAP (Lightweight Directory Access Protocol). Concernant linteraction entre lautorit de certification et la demande de certificat, la cinmatique est la suivante :

Gnration cl prive / cl publique

Demande de certificat + cl publique

Certificat

cl prive

Autorit de Certification

cl publique
Certificat

Publication

Base de Certificats Consultation

34

Lautorit de certification atteste que la cl appartient bien celui quil prtend tre par tous les moyens jugs ncessaires. Ces moyens peuvent aller de la simple rception dune demande via messagerie un contrle trs stricte de la demande effectue (preuve de lidentit, enqute, etc.). Le degr de confiance accord lautorit de certification dpend bien videmment du srieux et de la rigueur de lautorit de contrle et conditionne la fiabilit de la PKI toute entire. Ce point trs important sera repris plus en dtail dans la suite du document et mettra en vidence que fondamentalement, utiliser un certificat revient faire confiance lautorit de certification. 4.2.3 Le certificat X509

Le certificat X509 fait lobjet dune normalisation par lISO. Il a t ralis par lIETF (Internet Engineering Task Force) et est identifi par un Distinguished Name (DN). Cest concrtement un document lectronique attestant qu'une cl publique est bien lie une organisation, une personne physique, etc. Ce document lectronique contient une cl publique, un certain nombre de champs la norme X509 et une signature. C'est la liaison des attributs des champs et la cl publique par une signature qui constitue un certificat. Un certificat peut tre un faux; c'est sa signature par une autorit de certification (CA) qui lui donne une authenticit. Globalement, la composition dun certificats x509 est la suivante :

Version (v3 actuellement) Numro de srie (unique par CA) Algorithme de Signature du CA Nom du CA (DN) Priode de validit Sujet du certificat (DN) Caractristiques de la cl certifie : Algorithme utilis Cl Publique Extensions ventuelles : CRL(liste de rvocation), adresse ml, Estampille du CA : Hash sign

35

En voici un exemple complet pour illustration :

Certificate: Data: Version: 3 (0x2) Serial Number: 7 (0x7) Signature Algorithm: md5WithRSAEncryption Issuer: C=FR, ST=France, L=Meudon, O=CNRS, OU=DSI, Olivier/Email=porte@dsi.cnrs.fr Validity Not Before: Sep 11 09:49:27 1998 GMT Not After : Sep 11 09:49:27 1999 GMT Subject: C=FR, ST=France, L=Meudon, O=CNRS, OU=DSI, Olivier/Email=porte@dsi.cnrs.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d3:8a:78:15:90:bb:7f:62:50:5d:f4:37:e1:7f: ee:fd:7c:0e:86:c2:1f:50:d9 Exponent: 65537 (0x10001) X509v3 extensions: Netscape CA Revocation Url: http://anjou.dsi.cnrs.fr/ca-crl.pem Netscape Comment: Autorite de Certification CNRS-DSI Signature Algorithm: md5WithRSAEncryption 47:27:8b:b6:4e:7c:22:aa:00:93:9a:c1:e0:04:ad:55:cf:51: c7:11 -----BEGIN CERTIFICATE----MIIC7TCCAlagAwIBAgIBBzANBgkqhkiG9w0BAQQFADCBhjELMAkGA1UEBhMCRlIx fKkhXGEkWafhxb3ilCqAFxif4J7DPEX2fgmLEcwDqccR -----END CERTIFICATE-----

CN=PORTE

CN=PORTE

En plus des champs classiques dont le rle est relativement clair, un certificat peut possder un certain nombre dextensions. Ces extensions sont des couples forms dun type et dune valeur avec en plus un tmoin caractre optionnel. Ce tmoin permet de savoir, lorsquil est positionn, si lextension doit imprativement tre prise en compte ou, dans le cas contraire, tout simplement ignore. La nature de lextension peut tre diverse (une adresse IP, un alias, etc. ) donnant ainsi la possibilit de dfinir des profils de certificats. Ces profils peuvent tre de plusieurs types : banques, organismes publics, associations, etc. et donc tre utiliss de multiples fins. Enfin, le dernier point, touchant la fois aux certificats X509 proprement dit et aux autorits de certification, concerne la rvocation des certificats. Il est prvu dans le certificat lui-mme de pouvoir fournir un pointeur sur une CRL (Certificate Revocation List) afin de contrler auprs de lautorit de certification la validit dun certificat. Le problme est que la gestion de la rvocation des certificats via une CRL (qui est en gnral implmente sous la forme dune URL) ne fonctionne pas actuellement de manire satisfaisante. Les raisons de cette mauvaise gestion sont lies la difficult de limplmentation, aux obstacles lutilisation, la vulnrabilit aux attaques par dni de service et aux problmes de performances. 36

Cet aspect traduit une relle difficult et une contradiction entre les principes de b de la ase scurit qui impliquent de la rapidit quant la suppression des privilges de tous ordres en cas de problme, et limpossibilit voire au mieux la difficult et la lenteur quil y a rvoquer un certificat. Il existe aussi une dualit certaine entre la priode de validit constitutive du certificat et la liste de rvocation. Une entit voulant sassurer de la validit dun certificat devra de toute faon contrler si possible les deux critres. Malgr tout, une solution, dj sous entendue de multiples fois jusquici, consiste grer les certificats mais aussi la rvocation des certificats au sein dun annuaire. Mais, l encore, dautres inconvnients apparaissent tels que la ncessaire consultation de lannuaire chaque transaction, la disponibilit de lannuaire, les performances, etc. Le deuxime problme li la gestion de la rvocation des certificats des raisons fonctionnelles telles que le changement dadresse, de ml et en gnral de lun des attributs du certificat. Ces oprations sont courantes et ne souffrent pas non plus des dlais trop importants. Une autre consquence de ces remarques est la mise en vidence dans tous les cas de la ncessit dune structure organisationnelle complte et adapte au contexte pour toute PKI fiable.

37

Les applications du chiffrement

5 Le protocole SSL (Secure Socket Layer)
Le protocole SSL a t dvelopp par Netscape Communication Inc. de faon amliorer la confidentialit des changes de tout protocole bas sur TCP/IP. L'application la plus dveloppe est bien sr la scurisation des sessions HTTP ( Hyper Text Transfer Protocol, [HTTP]) entre clients et serveurs WWW. La premire version diffuse est SSL v2.0 [SSLV2] en 1994. C'est un standard propritaire accompagn d'une implmentation en en ANSI C libre pour un usage non commercial. Netscape a propos en 1996 une amlioration du protocole, appele SSL v3.0. La description a fait l'objet d'une proposition de standard Internet. Cette dernire est reste l'tat de draft. Elle a toutefois servi de base au dveloppement du protocole TLS (Transport Layer Security), en cours de normalisation par l'IETF (Internet Engineering Task Force).

5.1 Caractristiques du protocole SSL v2

L'un des points forts du protocole SSL est qu'il s'insre entre le protocole applicatif et le protocole TCP. Il est donc transparent pour le protocole applicatif, comme le montre la figure suivante :
SSL Handshake Protocol

HTTP

IMAP

Telnet

Autres

SSL Record Protocol

TCP

SSL assure l'authentification des extrmits du circuit de communication ainsi que la confidentialit et l'intgrit des informations transmises : le serveur s'identifie auprs du client par un certificat vrifiable par le client. Cette authentification est obligatoire. Le client peut optionnellement s'identifier auprs du serveur par les mmes mcanismes. le flux d'informations transmises entre les deux extrmits du circuit est segment en enregistrements (cf. SSL Record Protocol Specification). Chaque enregistrement est chiffr par un algorithme ngoci au moment de l'ouverture du circuit. En outre, chaque enregistrement est accompagn d'une signature MAC (Message Authentication Code) garantissant l'intgrit de l'enregistrement. 5.1.1 Ouverture de la session

Les transferts de donnes dans une session SSL sont caractriss, on l'a vu par la combinaison d'un algorithme de chiffrement et d'un algorithme de signature. Dans la suite, nous appellerons de telles combinaisons des "spcifications de chiffrement" (cipher spcifications, dans le jargon SSL). Par exemple, on utilisera IDEA avec une cl de 128 bits comme chiffrement et MD5 pour le calcul de l'empreinte. Le protocole SSL ne dfinit pas 38

une liste exhaustive des spcifications de chiffrement possibles : toute solution est acceptable, du moment qu'elle est connue la fois du client et du serveur. L'ouverture d'une session SSL a pour but d'authentifier le serveur auprs du client, de choisir les algorithmes de chiffrement et de signature, d'changer une cl de chiffrement, et, ventuellement, d'authentifier le client auprs du serveur. Le droulement de l'ouverture d'une session SSL v2.0 obit au SSL Handshake Protocol, est rsum dans le tableau ci-dessous : Squences protocole
client-hello server-hello client-master-key client-finish server-verify request-certificate client-certificate server-finish

du

Sens du flux
C= client, S= serveur

Informations changes Dfi_1, spcifs-chiffrements

Id-connexion, certificat du serveur, spcifs-chiffrement Ccl_publique_du_serveur(cl_de_session)

CS SC CS CS SC SC CS SC

Ccl_client(id-connexion) Ccl_serveur (dfi_1) Ccl_serveur (type-d'authentification, dfi_2) Ccl_client(type_de_certificat, certificat_du_client, donnes) Ccl_serveur (id-session)

5.1.2 Choix des algorithmes de chiffrement et d'empreintes Le client et le serveur s'accordent sur une spcification de chiffrement lors des deux premires squences du protocole, les squences client-hello et server-hello, dcrites ci-dessous. Le client envoie au serveur la liste des spcifications de chiffrement qu'il supporte. Il accompagne cette liste d'un dfi qui sera utilis ultrieurement (squences serververify). Le serveur renvoie un nombre alatoire, qui sera utilis comme identificateur de la connexion courante, son certificat X.509, et les spcifications de chiffrement supportes la fois par le client et le serveur. Le client est donc en mesure de slectionner dans cette liste la spcification de chiffrement qui sera utilise le reste de la session. 5.1.3 Gnration des cls de session Le client gnre une cl, dite cl-matre de la session. Il chiffre c ette cl-matre avec la cl publique du serveur et envoie le rsultat au serveur (squence client-master-key). Notons que pour s'harmoniser avec les rglementations sur l'exportation des technologies de chiffrement, il est possible que seule une partie de la cl-matre soit chiffre (par exemple 40 bits, dans le cas des versions exportables de RC4 ou RC2). Le reste de la cl transite en clair. A partir de la cl-matre, le client et le serveur vont dterminer chacun une cl de chiffrement. Ainsi, les enregistrements mis par le client ne sont pas chiffrs avec la mme cl que ceux mis par le serveur. La manire dont sont calcules ces cls dpendent de la spcification de chiffrement choisie l'tape prcdente. Par exemple, dans le cas de 39

chiffrements s ymtriques par RC2, RC4 ou IDEA et d'une empreinte par MD5, les cls sont gnres comme suit : la cl de chiffrement du client est forme de l'empreinte MD5 de la cl-matre, suivie du caractre ASCII "0" (0x30), suivi du dfi envoy par le client lors du client-hello, suivi de l'identificateur de connexion envoy par le serveur lors du server-hello. Cette cl est galement utilise par le serveur pour dchiffrer les informations transmises par le client. la cl de chiffrement du serveur est forme de l'empreinte MD5 de la cl-matre, suivie du caractre ASCII "1" (0x31), suivi du dfi envoy par le client lors du clienthello, suivi de l'identificateur de connexion envoy par le serveur lors du serverhello. Cette cl est galement utilise par le client pour dchiffrer les informations transmises par le serveur. Le client a termin sa phase d'initialisation et il le notifie au serveur (squence clientfinish). Pour ce faire, il chiffre l'identificateur de connexion et envoie le rsultat au serveur. Symtriquement, le serveur renvoie dans la squence server-verify le rsultat du chiffrement du dfi propos par le client dans la squence client-hello. Cette tape permet au client de vrifier qu'il est bien en communication avec le serveur qui dtient la cl prive associe la cl publique prsente dans le certificat transmis lors de la squence server-hello. En effet, seul ce serveur est capable de dchiffrer le message contenant la cl-matre et d'en dduire la cl correcte pour chiffrer le dfi. 5.1.4 Authentification du client L'authentification du client est optionnelle. Si le serveur souhaite que le client s'authentifie, il lui transmet une requte de certificat (squence request-certificate). Cette requte contient un dfi et le type d'authentification souhait par le serveur (par exemple, chiffrement du dfi par RSA et signature par MD5). Le client renvoie le type de son certificat, son certificat et la signature d'une combinaison d'informations permettant au serveur de vrifier que le client est bien le propritaire du certificat. 5.1.5 Fin de la phase d'ouverture de la session L'ouverture de la session est se termine par la squence server-finished. Le serveur gnre un identificateur de session et le transmet de faon chiffre au client. Le client et le serveur peuvent grer un cache dans lequel ils associent ce numro de session la clmatre. Pour toutes les connexions ultrieures entre le client et le serveur, les squences clienthello contiendront l'identificateur de session. Si le serveur dispose toujours dans son cache cet identificateur de session, alors le transfert du certificat du serveur (squence server-hello) et le transfert de la cl-matre (squence client-master-key) sont supprims. La phase d'ouverture de session en est acclre d'autant.

40

5.1.6 Le flux des donnes Le flux de donnes entre le serveur et le client est segment en enregistrements, selon le SSL Record Protocol. Chaque segment est compos d'un entte de 2 ou 3 octets suivi d'un MAC (Message Authentication Code), suivi des donnes transfrer et suivi ventuellement de caractres de bourrage. Ces derniers sont utiliss pour certains algorithmes de chiffrement lorsque la taille des donnes chiffrer n'est pas un multiple de la taille du bloc de chiffrement dfini par l'algorithme.

Ldata

Lb

MAC

Donnes transfrer

Bourrage

Lb
Entte : 2 ou 3 octets Total donnes : Ldata octets

Le bit de poids fort du premier octet indique le type d'entte : s'il vaut 1, l'entte contient deux octets et les 15 bits suivants donnent la longueur totale de la partie rserve aux donnes. S'il vaut 0, l'entte a trois octets, le bit suivant n'a pas de signification en SSL v2.0, les 14 bits suivants donnent la longueur de la partie rserve aux donnes, les 8 bits suivants donnent la taille de la zone de bourrage. Le MAC est l'empreinte, calcule selon l'algorithme ngoci l'ouverture de la session, de quatre valeurs : la cl de chiffrement de l'metteur, les donnes transfrer, ventuellement les caractres de bourrage, puis le numro de squence de l'enregistrement. La scurit du protocole SSL rside dans le fait que, mis part dans les deux premires squences de l'ouverture de la session, les donnes transitent toujours de faon chiffre. En outre, elle sont toujours accompagnes d'une empreinte qui permet au destinataire de vrifier que les donnes n'ont pas t dlibrment altres en cours de transfert.

5.2 Caractristiques du protocole SSL v3

Le protocole SSL v3 [SSLV3] corrige un certain nombre de faiblesses de la version 2 et apporte de nouvelles fonctionnalits. En plus du protocole d'ouverture de session (SSL Handshake Protocol), SSL v3 prvoit deux protocoles supplmentaires : le protocole d'change de spcifications de chiffrement (SSL Change Cipher Spec) et le protocole d'alerte (SSL Alert Protocol). Tous deux, l'instar du SSL Handshake Protocol, s'appuient sur le protocole de transfert d'enregistrement (SSL Record Protocol). Le messages changs par ces protocoles sont donc chiffrs ds que possible. Le protocole d'alerte est utilis pour la transmission de codes d'erreurs entre le client et le serveur. Les codes d'erreurs sont accompagns d'un indice de svrit de l'erreur (avertissement, erreur fatale). Le protocole SSL v3 spcifie que si une erreur fatale est dtecte lors d'une session, alors la session doit tre immdiatement interrompue et doit tre efface du cache des sessions, la fois sur le client et sur le serveur. Ainsi, une erreur dans le protocole SSL force, lors de la prochaine ouverture de session, la rengociation des spcifications de chiffrement et la gnration d'une nouvelle cl-matre. Le protocole d'alerte est galement utilis pour indiquer la fin d'une session entre le client et le serveur. Cette notion n'existe pas dans SSL v2, o l'une des extrmits indique la fin 41

d'une session SSL en fermant la connexion TCP/IP sous-jacente. Ce mcanisme rend SSL v2 vulnrable aux attaques par "troncature" : en effet, on peut trs bien imaginer un homme du milieu provoquant la fin prmature d'une session SSL en envoyant les paquets ad-hoc au client et au serveur. Dans le protocole d'ouverture de session, le serveur et le client ont la possibilit de ngocier un algorithme de compression des donnes avant leur chiffrement. En outre, lorsqu'ils transmettent leur certificat, ils transmettent galement la chane d'autorits de certification qui valide le certificat en question. De mme, lorsque le serveur demande le certificat du client, il lui transmet galement la liste des autorits de certification qu'il accepte. Le client est donc en mesure de slectionner le certificat le plus appropri.

6
6.1

Le protocole HTTPS
Comment utiliser HTTPS ?

Le protocole HTTPS est l'implmentation du protocole HTTP (Hyper Text Transfer Protocol) au dessus de SSL. Du fait que le dmarrage d'une session SSL se fait l'initiative du client, l'utilisation de HTTPS pour le transfert de pages WWW doit tre spcifi dans l'URL (Uniform Resource Locator). Ainsi, pour une URL de la forme http://www.domaine.fr, le client tablira une connexion HTTP classique, alors que pour une URL de la forme https://www.domaine.fr, le client ouvrira une session SSL avec le serveur, et utilisera ensuite le protocole HTTP au dessus de cette session. La plupart des navigateurs informent l'utilisateur lorsqu'une page a t obtenue par HTTPS. Ainsi, dans Netscape Communicator, le bouton "Scurit" s'entoure d'un liser jaune. Microsoft Internet Explorer affiche un cadenas dans le bas de la page. En outre, lorsqu'en cours de navigation on passe d'une page obtenue par HTTP une page obtenue par HTTPS, ou inversement, le navigateur affiche un avertissement l'utilisateur. Le protocole HTTPS est communment utilis dans les applications de commerce lectronique, au moins dans la phase de transfert des coordonnes bancaires (numros de cartes bancaires, notamment). Ce n'est bien sr pas la seule application, comme on le verra dans la suite. Notons qu'il est frquent d'entendre parler de "serveur WWW scuris" ds qu'il est en mesure d'changer des pages par HTTPS. Si HTTPS est, probablement, la meilleure solution pour changer des informations en toute scurit entre un client et un serveur, il faut garder l'esprit que seul ce transfert est rellement scuris. L'utilisation de HTTPS n'augmente en rien la scurit du serveur lui-mme, ni de l'application base sur HTTPS : comme on le verra d le paragraphe concernant les scripts CGI, une application au dessus ans de HTTPS peut prsenter un degr de scurit acceptable vis--vis d'un utilisateur extrieur, mais un degr de scurit nul pour un utilisateur ayant un compte (par exemple, un login Unix) sur le serveur.
6.2

Dmarrer un serveur Apache avec mod_ssl

La mise en uvre de HTTPS dans un serveur WWW est trs dpendante du serveur luimme. Nous avons donc choisi de dcrire la procdure pour installer et configurer le module mod_ssl v2.2 [MODSSL] dans un serveur Apache 1.3.x. 42

L'installation du module mod_ssl ncessite au pralable d'installer une version relativement rcente de OpenSSL [OPENSSL]. De plus, mod_ssl s'insre au niveau source dans Apache, si bien que la distribution de mod_ssl est dpendante de la version d'Apache utilise. Les exemples ci-dessous dcrivent l'installation pour une version 2.3.5 de mod_ssl, s'insrant dans une version source 1.3.6 d'Apache et utilisant la version 0.9.3a de OpenSLL. Les sources de ces diverses distributions sont localiss dans le rpertoire /sources. Vous pouvez bien sr changer le nom de ce rpertoire en fonction de l'arborescence des sources sur votre systme. Nous utiliserons les conventions suivantes : les commandes commenant par l'invite '%' peuvent s'excuter dans l'environnement d'un utilisateur standard, les commandes commenant par l'invite '#' doivent s"excuter en tant qu'utilisateur privilgi (root). Avant toute chose, effectuez une sauvegarde de votre distribution courante d'Apache. 6.2.1 installer OpenSSL Aller dans le rpertoire /sources/openssl-0.9.3a contenant la distribution de OpenSSL. Taper les commandes suivantes (pour un systme Linux 5.2 ou suprieur) : % ./Configure linux-elf ; make # make install Ces commandes installent OpenSSL dans le rpertoire /usr/local/ssl. 6.2.2 installer mod_ssl dans les sources d'Apache L'installation de mod_ssl s'effectue en deux temps. Dans un premier temps, on modifie les sources d'Apache pour rajouter le module, puis on recompile et on rinstalle Apache. Allez dans le rpertoire /sources/mod_ssl-2.3.5-1.3.6 contenant la distribution de mod_ssl. Tapez les commandes ci-dessous. Vrifiez les arguments --with-apache et --with-ssl qui indiquent dans quels rpertoires trouver les sources d'Apache et de OpenSSL ; vrifiez galement que les rpertoires de destination dcrits dans le fichier config.layout d'Apache sont conformes votre installation. Dans les exemples qui suivent, nous supposerons que le rpertoire contenant les fichiers de configuration du serveur Apache (paramtre prefix du fichier config.layout) est /etc/httpd. % ./configure linux-elf --with-pache=/sources/apache_1.3.6 \ --with-ssl=/sources/openssl-0.9.3a \ --prefix=/etc/httpd --enable-shared=ssl \ --enable-shared=max \ --with-layout=config.layout:Apache On peut ensuite reconstruire Apache par les commandes suivantes : % cd /sources/apache_1.3.6 % make # make install 6.2.3 configurer Apache et mod_ssl La procdure d'installation ci-dessus a fabriqu dans le rpertoire /etc/httpd/conf un fichier d'exemple de configuration qui s'appelle httpd.conf.default. Dans les 43

exemples qui suivent, nous indiquons les lignes minimales rajouter dans le fichier de configuration httpd.conf de faon dmarrer un serveur Apache incluant SSL. Les directives ci-dessous peuvent tre rajoutes n'importe o dans le fichier httpd.conf. Nous renvoyons le lecteur au manuel de rfrence de mod_ssl pour la signification de ces directives.
LoadModule ssl_module /usr/lib/apache/libssl.so AddModule mod_ssl.c Listen 80 Listen 443 AddType application/x-x509-ca-cert .crt .der SSLSessionCache dbm:/var/run/ssl_scache SSLSessionCacheTimeout 300 SSLMutex file:/var/run/ssl_mutex SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLLog /var/www/logs/ssl_engine_log SSLLogLevel info <VirtualHost _default_:443> DocumentRoot /var/www/ssl_htdocs ErrorLog /var/www/logs/ssl_error_log TransferLog /var/www/logs/ssl_access_log SSLEngine SSLCertificateFile SSLCertificateKeyFile SSLCACertificatePath SSLCACertificateFile SSLVerifyClient SSLVerifyDepth on conf/ssl.key/server.crt conf/ssl.key/server.key conf/ssl.crt conf/ssl.crt/ca-bundle.crt require 5

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-uncleanshutdown CustomLog /var/www/logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" </VirtualHost>

6.2.4 gnrer et installer le certificat du serveur La squence d'ouverture d'une session SSL ncessite le certificat du serveur. Ce certificat, obtenu auprs d'une autorit de certification s'installe dans le fichier /etc/httpd/conf/ssl.key/server.crt du serveur Apache. De mme, la cl prive non chiffre du certificat du serveur s'installe dans le fichier /etc/httpd/conf/ssl.key/server.key. Bien souvent, on ne souhaite pas faire l'acquisition d'un certificat de serveur auprs d'une autorit de certification reconnue, comme CertPlus, Belsign, Verisign, Thawte, etc. La procdure ci-dessous dcrit comment installer un certificat de serveur auto-sign. Bien sr, ce certificat ne sera pas reconnu comme valide par les clients connects au serveur. Toutefois, les navigateurs demanderont l'utilisateur l'autorisation pour accepter ou non le 44

certificat en question. Notez bien que le nom dans le champ CN (Common Name) doit ncessairement tre celui du serveur WWW, ou bien tre une expression (par exemple : "*.lbv.fr") lorsqu'on utilise le mme certificat pour plusieurs serveurs WWW.
# cd /etc/httpd/conf # mkdir ssl.key # /usr/local/ssl/bin/openssl req -new -x509 -days 1000 -nodes \ -keyout ssl.key/server.key -out ssl.key/server.crt Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Gironde Locality Name (eg, city) []:Talence Organization Name (eg, company) [Internet Widgits Pty Ltd]:La Boutique Virtuelle Organizational Unit Name (eg, section) []:Diffusion Multimedia Common Name (eg, YOUR name) []:www.lbv.fr Email Address []:webmaster@lbv.fr # chmod 600 ssl.key/server.key

6.2.5 installer les certificats des autorits de certification Le rpertoire /etc/httpd/conf/ssl.crt accueille les certificats des autorits de certification reconnue par le serveur WWW. Ce dernier n'est en effet en mesure de valider le certificat d'un client que s'il dispose du certificat de l'autorit qui a sign le certificat de ce client. Par dfaut, l'installation de Apache et de mod_ssl n'inclut aucun certificat d'autorits de certification. Normalement, le rpertoire /etc/httpd/conf/ssl.crt contient un fichier cabundle.crt et un fichier Makefile, copis partir des sources de mod-ssl. Le premier contient les certificats des principales autorits de certification reconnues. C'est la mme liste d'autorits que celle qui apparat dans les navigateurs usuels comme Netscape Navigator ou Internet Explorer. Un serveur HTTPS configur comme indiqu ci-dessus est donc en mesure de reconnatre les certificats signs par n'importe laquelle de ces autorits. Si vous disposez du certificat d'une autorit de certification qui n'est pas dans cette liste, vous pouvez le rajouter par la procdure suivante : nommez le certificat avec une extension ".crt", placez le dans le rpertoire /etc/httpd/conf/ssl.crt et excutez depuis ce rpertoire la commande make : # cp nouveau-ca.crt /etc/httpd/conf/ssl.crt/nouveau-ca.crt # cd /etc/httpd/conf/ssl.crt # make La commande make ci-dessus balaie la liste des fichiers ayant l'extension ".crt" et ne contenant pas la chane de caractres " KIPME". Pour chacun de ces fichiers, elle fabrique S un hash-code partir du DN de l'autorit de certification. Elle cre ensuite un lien symbolique entre le fichier d'origine et le rsultat du hash-code. Cette technique permet d'acclrer la recherche du certificat de l'autorit qui a sign le certificat du client. Nous attirons l'attention du lecteur sur la confiance qu'il peut ou doit accorder aux autorits de certification contenues dans le fichier ca-bundle.crt. La procdure qui permet l'autorit de certification de vrifier l'identit du requrant est peut-tre sujette caution, surtout dans le cas des autorits qui proposent des certificats gratuitement. 45

Ainsi, contrairement un passeport, le certificat d'un utilisateur ne prouve pas son identit. Il prouve simplement qu'une autorit a accept de certifier l'identit propose par cet utilisateur. L'identit du dtenteur du certificat est donc indissociable de l'autorit de certification qui a sign le certificat.
6.3

Les autorisations

Les paramtres dcrits prcdemment permettent d'accder de faon chiffre et authentifie des pages WWW. Dans l'tat actuel, l'intrt se limite l'authentification du serveur : le client est en mesure de vrifier qu'il dialogue bien avec le serveur qu'il croit, et non pas avec un serveur tiers qui usurpe le nom ou l'adresse Internet du serveur en question. En ce qui concerne le chiffrement des pages, il est peut utile si les pages en question sont en accs public. HTTPS, grce aux mcanismes d'authentifications de SSL, peut permettre au serveur d'identifier de faon fiable le client avec lequel il dialogue. 6.3.1 Par mot de passe On utilise pour HTTPS exactement les mmes paramtres dans le fichier httpd.conf que pour HTTP, par exemple : <Location /pages/confidentielles> AuthType Basic AuthName Pages-Confidentielles AuthUserFile /etc/httpd/conf/httpd.passwd require valid-user </Location> Les directives ci-dessus indiquent que toutes les pages localises dans le rpertoire /pages/confidentielles ne sont accessibles que pour les couples utilisateur, motde-passe indiqus dans le fichier /etc/httpd/conf/httpd.passwd. Selon la partie du fichier httpd.conf o se trouvent ces directives, les transferts des informations d'authentification et des pages auront lieu via HTTP o HTTPS. Dans le cas d'une authentification classique, dite "basic authentication" dans HTTP, le client encode au format Base 64 le nom de l'utilisateur et le mot de passe associ, et rajoute le rsultat dans le champ " Authentication" de l'entte de la requte HTTP. Ce codage est quasiment transparent pour toute personne l'coute de la communication et rcuprer le couple utilisateur, mot de passe est trivial :
Requte HTTP avec authentification basique
GET page.html HTTP/1.1 Authentication: xxxxxx

Transfert

Codage base 64

"utilisateur:mot-de-passe"

46

Dans le cas de HTTPS, la procdure reste exactement la mme, mais l'ensemble de la requte envoye par le client au serveur est chiffre, comme le montre la figure ci-dessous :
Requte HTTPS avec authentification basique
GET page.html HTTP/1.1 Authentication: xxxxxx

SSL

Transfert

Codage base 64

"utilisateur:mot-de-passe" L'observateur sur le rseau n'est, en principe, ni en mesure de dterminer contient des informations d'identification, ni de la dchiffrer, ni de la rejouer. si la requte

6.3.2 En fonction du certificat du client La directive "SSLVerifyClient require" du fichier httpd.conf indique au serveur qu'il doit demander le certificat du client (squence certificate-request) lors de l'ouverture de la session SSL. Le serveur extrait alors les divers champs du DN (Distinguished Name) contenu dans le certificat du client. On peut construire des conditions que ces champs doivent satisfaire pour accder telles o telles pages. Les directives ci-dessous permettent de ne donner l'accs certaines pages qu'aux titulaires d'un certificat indiquant qu'ils font partie de l'organisation "La Boutique Virtuelle" en France : <Location /pages/confidentielles> SSLVerifyClient require SSLVerifyDepth 5 SSLRequireSSL SSLRequire %{SSL_CLIENT_S_DN_C} eq "FR" and \ %{SSL_CLIENT_S_DN_O} eq "La Boutique Vituelle" </Location> Les variables qu'on peut utiliser sont de la forme "%{SSL_CLIENT_S_DN_xx}" pour dcrire le DN contenu dans le certificat du client, et de la forme "%{SSL_CLIENT_I_DN_xx}" pour dcrire le DN de l'autorit qui a sign ce certificat. Les xx reprsentent les divers composants du DN, savoir C pour le pays, O pour l'organisation, L pour la localisation gographique, CN pour le nom et Email pour l'adresse lectronique du titulaire du certificat. Si vous tes amen crire de telles directives portant sur le certificat du client, vrifiez galement que le DN de l'autorit qui a sign ce certificat. En effet, plusieurs autorits peuvent avoir sign des certificats diffrents pour des organisations (champ O) ou des personnes (champ CN) homonymes. Bien sr, la directive "SSLRequire" peut devenir trs complexe s'il n'y pas de critre simple permettant de dcrire les DN autoriss. Apache et le module SSL permettent de 47

dfinir des listes exhaustives de DN autoriss, de la mme faon qu'on gre une liste de mots de passe pour des accs HTTP classiques. La dclaration est modifie comme suit : <Location /pages/confidentielles> SSLVerifyClient require SSLVerifyDepth 5 SSLRequireSSL SSLOptions +FakeBasicAuth AuthType Basic AuthFile /etc/conf/httpd/https.passwd </Location> Les trois dernires lignes indiquent au serveur Apache de simuler une authentification basique et de trouver la liste des comptes utilisateurs et des mots de passe associs dans le fichier https.passwd. Ce dernier contient la liste des DN des utilisateurs. On associe chacun d'eux le mme mot de passe qui correspond au chiffrement du mot " assword". p On fabrique donc un fichier du style :
/C=FR/O=La Boutique Virtuelle/CN=Joe Dalton:xxj31ZMTZzkVA /C=FR/O=CNRS/OU=UMR9999/CN=Gus Tave/Email=tave@umr9999.cnrs.fr:xxj31ZMTZzkVA

6.4

Les scripts CGI et HTTPS

HTTPS est transparent vis--vis des scripts CGI ou autres : HTTPS garantit que les requtes de formulaires sont chiffres par le client lorsquelles sont soumises au serveur et que la rponse du serveur est elle aussi chiffre. Le serveur transmet au script les versions dchiffres des paramtres du formulaire. De mme, le script gnre une page HTML en clair, et cest le serveur qui la chiffre avant de la transmettre au client. Dans le cas dApache, le serveur appelle le script en enrichissant son environnement dun certain nombre de variables. Ces variables permettent au script de connatre un certain nombre de paramtres sur la session, notamment la version du protocole SSL utilis, les spcifications de chiffrement, les informations contenues dans le certificat du serveur (DN du serveur et DN de lautorit qui a sign le certificat). On peut bien sr, en utilisant les mmes mcanismes dautorisations que ceux dcrits au paragraphe 2.2.2, faire en sorte que le serveur demande le transfert du certificat du client. Dans ces conditions, lenvironnement pass au script CGI ou autre senrichit des informations contenues dans le certificat du client. Les variables de lenvironnement intressantes exploiter sont de la forme "SSL_CLIENT_S_DN_xx" o xx a la mme signification que dans le paragraphe 2.2.2. Avec un tel mcanisme, on peut construire des applications qui requirent une authentification forte du client, quelle que soit la localisation de ce client sur l'Internet. Attention : du ct du script, l'authentification n'tant ralise que par le contenu de variables d'environnement, il faut vrifier qu'un utilisateur ayant un compte sur le serveur n'est pas en mesure d'excuter directement le script aprs avoir reconstitu un environnement valide.

48

6.5

HTTPS et les serveurs proxys

Un serveur proxy-HTTP est un serveur qui relaye des requtes HTTP pour le compte de clients WWW : le client adresse la requte HHTP au proxy, qui la fait suivre vers le serveur de destination, rcupre la rponse de ce dernier et la renvoie vers le client :
http://www.dom.fr/x/y/z http://www.dom.fr/x/y/z

client

proxy

www.dom.fr

rponse

rponse

Parfois, le serveur proxy fait aussi office de cache : dans ce cas, le serveur cache stocke les pages qu'il rcupre depuis un serveur distant. Ainsi, si la page requise par un client est dans le cache, le serveur la renvoie directement au client, sinon, il fait suivre la requte.
http://www.dom.fr/x/y/z

proxy client

http://www.dom.fr/x/y/z

www.dom.fr

rponse
cache

rponse

On utilise les proxys dans le cas o les stations du site n'ont pas toutes un accs direct l'Internet. On utilise les fonctionnalits de cache pour conomiser la bande passante vers les serveurs distants. Les solutions de caches sont totalement inoprantes en ce qui concerne HTTPS, pour deux raisons. D'une part, chaque enregistrement transmis par SSL contient un numro de squence, qui le rend difficilement rejouable. D'autre part, le dialogue entre le client est le serveur est chiffr dans sa totalit, y compris les requtes soumises par le client. Un serveur cache, insr entre le client et le serveur d'une connexion HTTPS, n'est donc pas en mesure de dtecter les requtes HTTP ni de vrifier si elles sont prsentes dans le cache. Les solutions de proxys pour HTTPS sont possible : Apache, configur avec le module mod_ssl dispose d'un proxy capable de grer les connexions HTTPS pour le compte de clients. Le mcanisme est ncessairement diffrent de celui d'un proxy HTTP classique. En effet, lors d'une connexion HTTPS, le client et le serveur tablissent en premier lieu une connexion SSL. Ensuite, le client envoie la requte HTTP sur cette connexion. La requte est donc chiffre et un proxy HTTP classique n'est pas en mesure de s'insrer dans ce schma. Le proxy HTTPS doit donc reconnatre, soit par un port particulier, soit par tout autre moyen, que le client souhaite tablir une connexion HTTPS vers un serveur donn. Le proxy HTTPS relaye donc entre le client et le serveur des enregistrements SSL sans les interprter au lieu de faire suivre des requtes HTTP.
6.6

Une application : le Webmail

Le Webmail est une application de plus en plus rpandue. Elle tout utilisateur d'accder sa messagerie dans des conditions sres depuis un poste de travail pouvant tre localis dans un environnement peu sr, comme un cybercaf, une salle en libre service d'un campus universitaire, etc. 49

L'ide est simple : il suffit de disposer d'un serveur HTTPS et, sur ce serveur, d'une application IMAP cliente du serveur de messagerie du site : Requtes HTTPS messages chiffrs Requtes IMAP messages en clair

Client

Serveur HTTPS

Serveur messagerie

Le serveur HTTPS et le serveur de messagerie peuvent bien entendu rsider sur la mme machine. Il existe de nombreuses implmentations de Webmails. Pour plus d'informations on consultera les pages du Comit rseau des Universits sur ce thme [WEBMAIL]. L'intrt de HTTPS dans ce schma est que le transfert du mot de passe IMAP c ircule de faon chiffre entre le client WWW et le serveur HTTPS, de la mme faon que le contenu des messages. Cette solution est particulirement adapte aux utilisateurs itinrants. En effet, elle permet sans installer de logiciel ou de configuration particulire, d'accder de faon relativement sre sa messagerie.

SSL et la messagerie

Les technologies de "Webmails" dcrites ci-dessus souffrent parfois d'une ergonomie un peu austre du fait de l'utilisation de pages HTML pour accder aux botes aux l ttres. La e plupart des clients de messagerie, comme Netscape Messenger, offrent la possibilit d'encapsuler le protocole SMTP et le protocole IMAP dans des sessions SSL. L'ide est donc la mme que pour HTTPS : le client et le serveur tablissent en premier lieu une connexion SSL et droulent ensuite le protocole classique au dessus de cette connexion. Les protocoles qui en rsultent ont reu des numros de ports officiels par l'IANA : il s'agit de 993 pour S/IMAP et pour S/SMTP. Le fait que SSL soit transparent au protocole sous-jacent fait qu'il est en gnral facile de modifier un client ou un serveur pour utiliser SSL. On trouvera dans [WRAPSSL] un "wrapper SSL" permettant de scuriser par SSL tout service rseau implment par un serveur lanc par inetd sur un systme Unix et ce, sans modifier le code source du serveur en question. Par exemple, pour mettre en uvre un serveur S/IMAP sur Linux, on procde en trois tapes, comme indiqu ci-dessous. La premire tape est de dclarer le service " simap" dans le fichier /etc/services en y rajoutant la ligne ci-dessous : simap tcp/993 La deuxime tape consiste compiler et installer le "wrapper SSL". Pour ce faire, il suffit de modifier le fichier Makefile de la distribution de WrapSSL 8.5 pour rajouter le

50

rpertoire /usr/local/ssl/include/openssl d'inclusion :

dans

la

liste

des

fichiers

CFLAGS = -Wall -DSMART -I/usr/local/ssl/include/openssl On lance ensuite la commande "make" pour fabriquer le binaire wrapssl8. Nous avons choisi e l'installer ensuite dans le rpertoire /usr/sbin. La troisime tape consiste dclarer le nouveau service dans /etc/ined.conf. La commande demandant de nombreux arguments, nous avons prfr cr un script trivial qui lance wrapssl8. Ce script appel /usr/sbin/simapd contient les lignes suivantes : #!/bin/sh exec /usr/sbin/wrapssl8 -in -out -verify 0 \ -key_file /etc/httpd/conf/ssl.key/server.key \ -cert_file /etc/httpd/conf/ssl.key/server.crt \ -ca_path /etc/httpd/conf/ssl.crt/ca-bundle.crt \ /usr/sbin/imapd On rajoute ensuite la ligne ci-dessous dans signal 1.
/etc/inetd.conf

et on relance inetd par un

simap stream tcp nowait root /usr/sbin/simapd simapd Notons que dans la version 8.5, wrapssl8 ne gre que le protocole SSLv2. Le client de messagerie doit tre configur pour utiliser SSLv2. C'est le wrapper qui effectue l'ouverture de la session avec le client. Le wrapper et le client ngocient donc les spcifications de chiffrement. Le wrapper lance ensuite le serveur IMAP classique comme l'aurait fait inetd. Le wrapper gnre des enregistrements SSL pour toutes les donnes reues du serveur et les envoie au client. Le wrapper dchiffre les enregistrements SSL reus du client et les transmet en clair vers le serveur IMAP. Dans une configuration classique, le wrapper SSL et le serveur IMAP tournent sur la mme machine. Les messages ne transitent en clair qu' l'intrieur de cette machine : Requtes S/IMAP (chiffres) Rponses (chiffres) Requtes IMAP (en clair) Rponses (en clair) serveur
processus imapd

Client S/IMAP

Wrapper

SSL

Le format S/MIME

Le format S/MIME [SMIME] est une extension du format MIME [MIME]. Il dfinit un certain nombre de types MIME pour dcrire un message chiffr ou un message sign. 51

S/MIME s'appuie sur PKCS7 [PKCS7] qui dcrit une syntaxe gnrale pour des donnes auxquelles on a appliqu des techniques de cryptographie, c'est--dire essentiellement, la signature digitale et le chiffrement. Les clients de messagerie Netscape Messenger et Microsoft Outlook sont en mesure de gnrer et interprter correctement des messages au format S/MIME. On regrettera que la version 4.0 d'Eudora ne dispose pas d'extensions pour S/MIME. Les exemples ci-dessous dcrivent l'utilisation de S/MIME avec Netscape Messenger. L'utilisation avec Microsoft Outlook est tout fait similaire et laisse titre d'exercice.

8.1 La signature d'un message

S/MIME dfinit plusieurs format pour des messages signs. Le plus couramment utilis correspond au type MIME multipart/signed. Dans ce format, le message transmis est la runion de deux parties MIME. La premire correspond au message signer. Il a un type MIME et un encodage classique. La deuxime partie est l'empreinte correspondante chiffre avec la cl prive du signataire. Elle contient galement le certificat du signataire et les informations sur les algorithmes utiliss pour calculer l'empreinte du message et chiffrer cette emreinte. Plus prcisment, cette partie est un objet PKCS7 de type signedData avec un champ contentInfo vide. On lui attribue le type MIME application/pkcs7-signature, comme le montre l'exemple suivant :
MIME-Version: 1.0 Subject: message =?iso-8859-1?Q?sign=E9?= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="-----------ms27BFF969A2EBC8AE8D0C0A62" This is a cryptographically signed message in MIME format. --------------ms27BFF969A2EBC8AE8D0C0A62 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ceci est un message sign=E9. --------------ms27BFF969A2EBC8AE8D0C0A62 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIF2wYJKoZIhvcNAQcCoIIFzDCCBcgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaC C cT/jBEirPG0M3z+4O9idrhSHftctWDCgaxyo1tNw4pQ/rGylXkcCgrfLGBuT --------------ms27BFF969A2EBC8AE8D0C0A62--

L'intrt de ce format est que le message d'origine reste lisible pour un agent de messagerie qui ne connat pas le format S/MIME. Par exemple, dans le cas d'Eudora Pro, le destinataire d'un message sign est en mesure de le lire. Il voit un document attach de type application/pkcs7-signature, (suffixe p7s) qu'il ne peut dcoder.

8.2 Le chiffrement d'un message

Le type MIME application/pkcs7-mime est utilis dans le cas d'un message ou d'une partie de message chiffr. La partie chiffre du message est un objet PKCS7 de type 52

envelopedData. Il correspond au rsultat du chiffrement du message par la cl publique du destinataire. L'exemple ci-dessous montre le format S/MIME correspondant un message chiffr.
MIME-Version: 1.0 Subject: message =?iso-8859-1?Q?chiffr=E9?= Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgf0wgfoCAQAwgaMwgZ0xCzAJBgNVBAYTAkZSMRAwDgY VQQHEwdUYWxlbmNlMTgwNgYDVQQKEy9DTlJTIC0gRGVsZWdhdGlvbiBBcXVpdGFpbmUgZXQ 9RZB2CTfXWCGHOCw0ZdVxfmK9zJoUSkSjwQoXCHb2Y8b7UIyFPW2W2lYB4G53KkMk9PR+17 wqA8znuswA55CzxsIgQIJ0L/K5GtRn4ECE4tyuUVF1zwAAAAAAAAAAAAAA==

8.3 Le chiffrement et la signature

Dans le cas d'un message la fois sign et chiffr, il y a deux possibilits. Soit on chiffre le message sign, soit on signe le message chiffr. Les deux solutions ont chacune leur intrt. Dans le premier cas, la liste des signataires est masque par le chiffrement. Dans le deuxime cas, on peut vrifier les signataires sans tre en mesure de dchiffrer le message. C'est donc l'application de messagerie qui dcide quel mcanisme employer. Dans le cas de Netscape Messenger, un message est d'abord sign et le rsultat est chiffr.

8.4 Installation du certificat de l'utilisateur

Pour pouvoir utiliser S/MIME, il est ncessaire d'tre titulaire d'un certificat d'authentification. L'autorit signataire de ce certificat doit tre connue de tous les correspondants. Dans le cas contraire, le destinataire d'un message ne pourra pas tre en mesure de vrifier la signature de l'metteur du message. En principe, un certificat d'utilisateur ne contient que la cl publique. La manire habituelle de transmettre l'utilisateur son certificat et sa cl prive est de chiffrer l'ensemble par un algorithme symtrique standard (triple-DES, par exemple) et de communiquer la cl de chiffrement par un moyen sr (communication tlphonique chiffre, courrier en main propre, etc.) Le format dans lequel est chiffr le certificat et la cl prive s'appelle PKCS12 [PKCS12]. Importer un certificat au format PKCS12 depuis un navigateur standard est trivial. Depuis Netscape Navigator, on clique sur le bouton "Scurit", puis sur le lien "Vos certificats". Dans la fentre qui s'affiche, on clique sur le bouton "Importer un certificat". On slectionne alors le fichier contenant le certificat. L'importation se termine aprs une suite de bouton "Suivant". Notons que l'un des tableaux affichs demande pour quels types de services on pense utiliser le certificat. Nous vous recommandons de cocher toutes les cases. Dans la phase d'importation de votre premier certificat, Netscape vous demandera un mot de passe pour protger les donnes confidentielles, notamment la cl prive. Netscape stocke ces donnes dans un fichier chiffr qu'il appelle Netscape Communicator DB. Ce mot de passe sera utilis pour toutes les oprations lies l'authentification et la scurit 53

des transferts, la fois pour Navigator et pour Messenger. Il est demand une fois par session de Netscape. Dans les exemples qui suivent, la fentre vous demandant le mot de passe en question ne sera jamais mentionne. Pour Microsoft Outlook et Explorer, les cls prives sont stockes dans la base de registres propre l'utilisateur, et sont donc protges par le mot de passe de connexion Windows.
8.5

Comment obtenir le certificat d'un correspondant ?

Si on dsire tablir une communication chiffre avec un correspondant, il est ncessaire de dtenir une copie de certificat. En effet, ce dernier contient la cl publique de son titulaire, et c'est avec cette cl qu'on va chiffrer le message. Les paragraphes suivants dcrivent les deux manires usuelles de rcuprer le certificat d'un correspondant. 8.5.1 En recevant un message sign Ds qu'on dispose d'un certificat, il est possible d'envoyer des messages signs des correspondants. Depuis Netscape Messenger, lorsqu'on tape un message, il suffit d'utiliser le bouton "Options d'envoi de messages" situ gauche de la liste des destinataires du message. On coche la case "Sign". La signature lectronique est rajoute au message. Dans le cas o l'on est titulaire de plusieurs certificats, Netscape Messenger permet de spcifier le certificat qui sera utilis pour la signature. Pour cela, cliquez sur le bouton "Scurit", puis sur le lien "Messenger". Slectionnez le certificat dans le paragraphe "Certificat pour vos messages signs et chiffrs". Comme on l'a vu prcdemment, la signature lectronique contient une copie du certificat de l'metteur du message. Les outils de messagerie S/MIME stockent le certificat de tout metteur de message sign. Ds lors qu'on a reu un message sign d'un correspondant, il est possible de dmarrer une communication chiffre. 8.5.2 En interrogeant un annuaire Il est possible de demander le certificat d'un utilisateur un annuaire en utilisant le protocole LDAP [LDAP]. Dans Netscape, on procde comme suit. On clique sur le bouton "Scurit" puis sur le lien "Autres certificats". Dans la fentre qui s'affiche, on clique sur le bouton "Rechercher dans l'annuaire". On slectionne un annuaire, on tape l'adresse de messagerie recherche et on clique sur le bouton "Rechercher". Il est possible de rajouter un annuaire LDAP dans la liste. Par exemple, si l'annuaire rajouter est ldap.lbv.fr, on demande Netscape Navigator d'afficher l'URL ldap://ldap.lbv.fr. Netscape Navigator demande si on souhaite rajouter cette adresse dans la liste des annuaires.
8.6

Exporter un certificat

Compte tenu des volutions prvisibles de la lgislation franaise en matire de preuve, le certificat d'un utilisateur, ds lors qu'il est certifi par une autorit de qualit, est assimil sa signature originale. Dtenir le certificat d'un tiers et sa cl prive est donc une 54

responsabilit que les autorits de certification ne souhaitent pas ncessairement assumer. Pour la mme raison, les logiciels courants protgent les cls privs avec des mcanismes de chiffrement optimaux. Il est donc ncessaire de prvoir une procdure de sauvegarde des certificats d'utilisateurs. La manire optimale est de sauvegarder le certificat sur un support amovible (disquette, ou mieux encore cdrom). La sauvegarde est particulirement recommande dans le cas o les procdures de transferts entre l'autorit de certification et l'utilisateur n'ont pas utilis de support physique ou bien lorsque l'utilisateur change de navigateur ou de station de travail. La sauvegarde est aise. Depuis Netscape Navigator, il suffit de cliquer sur le bouton "Scurit", puis sur le lien "Vos certificats". On slectionne le certificat sauvegarder et on clique sur le bouton "Exporter". Netscape demande un mot de passe pour protger le certificat. Ce mot d passe est choisi e par l'utilisateur et connu de lui seul. Netscape demande ensuite confirmation de ce mot de passe. Une fentre apparat. Elle permet l'utilisateur d'indiquer dans quel fichier sauver le certificat au format PKCS12.
8.7

S/MIME et les listes de diffusion

Lutilisation de la messagerie S/MIME doit pourvoir se faire en particulier dans des listes de diffusion. 8.7.1 La signature Cest lapplication la plus simple de S/MIME aux listes de diffusion. Rappelons quun message sign via S/MIME est simplement un message SMTP contenant en attachement une partie de corps spcifique (Content-type : x-pkcs7-signature). Ce message peut donc tre relay sans altration par tout MTA conforme SMTP. Lexploitation de cette signature ne dpend que des capacits du client de messagerie destinataire. Diffuser un message sign est donc possible avec nimporte quel logiciel de listes de diffusion sans modification de celui-ci. Dans le cas des messages de service (abonnement, accs aux oprations privilgies du responsable de liste), il peut savrer trs prcieux dexploiter la signature S/MIME du demandeur. En effet, ces oprations demandent une identification, il serait dommage de ne pas profiter de lauthentification forte S/MIME. Pour en bnficier, il doit tre possible de configurer le robot de listes de diffusion liste par liste pour imposer ou non l'authentification S/MIME pour chaque opration. Le robot doit alors dcoder les signatures comme nimporte quel client de messagerie S/MIME. 8.7.2 La confidentialit Dans ce cas le but est de diffuser chaque abonn un message chiffr par lmetteur. Notre hypothse est celle dune liste de diffusion centralise et gre par un robot. Lmetteur chiffre donc son message destination de ladresse de la liste, pour le faire, celui-ci doit accder la clef publique de la liste 1 . Le robot doit alors dcoder le message (tant le seul pouvoir accder la clef prive associe, il est le seul pouvoir le faire). La diffusion s'effectue alors en chiffrant le message lintention de chaque destinataire. Le robot de listes de diffusion doit donc dtenir la clef publique de chaque abonn (ou tre capable daccder celle-ci via un annuaire LDAP) .

Sera-t-il possible dobtenir auprs dune autorit un certificat pour un service et non pas pour un individu

55

Cette opration na de sens que si le contrle de la liste des abonns est strict, cest lobjectif mme de lopration de chiffrement et il convient alors que le contrle des oprations de gestion de la liste des abonns soit aussi solide que le chiffrement S/MIME. Il serait stupide de chiffrer au sein dune liste de diffusion laquelle un petit malin se serait abonn par simple usurpation de ladresse SMTP du propritaire de liste. A noter que si labonnement se fait exclusivement au moyen dune commande subscribe dans un message sign, le robot peut stocker ce moment la clef publique de chaque nouvel abonn en prvision du chiffrement. Rciproquement, en signant le message de bienvenue dans la liste, il remet chaque nouvel abonn la clef publique de celle-ci.

56

IP Security (IPSec)

IP Security (IPSec) est un protocole fournissant un mcanisme de scurisation au niveau IP. Ce protocole, composante indissociable dIPV6 et utilisable aussi avec IPV4, permet de chiffrer et/ou dauthentifier les changes entre deux quipements rseau (quipements actifs du rseau ou postes de travail). Son origine remonte 1995, date des premiers RFC sur le sujet, une seconde version des RFC tant disponible depuis fin 1998. Les RFC importants sont essentiellement : - RFC 2409 concernant lInternet Key Exchange (IKE), - RFC 2401 concernant IPSec, - RFC 2402 concernant lAuthentication Header (AH), - RFC 2406 concernant lEncapsulating Security Payload (ESP). Au niveau des fonctionnalits, IPSec permet donc de faire du chiffrement et de lauthentification tout en offrant la possibilit de slectionner les algorithmes utiliss ainsi que les modalits de leur mise en uvre. Ces modalits sont alors dfinies dans une Association de Scurit (Security Association (SA)). IPSec est totalement indpendant des couches protocolaires de niveau suprieur (TCP, UDP, etc.) et peut tre dcompos en deux sous ensembles bien distincts : - le chiffrement et lauthentification dj voqus, - la gestion des cls. Dans ce qui suit, la description dIPSec sappuie uniquement sur le protocole IPV4. Pour une description plus complte sur le sujet, le lecteur intress pourra se reporter la bibliographie.

9.1 Fonctionnement dIPSec

9.1.1 Modes de fonctionnement

Concernant IPSec, deux modes de fonctionnement sont envisageables : le mode tunnel et le mode transport. Ces deux modes sont applicables aussi bien pour le cadre de lauthentification (Authentication Header (AH)) que dans le cadre du chiffrement (Encapsulation Security Payload (ESP)). Voici les modes de fonctionnement en mode transport et tunnel concernant AH :

57

En-tte IP dorigine

Donnes

Datagramme dorigine

En-tte IP dorigine

AH

Donnes Authentifi (sauf champs variables en-tte IP)

Mode Transport

Nouvel en-tte IP

AH

En-tte IP dorigine

Donnes

Mode Tunnel

Authentifi (sauf champs variables en-tte IP)

Voici les modes de fonctionnement concernant ESP :

En-tte IP dorigine

Donnes

Datagramme dorigine

En-tte IP dorigine

En-tte ESP

Donnes Chiffr Authentifi

Trailer ESP

Donnes Authentification

Mode Transport

Nouvel en-tte IP

En-tte ESP

En-tte IP dorigine

Donnes Chiffr

Trailer ESP

Donnes Authentification

Mode Tunnel

Authentifi

Les champs variables de len-tte IP (TTL, etc.) ne sont pas pris en compte pour raliser lauthentification et sont comptabiliss comme valant zro dans le calcul. La diffrence majeure entre les deux modes rside dans le fait que dans un cas, le mode transport , len-tte IP du datagramme dorigine est conserve alors que dans lautre cas, elle est modifie. En consquence, le mode tunnel a lavantage concernant ESP de chiffrer totalement lidentit des entits impliques dans lchange et donc de masquer au maximum les caractristiques des flux dinformation. 9.1.2 Les Associations de scurit (SAs)

La dfinition qui suit est reprise de la dfinition de [LABOURET1999] et fournit une vision synthtique de la notion de SA : Une association de scurit (SA) se dfinit comme une connexion simplexe qui offre des services de scurit au trafic quelle transporte. Les services de scurit fournis par une SA mettent en uvre lun ou lautre des protocoles AH ou ESP, mais pas les deux. Si les deux protocoles doivent tre appliqus un flux de donnes, il est ncessaire de crer deux SAs distinctes. Une communication bidirectionnelle typique entre deux entits ncessite louverture de deux SAs, une dans chaque sens de communication.

58

Concrtement, une SA est identifie de manire unique par un triplet constitu dun indice de paramtre de scurit (Security Parameter Index ou SPI, bloc de 32 bits), dune adresse IP de destination, et dun identifiant de protocole de scurit (AH ou ESP). Pour tre plus explicite, voyons comment ces notions se traduisent au niveau AH et ESP. Limplmentation de AH est la suivante :
32 bits

En-tte suivant

Longueur AH

Rserv

En-tte AH

Security Parameters Index (SPI) (Index de 32 bits identifiant la SA en cours)

Numro de squence

Donnes dauthentification

Pour ce qui concerne ESP :

32 bits Security Parameters Index (SPI) (Index de 32 bits) Numro de squence

E n-t

te E

SP

Authentifi

Donnes chiffres (taille variable)

P

Bourrage (0 255 octets)

C

Tr

er ail

ES

Longueur bourrage

En-tte suivant

Donnes dauthentification (taille variable)

Datagramme avec ESP

Les champs En-tte suivant font rfrence au type du contenu aprs le paquet AH ou ESP et sont conformes au RFC 1340 dcrivant et rfrenant les protocoles. Le champ SPI est une valeur arbitraire de 32 bits, utilise avec ladresse IP de destination et le type de protocole utilis (AH ou ESP) pour caractriser une SA. Le champ Donnes dauthentification contient la valeur de contrle du paquet, cest-dire une signature garantissant lintgrit, la rception, du paquet qui a t mis. Quant au champ Numro de squence , il est utilis comme protection contre le rejeu des connexions. Cest une option ngocie lors de la cration de la SA. 59

9.1.3

IPSec et la gestion des cls

Au del des aspects purement implmentation dIPSec qui viennent dtre dcrits travers AH et ESP, le principal problme rsoudre rside dans la gestion des cls et des SAs. Pour cela, le principe retenu par lIETF a t de grer ces SAs (et donc les algorithmes de chiffrement, les cls, etc.) comme une deuxime composante bien distincte au sein du protocole. De base, il existe bien entendu la possibilit de grer manuellement les cls utilises dans IPSec. Mais, pour des raisons videntes de performance et de mise en uvre, un protocole de ngociation des SAs a t dvelopp. Ce protocole de ngociation des SAs sappelle Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP fournit un cadre gnrique la ngociation des SAs. Dautres protocoles tels que SKEME et Oakley (protocoles de gestion des cls antrieurs ISAKMP, dont la description dpasse le cadre de cet article) ont t repris certaines de leurs fonctionnalits et combins ISAKMP pour donner en final le protocole IKE (Internet Key Exchange). IKE est en fait un protocole hybride fdrant SKEME et Oakley au sein dISAKMP. Pour le dcrire sommairement, on peut dire que IKE est utilis pour construire un change de cls scuris et une authentification des entits voulant entrer en communication, et ce, en amont de tout change de donnes. Cette fonction peut tre ralise manuellement, via une autorit de certification ou DNSSec par exemple. Dans IPSec, cest IKE (ou autrement dit ISAKMP/Oakley) qui assure cette fonction. De plus, ISAKMP ne fournissant quun cadre gnrique, sajoute tout cela la notion de Domain of Interpretation (DOI). Concrtement, cest le DOI qui dfinit les paramtres ngocis dans les changes ISAKMP. Sans entrer plus avant dans la description sur ces aspects de gestion des cls, il est important de retenir que les notions mises en jeu sont toujours bases sur des concepts connus, savoir des algorithmes asymtriques (Diffie-Hellman), des fonctions de hachage de type MD5, des certificats X509, etc. ainsi que des infrastructures cls publiques (PKI). Voici un schma synoptique rsumant quelque peu ces notions pour lesquelles la littrature sur le sujet est, en gnral, rarement trs explicite :

60

Oakley
Universit Arizona

Skeme
IBM

Skip
Sun Microsystems

Etc.

Modles de gestion de cls Plusieurs dveloppements, avec ou sans connexion Cadre gnrique la ngociation des SA : cration, suppression, etc.

Non retenus

ISAKMP
DOI

IKE
Diffie-Hellman Hachage Certificats X509 PKI

Domain of Interpretation Dfinit les paramtres selon le contexte IPSec : liste des algos, mode, ... Notions sous-jacentes

Concernant la notion de SA, sa mise en uvre au niveau IPSec couches basses se retrouve aussi au niveau ISAKMP/Oakley lui-mme comme lindique le schma qui suit :

ISAKMP SA ISAKMP
1ire phase

ISAKMP

TCP/UDP IPSec SA
2ime phase

TCP/UDP IPSec

IP

IP

Ainsi, pour construire une SA de niveau IPSec, il est ncessaire au pralable dtablir une SA de niveau ISAKMP. Cest ce niveau que sont utiliss des mcanismes de type Diffie-Hellman et certificats X509 pour amorcer et tablir un change scuris. On peut noter qu ce niveau, contrairement au niveau IPSec, la SA est bi-directionnelle (RFC 2409). Le protocole ISAKMP prconise lemploi dun format de donnes bien spcifique avec, lors de lchange, lutilisation de cookies pour identifier les participants la connexion. LIANA a mme normalis le port et le protocole requis pour ISAKMP : protocole UDP et port 500. Comme le prcise la dfinition dune SA, ltablissement dune communication bidirectionnelle au niveau IPSec ncessite la cration de deux SAs, une dans chaque sens. Il peut donc tre ncessaire aux couches rseau de solliciter par deux fois un protocole de niveau applicatif.

61

Les consquences en sont donc la fois une perte de performance lors de ltablissement dune connexion par exemple mais aussi un gain fonctionnel important pour garantir la scurisation de la communication. Le schma qui suit illustre de manire trs simplifie les composantes ncessaires ltablissement dune connexion scurise via IPSec. On distingue bien deux lments dissocis qui sont IPSec proprement dit (ESP et AH) et la gestion des cls (IKE).
ion Dfinit
Mise jour
Administration de la scurit

Consultation

Security Policy Database Security Association Database Liaison IP + IPSec (AH, ESP) TCP/UDP Tunnel Chiffr SA configures Liaison

Mise jour

D e m a n d e

IP + IPSec (AH, ESP) TCP/UDP Sockets Applications

RFC 2401 Oakley Skeme

Demande SA

Sockets Applications
Oakley Skeme

ISAKMP DOI

Consulte

Alerte

ISAKMP DOI

IKE Tunnel IKE

IKE

Concernant le fonctionnement du protocole, la couche IPSec fait donc normalement appel IKE pour construire une SA. Dans ce cas, si la SA nexiste pas au pralable, elle est soit construite directement, soit extraite dune Security Association Database (SAD). En effet, le RFC 2401 dfinit la notion de bases de donnes de scurit. Ces bases sont au nombre de deux : la SAD, qui contient tous les paramtres associs chaque SA active et la Security Policy Database (SPD) qui dcrit la politique de scurit travers la liste des flux entrants et sortants autoriss. La politique scurit applique aux datagrammes peut tre alors de trois types : - rejet du datagramme, - passage sans protection (quivalent un filtre passant), - lapplication dIPSec (AH et ESP). Lapplication de cette politique se base sur les critres classiques que sont ladresse IP de destination, ladresse IP source, le nom DNS ou un DN (au sens X500), le protocole de transport utilis (TCP ou UDP) et les ports source et destination.

62

La SAD contient quant elle les SAs actives et les caractristiques associes telles que la dure de vie, les paramtres de ESP et AH utiliss, le mode tunnel ou transport, etc. Le schma qui suit, inspir de [CISCO1998], illustre linteraction entre IPSec, IKE et une infrastructure cls publiques (PKI).

certificat Autorit de Certification

change de certificats change de certificats

Session IKE

Session IPSec avec SA associe Contrle de certificats Contrle de certificats

Dans ce cas, le dmarrage de la session IKE est assur par un change de certificats X509 entre les entits voulant communiquer. Ces certificats sont garantis par une autorit de certification accepte par lensemble des parties voulant entrer en communication. Globalement, concernant le mcanisme dchange des cls, IPSec prvoit une souplesse maximale au niveau du choix des mcanismes employer via ISAKMP. Comme il la dj t suggr, le mode manuel, les PKI, etc. sont envisageables, mais aussi dautres protocoles tels que DNSSEC par exemple. Pour mmoire, DNSSEC permet dtendre les Ressources Record (RR) du DNS classique avec de nouveau champs (certificats, etc.) et dutiliser les fonctionnalits du DNS ainsi modifi pour changer des certificats. Dans ce dernier cas, la difficult consiste rsoudre les problmes lis lemploi de fonctions telles que Network Address Translation (NAT), DHCP, etc. 9.1.4 Les modes de fonctionnement de IKE

Le protocole IKE fonctionne en deux phases : la premire permet dtablir la SA pour ISAKMP et la deuxime dtablir la ou les SAs pour IPSec. Il est possible de noter ici que la SA construite dans la premire phase peut servir construire plusieurs SAs dans la deuxime phase. La premire phase se dcline en deux modes qui sont le Main Mode (6 messages changs) et l Agressive Mode (3 messages changs).

63

La deuxime phase comprend deux options, le Quick Mode avec PFS (Perfect Forward Secrecy) et le Quick Mode sans PFS. La proprit PFS caractrise le fait que la dcouverte dune cl ne remet pas en cause lutilisation des autres cls (par exemple, la dcouverte dune cl matre ne compromet pas les cls de session, ce qui garantit dans le temps la validit des changes ayant dj eu lieu). Un autre mode existe, le New Group Mode , mais ce mode est un peu part dans le sens o il nest utilis dans aucune des phases 1 ou 2. Durant la premire phase, en Main Mode ou Agressive Mode , les informations suivantes sont changes : un algorithme de chiffrement et une fonction de hachage, une mthode dauthentification, les valeurs publiques pour Diffie-Hellman, trois cls : chiffrement, authentification et une cl pour la drivation dautres cls.

Durant la deuxime phase, les messages sont protgs grce aux paramtres changs lors de la premire phase. En plus, des alas sont utiliss pour viter le rejeu des sessions. Voici une illustration de ce mode dchange :

Entit A En-tte, Hash, SA, Ala, [Cl DH pour PFS], [Ida, Idb]
Si change de cl, la PFS est garantie. Autrement, la cl est drive de la phase 1

Entit B 1

En-tte, Hash, SA, Ala, [Cl DH pour PFS], [Ida, Idb]

La SA est ngocie : algorithme, AH, ESP, hachage, etc.

En-tte, Hash

Dans lexemple ci-dessus, la proprit PFS nest garantie que lorsque des cls DiffieHellman sont de nouveau changes. Lentte ISAKMP quant elle fixe le formatage des changes : place du Hash, de lala, etc. dans le paquet. Toutes les donnes sont changes chiffres ds le premier change grce la SA du niveau ISAKMP. Une description plus complte de ce mode et des autres modes disponibles est fournie dans le RFC 2409.

9.2 Implmentations actuelles et exemple de mise en uvre avec des routeurs

Il existe aujourdhui bon nombre dimplmentations dIPSec. Ces implmentations sont soit de nature commerciale, soit du domaine public, sachant que les deux environnements sont relativement dynamiques sur le sujet.

64

Au niveau des ralisations, il est possible de citer : FreeS/Wan pour Linux, Limplmentation native dans FreeBSD, Limplmentation dans AIX pour les versions suprieures la 4.3, Des implmentations dans les firewall (Firewall-1 de Checkpoint par exemple), Et des implmentations dans des quipements tels que des quipements ddis au chiffrement ou tout simplement des routeurs (Cisco partir de la version IOS 11.3 par exemple).

Dans tout ces exemples, les modalits de mise en uvre sont plus ou moins complexes et vont de limplmentation native (FreeBSD, IOS Cisco, etc.) la ncessaire recompilation du noyau (FreeS/Wan, etc.).

La maquette qui suit va permettre dillustrer de manire plus oprationnelle une petite mise en uvre en employant les fonctionnalits IPSec de lIOS de Cisco. Cet exemple nest quune illustration technique, un dploiement rel ncessitant bien sr une tude pralable quant aux flux scuriser et leur intgration au sein dune politique scurit. Voici le schma de principe ainsi que la configuration de base des routeurs, sans IPSec, assurant la simple interconnection des quipements :

R1

R2 Ethernet 10Mb/s Lien scuriser

Domaine 1
172.18.2.1 172.18.2.2

Domaine 2

version 12.0 service config hostname r1 ! enable secret 5 $1$C/Z h$uIE9MzyayxHMcTjB0qPnu0 ! ! interface Ethernet0/0 ip address 172.18.2.1 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable ! ! interface Ethernet0/1 ip address 172.19.2.1 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 password password login ! end

version 12.0 service config hostname r2 ! enable secret 5 $1$C/Z h$uIE9MzyayxHMcTjB0qPnu0 ! ! interface Ethernet0/0 ip address 172.18.2.2 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable ! ! interface Ethernet0/1 ip address 172.20.2.1 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable line con 0 exec-timeout 0 0 transport input none line aux 0 line vty 0 4 password password login ! end

65

Au niveau des configurations physiques, les caractristiques des routeurs R1 et R2 sont les suivantes : routeur Cisco 3640, 8 Mo de mmoire flash, 32 Mo de RAM, IOS version 12.0.3(T) avec IP, IP Plus et IPSec 56 bits.

Dans ce qui suit, la mise en uvre dIPSec nutilise pas, pour des raisons de simplicit, dautorit de certification (CA) et de certificats X509 pour tablir une SA de niveau ISAKMP. En lieu et place seront utilises des pre-shared keys dj configures et existantes au niveau du routeur. Ces cls sont issues dune fonctionnalit de Oakley et fixent les paramtres de base dun change Diffie-Hellman (groupe 1 pour les cls de 768 bits et groupe 2 pour les cls de 1024 bits. Par dfaut le groupe 1 est employ). Les configurations qui suivent font rfrence au routeur R1, la configuration du routeur R2 tant symtrique. Plusieurs tapes sont ncessaires pour mettre en uvre IPSec dans le cadre de lexemple et avec les restrictions prcdentes : 1- Configuration des paramtres ISAKMP : Sur le routeur R1, cette configuration est la suivante :
crypto isakmp policy 1 hash md5 authentication pre-share lifetime 3600

Dans lexemple, elle permet de fixer lalgorithme de hachage utilis, la dure de vie de la SA ngocie et le fait dutiliser des pre-shared keys .

2- Configuration de la cl ISAKMP
crypto isakmp key motdepasse address 172.18.2.2

Le mot de passe motdepasse est associ ladresse 172.18.2.2, le routeur R2. Dans le cas de lutilisation dune autorit de certification et non de la fonction pre-shared keys , il aurait fallu raliser les tapes suivantes, en lieu et place des tapes 1 et 2 : crer un couple RSA sur le routeur (crypto key gen rsa ) rcuprer le certificat dune autorit de certification (crypto ca identity <MaCA> puis enrollment url http://<MaCA>) faire certifier la cl publique du routeur par lautorit de certification (crypto ca enroll <MaCA>) enfin, configurer les paramtres ISAKMP comme prcdemment mais sans le paramtre authentication pre-shared .

66

3- Mise en uvre dune access-list Ltape suivante consiste crer une access-list tendue permettant de dclencher IPSec selon la nature des flux dinformation :
access-list 102 permit ip host 172.18.2.1 host 172.18.2.2

On peut noter que cette access-list prend comme premire adresse IP la source, cest-dire le routeur R1 lui-mme en loccurrence. Elle doit se concevoir en prenant en compte le flux sortant. 4- Configuration des paramtres des SAs Il reste ensuite configurer les paramtres ngocis lors de ltablissement des SAs :
crypto ipsec transform-set trans1 esp-rfc1829 mode transport crypto ipsec transform-set trans2 ah-md5-hmac esp-des mode transport

Les paramtres ngocier peuvent tre diffrents selon les cas et les configurations voulues. Ici, ces paramtres relvent purement du choix de lauteur et sont souvent montrs titre dexemple dans des documents de configuration pour illustrer le fait que mme les anciennes spcifications (RFC 1829 en loccurrence) sont prises en compte et restent compatibles avec les implmentation rcentes. Cest aussi ce niveau quest prcis le mode de fonctionnement dIPSec : mode tunnel ou mode transport. 5- Cration de la crypto map Puis, il faut ensuite crer une crypto-map fournissant les caractristiques quant au lien IPSec lui-mme :
crypto map e1 1 ipsec-isakmp set peer 172.18.2.2 set transform-set trans1 trans2 match address 102

A ce niveau sont prciss le routeur symtrique au routeur R1, lordre de prfrence dans la ngociation des paramtres de SAs (trans1 et trans2) et laccess-list associe permettant de dclencher IPSec. 6- Activation dIPSec La dernire tape consiste appliquer la crypto-map prcdemment dfinie sur une interface pour rendre oprationnel les configurations (ordre crypto map e1) :
interface Ethernet0/0 ip address 172.18.2.1 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable crypto map e1

67

Les configurations des routeurs avec IPSec sont alors les suivantes :

R1

R2 Ethernet 10Mb/s Lien scuriser

Domaine 1
172.18.2.1
! version 12.0 hostname r1 ! enable secret 5 $1$C/Zh$uIE9MzyayxHMcTjB0qPnu0 ! crypto isakmp policy 1 hash md5 authentication pre-share lifetime 3600 crypto isakmp key motdepasse address 172.18.2.2 ! crypto ipsec transform-set trans1 esp-rfc1829 mode transport crypto ipsec transform-set trans2 ah-md5-hmac esp-des mode transport ! crypto map e1 1 ipsec-isakmp set peer 172.18.2.2 set transform-set trans1 trans2 match address 102 ! interface Ethernet0/0 ip address 172.18.2.1 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable crypto map e1 ! no ip http server ! access-list 102 permit ip host 172.18.2.1 host 172.18.2.2 ! end

Domaine 2
172.18.2.2

! version 12.0 hostname r2 ! enable secret 5 $1CaxkIhtzyayxHMcTjB0qlppt ! crypto isakmp policy 1 hash md5 authentication pre-share lifetime 3600 crypto isakmp key motdepasse address 172.18.2.1 ! crypto ipsec transform-set trans1 esp-rfc1829 mode transport crypto ipsec transform-set trans2 ah-md5-hmac esp-des mode transport ! crypto map e1 1 ipsec-isakmp set peer 172.18.2.1 set transform-set trans1 trans2 match address 102 ! interface Ethernet0/0 ip address 172.18.2.2 255.255.255.252 no ip directed-broadcast no ip mroute-cache no cdp enable crypto map e1 ! no ip http server ! access-list 102 permit ip host 172.18.2.2 host 172.18.2.1 ! end

A ce niveau, les configurations de base tant effectives, il est possible den visualiser le rsultat ( partir du routeur R1) :
R1#sh crypto map

Crypto Map "e1" 1 ipsec-isakmp Peer = 172.18.2.2 Extended IP access list 102 access-list 102 permit ip host 172.18.2.1 host 172.18.2.2 Current peer: 172.18.2.2 Security association lifetime: 4608000 kilobytes/3600 seconds PFS (Y/N): N Transform sets={ trans1, trans2, }

R1#sh crypto ip transform-set

Transform set trans1: { esp-rfc1829 } will negotiate = { Var len IV, Transport, IV length: 8 bytes Transform set trans2: { ah-md5-hmac } will negotiate = { Transport, }, { esp-des } will negotiate = { Transport, },

},

68

R1#sh crypto ip sa

interface: Ethernet0/0 Crypto map tag: e1, local addr. 172.18.2.1 local ident (addr/mask/prot/port): (172.18.2.1/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (172.18.2.2/255.255.255.255/0/0) current_peer: 172.18.2.2 PERMIT, flags={origin_is_acl,} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #send errors 0, #recv errors 0 local crypto endpt.: 172.18.2.1, remote crypto endpt.: 172.18.2.2 path mtu 1500, media mtu 1500 current outbound spi: 0 inbound esp sas: inbound ah sas: outbound esp sas: outbound ah sas:

Le contrle des configurations permet de corriger les erreurs ventuelles et de prendre en compte, si besoin, de nouveaux paramtres (PFS, lifetime, etc.). Ltape suivante consiste activer le mode debug pour permettre de visualiser le rsultat de la mise en uvre dIPSec :
R1#debug crypto isakmp R1#debug crypto ipsec R1#debug cryto engine

Ensuite un ping du routeur R1 vers le routeur R2 permet de visualiser les phases ISAKMP et IPSec. Au pralable, la commande sh cryto engine connection active permet de confirmer ltablissement dune connexion scurise :
R1#ping 172.18.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.18.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms R1#sh cryp en conn a ID 1 2 3 Interface no idb Ethernet0/0 Ethernet0/0 IP-Address no address 172.18.2.1 172.18.2.1 State set set set Algorithm DES_56_CBC DES_56_CBC DES_56_CBC Encrypt 0 0 5 Decrypt 0 5 0

A ce niveau, on constate dune part que les routeurs R1 et R2 sont atteignables entre eux et, dautre part, que 5 paquets de part et dautre (paquets issus du ping) ont bien t changs avec chiffrement et dchifffement dans les deux sens vu de R1). Conformment la dfinition des SAs, deux SAs sont bien cres pour lchange (une dans chaque sens) :
R1#sh cryp ip sa interface: Ethernet0/0 Crypto map tag: e1, local addr. 172.18.2.1 local ident (addr/mask/prot/port): (172.18.2.1/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (172.18.2.2/255.255.255.255/0/0) current_peer: 172.18.2.2

69

PERMIT, flags={origin_is_acl,transport_parent,} #pkts encaps: 2, #pkts encrypt: 2, #pkts digest 0 #pkts decaps: 2, #pkts decrypt: 2, #pkts verify 0 #send errors 8, #recv errors 0 local crypto endpt.: 172.18.2.1, remote crypto endpt.: 172.18.2.2 path mtu 1500, media mtu 1500 current outbound spi: E772311 inbound esp sas: spi: 0x52924B8(86582456) transform: esp-rfc1829 , in use settings ={Var len IV, Transport, } slot: 0, conn id: 2, crypto map: e1 sa timing: remaining key lifetime (k/sec): (4607999/3377) IV size: 8 bytes replay detection support: N inbound ah sas: outbound esp sas: spi: 0xE772311(242688785) transform: esp-rfc1829 , in use settings ={Var len IV, Transport, } slot: 0, conn id: 3, crypto map: e1 sa timing: remaining key lifetime (k/sec): (4607999/3359) IV size: 8 bytes replay detection support: N outbound ah sas:

Quant aux traces issues du mode debug (les lments importants figurent dans une police de caractres plus grande) :
/* REQUETE IPSEC POUR CREATION DE SAs */
00:03:42: IPSEC(sa_request): , (key eng. msg.) src= 172.18.2.1, dest= 172.18.2.2, src_proxy= 172.18.2.1/255.255.255.255/0/0 (type=1), dest_proxy= 172.18.2.2/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-rfc1829 , lifedur= 3600s and 4608000kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4000 00:03:42: IPSEC(sa_request): , (key eng. msg.) src= 172.18.2.1, dest= 172.18.2.2, src_proxy= 172.18.2.1/255.255.255.255/0/0 (type=1), dest_proxy= 172.18.2.2/255.255.255.255/0/0 (type=1), protocol= AH, transform= ah-md5-hmac , lifedur= 3600s and 4608000kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4000 00:03:42: IPSEC(sa_request): , (key eng. msg.) src= 172.18.2.1, dest= 172.18.2.2, src_proxy= 172.18.2.1/255.255.255.255/0/0 (type=1), dest_proxy= 172.18.2.2/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-des , lifedur= 3600s and 4608000kb,

/* DEBUT DE NEGOCIATION ISAKMP */

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4000 00:03:42: ISAKMP (1): beginning Main Mode exchange 00:03:57: ISAKMP (1): retransmitting phase 1... 00:03:57: ISAKMP (1): processing SA payload. message ID = 0 00:03:57: ISAKMP (1): Checking ISAKMP transform 1 against priority 1 policy 00:03:57: ISAKMP: encryption DES-CBC 00:03:57: ISAKMP: hash MD5 00:03:57: ISAKMP: default group 1 00:03:57: ISAKMP: auth pre-share 00:03:57: ISAKMP: life type in seconds 00:03:57: ISAKMP: life duration (basic) of 3600 00:03:57: ISAKMP (1): atts are acceptable. Next payload is 0 00:03:57: Crypto engine 0: generate alg param 00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57: CRYPTO_ENGINE: Dh phase 1 status: 0 ISAKMP (1): SA is doing pre-shared key authentication ISAKMP (1): processing KE payload. message ID = 0 Crypto engine 0: generate alg param ISAKMP Crypto ISAKMP ISAKMP (1): processing NONCE payload. message ID = 0 engine 0: create ISAKMP SKEYID for conn id 1 (1): SKEYID state generated (1): processing vendor id payload

70

00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57: 00:03:57:

ISAKMP (1): speaking to another IOS box! /* :-) */ generate hmac context for conn id 1 ISAKMP (1): processing ID payload. message ID = 0 ISAKMP (1): processing HASH payload. message ID = 0 generate hmac context for conn id 1 ISAKMP (1): SA has been authenticated with 172.18.2.2 ISAKMP (1): beginning Quick Mode exchange, M-ID of 355270384

/* LA SA de NIVEAU IKE EST CREE. LE NIVEAU IPSEC COMMENCE POUR SES SAs */
00:03:57: IPSEC(key_engine): got a queue event... 00:03:57: IPSEC(spi_response): getting spi 86582456ld for SA from 172.18.2.2 to 172.18.2.1 for prot 3 00:03:57: IPSEC(spi_response): getting spi 516494449ld for SA from 172.18.2.2 to 172.18.2.1 for prot 2 00:03:57: IPSEC(spi_response): getting spi 26219091ld for SA from 172.18.2.2 to 172.18.2.1 for prot 3 00:03:58: generate hmac context for conn id 1 00:03:58: generate hmac context for conn id 1 00:03:58: ISAKMP (1): processing SA payload. message ID = 355270384 00:03:58: ISAKMP (1): Checking IPSec proposal 1 00:03:58: ISAKMP: transform 1, ESP_DES_IV64 00:03:58: ISAKMP: attributes in transform: 00:03:58: ISAKMP: encaps is 2 00:03:58: ISAKMP: SA life type in seconds 00:03:58: ISAKMP: SA life duration (basic) of 3600 00:03:58: ISAKMP: SA life type in kilobytes 00:03:58: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 00:03:58: ISAKMP (1): atts are acceptable.

/* EXAMEN DES PARAMETRE ECHANGES */

00:03:58: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 172.18.2.2, src= 172.18.2.1, dest_proxy= 172.18.2.2/255.255.255.255/0/0 (type=1), src_proxy= 172.18.2.1/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-rfc1829 , lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0 00:03:58: ISAKMP (1): processing NONCE payload. message ID = 355270384 00:03:58: ISAKMP (1): processing ID payload. message ID = 355270384 00:03:58: ISAKMP (1): processing ID payload. message ID = 355270384 00:03:58: generate hmac context for conn id 1 00:03:58: ISAKMP (1): Creating IPSec SAs 00:03:58: inbound SA from 172.18.2.2 to 172.18.2.1 (proxy 172.18.2.2 to 172.18.2.1 ) 00:03:58: has spi 86582456 and conn_id 2 and flags 0 00:03:58: lifetime of 3600 seconds 00:03:58: lifetime of 4608000 kilobytes 00:03:58: outbound SA from 172.18.2.1 to 172.18.2.2 (proxy 172.18.2.1 to 172.18.2.2 ) 00:03:58: has spi 242688785 and conn_id 3 and flags 0 00:03:58: lifetime of 3600 seconds 00:03:58: lifetime of 4608000 kilobytes 00:03:58: IPSEC(key_engine): got a queue event... 00:03:58: IPSEC(initialize_sas): , (key eng. msg.) dest= 172.18.2.1, src= 172.18.2.2, dest_proxy= 172.18.2.1/255.255.255.255/0/0 (type=1), src_proxy= 172.18.2.2/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-rfc1829 , lifedur= 3600s and 4608000kb, spi= 0x52924B8(86582456), conn_id= 2, keysize= 0, flags= 0x0 00:03:58: IPSEC(initialize_sas): , (key eng. msg.) src= 172.18.2.1, dest= 172.18.2.2, src_proxy= 172.18.2.1/255.255.255.255/0/0 (type=1), dest_proxy= 172.18.2.2/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp-rfc1829 , lifedur= 3600s and 4608000kb, spi= 0xE772311(242688785), conn_id= 3, keysize= 0, flags= 0x0

/* LES SAs DE NIVEAU IPSEC VONT ETRE CREES. LES ECHANGES VONT COMMENCER */ 00:03:58: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.18.2.1, sa_prot= 50, sa_spi= 0x52924B8(86582456), sa_trans= esp-rfc1829 , sa_conn_id= 2 00:03:58: IPSEC(create_sa): sa created, (sa) sa_dest= 172.18.2.2, sa_prot= 50, sa_spi= 0xE772311(242688785), sa_trans= esp-rfc1829 , sa_conn_id= 3

71

On retrouve bien dans ces traces les deux phases concernant ISAKMP et IPSec. De mme tous les paramtres fixs dans les configurations des routeurs R1 et R2 se retrouvent, sans surprise, lors de la ngociation. Pour conclure sur le sujet, il est possible de faire un certain nombre de constats lissue de cette petite exprimentation et dajouter des informations complmentaires : - la mise en uvre dIPSec dans le contexte dun environnement intgr comme IOS de Cisco a t relativement simple dans le cadre la maquette, - les performances obtenues semblent acceptables. Au niveau mise en uvre, des Cisco 2500 peuvent suffire et dans ce cas, il faut environ 4 secondes pour raliser lexponentiation Diffie-Hellman avec des cls de 1024 bits (source Cisco), - au niveau mmoire, la table des SAs dans le routeur prend environ 300 octets auxquels sajoutent 120 octets par entre (540 octets si deux SAs sont utilises pour une communication, en entre et en sortie), - au niveau des changes, les performances sont videmment moindres pour les flux chiffrs, - de mme, les performances des flux n chiffrs sont un peu la baisse cause du on passage de chaque paquet IP lexamen de la crypto map .

72

Vers une infrastructure de gestion de clefs publiques

Jacques : H ! Dis-moi donc, comment tre sr que personne nespionne notre correspondance ? Pierre : Je sais ! Jutilise un algorithme de chiffrement avec une clef secrte, tu es le seul pouvoir lire le courrier que je te poste car je te passe la clef secrte Jacques : Oui mais, comment tre sr que personne ne va espionner le rseau et semparer de la clef secrte ? Pierre : Je sais ! Jutilise une nouvelle clef secrte pour chaque message, je te la poste avec le message mais je la crypte avec un algorithme asymtrique. Pour le faire, jutilise ta clef publique et tu es le seul, avec ta clef prive, pouvoir retrouver la clef secrte pour dchiffrer le message. Jacques : Oui mais, comment peux-tu tre sr que la clef publique que tu utilises nest pas un faux ? Pierre : Je sais ! Tu fais signer ta clef publique par une autorit de certification. En vrifiant la signature de ta clef publique, (avec la clef publique de lautorit de certification), je sais que lautorit de certification a bien vrifi que tu es le titulaire de cette clef publique. Tu me suis ? Jacques : Oui mais, comment puis-je tre sr que la clef publique que tu utilises nest pas un faux certifi par une autorit de certification bidon ? Pierre : Pour cela Jacques, il nous faut grer une infrastructure de clefs publiques

Les spcifications de protocoles et les implmentations de solutions de chiffrement existent pour un grand nombre dapplications. Des serveurs et des clients compatibles avec le chiffrement par certificat sont mme dj largement dploys dans nos tablissements (Apache, IIS, Netscape, Internet-Explorer, ). Pourquoi ces techniques ne peuvent-elles se gnraliser que maintenant alors que lon dispose depuis longtemps dalgorithmes de chiffrement dont on peut admettre quils sont largement assez solides pour la scurit requise dans nos applications ? Les algorithmes de chiffrement symtrique ne peuvent tre dploys dans un contexte ouvert comme lInternet parce que la question du partage du secret (envoyer la clef de chiffrement) nest pas facile rsoudre une grande chelle. Les algorithmes de chiffrement asymtrique visent rsoudre ce problme en particulier parce quune infrastructure non scurise peut tre utilise pour diffuser des clefs publiques. La question dlicate dans ces techniques est celle de la vrification de la validit des clefs publiques. En effet, il est facile de forger un couple clef publique et clef prive contenant lidentit que lon souhaite usurper. La solution adopte est de faire signer sa clef publique par un tiers. Cette signature dune clef appele certificat peut tre vrifie, ce qui permet de valider la provenance de la clef publique sous rserve que deux conditions soient respectes : pouvoir accder la clef publique de lentit qui a certifi la clef publique que lon souhaite vrifier, savoir quel degr de confiance on peut accorder dans ce tiers certificateur. Tous les certificats nont pas la mme valeur. De mme quil est facile de forger une fausse clef publique, il est facile de faire certifier celle-ci par une autorit de certification complaisante. 73

Jusqu prsent, cest ce qui a empch le dploiement de PGP pourtant dj ancien (premire version stable de PGP en 1991) dont lusage est rest limit ou presque des informaticiens. Quels sont les facteurs nouveaux qui nous font penser que S/MIME ou HTTPS peuvent se dployer largement ? La lgislation du cryptage a considrablement volu en France et partout dans le monde, essentiellement sous la pression du commerce lectronique. Dans PGP la diffusion des clefs publiques nest pas spcifie. Il existe cependant des serveurs de clefs publiques de toutes sortes (robot de messagerie, serveurs FTP ou HTTP ; les serveurs de clefs publiques ne garantissent absolument pas la valid des clefs quils diffusent). Les certificats X509 utiliss sont bass sur des Distinguished Name (DN) et trouvent donc leur place naturellement dans des annuaires LDAP dont le dploiement est en cours. Labsence de cette infrastructure dannuaire a lourdement handicap lutilisation de PGP. On peut penser quun nombre relativement important de serveurs HTTPS peut tre mis en place dans le seul but de chiffrer les changes entre le navigateur et le client sans sappuyer sur un annuaire, par contre, il sera quasiment impossible dutiliser S/MIME dans une communaut ouverte de correspondant avant que des annuaires LDAP ne soit gnraliss.

10 Infrastructure de gestion de clefs

10.1 Composantes et services dune PKI
La disponibilit dautorits de certification commerciales ou administratives est lopportunit pour mettre en uvre une infrastructure de gestion de clefs ou Public Key Infrastructure (PKI). Linfrastructure de gestion de clefs recouvre lensemble des services mis en uvre pour assurer la gestion complte des clefs publiques. 10.1.1 Autorit denregistrement Cest lautorit qui reoit des utilisateurs les demandes de certificats ou CSR (Certificate Signing Request) et en vrifie la teneur. Les mthodes utilises pour ces vrifications dpendent de la nature du certificat demand et de la politique de certification choisie. La vrification peut tre limite lidentit du demandeur, mais on peut aussi vrifier sil possde bien la clef prive associe, sil a bien lautorisation de son organisation pour demander ce type de certificat, etc. Les moyens mis en uvre pour assurer cette vrification peuvent aller du simple change de courrier lectronique une vritable enqute effectue par exemple par les renseignements gnraux. Lenregistrement de la demande de certificat tant accept, la demande est passe lautorit de certification qui elle na connaissance que des informations strictement indispensables ltablissement du certificat.

74

10.1.2 Autorit de certification Elle fabrique le certificat en signant la clef publique du demandeur (avec sa clef prive). Le certificat contient le Distinguished Name du demandeur, sa clef publique, une date dexpiration et la destination du certificat, par exemple certificat destin un serveur HTTPS ou bien certificat pour signature S/MIME. Bien entendu, la clef prive de lautorit de certification est un lment vital de lensemble de linfrastructure de gestion de clefs, quiconque accde cette clef prive peut tablir de faux certificats. Lautorit de certification nest pas obligatoirement connecte sur le rseau Internet. 10.1.3 Service de publication Le service de publication permet laccs des utilisateurs aux clefs publiques de leurs correspondants. Lutilisation du service de publication nest pas requise pour toutes les applications de chiffrement asymtrique. En particulier, laccs un serveur HTTPS dans le but de chiffrer les changes ou dauthentifier le serveur ne requiert ni un accs au service de publication car le serveur HTTPS communique lui-mme son certificat au client, ni un accs lautorit de certification dont la clef publique peut accompagner le certificat du serveur HTTPS. De mme, il est possible dchanger des messages S/MIME sans utiliser le service de publication (lenvoi dun message sign permet de faire parvenir automatiquement son correspondant son certificat). Toutefois, lutilisation du service de publication est un lment dterminant ds que le nombre dutilisateurs augmente. Lidentit de la personne certifie est dfinie dans un Distinguished Name, elle constitue donc une clef daccs dans lannuaire LDAP. Par ailleurs LDAP est la seule API normalise et donc utilisable dans le contexte htrogne de lInternet. 10.1.4 Service de rvocation Lutilisation des cartes bancaires serait-elle rellement possible si lon ne pouvait pas faire opposition sur les cartes perdues ou voles ? De mme, il est vital de pouvoir rvoquer une clef publique. Dans le cas de la perte de sa clef prive, une personne doit bloquer lusage de sa clef publique faute de quoi elle ne peut plus lire les messages confidentiels qui lui sont adresss par ses correspondants. Dans le cas plus grave du vol de la clef prive, le voleur peut contrefaire la signature de sa victime et dchiffrer ses messages confidentiels. Le service de rvocation doit enregistrer, vrifier les demandes de rvocation (lauteur de la demande est-il bien la personne titulaire de la clef publique ?) et publier une liste des certificats rvoqus. Il appartient aux clients utilisateurs de vrifier les listes de rvocation pour les certificats quils utilisent. La rvocation est un lment du service de publication. Laccs aux listes de rvocation peut tre spcifi dans le certificat sous forme dune URL, mais peu de produits implmentent laccs aux listes de rvocation. Contrairement aux autres lments de la PKI, la liste de rvocation doit tre disponible en temps rel, de ce fait, cet lment de service de la PKI est le seul obligatoirement connect Internet.

75

10.1.5 Politique de certification La politique de certification dcrit lensemble de la procdure qui conduit certifier une clef publique. Cette politique prend en considration les moyens mis en uvre pour vrifier les informations constituant le certificat et la destination de celui-ci (certificat personnel pour la signature S/MIME, certificat de serveur HTTPS, etc). Une autorit de certification peut appliquer plusieurs politiques de certification selon les populations et les usages concerns. Quelques exemples de politiques de certification : Thawte personnal freemail : certificat gratuit obtenu quasiment sans vrification, le seul lment de preuve de lidentit du demandeur est acquis par change de mot de passe par courrier. On a donc la preuve que le demandeur a accs la boite aux lettres dont il prtend tre titulaire. Thawte personnal basic : il faut 100 points pour obtenir ce certificat. Les points sont obtenus auprs dun notaire Thawte qui peut vous attribuer 50 points si vous vous prsentez physiquement avec une copie de votre pice didentit. Avec 150 points vous devenez notaire. Cet exemple de politique de certification est assez intressant ; si trois complices malhonntes prouvent leur identit, ils peuvent devenir notaires et ds lors enregistrer de fausses demandes de certificats (Thawte propose un troisime niveau de certification Thawte personnal premium). Swisskey : ce service suisse vous demande de produire une pice didentit en cours de validit auprs dun reprsentant de son autorit denregistrement cest dire auprs de certaines banques (milieu dans lequel on a lhabitude de vrifier lidentit des personnes). Ces exemples montrent bien que la solidit des algorithmes de chiffrement ou la longueur des clefs utilises est relativement secondaire devant les aspects organisationnels de la PKI. LIETF a dfini dans le RFC-2560 un formalisme de description dune politique de certification. 10.1.6 Protection de la PKI Outre la politique de certification qui est un lment majeur de la confiance que lon peut accorder un certificat, la protection de la PKI est fondamentale. Le SCSSI a labor des profils de protection correspondant aux impratifs de ladministration franaise pour les niveaux les plus basiques jusquau niveau classifi secret dfense. Le fait par exemple que la socit de certification Certplus confie son blockhaus informatique un fabriquant de cartes bancaires illustre bien les enjeux qui dpendent de cette scurit.

10.1.7 Interoprabilit et PKI Nous avons montr comment linfrastructure de gestion de clefs publiques dont la pice matresse est lautorit de certification permet de rsoudre le dlicat problme des changes et vrification des clefs publiques. Comment des correspondants ayant obtenu leurs certificats personnels de messagerie auprs dautorits de certification distinctes peuvent-ils changer des courriers signs ou confidentiels ?

76

Pour vrifier la validit dun certificat, une application doit :

q

soit connatre directement et accorder confiance lautorit de certification ayant mis ce certificat (et donc disposer dans sa configuration de la clef publique de cette autorit), soit accorder confiance une autre autorit ayant elle-mme certifi la clef publique de lautorit mettrice du certificat valider (certification hirarchise ou croise).

Les logiciels de messageries Netscape et Outlook sont pr-configurs pour reconnatre et accepter comme digne de confiance un certain nombre dautorits de certification. La figure ci-dessous montre le menu security de la version franaise de Netscape Messenger.

Un menu permet dditer la liste des autorits reconnues. Il est possible dajouter de nouvelles autorits en chargeant dans son navigateur un certificat par exemple via un cgi. Lentte HTTP doit contenir Content-Type:application/x-x509-ca-cert. Les autorits pr-configures dans les deux principaux navigateurs du march le sont parce que des accords commerciaux lient ces autorits et les diteurs de ces logiciels. Ces accords ne sont absolument pas une garantie de fiabilit de ces autorits, ni du point de vue de leur profil de protection, ni de celui de la politique de certification mise en uvre. Pourtant, les clients de messagerie traitent indiffremment tous les certificats, quelle que soit lautorit mettrice. Trs peu de personnes disposent dune information suffisante pour choisir les autorits de certification dignes de confiance. Du point de vue dun serveur HTTPS Apache, il est possible de spcifier dans la configuration du serveur quelles sont les autorits reconnues. En pratique, il semble impossible pour un serveur destin une large population de refuser les certificats clients mis par des autorits largement dployes. Mais surtout, ce serveur sera tenu dobtenir (donc de payer) son certificat auprs dune de ces autorits, faute de quoi, le client est prvenu dans des termes trs inquitants quil communique avec un serveur dont on ne peut valider le certificat. Seules des applications dintranet peuvent peut-tre chapper ce dicta du march. 77

10.2 Les navigateurs et serveurs HTTPS

(source Thawte)

Internet Explorer 5.x Navigator 4.x Communicator 4.x Internet Explorer 4.x Internet Explorer 3.02

Navigateurs HTTPS Windows 95/98, NT 4.0 Toute plate-forme Windows 95/98, NT 4.0 Windows 3.1, NT 3.51 Windows 95/98, NT 4.0 SP3, Windows 3.1 (IE
3.02a.2916)

WebTV Classic et plus Opera 3.x et plus Windows 3.1, Windows95/98 FrontPage 2000 FrontPage 2000

Rpartition des serveurs HTTPS en France IIS 46.46% Apache 22.31% Netscape 14.17% Non identifis 4.20% Domino 3.41% Webstar 2.36% Website pro 2.10% Stronghold 1.84% Autres 3.15% Ces chiffres ont t obtenus en testant systmatiquement les URLs de la forme https://www.domaine.fr et https://secure.domaine.fr soit 350 certificats tests. Seulement 27% des serveurs franais utilisent des clefs de 128 bits, les autres tant toujours limits 40 bits. Apache est utilis pour 91% des serveurs utilisant les clefs de 128 bits.

10.3 Le projet OpenCA

Le but de ce projet est de fournir la communaut un ensemble logiciel permettant la mise en uvre des services de bases dune infrastructure de gestion de clefs publiques. Lensemble de ces logiciels tant disponible en open source. OpenCA est bas en particulier sur Apache, OpenSSL, OpenLDAP et mod_ssl. Massimiliano Pala, un des auteurs crit : this code is completly unfinished, unusable, but it works: the hard part is to guess how to set up the whole thing because of the lack of documentation. I would not release such an incomplete code normally, anyway let's see. Don't expect you'll get easily a working CA ... ". Sil fallait encore prouver quon ne peut faire confiance nimporte quelle autorit de certification, ce logiciel libre montre : que la technique de certification est la porte de tous les pirates de linternet ;

78

que le nombre dautorits de certification va augmenter considrablement et que faute dinscrire des dispositifs techniques dans des projets globaux de PKI, les problmes dinteroprabilit seront nombreux.

11 Les volutions lgislatives

Le Premier Ministre avait annonc au printemps 99 une libralisation du chiffrement concernant en particulier : augmentation de la taille des clefs utilisables (sauf exportation) ; suppression de lobligation de recourir un tiers de confiance (le tiers de confiance est charg du squestre des clefs prives) ; instauration dun label de qualit attribu aux autorits de certification ; instauration dune obligation (assortie de sanctions) de remise aux autorits judiciaires des transcriptions en clair des documents chiffrs ; modification du droit de la preuve pour la prise en compte de la signature lectronique.

Une partie de ces volutions tait possible par simple dcret ; celui du 19 mars 1999 permet lutilisation de moyens de chiffrement avec des clefs de 128 bits librement pour les personnes prives et sous rgime dclaratif pour les personnes morales. 2 Cette modification spectaculaire du cadre rglementaire est pourtant moins importante que la suppression des tiers de confiance. A noter toutefois que lesprit de ce qui a t annonc semble imposer un service dauto squestre des clefs prives pour nos tablissements. En effet, comment respecter lobligation de remise aux autorits judiciaires de la transcription lisible des changes chiffrs sans mettre en uvre un service de squestre des clefs prives ? Cette obligation est cependant beaucoup moins contraignante que les dispositions prcdentes, par ailleurs cette obligation permet la mise en uvre dun service de restauration de clef prive.

12 Des projets au sein nos administrations

Il nest pas prvu dautorit de certification interministrielle mais au sein du MENRT, la direction de ladministration travaille sur trois projets complmentaires. 1. Utilisation de signature S/MIME dans les rectorats. Dans les diffrents rectorats, vingt mille personnes environ ont des prrogatives administratives pour lesquelles leur signature papier est accepte. Ce premier projet dont les tudes se termine (dmarrage en janvier 2000) a pour objectif de distribuer vingt milles certificats de messagerie. La structure de la PKI est base sur des autorits de certification de niveau rectoral et une autorit de certification de ladministration. 2. Projet CPEN Carte Puce de lEducation Nationale. Ce projet concerne 1 300 000 personnels. Les applications de cette carte puce concernent laccs aux donnes personnelles des agents, laccs aux mises jour des annuaires, le partage de ressources pdagogiques ou de gestion etc . Il sera tudi la possibilit de passerelle
2

Vous pouvez utiliser le formulaire https://www.fortify.net/sslcheck.html pour vrifier la taille des clefs utilisables par votre navigateur

79

avec les services de fournisseurs d'accs. Le fait dutiliser une carte puce permet de stocker dautres informations que le seul certificat de la personne, par ailleurs, cest un atout important dans le cas dun usage nomade. Cet objet qui ressemble une carte bancaire, ne devrait pas tre peru comme un nime mot de passe. Cette image de la carte puce devrait faciliter la prise de conscience des responsabilits lies son usage. Comme dans le premier projet, la diffusion des clefs publiques est assure par un annuaire LDAP dont ltude est trs avance. 3. VPN sur Renater. Le but de ce troisime projet est de remplacer un certain nombre de liens privs par la notion de VPN applique sur linfrastructure de Renater. Ce rseau priv virtuel disposera de service de chiffrement.

Actuellement, les trois projets ne concernent pas directement les universits, cependant lexistence dans chaque acadmie dune autorit de certification accrdite par celle du ministre et lorganisation en parallle de serveurs LDAP constitueront un moteur important pour les projets de PKI que les universits pourraient adopter.

80

BIBLIOGRAPHIE
[BOUCQUEAU1997] BOUCQUEAU J.-M, DELAIGLE J .-F, DHEM J.-F , JOYE M., KOEUNE F., MASSIAS H., MESTRE P., QUISQUATER J.-J, Comment jouer pile ou face sur Internet sans tricher, Universit Catholique de Louvain, 1997 [CISCO1998] CISCO Systems, White Paper IPSec, 1998 [COHEN1995] COHEN Jo, La cryptographie au cur des rseaux, O1 Rseaux, Juin 1995 [DELEURENCE1996] DELEURENCE Guillaume, Une scurit presque parfaite, Rseaux & Tlcoms, Avril 1996 [EUROPE1997] Commission Europenne, Direction gnrale XII, Tlcommunication, March de linformation et valorisation de la recherche, Assurer la scutit et la confiance dans la communication lectronique, Vers un cadre Europen pour les signatures numriques et le chiffrement, 1997 [FAHN1993] FAHN Paul, Answers to frequently asked questions about todays cryptography, RSA laboratories, version 2.0, draft 2f, Septembre 1993 [FERRET1997] FERRET Bruno, Lauthentification, cl de voute de la scurit, Dcision Micro & Rseaux N 293, Avril 1997 [FISCHER1994] FISCHER M, How to implement the Data Encryption Standard (DES) - A step by step tutorial version 1.3, 1994 [FLORIN] FLORIN Grard NATKIN S., La scurit, CNAM - CEDRIC [GARFINKEL1995] GARFINKEL Simson, PGP Pretty Good Privacy, O'Reilly & Associates, Aot 1995 [HTTP] BERNERS-LEE T., FIELDING R. and FRYSTYK H., The Hypertext Transfer Protocol, RFC 1945, Mai 1996. [KARVE1997] KARVE Anita, Public Key Cryptography, LAN Magazine, page 23, Avril 1997 [KUPARINEN1998] KUPARINEN Martin, ISAKMP and IKE, 27 novembre 1998 [LABOURET1999] LABOURET Ghislaine, IPSec : prsentation technique, Herv Schauer Consultants, Avril 1999 [MIME] FREED, N. and BORENSTEIN N., "MIME Part 1: Format of Internet Message Bodies", RFC 2045, Novembre 1996. [PKCS7] RSA Laboratories, "PKCS #7: Cryptographic Message Syntax Standard", Novembre 1993.

81

[PKCS12] RSA Laboratories, "PKCS #12: Personnal Information Exchange Syntax", Juin 1999. [ROUSSEAU1996] ROUSSEAU Ludovic, Cours Scurit V1.1, Bordeaux 20 et 21 janvier 1997, CNAM/CEDRIC, Dcembre 1996 [SCHNEIER] SCHNEIER Bruce, Cryptographie applique, 2ime Edition, New York : John Wiley, 1996 [SMIME] DUSSE S., HOFFMAN P., RAMSDELL B., LUNDBLADE L. and REPKA L., "S/MIME Version 2 Message Specification", RFC2311, Mars 1998. [TANENBAUM1997] TANENBAUM A., Rseaux Applications, InterEditions, 3ime Edition, Juillet 1997 Architecture, Protocoles,

[SCHNEIER] SCHNEIER Bruce, Cryptographie applique, 2ime Edition, New York : John Wiley, 1996 [SSLV3] FREIER A., KARLTON P. and KOCHER P., "The SSL Protocol Version 3.0", Internet Draft, Transport Layer Security Working Group, Novembre 1996.

82

URL

[MODSSL] [OPENCA] [OPENSSL] [SSLV2] [WEBMAIL] [SCSSI] [WRAPSSL]

http://www.modssl.org http://www.openca.org http://www.openssl.org http://www.netscape.com/eng/security/SSL_2.html http://www.cru.fr/http-mail http://www.SCSSI.gouv.fr/document/igc.html http://www1.kappa.ro/~drazvan

83