Intégration de ISAKMP au sein du protocole SSL

UNIVERSITE LIBANAISE (Faculté de Génie) UNIVERSITE SAINT-JOSEPH (Faculté d'ingénierie) Sous l'égide de l'agence Universitaire de la Francophonie AUF Diplôme d'etudes Approfondies Réseaux de télécommunications Intégration de ISAKMP au sein du protocole SSL Par Ing. Hikmat ADHAMI Encadré par : M. Ahmed SERHROUCHNI (ENST) M. Antoine FEGHALI (ESIB) Soutenance le 16/4/2003 devant le jury composé de MM. Samir Tohmé Président Mohamad Zoaeter Membre Wajdi Najem Membre Imad Mougharbel Membre Nicolas Rouhana Membre Mahmoud Doughan Membre Maroun Chamoun Membre Intégration ISAKMP/SSL-H.Adhami-2002/2003 1

Table des matières Table des matières---------------------------------------------------------------------------------------------2 Introduction générale et résumé-----------------------------------------------------------------------------5 Chap I Introduction à la cryptographie -----------------------------------------------------------------7 I.1 Terminologie--------------------------------------------------------------------------------------7 I.2 Mécanismes et services de sécurité ------------------------------------------------------------7 I.3 Confidentialité et algorithmes de chiffrement ------------------------------------------------7 I.3.1 Chiffrement symétrique ----------------------------------------------------------------------8 I.3.2 Cryptographie à clef publique ---------------------------------------------------------------8 I.4 Fonctions de hachage, signature et scellement -----------------------------------------------9 I.4.1 Intégrité et authentification-------------------------------------------------------------------9 I.4.2 Fonction de hachage ------------------------------------------------------------------------ 10 I.4.3 Signature numérique ------------------------------------------------------------------------ 10 I.4.4 Scellement------------------------------------------------------------------------------------ 11 I.5 Authentification mutuelle et échange de clefs de session --------------------------------- 13 I.5.1 Transport de clef----------------------------------------------------------------------------- 13 I.5.2 Diffie-Hellman------------------------------------------------------------------------------- 13 I.5.2.1 Principe de déroulement de DH ----------------------------------------------------- 14 I.5.2.2 Propriétés de DH ---------------------------------------------------------------------- 14 I.6 Certificats, Autorités de Certification et PKI ----------------------------------------------- 15 I.6.1 Qu est-ce qu un Certificat?---------------------------------------------------------------- 15 I.6.2 Qu est-ce qu une Autorité de Certification ---------------------------------------------- 16 I.7 Conclusion -------------------------------------------------------------------------------------- 16 Chap II SSL: Socket Secure Layer------------------------------------------------------------------ 17 II.1 Présentation générale du protocole SSL----------------------------------------------------- 17 II.1.1 Architecture de fonctionnement -------------------------------------------------------- 17 II.1.2 Les apports de SSL----------------------------------------------------------------------- 19 II.2 Les sous-protocoles de SSL------------------------------------------------------------------- 19 II.2.1 Déroulement des échanges SSL -------------------------------------------------------- 20 II.2.1.1 Variables d'état d'une session SSL -------------------------------------------------- 21 II.2.1.2 Variables d'état d'une connexion SSL ---------------------------------------------- 22 II.2.2 Synopsis des calculs de paramètres ---------------------------------------------------- 23 II.3 Le protocole Handshake----------------------------------------------------------------------- 24 II.3.1 Fonctionnement général ----------------------------------------------------------------- 24 II.3.2 Ouverture d'une nouvelle session ------------------------------------------------------ 27 II.3.3 Identifications des suites de chiffrement ---------------------------------------------- 28 II.3.4 Authentification du serveur ------------------------------------------------------------- 28 II.3.5 Échanges de secrets ---------------------------------------------------------------------- 29 II.3.6 Vérification et confirmation par le serveur-------------------------------------------- 31 II.3.7 Ouverture d'une connexion-------------------------------------------------------------- 31 II.4 Le protocole ChangeCipherSpec (CCS)----------------------------------------------------- 32 II.5 Le protocole Record --------------------------------------------------------------------------- 33 II.6 Le protocole Alert ------------------------------------------------------------------------------ 34 II.7 Conclusion -------------------------------------------------------------------------------------- 35 Chap III IPsec------------------------------------------------------------------------------------------- 36 III.1 Vue d ensemble--------------------------------------------------------------------------------- 36 III.1.1 Architecture d IPsec --------------------------------------------------------------------- 36 Intégration ISAKMP/SSL-H.Adhami-2002/2003 2

III.1.1.1 Les mécanismes AH et ESP------------------------------------------------------- 36 III.1.1.2 La notion d association de sécurité.---------------------------------------------- 37 III.1.1.3 La gestion des clefs et des associations de sécurité ---------------------------- 37 III.1.1.4 Politique de sécurité. -------------------------------------------------------------- 38 III.1.2 Principe de fonctionnement. ------------------------------------------------------------ 38 III.1.3 Types d utilisations possibles----------------------------------------------------------- 39 III.1.3.1 Équipement fournissant IPsec ---------------------------------------------------- 39 III.1.3.2 Modes de fonctionnement --------------------------------------------------------- 41 III.2 Les mécanismes de sécurité : AH et ESP --------------------------------------------------- 41 III.2.1 Authentification Header (AH) ---------------------------------------------------------- 41 III.2.2 Encapsulating Security Payload (ESP)------------------------------------------------ 43 III.3 La gestion des clefs ---------------------------------------------------------------------------- 45 III.3.1 Les protocoles d authentification mutuelle avec échange de clef pour IP -------- 45 III.3.1.1 SKIP---------------------------------------------------------------------------------- 45 III.3.1.2 Photuris ------------------------------------------------------------------------------ 45 III.3.1.3 SKEME ------------------------------------------------------------------------------ 46 III.3.1.4 Oakley ------------------------------------------------------------------------------- 46 III.3.1.5 La gestion des clefs pour IPsec : ISAKMP ET IKE --------------------------- 46 III.4 Conclusion -------------------------------------------------------------------------------------- 47 Chap IV ISAKMP-------------------------------------------------------------------------------------- 48 IV.1 Placement D ISAKMP ------------------------------------------------------------------------ 48 IV.2 Indépendance vis à vis des mécanismes: les domaines d'interprétation et les phases - 48 IV.3 Les Charges utiles d ISAKMP --------------------------------------------------------------- 49 IV.3.1 Format de l en-tête ISAKMP (ISAKMP Header Payload)------------------------- 49 IV.3.2 Generic Header Payload ou charge utile de l En-tête Générique------------------ 50 IV.3.3 Attributs de données --------------------------------------------------------------------- 50 IV.3.4 Indépendance vis-à-vis du protocole de gestion des clefs: la construction des messages par blocs ----------------------------------------------------------------------------------- 51 IV.3.4.1 Bloc Security Association --------------------------------------------------------- 52 IV.3.4.2 Le bloc PROPOSAL---------------------------------------------------------------- 52 IV.3.4.3 Bloc TRANSFORM----------------------------------------------------------------- 52 IV.3.4.4 Bloc Key Exchange----------------------------------------------------------------- 53 IV.3.4.5 Les autres blocs--------------------------------------------------------------------- 54 IV.4 Interopérabilité et ligne directrice: les types d'échanges ---------------------------------- 57 IV.4.1 Etablissement de l Association de Sécurité ------------------------------------------- 58 IV.4.1.1 Exemples de l Etablissement de l Association de Sécurité ------------------- 59 IV.4.1.2 Modification de l Association de Sécurité -------------------------------------- 62 IV.4.2 Les types d échanges--------------------------------------------------------------------- 62 IV.5 IPsec DOI --------------------------------------------------------------------------------------- 64 IV.6 IKE ----------------------------------------------------------------------------------------------- 66 IV.6.1 Main Mode et Agressive Mode --------------------------------------------------------- 66 IV.6.2 Phase 2 :Quick Mode--------------------------------------------------------------------- 68 IV.6.3 Les groupes : New Group Mode-------------------------------------------------------- 69 IV.6.4 Phases et modes -------------------------------------------------------------------------- 69 IV.7 Conclusion -------------------------------------------------------------------------------------- 70 Chap V Intégration ISAKMP/SSL ------------------------------------------------------------------ 71 V.1 Openssl : l implémentation de référence de SSL------------------------------------------- 71 V.1.1 Exemples des opérations de base sur des certificats avec OpenSSL--------------- 71 V.1.2 Code Source SSL------------------------------------------------------------------------- 72 V.2 KAME ------------------------------------------------------------------------------------------- 72 V.2.1 Caratéristiques : Algorithmes cryptographiques ------------------------------------- 73 V.2.2 Le démon de la gestion de clef : Racoon ---------------------------------------------- 74 Intégration ISAKMP/SSL-H.Adhami-2002/2003 3

V.2.2.1 Implémentation de Racoon dans FreeBSD----------------------------------------- 74 V.2.2.2 Racoon, comment il fonctionne? --------------------------------------------------- 76 V.3 Définir un nouveau Domaine d Interprétation (Domain Of Interpretation DOI) ------ 79 V.3.1 La Situation ------------------------------------------------------------------------------- 79 V.3.2 Les politiques de Sécurité --------------------------------------------------------------- 80 V.3.3 Les Plans de Nomination ---------------------------------------------------------------- 80 V.3.4 Syntaxe pour la Spécification des Services de Sécurité ----------------------------- 80 V.3.5 Spécification de la Charge Utile-------------------------------------------------------- 80 V.3.6 Définir des nouveaux Types d Échange----------------------------------------------- 80 V.4 Nouveau protocole Handshake --------------------------------------------------------------- 80 Conclusions et perspectives--------------------------------------------------------------------------------82 Annexe A-----------------------------------------------------------------------------------------------------84 Annexe B-----------------------------------------------------------------------------------------------------87 Annexe C-----------------------------------------------------------------------------------------------------88 Bibliographie et références--------------------------------------------------------------------------------92 Intégration ISAKMP/SSL-H.Adhami-2002/2003 4

Introduction générale et résumé Pendant plusieurs décennies on a utilisé les réseaux d'ordinateurs essentiellement pour s échanger du courrier ou partager des imprimantes. La sécurité n était donc pas le premier souci des utilisateurs. Mais aujourd hui, des millions de citoyens utilisent les réseaux pour effectuer des opérations bancaires ou des achats par correspondance et la sécurité de ces transactions devient un véritable problème. Dans le présent rapport, nous étudierons en détail quelques protocoles de sécurité des couches réseau et transport, et des protocoles de gestion de clefs, dans le but de spécifier une intégration qui comble les lacunes et la vulnérabilité d un de ces protocoles, spécifiquement le sous protocole Handshake du protocole SSL. But du projet Les objectifs de la sécurisation sont: interdire à un tiers externe aux participants de lire ou de manipuler le contenu ou les séquences des messages échangés sans détection. Plus particulièrement, ce tiers ne doit pas pouvoir rejouer des anciens messages, remplacer des blocs d'information ou intercaler les messages de plusieurs suites d'échanges distinctes sans détection; entraver le truquage des pièces ou la génération de messages factices par des utilisateurs malintentionnés. Par exemple, des commerçants ou des centres de traitement peu scrupuleux ne devront pas être capables de réutiliser les informations bancaires des clients pour générer des commandes frauduleuses ou de conserver les paiements sans expédition des commandes. De même, les marchants seront protégés contre les révocations abusives des paiements ou les contestations malveillantes des commandes; satisfaire les conditions légales en vigueur pour valider les contrats et régler les litiges, notamment du consommateur, de la protection de la vie privée,... assurer les partenaires qu'ils pourront avoir accès au service selon le contrat établi avec les fournisseurs; assurer le même niveau de protection en dépit des variations climatologiques et atmosphériques: température, humidité, intempéries, etc. La sécurisation des échanges du commerce électronique consiste à utiliser des fonctions mathématiques pour brouiller le texte initial avant sa transmission. Ce texte devra être restitué à sa forme initiale après réception par le destinataire authentique. La sécurisation comporte cinq services (traités plus en détail au chapitre 1): - la confidentialité des messages; - l'identité des participants; - l'intégrité des données; - l'authentification des participants; - et la non répudiation. A chaque couche du modèle OSI, ont été assignées des fonctions de sécurisation cryptographiques (qui seront détaillées dans le chapitre 1) Le protocole Socket Secure Layer SSL, est un des protocoles les plus utilisés pour sécuriser la liaison entre un client et son serveur dans les applications de commerce électronique. Par rapport au modèle OSI, SSL se situe entre la couche de transport et celle d'application. On pourrait à la rigueur le qualifier de protocole de présentation. Dans son intégrité, il assure l'authentification, Intégration ISAKMP/SSL-H.Adhami-2002/2003 5

l'intégrité, et la confidentialité. A l'aide d'une signature numérique, il est possible d'assurer en plus un service de non répudiation. En outre, il est composé de 4 sous-protocoles. L'un de ces sous-protocoles, est le Handshake, qui est chargé de l'authentification des parties en communication, de la négociation des algorithmes de chiffrement et de hachage, et de l'échange d'un secret. Cependant, ce sousprotocole présente une certaine vulnérabilité dans ces premières étapes. Qui dit algorithme de chiffrement, hachage et secret partagé, dit gestion des clefs. En fait, la gestion des clefs continue tout le long du cycle de vie des clefs de jouer la divulgation non autorisée, la modification, la substitution, le rejeu ou l'usage non autorisé. La sécurisation à ce niveau est un problème récursif car les propriétés sécuritaires à atteindre avec un système cryptologique doivent être satisfaites par le système de gestion des clefs, afin de donner les propriétés requises. Ces propriétés se rapportent à tous les aspects du cycle de vie des clefs: la production des clefs, leur stockage, leur distribution, utilisation, retrait de la circulation, suppression, et archivage. La distribution des clefs joue un rôle primordial. Elle peut-être manuelle (par courrier ou par dépêche), dans ce cas c'est une opération à la fois coûteuse et lente, comme elle peut-être automatique et dans ce cas elle doit satisfaire tous les critères de sécurités, notamment ceux décrits précédemment. Il y a donc, un fort besoin de gérer la distribution des clefs. A ce sujet, on trouve ISAKMP (Internet Security Association and Key Management Protocol - Association de sécurité Internet et protocole de gestion de clefs) le protocole proposé par Cisco Systems pour la gestion de la distribution des clefs de chiffrement et spécifiquement à l'aide de la cryptographie à clef publique. Ce protocole, de niveau applicatif, est indépendant des protocoles de sécurité et d échange de clefs, et capable de sécuriser n importe quelle couche. Ce protocole est très riche et possède des propriétés le font plus avantageux que beaucoup d autres protocoles. Dans ce cadre, on penserait de profiter de ces avantages pour combler les lacunes et les vulnérabilités du sous-protocole Handshake du SSL. D où le but de ce rapport, qui était de spécifier une intégration d ISAKMP et de SSL, donc de modifier le code source de SSL et pour implanter des modules ISAKMP permettant de lever la vulnérabilité du Handshake. Mais, selon les contraintes du temps et des quelques difficultés rencontrées, on a procédé seulement par une démarche théorique pour l implémentation du nouveau protocole. Dans le premier chapitre, nous introduisons les services de sécurités et les bases de la cryptographie. Puis, dans le deuxième chapitre, nous détaillons le protocole SSL avec ces quatres sous-protocoles. IPsec, avec AH et ESP font l'objet du troisième chapitre. Le protocole ISAKMP, est traité en détail au chapitre 4, avec la gestion des échanges de clefs. Le dernier chapitre présente les étapes vers une intégration (implémentation) ISAKMP/SSL en introduisant la notion de création d un nouveau domaine d interprétation SSL pour ISAKMP. Une conclusion, à la fin, permet de donner quelques perspectives pour une continuation de ce projet. Le rapport est annexé par trois documents contenants les messages du Handshake, quelques directives d un outil (Racoon) qui sert dans l implémentation, et un petit glossaire. Et enfin, une bibliographie exhaustive, servant de références termine ce rapport. Mots-clef : Cryptographie, Algorithme de chiffrement, SSL, Confidentialité, Integrité, Authentification, Handshake, IPsec, AH, ESP, Gestion des clefs, Assotiation de sécurité, ISAKMP, Kame, Racoon. Intégration ISAKMP/SSL-H.Adhami-2002/2003 6

Introduction à la cryptographie Chap I Introduction à la cryptographie I.1 Terminologie La cryptologie est une science mathématique qui comporte deux branches : la cryptographie et la cryptanalyse. La cryptographie traditionnelle est l'étude des méthodes permettant de transmettre des données de manière confidentielle. Afin de protéger un message, on lui applique une transformation qui le rend incompréhensible ; c'est ce qu'on appelle le chiffrement, qui, à partir d'un texte en clair, donne un texte chiffré ou cryptogramme. Inversement, le déchiffrement est l'action qui permet de reconstruire le texte en clair à partir du texte chiffré. Dans la cryptographie moderne, les transformations en question sont des fonctions mathématiques, appelées algorithmes cryptographiques, qui dépendent d'un paramètre appelé «clef». La cryptanalyse, à l'inverse, est l'étude des procédés cryptographiques dans le but de trouver des faiblesses et, en particulier, de pouvoir décrypter des textes chiffrés. Le décryptement est l'action consistant à retrouver le texte en clair sans connaître la clef de déchiffrement. Note : Les termes "cryptage" et "crypter" sont des anglicismes, dérivés de l'anglais to encrypt, souvent employés incorrectement à la place de chiffrement et chiffrer. En toute rigueur, ces termes n'existent pas dans la langue française. Si le "cryptage" existait, il pourrait être défini comme l'inverse du décryptage, c'est-à-dire comme l'action consistant à obtenir un texte chiffré à partir d'un texte en clair sans connaître la clef. Un exemple concret pourrait être de signer un texte choisi en reproduisant un chiffrement avec la clef privée de la victime. Mais on préfère parler dans ce cas de contrefaçon et de l'action de forger une signature. I.2 Mécanismes et services de sécurité Si le but traditionnel de la cryptographie est d'élaborer des méthodes permettant de transmettre des données de manière confidentielle, la cryptographie moderne s'attaque en fait plus généralement aux problèmes de sécurité des communications. Le but est d'offrir un certain nombre de services de sécurité comme la confidentialité, l'intégrité, l'authentification des données transmises et l'authentification d'un tiers. Pour cela, on utilise un certain nombre de mécanismes basés sur des algorithmes cryptographiques. Nous allons voir dans ce qui suit quelles sont les techniques que la cryptographie fournies pour réaliser ces mécanismes. I.3 Confidentialité et algorithmes de chiffrement La confidentialité est historiquement le premier problème posé à la cryptographie. Il se résout par la notion de chiffrement, mentionnée plus haut. Il existe deux grandes familles d'algorithmes cryptographiques à base de clefs: les algorithmes à clef secrète ou algorithmes symétriques, et les algorithmes à clef publique ou algorithmes asymétriques. Intégration ISAKMP/SSL-H.Adhami-2002/2003 7

Introduction à la cryptographie I.3.1 Chiffrement symétrique Dans la cryptographie conventionnelle, les clefs de chiffrement et de déchiffrement sont identiques: c'est la clef secrète, qui doit être connue des tiers communicants et d'eux seuls. Le procédé de chiffrement est dit symétrique. Clef secrète Texte en clair Texte chiffré Texte en clair Alice Figure I.1 Chiffrement symétrique Bob I.3.2 Cryptographie à clef publique Avec les algorithmes asymétriques, les clefs de chiffrement et de déchiffrement sont distinctes et ne peuvent se déduire l'une de l'autre. On peut donc rendre l'une des deux publique tandis que l'autre reste privée. C'est pourquoi on parle de chiffrement à clef publique. Si la clef publique sert au chiffrement, tout le monde peut chiffrer un message, que seul le propriétaire de la clef privée pourra déchiffrer. On assure ainsi la confidentialité. Certains algorithmes permettent d'utiliser la clef privée pour chiffrer. Dans ce cas, n'importe qui pourra déchiffrer, mais seul le possesseur de la clef privée peut chiffrer. Cela permet donc la signature de messages. Le concept de cryptographie à clef publique a été inventé par Whitfield Diffîe et Martin Hellman en 1976, dans le but de résoudre le problème de distribution des clefs posé par la cryptographie à clef secrète. De nombreux algorithmes permettant de réaliser un «cryptosystème» à clef publique ont été proposés depuis. Ils sont le plus souvent basés sur des problèmes mathématiques difficiles à résoudre, donc leur sécurité est conditionnée par ces problèmes, sur lesquels on a maintenant une vaste expertise. Mais, si quelqu'un trouve un jour le moyen de simplifier la résolution d'un de ces problèmes, l'algorithme correspondant s'écroulera. Texte en clair Alice Clef publique Bob Texte chiffré Clef Privée Bob Texte en clair Bob Figure I.2 Chiffrement Texte en clair Alice Clef Privée Alice Texte chiffré Figure I.3 Signature Clef Publique Alice Texte en clair Bob Intégration ISAKMP/SSL-H.Adhami-2002/2003 8

Introduction à la cryptographie Tous les algorithmes actuels présentent l'inconvénient d'être bien plus lents que les algorithmes à clef secrète; de ce fait, ils sont souvent utilisés non pour chiffrer directement des données, mais pour chiffrer une clef de session secrète. Certains algorithmes asymétriques ne sont adaptés qu'au chiffrement, tandis que d'autres ne permettent que la signature. Seuls trois algorithmes sont utilisables à la fois pour le chiffrement et pour la signature : RSA, ElGamal et Rabin. Alice Texte en clair Clef secrète Clef publique Bob Texte chiffré Texte chiffré Clef Privée Bob Clef secrète Texte en clair Bob Figure I.4 Exemple de combinaison : Clefs publiques / Clefs secrètes I.4 Fonctions de hachage, signature et scellement I.4.1 Intégrité et authentification Parmi les problèmes auxquels s'attaque la cryptographie, on trouve l'authentification de l'origine des données et l'intégrité : lorsque l'on communique avec une autre personne au travers d'un canal peu sûr, on aimerait que le destinataire puisse s'assurer que le message émane bien de l'auteur auquel il est attribué et qu'il n'a pas été altéré pendant le transfert. Les fonctions de hachage à sens unique interviennent dans la résolution de ces problèmes. Si l'on dispose d'un canal sûr (mais plus coûteux) en parallèle du canal de communication normal, on peut communiquer l'empreinte des messages par l'intermédiaire de ce canal. On assure ainsi l'intégrité des données transférées. Sans canal sûr, le problème se complique: si l'on transfère l'empreinte sur un canal de communication non sûr, un intercepteur peut modifier les données puis recalculer l'empreinte. Il convient donc de trouver une méthode pour s'assurer que seul l'expéditeur est capable de calculer l'empreinte. Pour cela, on peut utiliser, par exemple, une fonction de hachage à sens unique qui fonctionne de plus avec une clef secrète ou privée. On remarquera que, ce faisant, on fournit Intégration ISAKMP/SSL-H.Adhami-2002/2003 9

Introduction à la cryptographie également l'authentification de l'origine des données. Inversement, si on désire fournir l'authentification de l'origine des données et que l'on utilise pour cela un moyen qui ne garantit pas l'intégrité des données authentifiées, un intrus peut modifier le message et donc faire accepter comme authentifiées des données qu'il a choisies. C'est pourquoi intégrité et authentification de l'origine des données sont généralement fournies conjointement par un même mécanisme. On utilisera parfois le terme d'authenticité pour désigner l'intégrité jointe à l'authentification des données. I.4.2 Fonction de hachage Aussi appelée fonction de condensation, une fonction de hachage est une fonction qui convertit une chaîne de longueur quelconque en une chaîne de taille inférieure et généralement fixe; la chaîne résultante est appelée empreinte (digest en anglais) ou condensé de la chaîne initiale. Message Empreinte Figure I.5 Hachage Une fonction à sens unique est une fonction facile à calculer mais difficile à inverser. La cryptographie à clef publique repose sur l'utilisation de fonctions à sens unique à brèche secrète : pour qui connaît le secret (i.e. la clef privée), la fonction devient facile à inverser. Une fonction de hachage à sens unique est une fonction de hachage qui est en plus une fonction à sens unique: il est aisé de calculer l'empreinte d'une chaîne donnée, mais il est difficile d'engendrer des chaînes qui ont une empreinte donnée, et donc de déduire la chaîne initiale à partir de l'empreinte. On demande généralement en plus à une telle fonction d'être sans collision, c'est-à-dire qu'il soit impossible de trouver deux messages ayant la même empreinte. On utilise souvent le terme fonction de hachage pour désigner, en fait, une fonction de hachage à sens unique sans collision. La plupart des fonctions de hachage à sens unique sans collision sont construites par itération d'une fonction de compression: le message M est décomposé en n blocs m1,...,mn, puis une fonction de compression f est appliquée à chaque bloc et au résultat de la compression du bloc précédent; l'empreinte h(m) est le résultat de la dernière compression. I.4.3 Signature numérique La norme ISO 7498-2 définit la signature numérique comme des "données ajoutées à une unité de données, ou transformation cryptographique d'une unité de données, permettant à un destinataire de prouver la source et l'intégrité de l'unité de données et protégeant contre la contrefaçon (par le destinataire, par exemple)". La mention "protégeant contre la contrefaçon" implique que seul l'expéditeur doit être capable de générer la signature. Intégration ISAKMP/SSL-H.Adhami-2002/2003 10

Introduction à la cryptographie Une signature numérique fournit donc les services d'authentification de l'origine des données, d'intégrité des données et de non-répudiation. Ce dernier point la différencie des codes d'authentification de message (voir paragraphe précédent), et a pour conséquence que la plupart des algorithmes de signature utilisent la cryptographie à clef publique. Sur le plan conceptuel, la façon la plus simple de signer un message consiste à chiffrer celui-ci à l'aide d'une clef privée: seul le possesseur de cette clef est capable de générer la signature, mais toute personne ayant accès à la clef publique correspondante peut la vérifier. Dans la pratique, cette méthode est peu utilisée du fait de sa lenteur. La méthode réellement utilisée pour signer consiste à calculer une empreinte du message à signer et à ne chiffrer que cette empreinte. Le calcul d'une empreinte par application d'une fonction de hachage étant rapide et la quantité de données à chiffrer étant fortement réduite, cette solution est bien plus rapide que la précédente: Signature Message Empreinte Signature Vérification Clef privée Alice Message Empreinte Identiques? Signature Empreinte Clef publique Alice Figure I.6 Signature numérique et sa vérification I.4.4 Scellement Tout comme la signature numérique, le scellement fournit les services d'authentification de l'origine des données et d'intégrité des données, mais il ne fournit pas la non-répudiation. Ceci permet l'utilisation de la cryptographie à clef secrète pour la génération du sceau ou code d'authentification de message : Scellement Vérification Message Sceau Message Sceau Clef secrète Sceau Clef secrète Identiques? Figure I.7 Scellement et sa vérification Intégration ISAKMP/SSL-H.Adhami-2002/2003 11

Introduction à la cryptographie Un code d'authentification de message (Message Authentication Code, MAC) est le résultat d'une fonction de hachage à sens unique dépendant d'une clef secrète: l'empreinte dépend à la fois de l'entrée et de la clef. On peut construire un MAC à partir d'une fonction de hachage ou d'un algorithme de chiffrement par blocs. Il existe aussi des fonctions spécialement conçues pour faire un MAC. Une façon courante de générer un code d'authentification de message consiste à appliquer un algorithme de chiffrement symétrique en mode CBC au message; le MAC est le dernier bloc du cryptogramme. Message Longueur variable Clef secrète Algorithme de Chiffrement symétrique En mode CBC Code d authentification de Message Dernier bloc Figure I.8 Scellement à l aide d un algorithme symétrique Une autre méthode consiste à appliquer la fonction de hachage non pas simplement aux données à protéger, mais à un ensemble dépendant à la fois des données et d'un secret. Keyed-Hash Un exemple simple de cette façon de procéder est de prendre pour MAC des valeurs du type H(secret, message), H(message, secret) ou H(secret, message, secret). Ces méthodes, présentées en 1992 par Gene Tsudik, s'appellent respectivement méthode du préfixe secret, du suffixe secret et de l'enveloppe secrète. Elles ont une sécurité limitée. HMAC Une méthode de calcul de MAC à base de fonction de hachage plus élaborée et plus sûre est HMAC, présenté dans la RFC 2104. La méthode HMAC peut être utilisée avec n'importe quelle fonction de hachage itérative telle que MD5, SHA-1 ou encore RIPE-MD. Soit H une telle fonction, K le secret et M le message à protéger. H travaille sur des blocs de longueur b octets (64 en général) et génère une empreinte de longueur l octets (16 pour MD5, 20 pour SHA-1 et RIPE-MD-160). Il est conseillé d'utiliser un secret de taille au moins égale à l octets. On définit deux chaînes, ipad (inner padding data) et opad (outer padding data), de la façon suivante : ipad = l'octet 0x36 répété b fois, opad = l'octet 0x5C répété b fois. Le MAC se calcule alors suivant la formule suivante: HMACK(M) = H ( K XOR opad, H(K XOR ipad, M) ). Une pratique courante avec les fonctions de calcul de MAC est de tronquer la sortie pour ne garder comme MAC qu'un nombre réduit de bits. Avec HMAC, on peut ainsi choisir de ne Intégration ISAKMP/SSL-H.Adhami-2002/2003 12

Introduction à la cryptographie retenir que les t bits de gauche, où t doit être supérieur à l/2 et 80. On désigne alors sous la forme HMAC-H-t l'utilisation de HMAC avec la fonction H, tronqué à t bits (par exemple, HMAC- SHA 1-96). I.5 Authentification mutuelle et échange de clefs de session Tout comme les protocoles de communication, les protocoles cryptographiques sont une série d'étapes prédéfinies, basées sur un langage commun, qui permettent à plusieurs participants (généralement deux) d'accomplir une tâche. Dans le cas des protocoles cryptographiques, les tâches en question sont bien sûr liées à la cryptographie: ce peut être une authentification, un échange de clef,... Une particularité des protocoles cryptographiques est que les tiers en présence ne se font généralement pas confiance et que le protocole a donc pour but d'empêcher l'espionnage et la tricherie. I.5.1 Transport de clef Les deux méthodes les plus courantes d'établissement de clef sont le transport de clef et la génération de clef. Un exemple de transport de clef est l'utilisation d'un algorithme à clef publique pour chiffrer une clef de session générée aléatoirement. Un exemple de génération de clef est le protocole Diffie-Hellman, qui permet de générer un secret partagé à partir d'informations publiques. Alice choisie la clef de session La chiffre avec la clef publique de Bob Clef publique Bob Envoie la clef chiffrée à Bob Bob récupère la clef de session grâce à sa clef privée Clef privée Bob I.5.2 Diffie-Hellman Figure I.9 Transport de clef Inventé en 1976 par Diffie et Hellman, ce protocole permet à deux tiers de générer un secret partagé sans avoir aucune information préalable l'un sur l'autre. Il est basé sur la cryptologie à clef publique (dont il est d'ailleurs à l'origine), car il fait intervenir des valeurs publiques et des valeurs privées. Sa sécurité dépend de la difficulté de calculer des logarithmes discrets sur un corps fini. Le secret généré à l'aide de cet algorithme peut ensuite être utilisé pour dériver une ou plusieurs clefs (clef secrète, clef de chiffrement de clefs...). Intégration ISAKMP/SSL-H.Adhami-2002/2003 13

Introduction à la cryptographie I.5.2.1 Principe de déroulement de DH Le déroulement de l'algorithme DH est comme suit: 1- Alice et Bob se mettent d'accord sur un grand entier n tel que (n-1)/2 soit premier et sur un entier g primitif par rapport à n. Ces deux entiers sont publics. 2- Alice choisit de manière aléatoire un grand nombre entier a, qu'elle garde secret, et calcule sa valeur publique, A = g a mod n. Bob fait de même et génère b et B = g b mod n. 3 - Alice envoie A à Bob ; Bob envoie B à Alice. 4- Alice calcule K AB = B a mod n ; Bob calcule K BA = A b mod n. K AB = K BA = g ab mod n est le secret partagé par Alice et Bob. Valeur privée a Valeur publique A = g a mod n Valeur publique B = g b mod n Valeur privée a Figure I.10 Echange de valeurs publiques g ab mod n B a mod n Secret partagé A b mod n Figure I.11 Génération du secret partagé Une personne qui écoute la communication connaît g, n, A =g a mod n et B=g b mod n, ce qui ne lui permet pas de calculer g ab mod n: il lui faudrait pour cela calculer le logarithme de A ou B pour retrouver a ou b. I.5.2.2 Propriétés de DH En revanche, Diffie-Hellman est vulnérable à l'attaque active dite attaque de l'intercepteur (Manin-the-Middle). Une façon de contourner le problème de l'attaque de l'intercepteur sur Diffie-Hellman est d'authentifier les valeurs publiques utilisées pour la génération du secret partagé. On parle alors de Diffie-Hellman authentifié. L'authentification peut se faire à deux niveaux: En utilisant des valeurs publiques authentifiées, à l'aide de certificats par exemple. Cette méthode est notamment à la base du protocole SKIP (voir chapitre III). En authentifiant les valeurs publiques après les avoir échangées, en les signant par exemple. Cette méthode est utilisée entre autres par les protocoles Photuris et IKE (voir chapitre III). L'inconvénient, dans les deux cas, est que l'on perd un gros avantage de Diffie-Hellman, qui est la possibilité de générer un secret partagé sans aucune information préalable sur l'interlocuteur. Mais Diffie-Hellman, même authentifié, fournit une propriété intéressante, appelée propriété de Perfect Forward Secrecy (PFS). Cette propriété est garantie si la découverte par un adversaire du ou des secrets à long terme ne compromet pas les clefs de session générées précédemment: les Intégration ISAKMP/SSL-H.Adhami-2002/2003 14

Introduction à la cryptographie clefs de session passées ne pourront pas être retrouvées à partir des secrets à long terme. On considère généralement que cette propriété assure également que la découverte d'une clef de session ne compromet ni les secrets à long terme ni les autres clefs de session. A ce sujet, on parle d'attaque de Denning-Sacco lorsqu'un attaquant récupère une clef de session et utilise celle-ci, soit pour se faire passer pour un utilisateur légitime, soit pour rechercher les secrets à long terme (par attaque exhaustive ou attaque par dictionnaire). I.6 Certificats, Autorités de Certification et PKI L'utilisation de la cryptographie à clef publique à grande échelle nécessite de pouvoir gérer des listes importantes de clefs publiques, pour des entités souvent réparties dans un réseau. Pour cela, on a recourt à des infrastructures à clefs publiques (Public Key Infrastructure, PKI), systèmes de gestion des clefs publiques prévus pour une utilisation à grande échelle. La plupart de ces systèmes utilisent des certificats, mais ce n'est pas une obligation. Ainsi, DNSSEC, qui permet de distribuer des clefs publiques de façon authentifiée, peut être utilisé pour mettre en oeuvre une PKI. En général, un amalgame est toutefois effectué entre PKI et système de gestion et de distribution de certificats. I.6.1 Qu est-ce qu un Certificat? Un certificat est un document électronique, résultat d un traitement fixant les relations qui existent entre une clef publique, son propriétaire (une personne, une application, un site) et l application pour laquelle il est émis : pour une personne il prouve l identité de la personne au même titre qu une carte d identité, dans le cadre fixé par l autorité de certification qui l a validé; pour une application il assure que celle-ci n a pas été détournée de ses fonctions; pour un site il offre la garantie lors d un accès vers celui-ci que l on est bien sur le site auquel on veut accéder. Server name CA name Server Public Key CA Signature = Hcask(ServNam+ CAnam+ServPK) Figure I.12 Certificat Le certificat est signé (au sens signature électronique): on effectue une empreinte (ou un condensé) du certificat à l aide d algorithme (MD5 par exemple), et on chiffre l empreinte obtenue. Le chiffrement s effectue avec la clef privée de l autorité de certification qui possède elle même son propre certificat. Intégration ISAKMP/SSL-H.Adhami-2002/2003 15

Introduction à la cryptographie Le certificat contient un certain nombre de champs obligatoires et des extensions dont certaines sont facultatives. Nous exposons au Chapitre V, des exemples de certificats SSL. I.6.2 Qu est-ce qu une Autorité de Certification Une Autorité de Certification AC est une organisation qui délivre des certificats électroniques à une population. Une AC possède elle-même un certificat (autosigné ou délivré par une autre AC) et utilise sa clef privée pour créer les certificats qu'elle délivre. N'importe qui peut se déclarer Autorité de Certification. Une AC peut être organisationnelle (exemple: CNRS), spécifique à un corps de métiers (exemple: notaires) ou encore institutionnelle. Selon le crédit accordé à l'ac, les certificats délivrés auront un champ d'applications plus ou moins important : - limité à l'intérieur d'un organisme - échanges inter-organismes - En délivrant un certificat, l'ac se porte garant de l'identité de l'entité qui se présentera avec ce certificat. Par rapport aux entités (personnes ou applications) qui utilisent ses certificats, une AC joue le rôle de tiers de confiance. Le niveau de garantie offert par une AC dépendra du mécanisme de signature: moyens mis en œuvre pour s'assurer de l'identité des demandeurs, sécurité mis en œuvre pour la protection de la clef privée de l'ac, etc. I.7 Conclusion Dans le cadre de la protection des échanges réseaux, les principaux services de sécurité sont : - La confidentialité, qui est assurée par le chiffrement des données. - L authenticité (authentification + intégrité), qui est assurée par l ajout d un code d authentification de message (MAC) à chaque paquet transféré. Bien entendu, tout cela nécessite la manipulation de clefs et des outils pour les chiffrer et les protéger (d où la présence des méthodes symétriques et asymétriques), en plus des signatures et des certificats, d où le besoin des autorités de certification, autorités dignes de confiance. Et comme la sécurisation concerne tous les niveaux, de la couche physique à l application, il y a une nécessité de parler sur le transport sécurisé et surtout du protocole SSL (Socket Secure Layer). Cela fait l objet du chapitre suivant. Intégration ISAKMP/SSL-H.Adhami-2002/2003 16

SSL: Socket Secure Layer Chap II SSL: Socket Secure Layer Le protocole SSL (Socket Secure Layer) est un protocole généraliste mais qui est actuellement très utilisé dans les applications dit commerce électronique. SSL avait été intégré en 1994 dans le navigateur de Netscape pour sécuriser les échanges sur un réseau ouvert tel que l'internet entre un client et un serveur. La première version publique était la version 2.0, la version 1.0 ayant été testée en interne par les employés de Netscape. La version 3.0, actuellement en vigueur, a remédié aux quelques défaillances qui ont été découvertes dans la version précédente. Cette même version 3.0 a été le point de départ des délibérations du groupe de travail TLS (Transport Layer Secure) de l'ietf (Internet Engineering Task Force), mandaté pour sécuriser la couche transport. Le protocole TLS qui est sur le point d'être adopté comme norme de l'ietf ne diffère de SSL que dans quelques détails. Enfin, la communauté des développeurs de radios mobiles est en train d'adapter TLS aux communications sans fil dans le protocole baptisé dénoté WTLS (Wireless TLS). Ce chapitre décrit le déroulement des échanges SSL dans le but d'illustrer les principaux messages pendant l'établissement d'une session SSL. II.1 Présentation générale du protocole SSL SSL est donc un protocole généraliste qui peut s'appliquer à tous les échanges entre deux points, aussi a-t-il dépassé le protocole S-HTTP (Secure HTTP) qui ne sécurise que les échanges régis par le protocole HTTP (HyperText Transfer Protocol). Par contre, le protocole SET (Secure Electronic Transaction) développé par VISA et Mastercard, concerne essentiellement les transactions du type carte bancaire. II.1.1 Architecture de fonctionnement SSL sécurise les échanges entre un client et un serveur d'une manière transparente en se plaçant entre les couches d'application et de transport. Par rapport au modèle de référence OSI, on pourrait à la rigueur qualifier SSL de «protocole de présentation». La figure II.1 illustre l'emplacement de SSL dans l'empilement des protocoles TCP/IP. Application Application SSL TCP IP Routeur Internet Routeur SSL TCP IP Couche liaison Routeur Couche liaison Couche physique Couche physique Figure II.1 Modèle de fonctionnement de SSL Intégration ISAKMP/SSL-H.Adhami-2002/2003 17

SSL: Socket Secure Layer La figure II.2 montre la correspondance de SSL avec les différents protocoles de l'internet. SSL n'opère pas au dessus du protocole de transport UDP (User Datagram Protocol), car la fiabilité du transport de ce dernier laisse à désirer. Aussi, les interruptions de flux qui résulteraient des pertes de paquets IP seraient interprétées comme des brèches de sécurité entraînant l'interruption de la communication. NFS FTP SMTP HTTP Telnet XDR SSL TCP SNMP RPC UDP IP Figure II.2 Position du protocole SSL au sein de la pile TCP/IP Parmi les applications que SSL est incapable de sécuriser citons le protocole de gestion de réseau SNMP (Simple Network Management Protocol- Protocole simplifié de gestion de réseau), les application de partage de fichiers sur réseau, NFS (Network File System Système de fichiers en réseau), et la traduction de nom de système en adresse IP à l'aide du protocole DNS (Domain Name Service Service de nommage des domaines). De même, le transport de la "voix sur IP" conformément aux spécifications de H.323 ne peut pas être sécurisé par SSL. L'IANA (Internet Assigned Numbers Authority Autorité d'immatriculation de l'internet), l'autorité de désignation de l'internet, a accordé à certaines applications des ports IP particuliers pour leur permettre d'interpeller SSL sans interférence. Ces ports sont donnés dans le tableau II.1. D'autres applications utilisent les ports mentionnés dans le tableau II.2 par une convention collective que l'iana n'a pas encore officialisé. Protocole Port Description Application HTTPS 443 HTTP sécurisé Transactions requêteréponse sécurisées SSMTP 465 SMTP sécurisé Messagerie SNNTP 563 NNTP sécurisé News réticulaires SSL-LDAP 636 LDAP EX "LDAP (X.500 Lightweigth Directory Access Protocol)" sécurisé Annuaire X.500 allégée SPOP3 995 POP3 sécurisé Accès distant à la boîte aux lettres avec rapatriement des messages Tableau II.1 Ports IP attribués par l'iana aux applications sécurisées par SSL Intégration ISAKMP/SSL-H.Adhami-2002/2003 18

SSL: Socket Secure Layer Protocole Port Description Application FTP-DATA 889 Protocole FTP Transfert de fichier sécurisé FTPS 990 Protocole FTP sécurisé Contrôle de transfert de fichier IMAPS 991 Protocole IMAP4 Accès distant à la boîte aux lettres avec ou sans rapatriement des messages TELNETS 992 Protocole telnet sécurisé Protocole d'accès distant à un système IRCS 993 Protocole IRC sécurisé informatique "Papotage" sur l'internet. Protocole de conférence réticulaire par l'écrit Tableau II.2 Ports IP utilisés sans attribution formelle par les applications sécurisées par SSL II.1.2 Les apports de SSL La communication est confidentielle. A l issue de la phase de négociation, les parties en présence disposent d une clef secrète à usage unique utilisée pour le chiffrement symétrique (DES RC4, ) de la suite des échanges. Les parties peuvent s authentifier en utilisant leurs clefs publiques et des algorithmes de chiffrement asymétriques (RSA, DSS, ) L intégrité des échanges est garantie par l emploi d une empreinte numérique (SHA,MD5, ). II.2 Les sous-protocoles de SSL Le protocole SSL comporte 4 sous-protocoles: 1- Le protocole Handshake; 2- Le protocole Record; 3- Le protocole ChangeCipherSpec; 4- Le protocole Alert ; La figure II.3 illustre l'agencement des différentes composantes. On voit que le protocole Record se place au-dessus de la couche transport, tandis que les trois autres protocoles se situent entre l'application et la couche Record. Intégration ISAKMP/SSL-H.Adhami-2002/2003 19

SSL: Socket Secure Layer Application SSL Handshake Alert CCS Record TCP FigureII.3 Empilement des sous-couches protocolaires de SSL Le protocole Handshake est chargé de l'authentification des parties en communication, de la négociation des algorithmes de chiffrement et de hachage et de l'échange d'un secret, le PreMasterSecret. Le protocole ChangeCipherSpec a pour fonction de signaler à la couche Record toute modification des paramètres de sécurité. Enfin, le protocole Alert signale les erreurs rencontrées pendant la vérification des messages ainsi que toute incompatibilité qui pourrait éventuellement survenir pendant le Handshake. Le protocole Record met en oeuvre les paramètres de sécurité négociés pour protéger les données d'application ainsi que les messages en provenance des protocoles Handshake, Change CipherSpec (CCS) et Alert. II.2.1 Déroulement des échanges SSL Les échanges que décrit le protocole SSL, se déroulent en deux temps: 1- durant la phase préliminaire ont lieu l'identification des parties, la négociation des attributs cryptographiques, la génération et le partage de clefs; 2- durant les échanges de données, la sécurisation a lieu à partir des algorithmes et les paramètres secrets négociés dans la phase préliminaire. A tout moment, il est possible de signaler une intrusion ou une erreur d'opération. SSL reprend, en l'adaptant au nouveau contexte de sécurité, la notion de session des applications TCP/IP. Chaque fois qu'un client se connecte à un serveur il déclenche une session SSL. Si le client se connecte à un autre serveur, il engage une nouvelle session, sans interrompre la session initiale. S'il revient par la suite au premier serveur, et qu'il souhaite conserver les précédents choix cryptographiques, il demandera au premier serveur de reprendre une ancienne session plutôt que d'en commencer une nouvelle. Ainsi dans SSL, une session est une association entre deux entités ayant en commun un certain nombre de paramètres et attributs cryptographiques. Pour limiter le risque d'attaque par interception de messages, le texte définissant SSL suggère de limiter l'âge des identificateurs de session à 24 heures au maximum, mais la durée exacte reste à la discrétion du serveur. En plus, la session interrompue ne pourra être reprise que si la procédure de suspension a été suivie scrupuleusement. Intégration ISAKMP/SSL-H.Adhami-2002/2003 20

SSL: Socket Secure Layer La notion de connexion SSL a été introduite pour permettre à une application de «rafraîchir» (modifier) certains attributs de sécurité (tels que les clefs de chiffrement) sans remettre en cause tous les attributs déjà négociés en début de session. Une session peut contenir plusieurs connexions contrôlées par l'application. Nous précisons ensuite les notions de session et de connexion à l'aide de leurs variables d'états et des paramètres de sécurité associés. II.2.1.1 Variables d'état d'une session SSL Une session est uniquement identifiée par les six variables d'états suivantes : l'identificateur de session (session ID): séquence arbitraire de 32 octets choisie par le serveur pour identifier une session active ou pouvant être réactivée ; le certificat du pair (peer certificate): certificat du correspondant conforme à la version 3 de X.509 (voir exemple au chapitre V). La valeur du certificat peut être nulle si le correspondant n'est pas certifié ou si l'algorithme de Fortezza a été choisi ; la méthode de compression: c.-à-d. l'algorithme de compression utilisé. Le protocole SSL prévoit en effet la possibilité de négocier une méthode de compression de données. Pour le moment aucune méthode n'a été retenue, et par conséquent, ce champ est vide ; la suite de chiffrement (cipher spec), qui défini les algorithmes de cryptage et de hachage utilisés à partir d'une liste préétablie; le MasterSecret de 48 octets partagés entre le client et le serveur. C'est à partir de ce paramètre que l'on va générer les autres secrets. Ce paramètre est donc valable pour toute la session ; le drapeau (is resumable) qui signale si la session peut être utilisée pour ouvrir de nouvelles connexions. Une suite de chiffrement est définie par les cinq éléments suivants: le mode de chiffrement utilisé: chiffrement enfilé (appelé aussi en continue ou à la volée) ou en bloc ; l'algorithme de chiffrement utilisé. Le choix peut se faire entre RC2, RC4, DES avec une clef de taille 40 bits ou de 64 bits, ou l'algorithme de Fortezza. Ce dernier algorithme est un algorithme secret du departement de la défense aux États Unis. Notons, qu'il est possible de choisir des échanges en clair; l'algorithme de hachage utilisé, qui peut être soit le MD5, soit le SHA. Il est possible de ne choisir aucun algorithme de hachage; la taille du condensât; la variable binaire signalant permission d'exporter l'algorithme de chiffrement conformément à la loi américaine sur l'exportation de la cryptographie. La négociation de cette suite de chiffrement se fait en clair pendant l'établissement de la session. Le tableau II.3 donne l'ensemble des algorithmes supportés par SSL tandis que tableau II.4 contient les suites de chiffrement reconnues. Intégration ISAKMP/SSL-H.Adhami-2002/2003 21

SSL: Socket Secure Layer Fonction Algorithme Echanges de clefs RSA, Fortezza, Diffie-Hellman Chiffrement symétrique à la volée RC4 avec clefs de 128 bits ou de 40 bits Chiffrement symétrique en blocs DES, DES40, 3DES RC2, IDEA, Fortezza Hachage MD5, SHA Table II.3 Algorithmes négociés par le protocole Handshake Echange de clefs RSA Diffie-Hellman Diffie-hellman ephémère Chiffrement symétrique Sans chiffrement RC4-40 RC4-128 RC2 CBC 40 IDEA CBC DES40 CBC DES CBC 3DES EDE CBC DES40 CBC DES CBC 3DES, EDE CBC DES40 CBC DES CBC 3DES EDE CBC Hachage MD5 ou SHA MD5 MD5 ou SHA MD5 SHA SHA SHA SHA SHA SHA SHA SHA SHA SHA Signature DSS ou RSA DSS ou RSA DSS ou RSA DSS ou RSA DSS ou RSA DSS ou RSA Table II.4 Suites de chiffrement reconnues par SSL NOTE - SSL permet l'échange de clefs par la méthode de Diffie-Hellman sans authentification des participants ("Diffie-Hellman anonyme"). Ce mode est susceptible aux attaques par interception ("Man-in-the-Middle"), ce qui le rend inadapté aux applications commerciales. II.2.1.2 Variables d'état d'une connexion SSL Les paramètres qui définissent l'état d'une connexion pendant une session seront «rafraîchis» à l'établissement d'une nouvelle connexion. Ces paramètres sont: deux nombres aléatoires (server_random et client_random) de 32 octets. Ces nombres sont générés respectivement par le serveur et par le client à l'établissement d'une session et pour chaque nouvelle connexion. Les clefs secrètes vont être dérivées à partir de ces nombres aléatoires, ce qui fait que ces nombres sont échangés en clair à l'ouverture d'une session. Par contre, pour l'ouverture d'une connexion autre que la première pendant une session active, le processus de chiffrement est déjà en plein fonctionnement et les nombres sont transmis chiffrés. L'utilisation de ces nombres protège contre les attaques par rejeu d'anciens messages; deux clefs secrètes, server MAC write secret et client MAC write secret, employées par les fonctions de hachage pour calculer les codes d'authentification (ou MAC). La taille du Intégration ISAKMP/SSL-H.Adhami-2002/2003 22

SSL: Socket Secure Layer MAC dépend de l'algorithme de hachage choisi et sera de 16 octets pour SHA ou de 20 octets pour MD5; deux clefs pour le chiffrement symétrique des données: une du côté serveur et l'autre du côté client. Quoique le même algorithme soit utilisé par les deux parties, chacune peut utiliser sa propre clef de chiffrement, respectivement server write key ou client write key, à condition de la partager avec l'autre. La taille des clefs dépend de l'algorithme de chiffrement choisi et de la législation sur la cryptographie en vigueur; deux vecteurs d'initialisation pour le chiffrement symétrique en mode CBC, l'un du côté serveur et l'autre du côté client. Leur taille dépend de l'algorithme choisi; deux numéros de séquence l'un pour le serveur et l'autre pour le client, chacun codé sur 8 octets. Ces numéros de séquence sont maintenus séparément pour chaque connexion et incrémentés à chaque émission de message de cette connexion. Ce mécanisme est une autre parade aux attaques par rejeu en empêchant la réutilisation de messages déjà émis. On remarque que les clefs de confidentialité pour chaque direction sont indépendantes les unes des autres, et que chaque connexion possède une clef qui lui est particulière. II.2.2 Synopsis des calculs de paramètres La figure II.4 illustre le calcul du MasterSecret, à partir du PreMastersecret et des paramètres client-random et server-random. La valeur du MasterSecret, sera constante pendant toute la durée d'une session. Les paramètres client-random et server-random sont échangés en clair alors que le PreMasterSecret est échangé confidentiellement à l'aide d'un algorithme d'échanges de clefs. Le calcul des clefs de chiffrement, des clefs de hachage et des vecteurs d'initialisation se fait à partir des variables MasterSecret, client-random et server-random de la manière illustrée dans la figure II.5 : Client Random (connexion) PreMasterSecret (session) Server Random (connexion) Fonction Mathématique MasterSecret FigureII.4 Construction du Master Secret à l ouverture d une session Intégration ISAKMP/SSL-H.Adhami-2002/2003 23

Client Random (connexion) PreMasterSecret (session) SSL: Socket Secure Layer Server Random (connexion) Fonction Mathématique Client MAC write secret Server MAC write secret (connexion) Vecteur d initialisation du client et du serveur (connexion) Client write secret Server write secret (connexion) FigureII.5 Génération des secrets à l ouverture d une session ou connexion L'ouverture d'une nouvelle connexion entraînera le renouvellement des variables client_random et server_random, toutefois sans affecter la valeur du MasterSecret. Par conséquent, les variables client write key (respectivement server write key) seront recalculées lors de l'ouverture d'une connexion. Notons que pour toute nouvelle connexion, chacune des entités communicantes possède une clef de chiffrement symétrique, différente de celle de son partenaire. Chaque flux est donc chiffré par une clef distincte et dans chaque direction. II.3 Le protocole Handshake II.3.1 Fonctionnement général Le protocole Handshake commence par l'authentification obligatoire du serveur, celle du client étant facultative. Une fois l'authentification établie, les deux parties passent à la phase de négociation afin de choisir la suite de chiffrement qui sera utilisée tout le long de la session. Le protocole Handshake, on le voit, conditionne l'ensemble du processus de transfert sécurisé de données, raison pour laquelle cette phase sera la cible privilégiée des agresseurs potentiels. Intégration ISAKMP/SSL-H.Adhami-2002/2003 24

SSL: Socket Secure Layer Client ClientHello Serveur ServeurHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished ChangeCipherSpec Finished ApplicationData ApplicationData * message optionnel Figure II.6 Messages échangés pendant l établissement d une nouvelle session Intégration ISAKMP/SSL-H.Adhami-2002/2003 25

SSL: Socket Secure Layer Massage Type de message Sens de transmission Signification HelloReques Optionnel Serveur client Notification au client de débuter le Handshake ClientHello Obligatoire Client serveur Ce message contient: Le numéro de version du protocole SSL Le nombre aléatoire: client_random Le numéro de session: session_id La liste des suites de chiffrement choisies par le client La liste des méthodes de compression choisies par le client serverhello Obligatoire Serveur client Ce message contient: Le noméro de version du protocole SSL Un numbre aléatoire: serveur_random Un identificateur de session session_id Une suite de chiffrement Une méthode de compression Certificate Optionnel Serveur client Ce message contient le Client serveur certificat du serveur ou celui du client si le serveur le lui a réclamé et si le client en ServerKeyExc hange CertificateReq uest ServerHelloD one ClienKeyExch ange CertificateVeri fy possède un Optionnel Serveur client Ce message n'est envoyé par le serveur que s'il ne possède pas de certificat ou un certificat de signature Optionnel Serveur client Message envoyé par le serveur pour réclamer un certificat de la part du client Obligatoire Serveur client Message signifiant au client la fin de l'envoi des messages ServerHello et subséquents Obligatoire Client serveur Message contenant le PreMasterSecret crypté à l'aide de la clef publique du serveur Optionnel Client serveur Message permettant une verification explicite du certificat du client Finished Obligatoire Serveur client Client serveur Message signalant la fin du protocole Handshake et le début de l'émission des données, protégées avec les nouveaux paramètres négociés Tableau II.5 Les différents messages du protocole Handshake Intégration ISAKMP/SSL-H.Adhami-2002/2003 26

SSL: Socket Secure Layer Le tableau II.5 donne la liste chronologique des messages du protocole Handshake et leur signification, tandis que la figure II.6 illustre les échanges. La structure des messages du protocole est présentée en Annexe A. La syntaxe de ces messages provient de différentes sources dans leurs structures, comme le langage C et XDR. Nous allons maintenant étudier le déroulement des échanges du Handshake en détail. II.3.2 Ouverture d'une nouvelle session L'ouverture d'une nouvelle session à l'initiative du client commence par l'envoi du message ClientHello au serveur. Le serveur peut aussi prendre l'initiative en envoyant le message HelloRequest qui ne contient aucune information et sert exclusivement à notifier le client que le serveur est prêt. Les échanges suivants se déroulent de la même manière dans les deux cas. La figure II.7 reprend en condensé les échanges effectués durant l'ouverture d'une nouvelle session. Ces échanges comportent quatre étapes qui se rapportent aux opérations suivantes: l'identification des suites de chiffrements disponibles des deux côtés; l'authentification du serveur; l'échange de secrets; la vérification et confirmation des messages échangés. Client Ouverture d une session SSLv3 ClientHello Serveur Server Hello (Certificate) (ServerKeyExchange) (CertificateRequest) ServerHelloDone (Certificate) ClientKeyExchange (CertificateVerify) ChangeCipherSpec Finished ChangeCipherSpec Finished ApplicationData ApplicationData Figure II.7 Echanges pendant l ouverture d une session Intégration ISAKMP/SSL-H.Adhami-2002/2003 27

SSL: Socket Secure Layer II.3.3 Identifications des suites de chiffrement Les premiers messages échangés entre le client et serveur, ClientHello et ServerHello, permettent de négocier le choix des paramètres, les algorithmes de chiffrement et les secrets caractéristiques de la session. Le client et serveur commencent obligatoirement par choisir la version du protocole SSL commune aux deux parties (la version 3 ou par défaut, la version 2.0). Le message ClientHello, même si il spécifie la version 3, est encapsulé dans un message Record au format de la version 2. Ceci permet au serveur de répondre au cas où sa version du protocole n'a pas été actualisée. Après l'envoi du message ClientHello, le client attend l'arrivée du message ServerHello. Ce message doit indiquer la version du protocole et l'identificateur unique de session, tous deux choisis par le serveur. L'identificateur de session servira à reprendre une session ouverte précédemment, comme indiqué plus loin. Le message comprend aussi le nombre aléatoire server_random. L'échange des nombres aléatoires, client_random et server_random, permet à chaque partie de reproduire les secrets de son correspondant et donc de les partager. Enfin, le message doit comprendre la suite de chiffrement retenue par le serveur parmi les choix suggérés par le client. Cette suite sera utilisée par la suite pour assurer la confidentialité et l'intégrité des données. Si aucune suite commune n'est disponible, un message d'erreur close_notify émanant du protocole Alert est généré par le serveur (ou par le client) et la session est abandonnée. NOTE - L'analyse des traces des messages entre client et serveur montre que certains serveurs n'envoient pas le message d'alerte close_notify comme prévu, mais ferment brutalement la connexion TCP. Il est important d'avoir présent à l'esprit que cette négociation se déroule en clair. Un intrus peut tenter de subtiliser le message ClientHello et le remplacer par un faux avec des algorithmes de chiffrement moins robustes. Cette attaque sera cependant déjouée à l'aide du message Finished échangé à la fin du Handshake, comme on le verra plus loin. II.3.4 Authentification du serveur Dans cette deuxième phase, le serveur s'authentifie en envoyant le message Certificate comprenant: le certificat X.509 version 3 du serveur qui renferme la clef publique reliée à la suite de chiffrement choisie précédemment. Dans le cas contraire le protocole Alert signalera l'erreur au serveur; l'ensemble de la chaîne de certification y compris le certificat de l'autorité maîtresse. Rappelons qu'un certificat X509 est de la forme suivante : Certificat = Nom Serveur + Nom AC + Kp serveur + Ks AC {H[Nom Serveur + Nom AC + Kp Serveur ]} Où: Nom Serveur Nom AC Kp Serveur Ks AC H Le nom du serveur Le nom de l'autorité de certification La clef publique du serveur La clef privée de l'autorité de certification Algorithme de hachage Intégration ISAKMP/SSL-H.Adhami-2002/2003 28

SSL: Socket Secure Layer Si le serveur ne possède pas de certificat, à la place du message Certificate, il transmet le message ServerKeyExchange. Cependant, les serveurs du commerce électronique ont intérêt à être authentifié. Même si le serveur présente un certificat, il peut être conduit à transmettre un message ServerKeyExchange : lorsque l'algorithme d'échange de clefs de Fortezza est utilisé; dans ce cas, le message ServerKeyExchange est envoyé sans signature (non-scellé); lorsque l'échange de clefs RSA fait appel à un certificat de signature pour authentifier les paramètres RSA temporaires utilisés pour conclure l'échange. Dans ce cas, le certificat de signature est compris dans le message ServerKeyExchange et comprendra les paramètres publics utilisés pour l'échange de la clef secrète, scellé (signé) par la clef privée associée à la clef publique contenue dans le certificat de signature scellé par l'autorité certifiante; lorsque la méthode dite «Diffie-Hellman éphémère», est utilisée pour l'échange de clefs. Dans ce cas aussi, le certificat de signature est compris dans le message ServerKeyExchange afin d'authentifier les paramètres de l'algorithme d'échanges de clefs. Ainsi dans le cas où un certificat de signature est employé, le serveur transmet deux messages consécutifs : 1- le message Certificate qui renferme la clef publique de signature du serveur dans le certificat dûment scellé par la clef privée de l'autorité de certification. Le client vérifie la véracité du certificat de signature avec la clef publique de l'autorité de certification; 2- le message ServerKeyExchange qui contient les paramètres publics de l'algorithme d'échange de la clef secrète de chiffrement. Ces paramètres sont scellés (signés) à l'aide de la clef privée correspondant à la clef publique récupérée précédemment. A la réception de ce second message, le client s'assure que les paramètres publiques de l'algorithme d'échange de clefs sont bien ceux du serveur, en vérifiant la signature à l'aide de la clef publique de signature déjà reçue. Le message comprend le condensât de l'enchaînement des variables client_random et server_random ainsi que des paramètres du serveur. Le hachage se fait avec l'algorithme choisit, MD5 ou SHA. Le serveur après s'être authentifié, peut demander au client d'en faire de même. Le serveur envoie alors le message CertificateRequest qui contient une liste par ordre de préférence des certificats demandés et des autorités de certification auxquelles il a foi. Suite à ces messages, le serveur envoie un message ServerHelloDone qui signifie au client qu'il a terminé et qu'il attend désormais une réponse. II.3.5 Échanges de secrets Si le serveur a demandé au client de s'authentifier en lui envoyant le message CertificateRequest, le client doit répliquer en incluant son certificat, s'il en possède un, dans le message Certificate. Si le client n'est pas en mesure de donner un certificat, sa réplique, le cas échéant, sera un message d'alerte du type no_certificate, pour signaler qu'il n'en possède pas. Cette alerte n'est qu'un avertissement (warning) et non pas une erreur fatale; la procédure n'est interrompue par le serveur que si l'authentification du client est indispensable à la transaction. Intégration ISAKMP/SSL-H.Adhami-2002/2003 29

SSL: Socket Secure Layer Le client envoie ensuite le message ClientKeyExchange. Ce message contient le paramètre PreMasterSecret chiffré, soit avec la clef publique du serveur, soit avec celle contenue dans son certificat de chiffrement, selon le type de certificat et l'algorithme d'échange de clefs utilisé. Considérons les trois cas suivants: si le certificat du serveur est un certificat de signature, l'algorithme RSA est utilisé, le PreMasterSecret est chiffré, soit par la clef publique du serveur, soit par la clef temporaire contenue dans le message ServerKeyExchange; pour l'échange de clefs de Fortezza, les paramètres envoyés par le serveur dans le message ServerKeyEchange sont le point de départ des calculs d'une clef de chiffrement de bon. Celle-ci sera ensuite utilisée pour chiffrer la clef du client, clientwritekey, le secret PreMasterSecret et les vecteurs d'initialisation ; pour les échanges de clefs Diffie-Hellman, les échanges se font par l'intermédiaire des messages ServerKeyExchange et ClientKeyExchange, si les paramètres ne sont pas inclus dans les certificats du serveur et du client. Si le client est certifié et si le certificat lui confère la faculté de signature numérique, il envoie également un message de confirmation explicite: CertificateVerify. Ce message contient le condensât de tous les messages depuis ClientHello à l'exception du message conteneur; ce condensât est chiffré avec la clef privée du client. Ce message a pour but de vérifier le sceau du client. Ainsi, le contenue du message CertificateVerify sera : hash {MasterSecret + pad_2 + hash (messages_déjà_envoyés_sans_celui_ci +MasterSecret + pad_1) } où hash est MD5 ou SHA selon le cas. Les champs pad_1 et pad_2 contiennent respectivement 48 répétitions des octets 0x36 et 0x5c pour MD5 et 40 répétitions pour SHA. Le client fait ensuite appel au protocole ChangeCipherSpec afin de déclencher le chiffrement des échanges avec les choix effectués dans les deux phases précédentes. Le client envoie subséquemment et sans attente le message Finished. Le message Finished est un condensé de tous les messages du Hanshake envoyés et reçus par le client au serveur depuis ClientHello avec les attributs qui viennent d'être négociés. Le but est de déjouer les attaques de subtilisation en vérifiant l'intégrité de l'ensemble des échanges. Le condensât est calculé à l'aide de la formule suivante: hash {MasterSecret + pad_2 + hash (handshake_messages + Sender + MasterSecret + pad_1) } où hash est MD5 ou SHA selon le cas. Le champ handshake_messages contient les messages échangés sauf le message ChangeCipherSpec et le message présent. On note la présence du champ Sender qui contient l'identité de l'expéditeur. Après avoir émis le message Finished, le client démarre l'envoie des messages d'application chiffrés sans attendre un accusé de réception. Intégration ISAKMP/SSL-H.Adhami-2002/2003 30

SSL: Socket Secure Layer NOTES 1/ Le message ChangeCipherSpec n'est pas inclus dans le calcul du condensât puisqu il n'est strictement pas du sous-protocole du Handshake. Pour des raisons de sécurité, il est préférable de ne traiter un message Finished reçu que s'il était précédé par un message ChangeCipherSpec. 2/ Le MasterSecret est inclus dans le paraphe ou code d'authentification MAC des messages CertificateVerify, ChangeCipherSpec et Finished. II.3.6 Vérification et confirmation par le serveur A la réception du message Finished, le serveur tente de reproduire le même condensât à partir des messages précédemment reçus. Il compare le résultat au contenu du message Finished qu'il vient de recevoir du client. Cette étape pourra déceler si un intrus a pu intercepté et modifié les messages. Le serveur envoit à son tour les messages ChangeCipherSpec et Finished. Là encore le message Finished est généré à partir de tous les messages que le serveur a précédemment envoyés, et est transmis chiffré. Le serveur commence alors aussitôt à envoyer ses données d'application. NOTE - L'envoie des données juste après l'expédition du message Finished peut ouvrir la brèche suivante. Un intrus modifie les messages ClientHello ou ServerHello pour forcer l'utilisation d'une suite de chiffrement faible, récupère le PreMasterSecret et le déchiffre et détourne le message de vérification Finished. Il peut ainsi se substituer à un ou deux des partenaires. Pour contrecarrer cette attaque, il suffit de ne commencer la transmission de données qu'après que les messages Finished soient échangés des deux côtés. II.3.7 Ouverture d'une connexion L'ouverture de la première connexion d'une session SSL ramène au cas de l'ouverture d'une session traitée plus haut. Si la session SSL a déjà été établie, ce qui signifie que les flux TCP peuvent transiter dans les deux sens, l'ouverture d'une connexion consiste à rafraîchir les paramètres client_random et server_random à l'aide des messages ClientHello et ServerHello, tout en préservant les algorithmes de chiffrement et de hachage déjà choisis. Une nouvelle authentification est donc évitée mais, contrairement à ce qui se passe pendant l'ouverture d'une session, les messages ClientHello et ServerHello sont envoyés chiffrés. Les échanges sont illustrés dans la figure II.8. Intégration ISAKMP/SSL-H.Adhami-2002/2003 31

SSL: Socket Secure Layer Client Ouverture d une Connexion Serveur ClientHello ServerHello ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Figure II.8 Messages échangés pour l ouverture d une connexion Le message ClientHello contient l'identificateur de la session qui contiendra la connexion. Si cet identificateur ne figure pas dans les tables du serveur, soit parce qu'il est erroné ou parce que le session à laquelle il renvoie ait expirée, le client n'est pas rejeté et le serveur entame un Handshake complet afin d'établir une nouvelle session SSL. Le client et le serveur confirment leur accord par l'envoie du message ChangeCipherSpec de chaque côté et terminent le Handshake abrégé par le message Finished comme précédemment. NOTES 1/ Les spécifications ne sont pas claires concernant l'action appropriée si les nouveaux échanges introduisent une nouvelle suite de chiffrement. 2/ De même, il n'est pas claire si la nouvelle connexion dans une session initialement prévue pour la version 3.0 peut être de la version 2.0. Il est cependant recommandé de ne pas mélanger de versions, afin d'éviter la dégradation de sécurité qu'introduit la version 2.0 II.4 Le protocole ChangeCipherSpec (CCS) Le protocole ChangeCipherSpec (CCS) comprend un seul et unique message, du même nom que le protocole, et qui tient sur un octet. Il a pour objectif d'indiquer au protocole Record la mise en place effective des algorithmes cryptographiques qui viennent d'être négociés afin qu'il entame le chiffrement. Avant ce message, le chiffrement incombait au protocole Handshake. A la réception de ce message, 1a couche du protocole Record du côté émetteur devra modifier ses attributs d'écriture, c-à-d, la méthode de chiffrement des messages émis. Du côté récepteur, la couche de protocole Intégration ISAKMP/SSL-H.Adhami-2002/2003 32

SSL: Socket Secure Layer Record de l'entité distante changera ses attributs en lecture afin de pouvoir déchiffrer les messages reçus. II.5 Le protocole Record Le protocole Record n'intervient, comme on vient de le voir, qu'à la suite de l'émission du message ChangeCipherSpec. Pendant la phase d'établissement de la session, le rôle de la couche du protocole Record est d'encapsuler les données du Handshake et de les transmettre sans aucune modification vers la couche du protocole TCP. Pendant la phase de chiffrement des données, le protocole Record reçoit les données des couches supérieures (Handshake, Alert, CCS, HTTP, ftp, etc., et les transmet au protocole TCP après avoir effectué dans l'ordre les tâches suivantes : 1- la fragmentation des données en blocs de taille maximum 214 octets ; 2- la compression des données, fonction prévue mais non supportée actuellement ; 3- la génération d'un condensât pour assurer le service d'intégrité ; 4- le chiffrement des données pour assurer le service de confidentialité. Le protocole Record rajoute un en-tête de 5 octets à chaque message reçu des couches supérieures. Cet en-tête indique le type du message, selon qu'il provient des sous-protocoles Handshake, Alert, CCS ou s'il s'agit des données d'application, par exemple, HTTP, ftp. Il signale aussi la version du protocole SSL utilisée ainsi que la longueur du bloc de données encapsulées. Les tâches inverses sont effectuées du côté récepteur: déchiffrement, vérification de l'intégrité, décompression et recomposition. Si le condensât calculé n'est pas identique à celui qui est reçu, le protocole Record invoque le protocole Alert afin de relayer le message d'erreur adéquat à l'entité émettrice. Le fonctionnement de la couche Record est illustré dans la figure suivante : Flux d information d une application Fragmentation du flux en fragments App1 App2 AppN CApp1 CApp2 CAppN CApp1 MAC CApp2 MAC CAppN MAC Cipher CApp1 Cipher CApp2 Cipher CAppN Compression des fragments Calcul d un MAC pour chaque fragment, adjonction du MAC au fragment correspondant Chiffrement de chaque fragment Réseau TCP/IP Figure II.9 Fonctions effectuées par la couche Record Transmission des fragments à la couche TCP/IP Intégration ISAKMP/SSL-H.Adhami-2002/2003 33

SSL: Socket Secure Layer II.6 Le protocole Alert Le protocole Alert sert essentiellement à générer des messages d'alerte suite aux erreurs de parcours, et à signaler les changements d'état tels que la fermeture d'une connexion. Comme tout autre message provenant des couches supérieures, les messages sont chiffrés avec les attributs de chiffrement en vigueur. Selon la gravité de la menace, l'alerte peut constituer un simple avertissement ou déclencher l'abandon de la session. Un message d'avertissement est une simple mise en garde qui n'exige aucune action particulière. Par contre, à la suite d'un message fatal, l'entité émettrice doit clore promptement la connexion sans attendre l'acquittement du récepteur. De son côté, le récepteur, quant à lui, ferme la connexion dès l'arrivée du message d'alerte. Comme les messages de niveau «fatal» causent l'abandon d'une session, SSL est susceptible aux attaques du type «déni de service», si un intrus parvient à substituer aux messages réglementaires d'autres non conformes, provoquant de la sorte la rupture de la session. Le protocole Alert peut être invoqué: par l'application, par exemple pour signaler la fin de connexion; par le protocole Handshake suite à un problème survenu au cours de son déroulement; par la couche Record directement, par exemple si l'intégrité d'un message est mise en doute. Le tableau suivant contient la liste des messages du protocole Alert disposés par ordre alphabétique : Message Contexte Type bad_certificate échec de verification d'un certificate fatal bad_record_mac réception d'un MAC erroné fatal certificate_expired certificat périmé fatal certificate_unknown certificat invalide pour motifs autres que ceux fatal précisés précédemment Close_notify interruption volontaire de session fatal decompression_failure la fonction de décompression ne peut pas s'appliquer fatal (cas de données trop longues) handshake_failure impossibilité de négocier des paramètres satisfaisants fatal illegal_parameter la taille du paramètre échangé au cours du protocole fatal Handshake dépasse la taille du champ correspondant ou lorsqu'il est sans rapport avec les autres paramètres no_certificate réponse négative à une requête de certificat avertissement ou fatal unexpected_message arrivee inopportune d'un message fatal unsupported_certificate certificat reçu n'est pas reconnu par le destinataire avertissement ou fatal Tableau II.6 Messages du protocole Alert NOTE- Remarquons qu'aucun message ne se rapporte à la différence de choix cryptographiques entre une session et une connexion qu'elle contient ou entre une session reprise et la session initiale. Cependant, le protocole TLS définit de nouveaux messages se rapportant aux opérations cryptographiques. Intégration ISAKMP/SSL-H.Adhami-2002/2003 34

II.7 Conclusion SSL: Socket Secure Layer L approche de bout en bout de SSL, n impose pas un déploiement sur l ensemble de l infrastructure existante. Par ailleurs, elle est indépendante des applications des couches supérieures et peut profiter à toutes les applications classiquement utilisées au dessus de TCP. SSL offre des services d authentification, de confidentialité et d intégrité des données dans les applications de point à point. Son grand avantage est sa transparence par rapport aux applications. Il comporte 4 sous-protocoles: 5- Le protocole Handshake; 6- Le protocole Record; 7- Le protocole ChangeCipherSpec; 8- Le protocole Alert ; Le principal intérêt de SSL consiste à «tunneler» des services de chiffrement sur TCP/IP sans bouleversement ni de l infrastructure réseau, ni des applications ainsi sécurisées. Contrairement à SSL, IPSec est mis en œuvre au cœur du réseau et concerne les couches basses, cette approche est détaillée au chapitre suivant. Intégration ISAKMP/SSL-H.Adhami-2002/2003 35

IPsec Chap III IPsec Le terme IPsec désigne un ensemble de mécanismes destinés à protéger le trafic au niveau IP (IPv4 ou IPv6). Les services de sécurité offerts sont l intégrité en mode non connecté, l authentification de l origine des données, la protection contre le rejeu et la confidentialité (confidentialité des données et protection partielle contre l analyse du trafic). Ces services sont fournis au niveau de la couche IP, offrant donc une protection pour IP et tous les protocoles de niveau supérieur. Optionnel dans IPv4, IPsec est obligatoire pour toute implémentation de IPv6. Une fois IPv6 en place, il sera ainsi possible à tout utilisateur désirant des fonctions de sécurité d avoir recours à IPsec. IPsec est développé par un groupe de travail du même nom à l IETF (Internet Engineering Task Force), groupe qui existe depuis 1992. Une première version des mécanismes proposés a été publiée sous forme de RFC en 1995, sans la partie gestion des clefs. Une seconde version, qui comporte en plus la définition du protocole de gestion des clefs IKE, a été publiée en novembre 1998. Mais IPsec reste une norme non figée qui fait en ce moment même l objet de multiples Internet Drafts notamment sur la protection des accès distants. III.1 Vue d ensemble Cette partie présente le principe de fonctionnement d IPsec, les différents éléments qui le composent, la façon dont ils interagissent et les différentes utilisations possibles. III.1.1 Architecture d IPsec Pour sécuriser les échanges ayant lieu sur un réseau TCP/IP, il existe plusieurs approches, en particulier en ce qui concerne le niveau auquel est effectuée la sécurisation: niveau applicatif (mails chiffrés par exemple), niveau transport (TLS/SSL, SSII ), ou à l opposé niveau physique (boîtiers chiffrant toutes les données transitant par un lien donné). IPsec, quant à lui, vise à sécuriser les échanges au niveau de la couche réseau. III.1.1.1 Les mécanismes AH et ESP Pour cela IPsec fait appel à deux mécanismes de sécurité pour le trafic IP, les «Protocoles» AH et ESP, qui viennent s ajouter au traitement IP classic: Authentication Header (AH) est conçu pour assurer l intégrité et l authentification des datagrammes IP sans chiffrement des données (i.e. sans confidentialité). Le principe de AH est d adjoindre au datagramme IP classic un champ supplémentaire permettant à la réception de vérifier l authenticité des données incluses dans le datagramme. Encapsulating Security Payload (ESP) a pour rôle premier d assurer la confidentialité, mais peut aussi assurer l authenticité des données. Le principe de ESP est de générer, à partir d un datagramme IP classique, un nouveau datagramme dans lequel les donnés et éventuellement l en-tête original sont chiffrés. Intégration ISAKMP/SSL-H.Adhami-2002/2003 36

IPsec Ces mécanismes peuvent être utilisés seuls ou combinés pour obtenir les fonctions de sécurité désirées. Ils seront décrits plus en détails dans ce qui suit. III.1.1.2 La notion d association de sécurité. Les mécanismes mentionnés ci-dessus font bien sûr appel à la cryptographie, et utilisent donc un certain nombre de paramètres comme les algorithmes de chiffrement utilisés, clefs, mécanismes sélectionnés (voir premier chapitre), sur lesquels les tiers communicants doivent se mettre d accord. Afin de gérer ces paramètres, IPsec a recours à la notion d association de sécurité (Security Association, SA). Une association de sécurité IPsec est une «connexion» simplexe qui fournit des services de sécurité au trafic qu elle transporte. On peut aussi la considérer comme une structure de données servant à stocker l ensemble des paramètres associés à une communication donnée. Une SA est unidirectionnelle; en conséquence, protéger les deux sens d une communication classique requiert deux associations, une dans chaque sens. Les services de sécurité sont fournis par l utilisation soit de AH soit de ESP. Si AH et ESP sont tous deux appliqués au trafic en question, deux SA (voire plus) sont créées; on parle alors de paquet (bundle) de SA. Chaque association est identifiée de manière unique à l aide d un triplet composé de : L adresse de destination des paquets. L identifiant d un protocole de sécurité utilisé (AH ou ESP). Un index des paramètres de sécurité (Security Parameter Index, SPI). Un SPI est un bloc de 32 bits inscrit en clair dans l en-tête de chaque paquet échangé; il est choisi par le récepteur. Pour gérer les associations de sécurité actives, on utilise une «base de données des associations de sécurité» (Security Association Database, SAD). Elle contient tous les paramètres relatifs à chaque SA et sera consultée pour savoir comment traiter chaque paquet reçu ou à émettre. III.1.1.3 La gestion des clefs et des associations de sécurité Comment nous l avons mentionné au paragraphe précédent, les SA contiennent tous les paramètres nécessaires à IPsec, notamment les clefs utilisées. La gestion des clefs pour IPsec n est liée aux autres mécanismes de sécurité de IPsec que par le biais des SA. Une SA peut être configurée manuellement dans le cas d une situation simple, mais la règle générale est d utiliser un protocole spécifique qui permet la négociation dynamique des SA et notamment l échange des clefs de session. D autre part, Ipv6 n est pas destiné à supporter une gestion des clefs «en bande», c est-à-dire où les données relatives à la gestion des clefs seraient transportées à l aide d un en-tête IPv6 distinct. Au lieu de cela on utilise un système de gestion des clefs dit «hors bande», où les données relatives à la gestion des clefs sont transportées par un protocole de couche supérieure tel que UDP ou TCP. Ceci permet le découplage clair du mécanisme de gestion des clefs et des autres mécanismes de sécurité. Il est ainsi possible de substituer une méthode de gestion des clefs à une autre sans avoir à modifier les implémentations des autres mécanismes de sécurité. Le protocole de négociation des SA développé pour IPsec s appelle «protocole de gestion des clefs et des associations de sécurité pour Internet» (Internet Security Association and Key Management Protocol, ISAKMP) est en fait inutilisable seul : c est un cadre générique qui Intégration ISAKMP/SSL-H.Adhami-2002/2003 37

IPsec permet l utilisation de plusieurs protocoles d échange de clef et qui peut être utilisé pour d autres mécanismes de sécurité que ceux de IPsec. Dans le cadre de la standardisation de IPsec, ISAKMP est associé à une partie des protocoles SKEME et Oakley (voir plus loin dans ce chapitre) pour donner un protocole final du nom d IKE (Internet Key Exchange). Ces protocoles seront décrits sommairement au paragraphe III.3.1; ISAKMP faisant l objet de ce rapport, sera décrit en détail au chapitre suivant. III.1.1.4 Politique de sécurité Les protections offertes par IPsec sont basées sur des choix définis dans une «base de données de politique de sécurité» (Security Policy database, SPD). Cette base de données est établie et maintenue par un utilisateur, un administrateur système ou une application mise en place par ceux-ci. Elle permet de décider, pour chaque paquet, s il se verra apporter des services de sécurité, s il sera autorisé à passer outre ou sera rejeté. La SPD contient une liste ordonnée de règles, chaque règle comportant un certain nombre de critères qui permettent de déterminer quelle partie du trafic est concernée. Les critères utilisables sont l ensemble des informations disponibles par le biais des en-têtes des couches IP et transport. Ils permettent de définir la granularité selon laquelle les services de sécurité sont applicables et influencent directement le nombre de SA correspondante. Dans le cas où le trafic correspondant à une règle doit se voir attribuer des services de sécurité, la règle indique les caractéristiques de la SA (ou paquet de SA) correspondante: protocole(s), modes, algorithmes requis III.1.2 Principe de fonctionnement Le schéma ci-dessous représente tous les éléments présentés ci-dessus, leurs positions et leurs interactions. Figure III.1 Organisation de IPsec Intégration ISAKMP/SSL-H.Adhami-2002/2003 38

IPsec On distingue deux situations : Trafic sortant Lorsque la «couche» IPsec reçoit des données à envoyer, elle commence par consulter la base de données des politiques de sécurité (SPD) pour savoir comment traiter ces données. Si cette base lui indique que le trafic doit se voir appliquer des mécanismes de sécurité, elle récupère les caractéristiques requises pour la SA correspondante et va consulter la base des SA (SAD). Si la SA nécessaire existe déjà, elle est utilisée pour traiter le trafic en question. Dans le cas contraire, IPsec fait appel à IKE pour établir une nouvelle SA avec les caractéristiques requises. Trafic entrant Lorsque la couche IPsec reçoit un paquet en provenance du réseau, elle examine l en-tête pour savoir si ce paquet s est vu appliquer un ou plusieurs services IPsec et si oui quelles sont les références de la SA. Elle consulte alors la SAD pour conna ître les paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si l association de sécurité appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. Dans le cas où le paquet reçu est un paquet IP classique, la SPD permet de savoir s il a néanmoins le droit de passer. Par exemple, les paquets IKE sont une exception. Ils sont traités par IKE, qui peut envoyer des alertes administratives en cas de tentative de connexion infructueuse. III.1.3 Types d utilisations possibles Après avoir vue comment est constitué IPsec et comment il fonctionne, nous allons maintenant nous intéresser aux différentes façons de l utiliser. Un point important à retenir est que le fait d intervenir au niveau réseau rend la sécurisation totalement transparente pour les applications. III.1.3.1 Équipement fournissant IPsec IPsec peut être utilisé au niveau d équipements terminaux ou au niveau des passerelles de sécurité (security gateway), permettant ainsi des approches de sécurisation lien par lien comme de bout en bout. Trois configurations de base sont possibles : IPsec IPsec Réseau de confiance Réseau non fiable Réseau de confiance Passerelle de sécurité IPsec Passerelle de sécurité IPsec Réseau non fiable Réseau de confiance Equipement terminal Passerelle de sécurité Figure III.2 Différentes configurations suivant l équipement mettant IPsec en œuvre Intégration ISAKMP/SSL-H.Adhami-2002/2003 39

IPsec IPsec IPsec Réseau non fiable Equipement terminal Equipement terminal Figure III.2 (suite) La première situation est celle où l on désire relier des réseaux privés distants par l intermédiaire d un réseau non fiable, typiquement Internet. Les deux passerelles de sécurité permettant içi d établir un réseau virtuel privé (Virtual Private Network, VPN). La deuxième situation correspond au cas où l on désire fournir un accès sécurisé au réseau interne pour des postes nomades. Le réseau non fiable peut être Internet, le réseau téléphonique Enfin, la troisième situation, deux tiers désirent communiquer de façon sécurisée mais n ont aucune confiance dans le réseau qui les sépare. On peut également imaginer des configurations plus complexes ou plusieurs associations de sécurité, apportant éventuellement des services de sécurité différents, se succéderaient ou se superposeraient partiellement: Association de sécurité 1 Association de sécurité 2 Réseau non fiable Réseau de confiance IPsecc IPsec IPsec Association de sécurité 2 Association de sécurité 1 Réseau non fiable Réseau de confiance IPsec IPsec IPsec Figure III.3 Exemples de double utilisation d IPsec Dans les exemples ci-dessus, la première association peut servir à assurer les services de sécurité requis par la politique de sécurité externe (authentification et confidentialité par exemple), et la Intégration ISAKMP/SSL-H.Adhami-2002/2003 40

IPsec seconde à assurer les services requis par la politique de sécurité interne (authentification vis-à-vis de l hôte final par exemple). III.1.3.2 Modes de fonctionnement Pour chacun des mécanismes de sécurité d IPsec, il existe deux modes: Le mode transport et le mode tunnel. En mode transport, seules les données en provenance du protocole de niveau supérieur et transportées par le datagramme IP sont protégées. Ce mode n est utilisable que sur des équipements terminaux; en effet, en cas d utilisation sur des équipements intermédiaires, on courrait le risque, suivant les aléas du routage, que le paquet atteigne sa destination finale sans avoir traversé la passerelle sensée le déchiffrer. En mode tunnel, l en-tête IP est également protégé (authentification, intégrité et/ou confidentialité) remplacé par un nouvel en-tête. Ce nouvel en-tête sert à transporter le paquet jusqu à la fin du tunnel, où l en-tête original est rétabli. Le mode tunnel est donc utilisable à la fois sur des équipements terminaux et sur des passerelles de sécurité. Ce mode permet d assurer une protection plus importante contre l analyse du trafic, car il masque les adresses de l expéditeur et du destinataire final. III.2 Les mécanismes de sécurité : AH et ESP Les mécanismes IPsec (mentionnés au paragraphe précédent) ne sont liés à aucun algorithme crypthographique spécifique, donc ces algorithmes peuvent être modifiés sans affecter les autres éléments d une implémentation. Pour assurer l interopérabilité, des algorithmes cryptographiques par défaut sont toutefois indiqués. Par ailleurs, les propriétés de l algorithme utilisé influenceront les fonctions de sécurité fournies. Les principaux services et mécanismes de sécurité, dans le cadre de la protection des échanges (abordés au chapitre I) sont : la confidentialité, qui est assurée par le chiffrement des données, et l authenticité (authentification + intégrité), qui est assurée par l ajout d un code d authentification du message (MAC) à chaque paquet transféré. III.2.1 Authentification Header (AH) AH assure l intégrité des données en mode non connecté, l authentification de l origine des données et, de façon optionnelle, la protection contre le rejeu. L absence de confidentialité dans AH permet de s assurer que ce standard pourra être largement répandu sur l Internet, y compris dans les endroits où l exportation ou l utilisation du chiffrement dans des buts de confidentialité est retreint par la loi. Cela constitue l une des raisons de l utilisation de deux mécanismes distincts. Dans AH, intégrité et authentification sont fournies ensembles, à l aide d un bloc de données supplémentaire adjoint au message à protéger. Ce bloc de données est appelé valeur de vérification d intégrité (Integrity Check Value, ICV), terme générique pour designer soit un code d authentification de message (Message Authentification Code, MAC), soit une signature numérique. Pour des raisons de performances, les algorithmes proposés actuellement sont tous des algorithmes de scellement (code d authentification de message et non signature). Intégration ISAKMP/SSL-H.Adhami-2002/2003 41

IPsec La protection contre le rejeu se fait grâce à un numéro de séquence; elle n est disponible que si IKE est utilisé, car en mode manuel aucune ouverture de connexion ne permet d initialiser le compteur. Voici l organisation de l en-tête d authentification : En-tête suivant longueur Réservé Index des paramètres de sécurité (SPI) Numéro de séquence Données d authentification (longueur variable) Figure III.6 Format de AH L expéditeur calcule les données d authentification à partir de l ensemble des champs invariants du datagramme IP final, AH compris, ce qui permet d étendre l authentification au SPI et au numéro de séquence notamment. Les champs variables (TTL, routage ) et le champ destiné à recevoir les données d authentification sont considérés comme égaux à zéro pour le calcul. Les données d authentification sont alors adjointes au paquet IP par le biais de l en-tête d authentification (AH). Le récepteur vérifie l exactitude de ces données à la réception. Les figures ci-dessous indiquent la position de AH et le service apporté en fonction du mode choisi (transport ou tunnel). Avant application de AH En-tête IP d origine Données Protocole de niveau supérieur En-tête IP d origine Après application de AH AH Autentifié Données Protocole de niveau supérieur Figure III.7 Position de AH en mode transport (IPv4) En-tête IP d origine Avant application de AH Données Protocole de niveau supérieur Nouvel en-tête IP Avant application de AH AH En-tête IP d origine Autentifié Données Protocole de niveau supérieur Figure III.8 Position de AH en mode tunnel (IPv4) Intégration ISAKMP/SSL-H.Adhami-2002/2003 42

IPsec Parmi les algorithmes par défaut que doit fournir toute réalisation de IPsec pour AH, on peut trouver: HMAC-MD5, et HMAC-SHA-1. Les autres algorithmes prévus sont KPDK-MD5, DES-MAC et HMAC-RIPE-MD. III.2.2 Encapsulating Security Payload (ESP) ESP peut assurer, au choix, un ou plusieurs des services suivants: Confidentialité (confidentialité des données et protection partielle contre l analyse du trafic si l on utilise le mode tunnel), Intégrité des données en mode non connecté et authentification de l origine des données, protection contre le rejeu. La confidentialité peut être sélectionnée indépendamment des autres services, mais son utilisation sans intégrité/authentification (directement dans ESP ou avec AH) rend le trafic vulnérable à certains types d attaques actives qui pourraient affaiblir le service de confidentialité. Comme dans AH, authentification et intégrité sont deux services qui vont de pair et que l on désigne souvent sous le terme authentification ; ils sont fournis par l utilisation d une ICV (en pratique, un MAC). La protection contre le rejeu ne peut être sélectionnée que si l authentification l a été et que IKE est utilisé. Elle est fournie par un numéro de séquence que le destinataire des paquets vérifie. Contrairement à AH, où l on se contentait d ajouter un en-tête supplémentaire au paquet IP, ESP fonctionne suivant le principe de l encapsulation: les données originales sont chiffrées puis encapsulées entre un en-tête et un trailer. Voici l organisation de ESP: Index des paramètres de sécurité (SPI) Numéro de séquence Charge utile (Vecteur d initialisation éventuel+données chiffrées) En-tête ESP Charge utile Bourrage Longueur de bourrage Données d authentification Figure III.9 Format de ESP En-tête suivant Trailer ESP Authentification ESP Le champ bourrage peut être nécessaire pour les algorithmes de chiffrement par blocs ou pour aligner le texte chiffré sur une limite de 4 octets. Les données d authentification ne sont présentes que si ce service a été sélectionné. Voyons maintenant comment est appliquée la confidentialité dans ESP. l expéditeur: Encapsule, dans le champ charge utile de ESP, les données transportées par le datagramme original et éventuellement l en-tête IP (mode tunnel). Ajoute si nécessaire un bourrage. Intégration ISAKMP/SSL-H.Adhami-2002/2003 43

IPsec Chiffre le résultat (données, bourrage, champs, longueur et en-tête suivant). Ajoute éventuellement des données de synchronisation cryptographiques (vecteur d initialisation) au début du champ charge utile. Si elle a été sélectionnée, l authentification est toujours appliquée après que les données ne soient chiffrées. Cela permet, à la réception, de vérifier la validité du datagramme avant de se lancer dans la coûteuse tâche de déchiffrement. Contrairement à AH, l authentification dans ESP est appliquée uniquement sur le paquet (en-tête charge utile trailer) ESP et n inclut ni l en-tête IP ni le champ d authentification. Les figures ci-dessous indiquent la position de ESP et les services apportés en fonction du mode choisi (transport ou tunnel). Avant application de ESP En-tête IP d origine Données Protocole de niveau supérieur En-tête IP d origine En-tête ESP Après application de ESP Données Protocole de niveau supérieur Chiffré (confidentialité) Authentifié Trailer Données d authentification Figure III.10 Position de ESP en mode transport (IPv4). En-tête IP d origine Avant application de ESP Données Protocole de niveau supérieur Après application de ESP En-tête ESP En-tête d origine IP Données Protocole de niveau supérieur Trailer Données d authentification Chiffré (confidentialité) Authentifié Figure III.11 Position de AH en mode tunnel (IPv4) Parmi les algorithmes prévus pour être utilisés avec ESP, ont peut trouver: Confidentialité: DES triple (obligatoire), DES, RC5, CAST, IDEA, IDEA triple, Blow fish, RC4 et NULL pour le cas ou le chiffrement n est pas souhaité. Authentification: HMAC-MD5 (obligatoire), HMAC-SHA-1 (obligatoire), DES- MAC, HMAC-RIPE-MD, KPDK-MD5 et NULL pour le cas où l authenticité n est pas sélectionnée. Intégration ISAKMP/SSL-H.Adhami-2002/2003 44

IPsec III.3 La gestion des clefs Les protocoles sécurisés présentés précédemment ont recours à des algorithmes cryptographiques et ont donc besoin de clefs. Un des problèmes fondamentaux d utilisation de la cryptographie est la gestion de ces clefs. Le terme gestion recouvre la génération, la distribution, le stockage et la suppression des clefs. Les concepts généraux relatifs à la gestion des clefs, (tels types de clefs, infrastructure à clef publique, propriétés des protocoles d échange de clef, Diffie-Hellman, etc ) ont été abordé au premier chapitre, nous illustrons sommairement, dans les paragraphes suivants, les protocoles d authentification mutuelle avec échange de clef développés pour IP. III.3.1 Les protocoles d authentification mutuelle avec échange de clef pour IP Il existe de nombreux protocoles d authentification mutuelle avec échange de clef, qui se différencient suivant les prérequis qu ils imposent (secret partagé préalable, infrastructure à clef publique ) et les propriétés qu ils vérifient (direct authentication, perfect forward secrecy ). Dans le cadre des protocoles d échange de clef développés pour la sécurisation des échanges sous IP, une distinction supplémentaire s impose entre les protocoles orientés connexion et ceux sans connexion. Dans le premier cas, on a recours à un protocole d établissement de clef de session authentifiée, hors bande, avant la communication. La clef résultante est ensuite utilisée pour sécuriser le trafic IP. L inconvénient de cette approche est qu elle nécessite l établissement et la gestion d une pseudo couche session sous IP, alors qu IP est un protocole sans connexion. Dans le second cas, on a recours à une gestion des clefs sans état (stateless), qui ne nécessite donc pas de connexion. Ceci est réalisable à travers un système en bande, où la clef ayant servi à chiffrer le paquet est transmise avec celui-ci, chiffrée avec la clef publique du destinataire par exemple. L inconvénient de ce système est qu il ajoute des données à chaque paquet transmis. D autre part, DIFFIE HELLMAN est très utilisé dans tous les protocoles présentés ici, les différences venant de la durée de vie des valeurs publiques utilisées et de la façon dont elles sont authentifiées et échangées. III.3.1.1 SKIP C est un protocole de gestion des clefs en ligne spécifiquement prévu pour sécuriser des protocoles sans connexion comme IP. Il utilise une génération de clef DIFFIE-HELLMAN, à base de valeurs publiques authentifiées. Le secret partagé ainsi généré sert de clef de chiffrement de clef pour des clefs de session. Il n y a donc pas de perfect forward secrecy (PFS). Une extension de SKIP a été définie qui fournit la propriété de PFS et la protection de l anonymat, au prix d échange de certificats supplémentaires entre les entités. III.3.1.2 Photuris C est un protocole orienté connexion qui utilise une génération de secret partagé DIFFIE- HELLMAN, suivie d une authentification des valeurs publiques utilisées, pour établir une clef de session. Photuris introduit le concept de cookie, mécanisme qui permet de contrer certaines attaques en déni de service. Le protocole comporte trois phrases: échange de cookies, échange de valeurs publiques et échange d identités. Intégration ISAKMP/SSL-H.Adhami-2002/2003 45

IPsec III.3.1.3 SKEME C est un protocole orienté connexion qui propose quatre modes d échange de clefs distincts et se compose de trois phases: partage, échange et authentification. SKEME peut également utiliser le mécanisme de cookies de Photuris. III.3.1.4 Oakley a/ Contexte : Initialement proposé par Hilarie ORMAN du département informatique de l université d Arizona, Oakley a fait l objet d une RFC dans le cadre du groupe IPsec et est, avec ISAKMP et SKEME, à la base de l échange de clef pour IPsec. b/ Principe : Oakley est un protocole d échange de clef qui ressemble beaucoup à SKEME, en ce sens qu il possède également plusieurs modes, a recours aux cookies et ne nécessite pas le calcul du secret partagé DIFFIE HELLMAN avant la fin du protocole. Il se distingue des protocoles présentés jusqu à présent par le fait qu il permet explicitement aux tiers en présence de se mettre d accord sur les mécanismes d échange de clef, de chiffrement et d authentification utilisés. De fait, le but d Oakley est de permettre le partage, de façon sûre entre les tiers, d un ensemble d informations relatives au chiffrement: nom de la clef, clef secrète, identités des tiers, algorithmes de chiffrement, d authentification et fonction de hachage. Plusieurs options sont disponibles dans Oakley. En plus du classique DIFFE HELLMAN, Oakley peut être utilisé pour dériver une nouvelle clef d une clef ancienne ou pour distribuer une clef en la chiffrant. Ces options se traduisent par l existence de plusieurs modes. Le principe général d Oakley est que l initiateur de l échange commence par spécifier autant d information qu il le désire dans un premier message. Son interlocuteur lui répond en fournissant également autant d information qu il le désire. La conversation se poursuit jusqu'à ce que l état recherché soit atteint. Le choix de la quantité d information à inclure dans chaque message dépend des options sélectionnées (utilisation de cookies sans état, protection de l indenté, PFS, non répudiation ). Les trois composants du protocole sont: 1. échange de cookies (éventuellement sans état), 2. échange de valeurs publiques DIFFE HELLMAN (optionnel), 3. authentification (options: anonymat, PFS sur les identités, non-répudiation). III.3.1.5 La gestion des clefs pour IPsec : ISAKMP ET IKE IKE (Internet Key Exchange) est un système développé spécifiquement pour IPsec qui vise à fournir des mécanismes d'authentification et d échange de clef adaptés à l ensemble des situations qui peuvent se présenter sur l'internet. Il est composé de plusieurs éléments: le cadre générique ISAKMP (qui fait l objet du chapitre suivant) et une partie des protocoles Oakley et SKEME. Lorsqu il est utilisé pour IPsec, IKE est de plus complété par un «domaine d interprétation» (voir paragraphe IV.2, chapitre suivant) pour IPsec. Intégration ISAKMP/SSL-H.Adhami-2002/2003 46

IPsec III.4 Conclusion IPsec est un système de sécurisation des échanges au niveau IP qui repose sur deux mécanismes (ou protocoles), AH (Authentication Header) et ESP (Encapsulating Security Payload). Les paramètres nécessaires à l utilisation de ces protocoles sont gérés à l aide d associations de sécurité (Security Association, SA), une association de sécurité regroupant les paramètres servant à protéger une partie donnée du trafic. Les SA sont stockées dans la base de donné des associations de sécurité (Security Association Database, SAD) et gérées à l aide du protocole IKE (Internet Key Exchange). Les protections offertes par IPsec sont basées sur des choix définis dans la base de données de politique de sécurité (Security Policy Database, SPD). Cette liste de règles permet de décider, pour chaque paquet, s il se verra apporter des services de sécurité, s il sera autorisé à passer outre ou sera rejeté. IPsec peut être utilisé au niveau d équipements terminaux ou au niveau de passerelles de sécurité, permettant ainsi des approches de sécurisation lien par lien comme de bout en bout. Enfin, IPsec comporte deux modes, le mode transport qui protège juste les données transportées et le mode tunnel qui protège en plus l en-tête IP. Le chapitre suivant détaille la gestion des clefs pour IPsec, plus précisément le protocole ISAKMP (Internet Security Association Key Management Protocol). Intégration ISAKMP/SSL-H.Adhami-2002/2003 47

ISAKMP Chap IV ISAKMP Nous avons vu dans les chapitres précédents, que l apport de services de sécurité passait par l'utilisation d'associations de sécurité qui permettent de définir les paramètres (clefs, protocoles ) nécessaires à la sécurisation d'un flux donné. ISAKMP (Internet Security Association and Key Management protocol) a pour rôle la négociation, l établissement, la modification et la suppression des associations de sécurité et de leurs attributs. IV.1 Placement D ISAKMP La figure ci-dessous est une vue de niveau supérieur du placement d ISAKMP dans le contexte d un système dans une architecture de réseaux. Une partie importante de la négociation des services de sécurité, est de considérer la pile toute entière des SA individuelles en tant qu unité. On appelle cela la suite de protection. DOI Definition ISAKMP Application Process Application Protocol Key Exchange Definition API Security Protocol Socket Layer Transport Protocol (TCP / UDP) IP Link Layer Protocol Figure IV.1 Les rapports d ISAKMP IV.2 Indépendance vis à vis des mécanismes: les domaines d'interprétation et les phases ISAKMP est un cadre générique indépendant des mécanismes en faveur desquels la négociation a lieu. En effet, ISAKMP, est a priori utilisable pour négocier, sous forme d associations de sécurité, les paramètres relatifs à n'importe quels mécanismes de sécurité: IPsec, TLS Il est en effet prévu pour supporter la négociation de SA pour n importe quel protocole de niveau supérieur ou égale à IP. Ceci est possible grâce à la façon dont les négociations ont lieu. Tout d abord, ISAKMP est prévu pour fonctionner indépendamment des mécanismes pour lesquels il travaille: les Intégration ISAKMP/SSL-H.Adhami-2002/2003 48

ISAKMP données relatives à la gestion des clefs seront transportées à part. ISAKMP peut être implémenté directement au-dessus d IP, ou au-dessus de tout protocole de la couche transport. Il s est notamment vu attribuer le port 500 sur UDP par l IANA. Ensuite, ISAKMP définit un cadre pour négocier les associations de sécurité, mais n'impose rien quant aux paramètres qui les composent. Un document appelé «domaine d'interprétation» (Domain of Interpretation, DOI) doit définir les paramètres négociés et les conventions relatives à l'utilisation de ISAKMP dans un cadre précis. Un identificateur de DOI est utilisé pour interpréter le contenu des messages ISAKMP. La [RFC 2407] définit le DOI pour l'utilisation de ISAKMP avec IPsec. Nous reviendrons sur ce document plus loin dans ce chapitre. Enfin, ISAKMP comporte deux phases, qui permettent une séparation nette de la négociation des SA pour un protocole donné et de la protection du trafic propre à ISAKMP : Durant la première phase, un ensemble d'attributs relatifs à la sécurité est négocié, les identités des tiers sont authentifiées et des clefs sont générées. Ces éléments constituent une première «association de sécurité», dite SA ISAKMP. Contrairement aux SA IPsec, la SA ISAKMP est bidirectionnelle. Elle servira à sécuriser l'ensemble des échanges ISAKMP futurs. La seconde phase permet de négocier les paramètres de sécurité relatifs à une SA à établir pour le compte d'un mécanisme de sécurité donné (par exemple AH ou ESP). Les échanges de cette phase sont sécurisés (confidentialité, authenticité ) grâce à la SA ISAKMP. Celleci peut bien sûr être utilisée pour négocier plusieurs SA destinées à d'autres mécanismes de sécurité. Les paramètres de la SA ISAKMP peuvent être propres à ISAKMP seulement, ou comporter également des éléments propres à un protocole de sécurité donné et définis dans le DOI correspondant. Dans le premier cas, on parlera de Generic ISAKMP SA, et celle-ci pourra servir pour la négociation de SA pour n'importe quel protocole de sécurité. Dans le second cas, la SA ISAKMP ne pourra être utilisée que pour négocier une SA dépendant du même DOI. IV.3 Les Charges utiles d ISAKMP ISAKMP est également indépendant de la méthode de génération des clefs et des algorithmes de chiffrement et d'authentification utilisés. Il est donc indépendant de tout protocole d'échange de clef, ce qui permet de séparer clairement les détails de la gestion des associations de sécurité des détails de l'échange de clef. Différents protocoles d'échange de clef, présentant des propriétés différentes sont ainsi utilisables avec ISAKMP. Ceci est possible à cause du fait que ISAKMP n'impose pas un déroulement fixe, basé sur la définition d'un ensemble de messages limité. ISAKMP est plutôt une sorte de «kit de construction», puisque les messages d'isakmp sont constitués d'un en-tête suivi d'un nombre variable de blocs. Ces blocs (payloads en anglais) sont les briques de base d'isakmp. Les types de la charge utile d ISAKMP sont discutés dans les sections IV.3.4 jusqu à IV.3.8. IV.3.1 Format de l en-tête ISAKMP (ISAKMP Header Payload) Chaque message ISAKMP commence par un en-tête (ISAKMP Header) de longueur fixe. Celui-ci comprend notamment deux cookies, l'initiator cookie et le responder cookie, qui, en Intégration ISAKMP/SSL-H.Adhami-2002/2003 49

ISAKMP plus du rôle classique de protection contre le déni de service (anti-clogging), permettent d'identifier l'association de sécurité ISAKMP en cours (contrairement aux autres SA, elle n'est pas identifiée pas un SPI). Initiator Cookie Responder Cookie Next Payload MjVer MnVer Exchange Type Flag1 Message Id Length Figure IV.2 Format de l en-tête ISAKMP Un champ Exchange Type permet de connaître le type d'échange en cours et donc de connaître l'organisation et le nombre des messages. L'en-tête ISAKMP comprend également un champ, Next Payload, qui indique le type du premier bloc du message. Chaque bloc commence à son tour par un en-tête propre, qui indique la longueur du bloc courant et le type du bloc suivant. Le dernier bloc du message indique 0 comme type de bloc suivant. La construction des messages ISAKMP repose sur le chaînage en blocs. IV.3.2 Generic Header Payload ou charge utile de l En-tête Générique Chaque bloc ISAKMP, commence par un en-tête générique, montré à la figure IV.3, qui procure une capacité de chaînage de charges utiles et définie clairement les frontières d une charge utile. Next Payload Reserved Payload Length Figure IV.3 Format de l en-tête générique Les champs de l en-tête générique sont définis comme suit : - Next Payload ou Charge utile suivante (1 octet): Identificateur pour le type de la charge utile suivante dans un message. Si la charge utile en cours est la dernière dans le message, ce champ sera alors nul. Ce champ procure la capacité de «chaînage». - RESERVED ou champ Réserve (1 octet), inutilisé, mis à 0. - Payload Length ou Longueur de la charge utile (2 octets): longueur en octets de la charge utile en cours y compris l en-tête générique. IV.3.3 Attributs de données Il y a plusieurs instances dans ISAKMP où il est nécessaire de présenter des attributs de données (Data Attributes). Par exemple: les attributs de l Association de Sécurité SA contenus dans la charge utile Transform (décrit dans la section IV.3.6). Intégration ISAKMP/SSL-H.Adhami-2002/2003 50

ISAKMP Les attributs de donnés ne sont pas des blocs ISAKMP, mais ils sont contenus dans les blocs ISAKMP. Le format de ces attributs de donnés procure une flexibilité pour la représentation de plusieurs types différents d information. Il peut y avoir plusieurs attributs de donnés dans une charge utile. Leur longueur peut être soit quatre octets ou bien elle est définie par le champ de longueur de l attribut. Ceci se fait en utilisant le bit du format de l attribut (attribute format bit) décrit ci-dessous. Des informations spécifiques concernant les attributs de chaque domaine seront décrites dans un document DOI (Domain Of Interpretation) par exemple: IPSEC DOI. Attribute Type AF = 0 Attribute Length AF = 1 Attribute Value AF = 0 Attribute Value AF = 1 Not Transmitted Figure IV.4 Les attributs de données Les champs des attributs de données sont définis comme suit: -Type de l attribut (2 octets): Identificateur unique de chaque type d attribut. Ces attributs sont définis comme partie de l information spécifique du DOI. Le MSB, ou format de l attribut (Attribut Format, AF), indique si la donnée des attributs suit le format Type/Longueur/Valeur (TLV) ou le format réduit Type/Valeur. Si le bit AF est à 0, les attributs de donnés sont alors de la forme (TLV). Si le bit AF est à 1, les attributs de donnés sont alors de la forme Type/Valeur. -Longueur de l attribut (2 octets): Longueur en octets de la valeur de l attribut. Quand le bit AF est à 1, la valeur de l attribut est seulement 2 octets et le champ de longueur de l attribut n est pas présent. -Valeur de l attribut (longueur variable): Valeur de l attribut associée au type de l attribut spécifique du DOI. Si le bit AF est nul, cette zone a une longueur variable définie par la zone de longueur de l attribut. Si le bit AF est à 1, la valeur de l attribut a une longueur de 2 octets. IV.3.4 Indépendance vis-à-vis du protocole de gestion des clefs: la construction des messages par blocs Le document de base ISAKMP définit 13 types de blocs différents : Nom Sigle Security Association SA Proposal P Transform T Key Exchange KE Identification ID Certificate CERT Certificate Request CR Hash HASH Signature SIG Nonce NONCE Notification N Delete D Vendor ID VID Tableau IV.1 Blocs ISAKMP Intégration ISAKMP/SSL-H.Adhami-2002/2003 51

ISAKMP IV.3.4.1 Bloc Security Association Le bloc Security Association (SA) est utilisé pour négocier les attributs de sécurité. Next Payload Reserved Payload Length Domain of Interpretation (DOI) Situation Figure IV.5 Format du bloc SA En lui-même, il contient des champs qui indiquent le contexte de la négociation (DOI et situation). La situation est un paramètre qui dépend du DOI et qui permet d'indiquer quel type de politique de sécurité on désire utiliser (voir IV.5 a/). Une valeur de 0 pour le DOI pendant la phase 1 indique que l on négocie une SA ISAKMP générique. Une valeur de 1 indique le DOI IPsec. Un bloc SA est toujours suivi d'un ou plusieurs blocs Proposal, qui permettent de faire des propositions (présentées par ordre de préférence) à l'interlocuteur. IV.3.4.2 Le bloc PROPOSAL Chaque bloc Proposal constitue une proposition d un ensemble d'attributs relatifs à une association de sécurité. Next Payload Reserved Payload Length Proposal # Protocol - Id SPI Size # of Transforms SPI (variable) Figure IV.6 Format du bloc Proposal En lui-même, le bloc Proposal indique le mécanisme de sécurité que l'on désire utiliser (AH, ESP...) ainsi que le SPI à associer à la SA si cette proposition est retenue. Comme il est possible de laisser le choix à l'interlocuteur en lui faisant plusieurs propositions, chaque bloc Proposal est numéroté. Lorsque plusieurs propositions constituent un tout (par exemple si l on veut négocier une protection par AH ESP), elles portent le même numéro et résulteront en la création d un paquet de SA. Un bloc P est toujours suivi d'un ou plusieurs blocs Transform (paragraphe suivant), qui permettent de préciser les attributs choisis pour la SA en question. IV.3.4.3 Bloc TRANSFORM Chaque bloc Transform indique une transformation (algorithme de chiffrement, fonction de hachage...) et ses attributs. Intégration ISAKMP/SSL-H.Adhami-2002/2003 52

ISAKMP Next Payload Reserved Payload Length Transform # Transform - Id Reserved 2 SA Attributes Figure IV.7 Format du bloc Transform Ces éléments dépendent bien sûr du DOI et du mécanisme de sécurité sélectionné dans les blocs précédents. Comme pour les blocs Proposal, les blocs Tranform sont numérotés: si deux blocs portent le même numéro, ils forment un tout et doivent être sélectionnés ensemble; des blocs de numéros différents indiquent une possibilité de choix. Ces trois premiers types de blocs ne sont pas indépendants et on peut considérer qu ils sont emboîtés. On désigne donc souvent par le bloc SA seul l'ensemble des blocs SA, P et T. SA P1 T1.1 T1.2 T1.3 P2 T2.1 T2.2 DOI Mécanisme Transfo. Transfo. Transfo. Mécanisme Transfo Transfo Situation SPI Attributs Attributs Attributs SPI Attributs Attributs Figure IV.8 Organisation des blocs SA, P et T L'ensemble représenté dans le schéma ci-dessus pourrait être un ensemble de propositions envoyé par un tiers à un autre. Le destinataire de ce message doit répondre par une suite identique dans laquelle il ne conserve que la proposition (ou le groupe de propositions) retenue. L'association de sécurité (ou le paquet d'associations de sécurité) résultant de cette négociation se verra attribué le SPI de la proposition retenue. IV.3.4.4 Bloc Key Exchange Le bloc Key Exchange sert à transporter les données nécessaires à la génération de la clef de session. Next Payload Reserved Payload Length Key Exchange Data Figure IV.9 Format du bloc Key Exchange Son interprétation dépend du DOI et du protocole d'échange de clefs choisi. Intégration ISAKMP/SSL-H.Adhami-2002/2003 53

ISAKMP IV.3.4.5 Les autres blocs Identification Le bloc Identification sert à transporter les données nécessaires à l identification des tiers. Son interprétation dépend du DOI. Next Payload Reserved Payload Length ID TYPE DOI Specific ID Data Identification Data Figure IV.10 Format du bloc Identification Un champ intitulé ID Type indique le type de donnée d indentification contenu dans le bloc. Pour ISAKMP ce sont une adresse IP (IPv4 ou IPv6) ou une plage d adresses IP (adresse /masque de sous-réseau). Chaque DOI peut définir différents types d indentification. Certificate Le bloc Certificate fournit un moyen de transporter des certificats ou toute autre information en relation avec les certificats. Next Payload Reserved Payload Length Cert Encoding Certificate Data Figure IV.11 Format du bloc Certificate Un champ intitulé Certificate Encoding indique le type de certificat ou de donnée relative aux certificats contenue dans le champ Certificate Data. Les types définis actuellement sont : - PKCS #7 wrapped X.509 certificate - PGP certificate - DNS signed key - X.509 certificate signature - X.509 certificate Key exchange - Kerberos tokens - Certifcate revocation list (CRL) - Authority revocation list (ARL) - SPKI certificate - X.509 certificate attribute Intégration ISAKMP/SSL-H.Adhami-2002/2003 54

ISAKMP Certificate Request Le bloc Certificate Request permet à un tiers de réclamer un certificat à son interlocuteur. Next Payload Reserved Payload Length Cert. Type Certificate Authority Figure IV.12 Format du bloc Certificate Request Comme dans le bloc précédent, un champ indique le type de certificat requis. Un second champ, intitulé Certificate Authority, contient les références d'une autorité de certification acceptable par le demandeur. Ce champ est facultatif. Hash Le bloc Hash contient le résultat de l'application d'une fonction de hachage sélectionnée au préalable à tout ou partie du message ou à une variable d'état donnée. Next Payload Reserved Payload Length Hash Data Figure IV.13 Format du bloc Hash Ce bloc peut être utilisé à des fins de vérification de l'authenticité d'un message ISAKMP d'authentification des tiers en présence. Signature De même, le bloc Signature contient le résultat de l'application d'une fonction de signature numérique sélectionnée au préalable à tout ou partie du message ou à une variable d'état donnée. Next Payload Reserved Payload Length Signature Data Figure IV.14 Format du bloc Signature L'utilisation est la même que pour le bloc Hash. Intégration ISAKMP/SSL-H.Adhami-2002/2003 55

ISAKMP Nonce Le bloc Nonce sert à transporter des aléas. Next Payload Reserved Payload Length Nonce Data Notification Figure IV.15 Format du bloc Nonce Le bloc Notification sert à véhiculer des messages d'erreur ou d'information sur l'état actuel des négociations. Next Payload Reserved Payload Length Domain of Interpretation (DOI) Protocol - ID SPI Size Notify Message Type Security Parameter Index (SPI) Notification Data Figure IV.16 Format du bloc Notification Son interprétation dépendant du DOI, celui-ci est indiqué au début du bloc. Le début du bloc contient également les références de l'association de sécurité concernée (mécanisme et SPI). Le message est représenté par deux champs Notify Message Type et Notification Data (facultatif). Delete Le bloc Delete permet à l'émetteur de signaler à son interlocuteur qu'il vient de supprimer une association de sécurité et que celle-ci n'est donc plus valable. Un seul bloc permet éventuellement d'indiquer plusieurs SA, à conditions qu'elles soient toutes relatives au même mécanisme. Dans ISAKMP, la modification des SA se fait en créant une nouvelle SA puis en supprimant l'ancienne. Intégration ISAKMP/SSL-H.Adhami-2002/2003 56

ISAKMP Next Payload Reserved Payload Length Domain of Interpretation (DOI) Protocol - ID SPI Size # of SPIs Security Parameter Index (es) (SPI) Figure IV.17 Format du bloc Delete Vendor ID Le bloc Vendor ID peut être utilisé par un programmeur pour permettre à deux instances de se reconnaître et de pouvoir ensuite utiliser des éléments propres à cette implémentation. Next Payload Reserved Payload Length Vendor ID (VID) Figure IV.18 Format du bloc Vendor ID IV.4 Interopérabilité et ligne directrice: les types d'échanges A partir de ces blocs, ISAKMP définit des types d échanges (Exchange types). Un type d échange est une spécification de l ensemble des messages constituant un type d échange donné (nombre, contenu ). Chaque type d échange est conçu pour fournir un certain nombre de services de sécurité spécifiques, comme l anonymat, la propriété de perfect forward secrecy, l authentification mutuelle, Le document de base sur ISAKMP, (RFC 2408), définit, à des fins d interopérabilité et surtout pour indiquer comment doivent être utilisés les blocs dans le cadre d'une négociation donnée, des types d'échanges par défaut. D autres types peuvent bien sûr être définis, en fonction du protocole d'échange de clef utilisé et du DOI notamment. D'autre part, plusieurs propositions de types d'échanges supplémentaires pour ISAKMP font l'objet d'internet Drafts séparés. La spécification actuelle de ISAKMP comporte cinq types d'échanges par défaut: Base Exchange, Identity Protection Exchange, Authentication-Only Exchange, Aggressive Exchange, Informational Exchange. Seul ce dernier est obligatoire. Tous ces échanges peuvent être utilisés soit durant la phase 1, soit durant la phase 2. Dans les descriptions qui vont suivre, on utilisera les notations suivantes : Intégration ISAKMP/SSL-H.Adhami-2002/2003 57

ISAKMP HDR ISAKMP Header SA Security Association Payload KE Key Exchange Payload ID Identity Payload AUTH Authentication Payload (HASH ou SIG) NONCE Nonce payload * Signifie que le message est chiffré Notation pour les échanges ISAKMP Avant de procéder par les échanges, on donnera les directives pour l établissement et la modification de SA. IV.4.1 Etablissement de l association de sécurité Les blocs SA, Proposal et Transform sont utilisées pour bâtir des messages ISAKMP pour la négociation et l établissement des SA. Un message d établissement de SA consiste en une charge utile SA unique suivie d un au moins ou de plusieurs charges utiles de Proposal et au moins un ou plusieurs charges utiles de Transform associées à chacun des Proposals. Puisque ces blocs sont considérés ensemble, le bloc SA pointe sur n importe quel bloc suivant et non pas sur le bloc Proposal y compris. Le bloc SA contient le DOI et la «Situation» de la SA proposée. Chaque bloc Proposal contient un SPI (Security Parameter Index) et assure que ce SPI doit être associé au Protocol-Id conformément à l Architecture de Sécurité sur Internet. Les blocs Proposal peuvent avoir le même SPI ou pas, car ils dépendent de l implémentation. Chaque bloc Transform contient des mécanismes de sécurité spécifiques utilisés pour le protocole désigné. Il faut s attendre à ce que les Proposals et Transforms seront utilisées seulement durant la négociation d établissement de SA. La création des blocs pour la négociation et l établissement de l Association de Sécurité, décrite dans cette section, est applicable pour tous les échanges ISAKMP qui seront décrits plus tard dans la section IV.4.3. Les exemples présentés dans IV.4.1.1 contiennent seulement les blocs SA, Proposal et Transform, et ne contiennent pas d autres blocs qui pourront exister pour un échange ISAKMP donné. Le bloc Proposal fournit à l initiateur la capacité de présenter, au répondeur, les protocoles de sécurité ainsi que les mécanismes de sécurité associés, pour les utiliser avec l Association de Sécurité en question. Si la négociation d établissement de SA est faite pour une suite de protection combinée, composée de plusieurs protocoles, il faut avoir alors plusieurs blocs Proposal, ayant chacun le même numéro. Ces Proposals doivent être considérées comme une unité et ne doivent pas être séparées par un autre Proposal ayant un numéro différent. L utilisation du même numéro de Proposals dans plusieurs charges utiles procure une opération AND logique c.à.d Protocol1 AND Protocol2. Le premier exemple ci-dessous montre une suite de protection ESP et AH. Si la négociation d établissement de SA est pour différentes suites de protection, alors, il doit y avoir plusieurs Proposals, possédant chacun un numéro croissant d une façon monotone. Les différents Proposals doivent être présentées dans l ordre de préférence de l initiateur. L utilisation de différents numéros de Proposals dans plusieurs charges utiles, procure une opération OR logique, c.à.d., Proposal1 OR Proposal2, où chaque Proposal pourrait avoir plus qu un protocole. Le deuxième exemple ci-dessous montre une suite de protection AH ET(AND) ESP, OU(OR) une suite de protection ESP seulement. Noter que le champ Next Payload du bloc Proposal pointe sur un autre bloc (s il existe). L existence d un bloc Proposal implique l existence d un ou de plusieurs blocs Transform. Intégration ISAKMP/SSL-H.Adhami-2002/2003 58

ISAKMP Le bloc Transform procure à l initiateur une capacité de présenter au répondeur plusieurs mécanismes ou transformations (Transforms), pour un protocole donné. Le bloc Proposal identifie un protocole pour lequel services et mécanismes sont négociés. Le bloc Transform permet à l initiateur de présenter plusieurs transformations (Transforms) soutenues possibles pour le protocole proposé. Il pourrait y avoir plusieurs transformations associées à un Proposal spécifique, dont chacune est identifiée dans un bloc Transform séparé. Les transformations multiples doivent être présentées avec des numéros croissants, d une façon monotone, dans l ordre de préférence de l initiateur. L entité réceptrice doit sélectionner une transformation unique pour chaque protocole dans un Proposal ou rejeter le Proposal tout entier. L utilisation du numéro du Transform dans plusieurs charges utiles procure une opération OR du deuxième niveau, c.à.d., Transform1 OR Transform2 OR Transform3. L exemple 1 ci-dessous montre deux «Transformations» possibles pour ESP et une seule pour AH. L exemple 2 montre une «Transformation» pour AH ET(AND) une Transformation pour ESP OU(OR) deux Transformations pour ESP tout seul. Noter que le champ Next Payload du bloc Transform pointe sur un autre bloc ou sur 0. En répondant à un bloc SA, le répondeur doit envoyer un bloc SA avec une proposition sélectionnée, qui peut consister en plusieurs Proposals et leur Transforms associés. Chaque Proposal doit contenir un seul Transform associé au protocole. Le répondeur doit retenir le champ Proposal #, dans le bloc Proposal et le champ Transform # dans chaque bloc Transform de la «Proposition» sélectionnée. La rétention des numéros des Proposals et Transforms doit précipiter le traitement du protocole de l initiateur en annulant le besoin de comparer la sélection du répondeur avec chaque option offerte. Ces valeurs permettent à l initiateur d exécuter la comparaison directement et rapidement. L initiateur doit vérifier si le bloc SA, reçu du répondeur, s accorde avec un des propositions envoyées initialement. IV.4.1.1 Exemples de l Etablissement de l association de sécurité Exemple 1 : Cet exemple montre un Proposal pour une suite de protection associée à deux différents protocoles. Le premier protocole présente deux transformations soutenues par l initiateur. Le deuxième protocole présente une seule transformation. Comme exemple de cette transformation, on peut citer: Protocole 1 est ESP avec comme Transformation 1 : 3DES, et Transformation 2 : DES, et Protocole 2 est AH avec comme Transformation 1 : SHA. Le répondeur doit choisir entre les deux transformations proposées par ESP. La suite de protection résultante sera: 1)3DES AND SHA OU(OR) 2)DES AND SHA, dépendant de la Transformation ESP choisie par le répondeur. Noter que cet exemple est illustré en utilisant l échange de Base (Base Exchange,section IV.4.3). Intégration ISAKMP/SSL-H.Adhami-2002/2003 59

ISAKMP NP = Nonce Reserved Payload Length SA Pay Domain of Interpretation (DOI) Situation Prop 1 Prot 1 NP = Proposal Reserved Payload Length Proposal # = 1 Protocol - Id SPI Size # of Trans. =2 SPI (variable) NP = Transform Reserved Payload Length Tran 1 Transform # 1 Transform ID Reserved 2 SA Attributes NP = 0 Reserved Payload Length Tran 2 Transform # 2 Transform ID Reserved 2 SA Attributes Prop 1 Prot 2 NP = 0 Reserved Payload Length Proposal # = 1 Protocol - Id SPI Size # of Trans. =1 SPI (variable) NP = 0 Reserved Payload Length Tran 1 Transform # 1 Transform ID Reserved 2 SA Attributes Figure IV.19 Exemple avec une suite de chiffrement combinée Exemple 2 : Le deuxième exemple est un Proposal de deux suites de protection différentes. Le bloc SA a été négligé par manque d espace. La première suite de protection est présentée avec une transformation pour le premier protocole et une pour le second protocole. La deuxième suite de protection est présentée avec deux transformations pour un seul protocole. Comme exemple de cette proposition, on peut citer: Proposition 1 avec Protocole 1 comme AH avec Transformation 1 comme MD5 et Protocole 2 comme ESP avec Transformation 1 comme 3DES. Intégration ISAKMP/SSL-H.Adhami-2002/2003 60

ISAKMP Ceci est suivi par: Proposition 2 avec Protocole 1 comme ESP avec Transformation 1 comme DES et Transformation 2 comme 3DES. Le répondeur doit choisir entre deux propositions différentes. Si le deuxième Proposal est sélectionné, le répondeur doit choisir entre les deux transformations pour ESP. La suite de protection résultante sera (1) MD5 ET(AND) 3DES OU(OR) la sélection entre (2) DES OU(OR) (3) 3DES. Prop 1 Prot 1 NP = Proposal Reserved Payload Length Proposal # = 1 Protocol - Id SPI Size # of Trans. =1 SPI (variable) NP = 0 Reserved Payload Length Tran 1 Transform # 1 Transform ID Reserved 2 SA Attributes Prop 1 Prot 2 Tran 1 Prop 2 Prot 1 NP = Proposal Reserved Payload Length Proposal # = 1 Protocol - Id SPI Size # of Trans. =1 SPI (variable) NP = 0 Reserved Payload Length Transform # 1 Transform ID Reserved 2 SA Attributes NP = 0 Reserved Payload Length Proposal # = 2 Protocol - Id SPI Size # of Trans. =2 SPI (variable) NP = Transform Reserved Payload Length Tran 1 Transform # 1 Transform ID Reserved 2 SA Attributes NP = 0 Reserved Payload Length Tran 2 Transform # 2 Transform ID Reserved 2 SA Attributes Figure IV.20 Exemple avec 2 suites de chiffrement Intégration ISAKMP/SSL-H.Adhami-2002/2003 61

ISAKMP IV.4.1.2 Modification de l Association de Sécurité La modification de l Association de Sécurité dans ISAKMP est accomplie par la création de nouvelles SA et des communications d initiation utilisant cette même nouvelle SA. La suppression de l ancienne SA peut être faite à n importe quel moment après l établissement de la nouvelle SA. La suppression de l ancienne SA dépend de la politique de sécurité locale. La modification des SA en utilisant la méthode créer des nouvelles SA en supprimant les anciennes (Create new SA followed by Delete old SA) est faite pour empêcher les vulnérabilités possibles dans la modification synchronisée des attributs de SA existants. La procédure de création de nouvelles SA est exposée dans la section IV.4.1. La procédure suivie pour supprimer des SA n est pas exposée. La modification d une SA ISAKMP (négociation de la phase 1) suit la même procédure que la création d une SA ISAKMP. Il n y a pas de relation entre les deux SA et les paires de cookies de l initiateur et du répondeur doivent être différents. La modification d une SA d un protocole (négociation de la phase 2) suit la même procédure que la création d un protocole SA. La création d une nouvelle SA est protégée par l existence d une SA ISAKMP. Il n y a pas de relation entre les deux SA de protocoles. Une implémentation d un protocole doit commencer par utiliser la SA créée récemment pour le trafic sortant et doit continuer à soutenir le trafic entrant sur l ancienne SA jusqu à ce qu il soit supprime ou jusqu à ce que le trafic est reçu sous la protection de la SA créée récemment. Comme on a déjà mentionné dans cette section, la suppression d une ancienne SA dépend alors de la politique de sécurité locale. IV.4.2 Les types d échanges L'échange de base (Base Exchange) est conçu pour permettre le transfert simultané des données d'identification et des données servant à la génération de la clef, ce qui permet de réduire 1e nombre total de messages nécessaires, au détriment de la protection de l'anonymat des tiers en présence. En effet: les identités sont échangées avant qu'un secret partagé ne soit établi et ne permette de les chiffrer. Initiator Responder HDR, SA, NONCE 1 HDR, SA, NONCE 2 Attributs de la SA négociés Sélectionne les attributs de SA désirés Vérifie l authenticité HDR, KE, IDi, AUTH 3 Vérifie l authenticité HDR, KE, IDr, AUTH 4 Figure IV.21 Echange de base Les données échangées au cours des messages 3 et 4 sont protégées, par le biais du bloc AUTH, par la fonction d'authentification sélectionnée au cours de la négociation des messages 1 et 2. Intégration ISAKMP/SSL-H.Adhami-2002/2003 62

ISAKMP L'échange de protection d'identité (Identity Protection Exchange), quant-à-lui, repousse l'envoi des données d'identification à après l'échange des données permettant la génération du secret partagé, assurant ainsi l'anonymat des tiers. Initiator HDR, SA 1 HDR, SA 2 Attributs de la SA négociés HDR, KE, NONCE 3 HDR, KE, NONCE 4 Clef calculée par les 2 tiers Responder Sélectionne les attributs de SA désirés HDR*, IDi, AUTH 5 HDR*, IDr, AUTH Vérifie l authenticité 6 Figure IV.22 Echange de protection d identité Vérifie l authenticité L'échange d'authentification seule (Authentication Only Exchange) est conçu pour aboutir uniquement à l'authentification des tiers, évitant ainsi le temps de calcul engendré par la génération de clef lorsque celle-ci n'est pas nécessaire. Cet échange est particulièrement utile durant la seconde phase, où il sera protégé par les services de sécurité négociés au cours de la première phase. Initiator Responder HDR, SA, NONCE 1 Sélectionne les attributs de SA désirés Vérifie l authenticité HDR, SA, NONCE, IDr, AUTH 2 Attributs de la SA négociés HDR, IDi, AUTH 3 Figure IV.23 Echange d authentification seule Vérifie l authenticité L'échange agressif (Aggressive Exchange) combine les données de négociation de la SA, d'authentification et d'échange de clef en un seul message afin de réduire au maximum le nombre de messages nécessaires. Tout comme pour l'échange de base, l anonymat des tiers Intégration ISAKMP/SSL-H.Adhami-2002/2003 63

ISAKMP n'est donc pas préservé. De plus, le fait de ne pas séparer la négociation de la SA de l'envoi du bloc KE empêche 1a négociation du groupe Diffie- Hellman. Initiator Responder HDR, SA,KE, NONCE, IDi 1 Vérifie l authenticité HDR, SA,KE, NONCE, IDr, AUTH 2 Clef calculée. Attributs de la SA négociés HDR*, AUTH 3 Vérifie l authenticité Figure IV.24 Echange agressif L'échange d'information (Informational Exchange) est constitué d'un seul message et sert à transmettre une information relative à la gestion des SA: message d'erreur, information d'état, annonce de suppression de SA Il utilise soit un bloc Notification, soit un bloc Delete. Ce message est protégé par la SA ISAKMP si celle-ci a déjà été établie, sinon il n'est pas protégé. Initiator Responder HDR*, ND 1 Figure IV.25 Echange d information IV.5 IPsec DOI ISAKMP définit un cadre pour négocier les associations de sécurité, mais n'impose rien quant aux paramètres qui les composent. Un document appelé "domaine d'interprétation" (Domain Of Interpretation, DOI) définit les paramètres négociés et les conventions relatives à l'utilisation de ISAKMP dans un cadre précis. Un identificateur de DOI est utilisé pour interpréter le contenu des messages. La [RFC 2407] définit le DOI pour l'utilisation de ISAKMP avec IPsec. a/ Bloc SA: situation Utilisé dans le bloc SA de ISAKMP, le champ «situation» permet de préciser la situation à laquelle doit être rattachée la négociation. Le DOI IPsec définit trois situations différentes: Identity only, qui impose une identification des tiers par le biais d'un bloc ID. Secrecy, qui permet l'utilisation d'indicateur de niveaux de confidentialité. Integrity, qui permet l'utilisation d'indicateurs de niveaux pour l'intégrité. Le DOI IPsec définit également des champs supplémentaires dans le bloc SA pour transporter les données relatives à la situation: niveau de confidentialité, niveau d'intégrité. Intégration ISAKMP/SSL-H.Adhami-2002/2003 64

ISAKMP b/ Bloc P: Protocole de sécurité Les protocoles (ou mécanismes) qui entrent dans le cadre DOI IPsec sont: ISAKMP (pour une négociation de phase 1 avec le DOI IPsec au lieu de Generic ISAKMP) AH ESP IPCOMP IPCOMP est un protocole de compression des données au niveau IP. Le chiffrement des données rendant inefficace toute compression ultérieure, il peut être intéressant de compresser les données avant de les chiffrer. c/ Bloc T: Transformation et attributs A chacun des quatre protocoles mentionnés ci-dessus sont associées des transformations permettant de faire des choix par le biais de blocs Transform. Pour ISAKMP, cette méthode permet de choisir le protocole d'échanges de clefs à utiliser. Le seul choix possible dans le cadre de IPsec est IKE. Les transformations relatives à AH sont MD5, SHA et DES. Cette information est à compléter, par le biais du champ SA Attributes du bloc Transform, par la référence de l'algorithme à utiliser. D'où en fait quatre possibilités: HMAC-MD5, KPDK-MD5, HMAC-SHA, DES-MAC. Les transformations relatives à ESP sont DES_IV32, DES_IV64 (DES en mode CBC avec un vecteur d'initialisation de longueur 32 ou 64 respectivement), DES (DES en mode CBC, demande une précision par le biais d'attributs), 3DES (demande une précision par le biais d'attributs), RC5, IDEA, CAST, BLOWFISH, 3IDEA, RC4 et NULL (permet d'utiliser ESP sans chiffrement des données). Enfin, les transformations utilisables avec IPCOMP sont OUI (transformation propriétaire, à préciser par le biais d'un attribut), DEFLATE, LZS et V42BIS. En plus des attributs mentionnés ci-dessus, il est possible d'avoir recours à plusieurs attributs pour préciser le groupe sur lequel effectuer les calculs relatifs à DIFFIE HELLMAN, la durée de vie de la SA, la longueur de la clef pour les algorithmes à clef de longueur variable Ces éléments sont décrits en détail dans [RFC 2407]. d/ Bloc ID Le DOI IPsec ajoute au bloc ID les champs Protocol ID (UDP, TCP ) et Port, et définit les modes d'identification suivants : - Adresse IPv4, adresse IPv6. - Sous réseau IPv4 ou IPv6 (adresse / masque de sous-réseau). - Plage d'adresses IPv4 ou IPv6 ( adresse de début, adresse de fin). - FQDN (foo.bar.com). - User FQDN ( user@foo.bar.com). - Binary DER encoding of an ASN.1X.500 Distinguished Name [X.501]. - binary DER encoding of an ASN.1X.500 General Name [X.509]. - KEY ID : information propre à un fournisseur et permettant d'identifier le secret partagé préalable à utiliser. Intégration ISAKMP/SSL-H.Adhami-2002/2003 65

ISAKMP e/ Bloc N 3 nouveaux messages de statut sont introduits : - RESPONDER-LIFETIME. - REPLAY-STATUS. - INITIAL-CONTACT. IV.6 IKE Si le DOI IPsec précise le contenu des blocs ISAKMP dans le cadre de IPsec, IKE en revanche utilise ISAKMP, pour construire un protocole pratique. Le protocole de gestion des clefs associé à ISAKMP dans ce but est inspiré à la fois d'oakley et de SKEME. Plus exactement, IKE utilise certains des modes définis par Oakley et emprunte à SKEME son utilisation du chiffrement à clef publique pour l'authentification et sa méthode de changement de clef rapide par échange d'aléas. D'autre part, IKE ne dépend pas d'un DOI particulier mais peut utiliser tout DOI. IKE comprend quatre modes : le mode principal (Main Mode), le mode agressif (agressive Mode), le mode rapide (Quick Mode) et le mode nouveau groupe (New Group Mode). Main Mode et Agressive Mode sont utilisés durant la phase 1, Quick Mode est un échange de phase2. New Group Mode est un peu à part : ce n'est ni un échange de phase 1, ni un échange de phase2, mais il ne peut avoir lieu qu'une fois une SA ISAKMP établie; il sert à se mettre d'accord sur un nouveau groupe pour de futurs échanges DIFFIE-HELLMAN. IV.6.1 Main Mode et Agressive Mode Les attributs suivants sont utilisés par IKE et négociés durant la phase 1 : un algorithme de chiffrement, une fonction de hachage, une méthode d'authentification et un groupe pour DIFFIE- HELLMAN. Trois clefs sont générées à l'issue de la phase 1 : une pour le chiffrement, une pour l'authentification et une pour la dérivation d'autres clefs. Ces clefs dépendent des cookies, des aléas échangés et des valeurs publiques DIFFIE-HELLMAN ou du secret partagé préalable. Leur calcul fait intervenir la fonction de hachage choisie pour la SA ISAKMP et dépend du mode d'authentification choisi. Composé de six messages, Main Mode est une instance de l'échange ISAKMP Identity Protection Exchange : -Les deux premiers messages servent à négocier les paramètres IKE : algorithme de chiffrement, fonction de hachage, méthode d'authentification des tiers et groupe pour DIFFIE-HELLMAN. Intégration ISAKMP/SSL-H.Adhami-2002/2003 66

ISAKMP Proposition Sélection 3DES SHA RSA sig DH group 2 DES MD5 Preshared Négociation des paramètres IKE 3DES SHA RSA sig DH group 2 Choix 1 Choix 2 Figure IV.26 Main Mode : exemple de premier échange Les quatre méthodes d'authentification possibles sont la signature numérique, deux formes d'authentification par chiffrement à clef publique et l'utilisation d'un secret partagé préalable. - Les deux seconds messages permettent l établissement d un secret partagé via l utilisation de l échange de valeurs publiques DIFFIE-HELLMAN. Génération des valeurs DH et d aléas Valeur publique DH Nombre aléatoire (requète CERT) Valeur publique DH Nombre aléatoire (requète CERT) Calcul du secret partagé Figure IV.27 Main Mode : second échange Le secret partagé sert à dériver des clefs de session, deux d entre elles étant utilisées pour protéger la suite des échanges avec les algorithmes de chiffrement et de hachage négociés et précédemment. - Les deux derniers messages servent à 1'authentification de des valeurs publiques. Alice Empreinte/Sig.sur l ensemble des données échangées Authentification mutuelle Bob Empreinte/Sig.sur l ensemble des données échangées Figure IV.28 Main Mode : troisième et dernier échange Aggressive Mode est une instance de 1'échange ISAKMP Aggressive Exchange : il combine les échanges décrits ci dessus pour Main Mode de façon à ramener le nombre total de messages à trois. Intégration ISAKMP/SSL-H.Adhami-2002/2003 67

ISAKMP Dans ces deux cas, la méthode choisie pour l authentification influence le contenu des messages et la méthode de génération de la clef de session. IV.6.2 Phase 2 :Quick Mode Les messages échangés durant la phase 2 sont protégés en authenticité et en confidentialité grâce aux éléments négociés durant la phase 1. L'authenticité des messages est assurée par l ajout d un bloc HASH après l en-tête ISAKMP, et la confidentialité est assurée par le chiffrement de l ensemble des blocs du message. Quick Mode est utilisé pour la négociation de SA pour des protocoles de sécurité donnés comme IPsec. Chaque négociation aboutit en fait à deux SA, une dans chaque sens de la communication. Plus précisément, les échanges composant ce mode ont le rôle suivant : Négocier un ensemble de paramètres IPsec (paquets de SA). Échanger des nombres aléatoires, utilisés pour générer une nouvelle clef qui dérive de celle de la SA ISAKMP. De façon optionnelle, il est possible d avoir recours à un nouvel échange DIFFIE-HELLMAN, afin d'accéder à la propriété de Perfect Fowrard Secrecy, qui n est pas fournie si on se contente de générer une nouvelle clef à partir de l'ancienne et des aléas. Optionnellement, identifier le trafic que ce paquet de SA protégera, au moyen de sélecteurs (blocs optionnels IDi et IDr ; en leur absence, les adresses IP des interlocuteurs sont utilisées). Les échanges composant ce mode sont les suivants : Proposal SPI 1001 ESP CAST SHA-1 SPI 1002 ESP Blowfish MD5 Choix 1 Choix 2 Hash ( DH public value) Nonce IDi, IDr Sélection SPI 1002 ESP Blowfish MD5 Hash ( DH public value) Nonce IDi, IDr Empreinte Figure IV.29 Quick Mode Ou, en terme de composition des messages par blocs : Intégration ISAKMP/SSL-H.Adhami-2002/2003 68

ISAKMP Initiator Responder HDR*, HASH, SA, NONCE [, KE] {IDi,IDr} 1 HDR*, HASH, SA, NONCE [, KE] {IDi,IDr} 2 Clef calculée, attributs de la SA négociés HDR*, HASH 3 Figure IV.30 Quick Mode : messages échangés IV.6.3 Les groupes : New Group Mode Le groupe à utiliser pour DIFFIE-HELLMAN peut être négocié, par le biais du bloc SA, soit au cours du Main Mode, soit ultérieurement par le biais du New Group Mode. Dans les deux cas, il existe deux façons de désigner le groupe à utiliser: Donner la référence d'un groupe prédéfini: il en existe actuellement quatre groupes Oakley (deux groupes MODP et deux groupes EC2N). Donner les caractéristiques du groupe souhaité: type de groupe (MODP, ECP, EC2N), nombre premier ou polynôme irréductible, générateurs... IV.6.4 Phases et modes Au final, 1e déroulement d'une négociation IKE suit le diagramme suivant: Phase 1 Négociation ISAKMP SA Début Main mode Ou Aggressive mode Nouveau tunnel Ipsec ou renouvellement des clefs Phase 2 Négociation de SA pour AH et ESP Quick mode avec PFS Ou Quick mode sans PFS Echanges de données protégés Figure IV.30 Les 2 phases d IKE Intégration ISAKMP/SSL-H.Adhami-2002/2003 69

ISAKMP IV.7 Conclusion ISAKMP pose les bases permettant de construire divers protocoles de gestion des clefs (et plus généralement des associations de sécurité). Il comporte trois aspects principaux : - Il définit une façon de procéder, en deux étapes appelées phase 1 et 2 : dans la première, un certain nombre de paramètres de sécurité propres à ISAKMP sont mis en place, afin d établir entre les deux tiers un canal protégé ; dans un second temps, ce canal est utilisé pour négocier les associations de sécurité pour les mécanismes de sécurité que l on souhaite utiliser (AH et ESP par exemple) - Il définit des formats de messages, par l intermédiaire de blocs ayant chacun un rôle précis et permettant de former des messages clairs. - Il présente un certain nombre d échanges types, composés de tels messages, qui permettent des négociations présentant des propriétés différentes : protection ou non de l identité, perfect forward secrecy, Du fait de l importance extrême de ce protocole, du point de vue gestion de clef de sécurité et son indépendance des autres protocoles, la phase restante de notre projet a été consacrée à l intégration des deux protocoles ISAKMP et SSL. Ça sera donc le sujet du dernier chapitre. Intégration ISAKMP/SSL-H.Adhami-2002/2003 70

Intégration ISAKMP/SSL Chap V Intégration ISAKMP/SSL Le présent chapitre présente les étapes de l intégration des protocoles ISAKMP et SSL menant à une implémentation du nouveau sous-protocole Handshake. Les codes SSLv3 à manipuler sont fournis par la librairie OpenSSL. Nous travaillons dans un environnement IPsec sur une machine FreeBSD 4.7, et nous nous inspirons de KAME qui est l implémentation d IPsec sur FreeBSD. Nous présentons dans un premier lieu, des exemples de manipulation de certificats SSL, les codes sources SSL, puis nous introduisons KAME et les outils associés. Notons, enfin que notre démarche s appuie sur des apports théoriques. L implémentation, en elle-même et dans les limites du temps dédié au projet et des différentes difficultés rencontrées, n a pas été réalisée. V.1 Openssl : l implémentation de référence de SSL De nombreuses offres commerciales du protocole SSL sont disponibles. Les implémentations sont en général constituées de deux modules, l'un regroupant les fonctions de cryptographie et l'autre la librairie du protocole SSL. L'une des API (Application Programming Interface - Interface de programmation d'applicatifs) les plus populaires actuellement est SSLeay : non seulement elle est distribuée gratuitement mais elle a été combinée à plusieurs applications (ftp, telnet, etc.). FreeBSD inclus un logiciel du Projet OpenSSL. Openssl, http://www.openssl.org, (historiquement SSLeay) est une suite logicielle de chiffrement essentiellement destinée aux développeurs. De très nombreux produits utilisent Openssl, aussi, ce produit fait maintenant partie de la plupart des distributions Linux et plus généralement de la plupart des paquets Unix (FreeBSD). Openssl se présente sous la forme d un ensemble impressionnant de librairie, on peut aussi utiliser la commande en ligne openssl qui permet en particulier de manipuler des certificats x509. V.1.1 Exemples des opérations de base sur des certificats avec OpenSSL L exemple ci-dessous illustre le contenu d un certificat SSL x509 (dans le fichier cert.pem) du format PEM. # /usr/bin/openssl x509 inform PEM in cert.pem text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: md5withrsaencryption Issuer: Email=ca-admin@cru.fr, CN=ca-cru, O=CRU, C=FR Validity Not Before: Apr 26 12:54:43 2001 GMT Not After : Mar 22 12:54:43 2023 GMT Subject: Email=ca-admin@cru.fr, CN=ca-rssi, O=cru, C=fr Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:f9:54:bd:4f:c4:4b:4c:cb:9c:5e:55:ab:26:76:... Intégration ISAKMP/SSL-H.Adhami-2002/2003 71

Intégration ISAKMP/SSL 08:7d:3d:2f:18:b6:18:43:b7:42:ee:00:7b:86:62: df:19 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:TRUE X509v3 Subject Key Identifier: 4E:18:88:D0:0D:1E:77:08:B1:0B:F2:F9:9F:0A:52:06:15:DB:77:65 X509v3 Authority Key Identifier: keyid:ce:e8:69:48:74:9c:42:87:18:2f:16:3e:71:94:95:57:fc:f6:e1:d3 DirName:/Email=ca-admin@cru.fr/CN=ca-cru/O=CRU/C=FR serial:00 X509v3 Key Usage: Certificate Sign, CRL Sign X509v3 CRL Distribution Points: URI:http://pki.cru.fr/cautil/ca-cert.cgi?ca=ca-cru&crl=true Netscape Revocation Url: http://pki.cru.fr/cautil/ca-cert.cgi?ca=ca-cru&crl=true Signature Algorithm: md5withrsaencryption 12:33:e3:33:a1:f1:f9:81:21:ea:cb:99:d0:25:4c:b6:64:ab:... 23:c1:00:0b:0f:3f:4f:69:b0:b9:67:6d:67:9c:9a:09:2a:50: e6:a2:ff:c5 La signification des différents champs est donnée comme suit : Version Serial number Signature Algorithm Issuer Validity Subject Subject public key info X509v3 Extensions Signature Indique à quelle version de X.509 correspond ce certificat. Numéro de série du certificat (propre à chaque autorité de certification). Type de signature utilisée. Distinguished Name (Subject) de l'autorité de certification qui a émis ce certificat. Période de validité. Distinguished Name du propriétaire de ce certificat. Infos sur la clef publique de ce certificat. Extensions génériques optionnelles, introduites avec la version 3 de X.509. Signature numérique de l'ac sur l'ensemble des champs précédents. De même l exemple ci-contre vérifie le certificat cert.pem vis à vis des autorités de certification dont les certificats sont compilés dans le fichier cabundle.pem # /usr/bin/openssl verify -CAfile cabundle.pem -purpose any cert.pem cert.pem: OK V.1.2 Code Source SSL Le code source de SSL peut être obtenu à partir de la librairie OpenSSL, un code ouvert, qu on le télécharge sur une machine FreeBSD 4.7. On a pu décortiquer ce code, et enfin extraire deux fichiers sources «bio.h» et «ssl.h» qui sont (à mon avis) les codes qu on puisse manipuler et modifier, et dans lesquels se trouvent quelques modules qui peuvent être remplacés par des modules ISAKMP (ou KAME). D ailleurs, ils contiennent la majorité des modules concernant la phase de négociation du Handshake. Ces deux fichiers sont fournis sur une disquette (à cause de leur taille) avec le rapport. V.2 KAME Intégration ISAKMP/SSL-H.Adhami-2002/2003 72

Intégration ISAKMP/SSL KAME, http://www.kame.net, un projet Japonais débuté en 1998 comme partie du Wide Consortium, constitue une implémentation de IPv6/IPsec dans les systèmes BSD. KAME procure les piles: IPv6 pour {Free, Net, Open} BSD et BSD/OS, et IPsec pour les mêmes systèmes sauf OpenBSD (qui a sa propre pile). L implémentation KAME IPsec utilisée dans FreeBSD est basée sur 2 composants : -l implémentation du protocole IPsec dans le noyau du système d exploitation, -le démon Racoon assurant l échange de clefs (IKE), et est conçu pour opérer avec IPv4 et IPv6, sachant qu il est initialement créé pour IPv6. V.2.1 Caratéristiques : Algorithmes cryptographiques Les algorithmes cryptographiques supportés sont, au moment où ce rapport est rédigé : Pour l ancient IPsec, -pour AH: null crypto checksum keyed MD5 with 128bit crypto checksum keyed SHA1 with 128bit crypto checksum HMAC MD5 with 128bit crypto checksum HMAC SHA1 with 128bit crypto checksum -pour ESP: null encryption DES-CBC mode Il peut-être utile d interopérer avec quelques implémentations. Pour le "nouveau" IPsec, les algorithmes sont: -pour AH: null crypto checksum keyed MD5 with 96bit crypto checksum keyed SHA1 with 96bit crypto checksum HMAC MD5 with 96bit crypto checksum HMAC SHA1 with 96bit crypto checksum -pour ESP: null encryption DES-CBC with derived IV DES-CBC with explicit IV 3DES-CBC with explicit IV BLOWFISH CBC CAST128 CBC RIJNDAEL CBC TWOFISH CBC Intégration ISAKMP/SSL-H.Adhami-2002/2003 73

Intégration ISAKMP/SSL AES CBC (AES est Rijndael) Il est très facile d ajouter des nouveaux algorithmes cryptographiques à la pile KAME. Pour IPComp: IP Payload Compression utilisant DEFLATE Les algorithmes suivants ne sont pas implémentés: Pour l ancient IPsec AH: HMAC MD5 with 128bit crypto checksum + 64bit replay prevention keyed SHA1 with 160bit crypto checksum + 32bit padding. V.2.2 Le démon de la gestion de clef : Racoon On a vu qu il est nécessaire d établir une association de sécurité SA pour une communication sécurisée (en IPsec par exemple) entre deux tiers communicants. Il y a deux méthodes pour cela : l une en utilisant une configuration manuelle, et l autre une configuration automatique. Dans notre implémentation, nous avons pour la deuxième méthode, un démon de gestion de clef (IKE daemon) : Racoon, qui permet de négocier et établir des SA pour IPv6 et IPv4. Racoon suit les spécifications de IKE (RFC2407 à RFC2409). La pile IPsec est directement implémentée dans le noyau du système d exploitation. L API de gestion de clef est basée sur la PF_KEY key management API. Il est compatible avec : -le DOI IPsec pour ISAKMP (RFC2407), -l Internet Security Association and Key Management Protocol (ISAKMP, RFC2408), -l Internet Key Exchange (IKE, RFC2409), et utilise la librarie de source ouverte OpenSSL pour les fonctions cryptographiques. Il peut utiliser: -les deux modes aggressive mode et main mode comme phase 1, -les secrets partagés préalables et les signatures RSA, et peut échanger des certificats X509v3 soit surligne soit d après un fichier système local. V.2.2.1 Implémentation de Racoon dans FreeBSD Racoon est implémenté dans FreeBSD avec l outil (toolkit) Racoon(8), qui fonctionne conjointement avec deux fichiers. Le premier est le fichier de configuration racoon.conf(5), le second fichier (on l appelle psk.txt) contenant les secrets pour la négociation des clefs. En outre, FreeBSD fournit un outil de commande en ligne Setkey pour configurer IPsec. Cet outil lit les Intégration ISAKMP/SSL-H.Adhami-2002/2003 74

Intégration ISAKMP/SSL paramètres soit à partir de la commande en ligne, soit à partir d un fichier donné. L Annexe B présente le manuel de l outil Racoon(8). La figure suivante montre le mécanisme de base de Racoon. Administrateur Set policy Configure Outil Setkey Racoon 5 Protocole IKE L autre bout 1 4 6 SPD 2 3 BSD kernel 7 SAD Réseau Figure V.1 Mécanisme de base de Racoon 1. L administrateur indique une politique à la SPD, utilisant setkey. 2. Le noyau (kernel) se réfère à la SPD pour décider d appliquer IPsec à un paquet. 3. Si IPsec est demandé, le noyau récupère la clef pour la SA IPsec de la SAD. 4. Si cette tentative échoue, alors le noyau envoie une requête à Racoon pour récupérer la clef. 5. Racoon échange la clef avec l autre correspondant en utilisant IKE. 6. Il charge la SAD par la clef. 7. Le noyau peut envoyer, à ce stade, un paquet sur lequel est appliqué IPsec. De cette façon, l administrateur doit configurer les entrées de la SPD, en utilisant setkey, et doit configurer Racoon. Bien entendu, il est demandé d utiliser Racoon (ou l équivalent, si un autre système d exploitation est utilisé, mais à condition que les deux soient interopérables) à l autre bout de la communication. Exemple de configuration Un exemple de configuration de Racoon dans FreeBSD, est donné ci-dessous : # cat case1.conf path pre_shared_key "/usr/local/racoon/etc/psk.txt" ; remote anonymous { exchange_mode main ; Intégration ISAKMP/SSL-H.Adhami-2002/2003 75

Intégration ISAKMP/SSL } lifetime time 24 hour ; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } sainfo anonymous { pfs_group 2; lifetime time 12 hour ; lifetime byte 50 MB ; encryption_algorithm 3des, blowfish, des, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } La directive path pre_shared_key spécifie le fichier des clefs partagées au préalable. Ceci est utilisé pour authentifier les tiers communicants durant la phase 1. La directive remote spécifie la phase 1. anonymous, signifie n importe quel pair. -exchange_mode spécifie le mode d échange durant la phase 1. -lifetime time et lifetime byte spécifie la durée de vie de la SA-IKE, en temps (sec, min, et heures) et capacité (B, KB, MB, et TB) respectivement. -proposal spécifie la proposition durant la phase 1. Plusieurs proposals peuvent être spécifiés. -encryption_algorithm spécifie l algorithme cryptographique durant cette phase. -hash_algorithm spécifie l algorithme de hachage. -authentication_method spécifie la méthode d authentification durant la phase 1. Ici la méthode de la clef partagée au préalable est utilisée. Racoon peut utiliser aussi la méthode de signature RSA. -dh_group spécifie un groupe pour l échange de clef Diffie-Hellman. De même pour la directive sainfo. Note- Ici Racoon négocie des clefs IPsec seulement. Il ne négocie pas les politiques de sécurité. Les politiques de sécurité doivent être configurées dans le noyau séparément de Racoon. V.2.2.2 Racoon, comment il fonctionne? Le fonctionnement de Racoon est donné par les organigrammes suivants pour des trafics entrants : Intégration ISAKMP/SSL-H.Adhami-2002/2003 76

Intégration ISAKMP/SSL Others ICMP UDP TCP Traitement IPsec Pas d IPsec IPsec Proto = 50, 51 ou 108 {esp,ah,ipcomp}{4,6}_input() Pour un paquet entrant (*inetsw[proto])() ip6_input() ou ip_input Retour du traitement mbuf venant de l interface réseau Figure V.2 Dans le Kernel : paquet entrant Le traitement d IPsec est illustré par l organigramme suivant: (*inetsw[proto]() 5 Enlever en-tête 4 Déchiffrement/Authentification avec les paramèters et l argorithme sélectionnés Faute déchiff./auth. jeter le paquet 3 {ah,esp}_algorithm_lookup Pas d algorithme jeter le paquet 2 Avec le SPI, trouver la SA associée SA trouvée {ah,esp}{4,6}_input() 1 Pas de SA jeter le paquet Figure V.3 Dans le boîtier : traitement IPsec pour un paquet entrant Intégration ISAKMP/SSL-H.Adhami-2002/2003 77

Intégration ISAKMP/SSL De même, pour des trafics sortants : mbuf du protocole du niveau supérieur Pour un paquet sortant ip_output ou ip6_output Traitement IPsec Paquet IP if_output Interface réseau Figure V.4 Dans le Kernel : paquet sortant De même, le traitement d IPsec est illustré par l organigramme suivant: ip6_output() ou ip_ouyput() Si policy = IPsec 1 2 ipsec6_getpolicyby{addr,sock}() ou ipsec_getpolicyby{addr,sock}() key_spdacquire() 3 Policy: DISCARD BYPASS No Ipsec IPsec ipsec6_output_{trans,tunnel}() ou ipsec_output_{trans,tunnel}() {ah,esp}{4,6}_output() 4 Router paquet Figure V.5 Dans le boîtier : traitement IPsec pour un paquet sortant Intégration ISAKMP/SSL-H.Adhami-2002/2003 78

Intégration ISAKMP/SSL V.3 Définir un nouveau Domaine d Interprétation (Domain Of Interpretation DOI) Le DOI de l Internet doit être suffisant pour rencontrer les exigences de sécurité d une large portion de la communauté de l internet. Cependant, quelques groupes peuvent avoir un besoin pour personnaliser quelques aspects du DOI, peut-être pour ajouter un ensemble différent d algorithmes cryptographiques, ou parce qu ils veulent faire leurs décisions, relatives à la sécurité, basées sur quelque chose autre que l identificateur du hôte (Host ID) ou de l utilisateur (User ID). De même, un group particulier peut avoir un besoin d un nouveau type d échange, par exemple, pour la gestion de clef pour des groupes multicast. Dans notre étude des protocoles ISAKMP et SSL et dans le but de pouvoir implémenter le nouveau protocole Handshake, on a pu être convaincu qu il faut créer un nouveau domaine d interprétation (DOI) spécifique de SSL autre que le seul standard de IPsec. Cette section discute les lignes directrices pour définir un nouveau DOI. Définir un nouveau DOI peut s avérer plutôt un processus consommateur du temps. Si possible, il est recommandé de commencer avec un DOI existant et de personnaliser seulement les parties demandées. Le créateur du nouveau DOI doit procéder par définir les items suivants : - Une situation : l ensemble des informations utilisées pour déterminer les services de sécurités exigés. - L ensemble des politiques de sécurité qui doivent être utilisées. - Un plan pour nommer les informations relatives à la sécurité, y compris les algorithmes de cryptage, les algorithmes de l échange de clef, etc. - Une syntaxe pour la spécification des services de sécurité proposés, des attributs, et des autorités de certification. - Les formats spécifiques des contenus variés de la charge utile. - Des types d échanges additionnels, s ils sont demandés. V.3.1 La Situation La situation est la base pour décider comment protéger un canal de communication. Elle doit renfermer toutes les données qui seront utilisées pour déterminer les types et les formes des protections appliquées dans une SA. Par exemple, un DOI du Département de la Défense utiliserait peut-être des algorithmes non publiés, et aurait des attributs additionnels spéciaux pour négocier. Ces attributs de sécurité additionnels seront inclus dans la situation. Intégration ISAKMP/SSL-H.Adhami-2002/2003 79

Intégration ISAKMP/SSL V.3.2 Les politiques de Sécurité Les politiques de sécurité définissent comment les différents types de l information devront être catégorisés et protégés. Le DOI doit définir l ensemble des politiques de sécurité soutenues, parce que les deux parties dans une négociation, doivent avoir confiance que l autre partie comprend la situation, et va protéger l information d une manière convenable, que ça soit en transit ou pour le stockage. Noter que, mettre les politiques de sécurité exigées dans le DOI, indique seulement que les hôtes participants comprennent et implémentent ces politiques dans le contexte d un système complet. V.3.3 Les Plans de Nomination N importe quel DOI définit une voie consistante pour nommer les algorithmes cryptographiques, les autorités de certification, etc. Habituellement, cela peut être fait en utilisant les conventions de nomination de l IANA, peut-être avec des extensions privées. V.3.4 Syntaxe pour la Spécification des Services de Sécurité En plus de spécifier simplement la manière de nommer les entités, le DOI doit aussi spécifier le format des propositions complètes de manière à protéger le trafic sous une situation donnée. V.3.5 Spécification de la Charge Utile Le DOI doit spécifier le format de chaque type de charge utile (ou bloc). Pour plusieurs types, ISAKMP a défini des champs qui devraient être présents à travers tous les DOIs (tel une autorité de certification dans le bloc Certificate, ou un identificateur d échange de clef dans le bloc Key Exchange). V.3.6 Définir des nouveaux Types d Échange Si les types d échanges principaux ne sont pas adéquats pour rencontrer les exigences dans un DOI, un créateur peut définir jusqu à 13 types d échange/doi supplémentaires. Le créateur crée un nouveau type d échange en choisissant une valeur non utilisée du type d échange, et en définissant une séquence de messages indiquant les types des blocs ISAKMP. Noter que n importe quel nouveau type d échange doit être rigoureusement analysé pour les vulnérabilités. Puisque cela est une entreprise chère et imprécise, un nouveau type d échange doit seulement être créé en cas de nécessité absolue. V.4 Nouveau protocole Handshake Dans SSL, les informations les plus importantes échangées sont les suivants (d après le canevas des échanges Handsahke) : Intégration ISAKMP/SSL-H.Adhami-2002/2003 80

Intégration ISAKMP/SSL - la version du SSL, - la suite de chiffrement et l algorithme de compression, - le Client/Server-Random, - le certificat, - et Finished qui est le hachage de tous les messages échangés dans SSL. La plupart de ces informations se trouvent dans le message Client Hello. La phase du SSL qui est vulnérable, est bien sûr la première étape (celle du Client et Server Hello), qui en analogie avec ISAKMP, constitue une partie intégrante de la phase d établissement de la SA (Association de sécurité) de base. D après tout ce qui a précédé, dans les chapitres de SSL et ISAKMP, on voit bien l analogie entre certains blocs ISAKMP et des messages du Handshake, et principalement en ce qui concerne : la suite de chiffrement, l algorithme de compression (pouvant transiter dans le bloc Proposal), Client/Server-Random (transitant dans le bloc Nonce ), et le certificat (transitant dans le bloc Certificate). D autres (appartenant à Handshake) ne transitent pas dans ISAKMP, comme la version du SSL, et le Finished. Notons encore qu il y a une analogie entre cette première étape du Handshake et certains types d échange ISAKMP (voir paragraphe IV.4.3 chapitre IV), à savoir l échange de la protection d identité ; l échange de base, dans lequel l identité IP est pas chiffrée (donc non protégée), est tout à fait identique au Handshake. L Identity Protection Exchange, constitue donc, une bonne alternative non vulnérable, de la première étape du Handshake. L architecture modulaire de SSL permet de faire évoluer certaines parties du protocole sans remettre en cause l ensemble de l édifice. Donc, pratiquement, c est le message client_hello qui va être modifié. D après ce qui précède, et en profitant de Racoon, ce dernier va remplacer le message client_hello dans les structures des messages du Handshake. Racoon va être spécifique de SSL et non pas de IPsec, il doit donc obéir aux règles de la création d un nouveau DOI (évoquées précédemment) implémenté selon les structures des échanges ISAKMP. Le diagramme de la nouvelle négociation sera comme suit : SSL Handshake DOI SSL pour ISAKMP Racoon Figure V.6 Racoon intégré dans Handshake du SSL Intégration ISAKMP/SSL-H.Adhami-2002/2003 81

Intégration ISAKMP/SSL Conclusion et motivations En créant un nouveau domaine d interprétation spécifique de SSL, et en respectant les règle de cette création, on pourra implémenter un nouveau protocole Handshake conforme à ISAKMP. Les motivations, et parsuite, les avantages de cette implémentation sont les suivants : Avant, la négociation était en clair (première étape : Client Hello) Elle sera sécurisée par la phase 1 de ISAKMP Handshake était intégré au sein de SSL La négociation deviendra indépendante Handshake était réservé à SSL ISAKMP est partagé par tous les protocoles Il y avait un seul type d échange ISAKMP présente une multitude d échanges. Intégration ISAKMP/SSL-H.Adhami-2002/2003 82

Conclusions et perspectives Conclusions et perspectives Le problème posé dès le départ avait pour but de répondre à la question essentielle posée dans le cahier de charge. La question est la suivante : «Est-ce qu on peut modifier le protocole Handshake du SSL dans ces premières étapes pour devenir invulnérable?». En d autre terme, «Est-ce qu on peut lui ajouter les fonctionnalités d un autre protocole (supposé invulnérable), même les intégrer en grande partie dans sa structure initiale?». Ce protocole invulnérable est le protocole ISAKMP. La réponse est comme suit : D après les études (théoriques) menées sur les différents protocoles, et les recherches entreprises, et en localisant les points de croisements de certains d entre eux (et surtout Handshake de SSL et ISAKMP), et puis à partir de la création d un nouveau domaine d interprétation, spécifique pour SSL et ISAKMP, on peut modéliser la structure d un nouveau protocole «Handshake élaboré» intégrant à la fois les fonctionnalités du Handshake traditionnel et celles d ISAKMP, à condition de suivre la démarche évoquée précédemment. La possibilité de négocier les algorithmes de chiffrement dans ISAKMP, et la multitude des échanges, ouvrent les perspectives d évoluer vers des algorithmes plus éprouvés. Problèmes rencontrés Durant notre travail, nous étions amenés à faire face à quelques problèmes gênant qui ont surtout rendu difficile la continuation de la partie pratique concernant l implémentation. 1- La nouveauté totale du sujet de sécurité et de l ampleur de chaque thème à part. Ainsi, il était difficile de trouver des gens capables de répondre à nos questions, et surtout que le projet était mené à distance. 2- La diversité et la grande multitude des différents sujets (algorithmes de chiffrement, protocoles de sécurité, gestion des associations de sécurité) et surtout l ambiguïté et la non standardité des méthodes suivies (concernant les DOI par exemple), et la non stabilité des différents outils et produits existant (les plateformes BSD et KAME, par exemple), a rendu le sujet très ouvert et a augmenté la charge des tâches à achever. 3- Le problème de temps pour la manipulation, seule, des codes sources et surtout celui de OpenSSL, pour enfin en extraire deux fichiers (et seulement extraire et non pas pouvoir modifier), ce qui rend difficile le pouvoir de présenter clairement le travail effectué et par suite ne reflète pas les efforts exercés. 4- Notons enfin, les problèmes techniques rencontrés et surtout en rapport avec FreeBSD et son installation, en plus de l indisponibilité précoce de quelques modules nécessaires (se rapportant à Racoon) pour notre implémentation. Intégration ISAKMP/SSL-H.Adhami-2002/2003 83

Conclusions et perspectives Perspectives La possibilité de négocier les algorithmes de chiffrement dans ISAKMP, et la multitude des échanges, ouvrent les perspectives d évoluer vers des algorithmes plus éprouvés. La suite logique de ce travail sera donc dans l implantation du nouveau protocole Handshake non vulnérable, à écrire donc le nouveau code d après les codes sources d OpenSSL et Kame, tout en essayant de mettre en relief les points suivants qui fortifient notre choix d une implémentation bien adéquate : La négociation du nouveau SSL va se passer en deux phases. La négociation peut choisir différents types d échanges. On va essayer d étendre les suites de chiffrement, donc la SPD (Security Policy Database). On va essayer de faire transiter dans le nouveau protocole, les données ne pouvant pas transiter sous ISAKMP (comme SSL version). Apports personnels A la fin de ce rapport, on peut déclarer qu on a été bien satisfait des résultats fertiles (plutôt théoriques que pratiques), reste à démarrer la spécification du nouveau protocole et le tester pour prouver sa validation, en se basant ces résultats. Cela revient peut être à plus d une raison, dont la nature attirante du projet, qui débute une vaste recherche dans ce domaine. Enfin, ce projet nous a fournit des bonnes connaissances en matières de protocoles de sécurité, dans laquelle on voit un manque d expert chez nous, et mérite bien de lui consacrer beaucoup de temps. De plus c est un domaine très important qui demande des personnes passionnées par la programmation, les réseaux, l administration et les systèmes d exploitation. Intégration ISAKMP/SSL-H.Adhami-2002/2003 84

Messages Handshake Annexe A Cet annexe reproduit les specifications de SSL pour les messages du Handshake. Main Code enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; /* type of handshake message */ uint24 length; /* # bytes in handshake message body */ select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake; Hello messages Hello request struct { } HelloRequest; Client hello struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; opaque SessionID<0..32>; uint8 CipherSuite[2]; enum { null(0), (255) } CompressionMethod; struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..216-1>; CompressionMethod compression_methods<1..28-1>; } ClientHello; Server hello struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; } ServerHello; Server certificate opaque ASN.1Cert<1..224-1>; Intégration ISAKMP/SSL-H.Adhami-2002/2003 85

Messages Handshake struct { ASN.1Cert certificate_list<1..224-1>; } Certificate; Server key exchange message enum { rsa, diffie_hellman, fortezza_dms } KeyExchangeAlgorithm; struct { opaque rsa_modulus<1..216-1>; opaque rsa_exponent<1..216-1>; } ServerRSAParams; struct { opaque dh_p<1..216-1>; opaque dh_g<1..216-1>; opaque dh_ys<1..216-1>; } ServerDHParams; struct { opaque r_s [128]; } ServerFortezzaParams; struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params; Signature signed_params; case rsa: ServerRSAParams params; Signature signed_params; case fortezza_dms: ServerFortezzaParams params; }; } ServerKeyExchange; enum { anonymous, rsa, dsa } SignatureAlgorithm; digitally-signed struct { select(signaturealgorithm) { case anonymous: struct { }; case rsa: opaque md5_hash[16]; opaque sha_hash[20]; case dsa: opaque sha_hash[20]; }; } Signature; Certificate request enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_dms(20), (255) } ClientCertificateType; opaque DistinguishedName<3..216-1>; struct { ClientCertificateType certificate_types<1..28-1>; DistinguishedName certificate_authorities<3..216-1>; } CertificateRequest; Server hello done struct { } ServerHelloDone; Client certificate Client certificates are sent using the Certificate defined above. Client key exchange message struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret; Intégration ISAKMP/SSL-H.Adhami-2002/2003 86

Messages Handshake struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; struct { opaque y_c<0..128>; opaque r_c[128]; opaque y_signature[20]; opaque wrapped_client_write_key[12]; opaque wrapped_server_write_key[12]; opaque client_write_iv[24]; opaque server_write_iv[24]; opaque master_secret_iv[24]; block-ciphered opaque encrypted_pre_master_secret[48]; } FortezzaKeys; enum { implicit, explicit } PublicValueEncoding; struct { select (PublicValueEncoding) { case implicit: struct { }; case explicit: opaque dh_yc<1..216-1>; } dh_public; } ClientDiffieHellmanPublic; struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; case fortezza_dms: FortezzaKeys; } exchange_keys; } ClientKeyExchange; Certificate verify struct { Signature signature; } CertificateVerify; Finished enum { client(0x434c4e54), server(0x53525652) } Sender; struct { opaque md5_hash[16]; opaque sha_hash[20]; } Finished; Intégration ISAKMP/SSL-H.Adhami-2002/2003 87

Racoon (8) Annexe B RACOON(8) FreeBSD System Manager's Manual November 20, 2000 NAME racoon - IKE (ISAKMP/Oakley) key management daemon SYNOPSIS racoon [-BdFv46] [-f configfile] [-l logfile] [-p isakmp-port] DESCRIPTION racoon speaks IKE (ISAKMP/Oakley) key management protocol, to establish security association with other hosts. SPD (Security Policy Database) in the kernel usually triggers to start racoon. racoon usually sends all of informational messages, warnings and error messages to syslogd(8) with the facility LOG_DAEMON, the priority LOG_INFO. Debugging messages are sent with the priority LOG_DEBUG. You should configure syslog.conf(5)appropriately to see these messages. -B Install SA(s) from the file which is specified in racoon.conf(5). -d Increase the debug level. Multiple -d will increase the debug level even more. -F Run racoon in the foreground. -f configfile. Use configfile as the configuration file instead of the default. -l logfile Use logfile as the logging file instead of syslogd(8). -p isakmp-port Listen to ISAKMP key exchange on port isakmp-port instead of the default port number, 500. -4 -v The flag causes the packet dump be more verbose, with higher debugging level. -6 Specifies the default address family for the sockets. racoon assumes the presence of kernel random number device rnd(4) at /dev/urandom. Informational messages are labeled info, and debugging messages are labeled debug. You have to configure syslog.conf(5) if you want to see them in a logging file. FILES /usr/local/v6/etc/racoon.conf default configuration file. RETURN VALUES The command exits with 0 on success, and non-zero on errors. SEE ALSO ipsec(4), racoon.conf(5), setkey(8), syslogd(8) syslog.conf(5) HISTORY The racoon command first appeared in ``YIPS'' Yokogawa IPsec implementation. Intégration ISAKMP/SSL-H.Adhami-2002/2003 88

Bibliographie et références Annexe C Glossaire Bump-in-the-stack Une implémentation est dite de type bump-in-the stack. Si elle s intercale entre deux couches de la pile de protocole (par exemple, entre PPP et le modem). La logique ainsi insérée est perçus par la couche de rang n comme étant celle de rang n 1 et réciproquement. Clef de chiffrement de clefs Clef utilisée exclusivement pour chiffrer d autres clefs, afin de les faire parvenir à interlocuteur. Une clef de chiffrement de clef a généralement une durée de vie assez longue, par opposition aux clefs qu elle sert à chiffrer. Clef de session Clef ayant une durée de vie très limitée, généralement à une session. Les clefs de session sont généralement des clefs secrètes, utilisées pour chiffrer les données transmises, et que les tiers communicants générant en début de communication. Clef maîtresse Clef servant à générer d'autres clefs. Code d'authentifcation de message (CAM) Résultat d'une fonction de hachage à sens unique à clef secrète. L'empreinte dépend à la fois des données et de la clef ; elle n est donc calculable que par les personnes connaissant la clef. Adjointe aux données sur lesquelles elle a été calculée, elle permet de vérifier leur authenticité et (authentification l intégrité). Connexion Relation logique établie entre deux entités. Chaque couche réseau fournit aux couhes supérieures un certain nombre de services dont certains sont dits sans connexion et d'autres orientés connexion. Dans un service sans connexion, chaque message est considéré comme totalement indépendant des autres et peut être envoyé à tout moment, sans procédure préalable et sans que le destinataire final soit nécessairement présent à ce moment. C est le cas par exemple de IP, qui n'offre qu'un service de type remise de datagrammes. Dans un service orienté connexion, l'initiateur de la communication doit d'abord établir un lien logique avec l entité avec laquelle il désire communiquer. Cette procédure est appelée ouverture de la connexion et implique généralement de se mettre d'accord sur un certain nombre d options. Intégration ISAKMP/SSL-H.Adhami-2002/2003 89

Bibliographie et références Cryptage, crypter Termes dérivés de l'anglais to encrypt et souvent employés incorrectement à la place de chiffrement et chiffrer. En toute rigueur, ces termes n existent pas dans la langue française. Si le "cryptage" existait, il pourrait être défini comme l'inverse du décryptage, c'est-à-dire comme l'action consistant à obtenir un texte chiffré à partir d'un texte en clair sans connaître la clef. Un exemple concert pourrait être de signer un texte choisi en reproduisant un chiffrement avec la clef privée de la victime. Mais on préfère parler dans ce cas de contre façon. Déchiffrement Action inverse du chiffrement, lorsque celui-ci est réversible : à l'aide d'un algorithme cryptographique et d'un clef, on reconstruit le texte en clair à partir du texte chiffré. Décryptement, décryptage Action qui consiste à «casser» le chiffrement d un texte de façon à retrouver le texte en clair sans connaître la clef qui permet son déchiffrement normal. Déni de Service «Impossibilité d'accès à des ressources pour des utilisateurs autorités ou introduction d un retard pour le traitement d opérations critiques. [ISO 7498-2] Empreinte (digest) Aussi appelé condensé. Chaîne de taille fixe obtenue par application d'une fonction de hachage à un ensemble de données. Fonction à sens unique Une fonction à sens unique est une fonction facile à calculer mais difficile à inverser. La cryptographie à clef publique repose sur l'utilisation de fonctions à sens unique à brèche secrète : pour qui connaît le secret (i.e. la clef privée), la fonction devient facile à inverser. ICV (Integrity Check Value) «Valeur de vérification d'intégrité». Cette valeur est calculée par l'expéditeur sur l ensemble des données à protéger. L'ICV est alors envoyée avec les données protégées. En utilisant le même algorithme, le destinataire recalcule l'icv sur les données reçues et la compare à l'icv origine. Si elles se correspondent, il en déduit que les donnés n ont pas été modifiées. Mascarade (Masquerade, spoofing) Acte de prétendre être une autre entité dans le but d'accéder aux ressources de celle-ci ; incident au cours duquel un tiers non autorisé prétend être le véritable utilisateur. Intégration ISAKMP/SSL-H.Adhami-2002/2003 90

Bibliographie et références Perfect Forward Secrecy (PFS) Propriété d'un protocole d'échange de clef selon laquelle la découverte, par un attaquant, du ou des secrets à long terme utilisés ne permet pas de retrouver les clefs de session. Rejeu Action consistant à envoyer un message intercepté précédemment, en espérant qu'il sera accepté comme valide par le destinataire. Répudiation «Le fait, pour une des entités impliquées dans la communication de nier avoir participé aux échanges, totalement ou en partie." [ISO 7498-2] Réseau privé virtuel Réseau composé par un ensemble d'hôtes et d'équipements qui utilisent des protocoles spécifiques pour sécuriser leurs communications. RFC (Request For Comment) Littéralement, «Appel à commentaires». C'est en fait un document décrivant un des aspects d'internet de façon relativement formelle (généralement, spécification d'un protocole). Ces documents sont destinés à être diffusés à grande échelle dans la communauté Internet et servent souvent de référence. On peut les trouver sur la plupart des sites FTP. Signature numérique «Données ajoutées à une unité de données, ou transformation cryptographique d'une unité de données, permettant à un destinataire de prouver la source et l'intégrité de l'unité de données et protégeant contre la contrefaçon (par le destinataire, par exemple)» [ISO 7498-2]. Une signature numérique fournit donc les services d'authentification de l'origine des données, d'intégrité des données et de non-répudiation. Ce dernier point la différencie des codes authentification de message, et a pour conséquence que la plupart des algorithmes de signature utilisent la cryptographie à clef publique. D'autre part, la signature peut prendre deux formes «transformation chiffrée»: un algorithme cryptographique modifie directement le message (par exemple chiffrement du message avec une clef privée). «données annexées» : des données supplémentaires sont adjointes au message (par exemple une empreinte, chiffrée avec une clef privée). Intégration ISAKMP/SSL-H.Adhami-2002/2003 91

Bibliographie et références Somme de contrôle Condensé d'un ensemble de données, calculé par l'expéditeur avant l'envoi des données recalculé par le destinataire à la réception pour vérifier l intégrité des données transmises. SPI ( Security Parameter Index) Bloc de 32 bits qui, associé à une adresse de destination et au nom d'un protocole de sécurité (par exemple AII ou ESP), identifie de façon unique une association de sécurité (SA). Le SPI est transporté dans chaque paquet de façon à permettre au destinataire de sélectionner la SA qui servira à traiter le paquet. Le SPI est choisi par le destinataire à la création de la SA. Tunneling Technique consistant à créer un «tunnel» entre deux points du réseau en appliquant une transformation aux paquets à une extrémité (généralement, une encapsulation dans un protocole approprié) et en les reconstituant à l'autre extrémité. Vecteur d'initialisation (Initialization Vector :IV) Bloc de texte de valeur quelconque servant à initialiser un chiffrement avec chaînage de blocs, et donc à faire en sorte que deux messages identiques donnent des cryptogrammes distincts. Intégration ISAKMP/SSL-H.Adhami-2002/2003 92

Bibliographie et références Bibliographie et Références sur Internet TCP/IP Illustrated volume 1 et 2 : Richard W. Stevens et Gary R. Wright, Addison Wesley Réseaux : A.Tanenbaum, 3 ième édition, Prentice Hall Internetworking with TCP/IP : Douglas E.Comer, 4 ième edition, Prentice Hall Réseaux et Internet : Douglas E. Comer,CampusPress Le protocole SSL SSL: Socket Secure Layer, A.Serhrouchni et M.H.Sherif, 1998 The SSL Protocol Version 3.0, Alan O. Freier, Philip Karlton, Paul C. Kocher, (Internet Draft) 1996. http://developer.netscape.com/tech/security/ssl/howitworks.html http://home.netscape.com/eng/ssl3/ssl-toc.html http://developer.netscape.com/docs/manuals/security/sslin/index.htm http://www.counterpane.com/ssl-revised.pdf Les protocoles IPsec, AH et ESP (Standards) RFC 2401 concernant l architecture de sécurité pour IP : http://www.ietf.org/rfc/rfc2401.txt RFC 2402 concernant le mode AH (authentification) : http://www.ietf.org/rfc/rfc2402.txt RFC 2406 concernant le mode ESP (chiffrement) : http://www.ietf.org/rfc/rfc2406.txt RFC 2407 concernant le DOI IPsec pour ISAKMP: http://www.ietf.org/rfc/rfc2406.txt http://www.hsc.fr/ressources/veille/ipsec/index.html.fr http://www.counterpane.com/ipsec.html Les protocoles ISAKMP et IKE (Standards) RFC 2408 concernant le protocole ISAKMP: http://www.ietf.org/rfc/rfc2408.txt RFC 2409 concernant le protocole IKE : http://www.ietf.org/rfc/rfc2409.txt Produits et plateformes Openssl: http://www.openssl.org/ FreeBSD: http://www.freebsd.org/ Intégration ISAKMP/SSL-H.Adhami-2002/2003 93

Bibliographie et références KAME: http://www.kame.net/ FreeS-WAN Project: http://www.freeswan.org/ Différents articles couvrant tous les thèmes «Introduction à la cryptographie», G.Labouret, 1999 (Cryptographie) «Certificats x509 et Infrastructure de gestion de clés», Serge Aumont, Claude Gross, Philippe Leca, Novembre 2001 «The different OpenSource Implementations of IPsec», Jean-Jacques Bernard-Gundol, 2000 (IPsec) http://www.kame.net/newsletter/20000428/, Shoichi Sakane, KAME Project (Racoon), Avril 2000 «Simple Configuration Sample of IPsec/Racoon», Shoichi Sakane, KAME Project, Sept.2001 Interoperability of IPsec/IPv6 implementations: FreeBSD/Racoon-FreeS/WAN for Linux, M.Eberle, Mai 2002 IPsec interoperability tests with respect to deployment as Last Mile security solution, Petr Holub, Fev.2002 Sites traitants de la sécurité http://www.hsc.fr/ (Hervé Schauer Consultants, site très important en matière de sécurité). http://www.cert.org http://www.securite.org http://www.guill.net Intégration ISAKMP/SSL-H.Adhami-2002/2003 94