Intégration de ISAKMP au sein du protocole SSL

Transcription

1 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

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

3 III Les mécanismes AH et ESP III La notion d association de sécurité III La gestion des clefs et des associations de sécurité III Politique de sécurité III.1.2 Principe de fonctionnement III.1.3 Types d utilisations possibles III Équipement fournissant IPsec III Modes de fonctionnement III.2 Les mécanismes de sécurité : AH et ESP III.2.1 Authentification Header (AH) III.2.2 Encapsulating Security Payload (ESP) III.3 La gestion des clefs III.3.1 Les protocoles d authentification mutuelle avec échange de clef pour IP III SKIP III Photuris III SKEME III Oakley III La gestion des clefs pour IPsec : ISAKMP ET IKE III.4 Conclusion Chap IV ISAKMP IV.1 Placement D ISAKMP 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 IV.3.1 Format de l en-tête ISAKMP (ISAKMP Header Payload) IV.3.2 Generic Header Payload ou charge utile de l En-tête Générique IV.3.3 Attributs de données IV.3.4 Indépendance vis-à-vis du protocole de gestion des clefs: la construction des messages par blocs IV Bloc Security Association IV Le bloc PROPOSAL IV Bloc TRANSFORM IV Bloc Key Exchange IV Les autres blocs IV.4 Interopérabilité et ligne directrice: les types d'échanges IV.4.1 Etablissement de l Association de Sécurité IV Exemples de l Etablissement de l Association de Sécurité IV Modification de l Association de Sécurité IV.4.2 Les types d échanges IV.5 IPsec DOI IV.6 IKE IV.6.1 Main Mode et Agressive Mode IV.6.2 Phase 2 :Quick Mode IV.6.3 Les groupes : New Group Mode IV.6.4 Phases et modes IV.7 Conclusion Chap V Intégration ISAKMP/SSL V.1 Openssl : l implémentation de référence de SSL V.1.1 Exemples des opérations de base sur des certificats avec OpenSSL V.1.2 Code Source SSL V.2 KAME V.2.1 Caratéristiques : Algorithmes cryptographiques V.2.2 Le démon de la gestion de clef : Racoon Intégration ISAKMP/SSL-H.Adhami-2002/2003 3

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

5 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

6 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

7 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

8 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

9 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

10 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 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/

11 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/

12 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 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/

13 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/

14 Introduction à la cryptographie I 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 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/

15 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/

16 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/

17 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/

18 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/

19 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/

20 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/