Première partie - La genèse du standard
publicité
Le protocole « IP Security » Sommaire Introduction ............................................................................................................................... 3 Première partie - La genèse du standard .................................................................................. 5 1.1 L’histoire de la protection des données ........................................................................ 5 1.2 Le développement d’IP .................................................................................................. 6 1.2.1 Ipv4............................................................................................................................ 6 1.2.2 Ipv6............................................................................................................................ 6 1.3 Les attaques sur les réseaux IP ..................................................................................... 7 1.3.1 IP sniffing .................................................................................................................. 7 1.3.2 IP spoofing ................................................................................................................ 7 1.3.3 IP flooding ................................................................................................................. 7 1.4 Les critères de sécurité ................................................................................................... 8 1.4.1 L'authentification ....................................................................................................... 8 1.4.2 L'intégrité .................................................................................................................. 8 1.4.3 La confidentialité....................................................................................................... 8 1.4.4 La non répudiation .................................................................................................... 8 1.4.5 Le non rejeu ............................................................................................................... 8 Deuxième partie - Le standard .................................................................................................. 9 2.1 Les grands principes de la norme ................................................................................. 9 2.1.1 L'impact de la législation sur le choix des modes de sécurité ................................... 9 2.1.2 La protection « de bout en bout » ou « sur des segments du réseau » ...................... 9 2.2 Les modes de protection des communications ........................................................... 10 2.2.1 Le mode transport.................................................................................................... 10 2.2.2 Le mode tunnel ........................................................................................................ 10 2.3 Les associations de sécurité ......................................................................................... 11 2.3.1 Les caractéristiques ................................................................................................. 11 2.3.2 Les informations échangées .................................................................................... 11 2.3.3 Les bases de données SPD et SAD ......................................................................... 12 2.4 Les protocoles de sécurité ............................................................................................ 12 2.4.1 Le protocole d'authentification AH ......................................................................... 12 2.4.1.1 Les services de sécurité .................................................................................... 13 2.4.1.2 Le format de l'entête AH .................................................................................. 13 BERGEROT Stéphane 2006 1/44 Le protocole « IP Security » 2.4.1.3 Les modes de protection ................................................................................... 14 2.4.2 Le protocole de confidentialité ESP ........................................................................ 15 2.4.2.1 Les services de sécurité .................................................................................... 15 2.4.2.2 Le format de l'entête et de la queue ESP .......................................................... 15 2.4.2.3 Les modes de protection ................................................................................... 16 2.5 La gestion des clés et des associations de sécurité ..................................................... 17 2.5.1 La gestion manuelle ................................................................................................ 17 2.5.2 Le protocole IKEv1 ................................................................................................. 18 2.5.2.1 Les protocoles de gestion ISAKMP et « SKEME et Oakley » ........................ 18 2.5.2.2 Le fonctionnement d’IKEv1 ............................................................................. 18 2.5.2.3 La mise en œuvre d’IKEv1 dans une architecture IPsec .................................. 19 2.5.3 Les infrastructures à clés publiques ........................................................................ 20 2.5.3.1 Les infrastructures à certificats ........................................................................ 20 2.5.3.2 Une solution alternative : HIP .......................................................................... 20 Troisième partie - Les problématiques d'entreprise ............................................................... 21 3.1 Les architectures IPsec ................................................................................................ 21 3.1.1 L’interconnexion de réseaux privés ........................................................................ 21 3.1.2 L’extranet ................................................................................................................ 22 3.1.3 La protection d’un serveur sensible dans un intranet .............................................. 22 3.2 Les limites ...................................................................................................................... 23 3.2.1 Les Firewall ............................................................................................................. 23 3.2.2 Les systèmes de traduction d’adresse...................................................................... 23 3.2.3 Le nomadisme et les VPN ....................................................................................... 24 3.3 Les performances ......................................................................................................... 24 3.3.1 Comparaison des protocoles AH et ESP ................................................................. 24 3.3.2 Comparaison des algorithmes de chiffrement ......................................................... 26 Quatrième partie - Le bilan ..................................................................................................... 29 4.4 Les implémentations .................................................................................................... 29 4.4.1 Windows.................................................................................................................. 29 4.4.2 Linux: Frees/WAN et USAGI ................................................................................. 30 4.4.3 BSD: Kame ............................................................................................................. 30 4.4.4 Cisco IOS ................................................................................................................ 31 4.5 La critique de la norme ................................................................................................ 31 4.5.1 Le multicast ............................................................................................................. 31 4.5.2 Les systèmes de traduction d'adresses ..................................................................... 32 4.5.3 La fragmentation IP ................................................................................................. 32 4.5.4 Les autorités de certification ................................................................................... 32 4.6 Les évolutions................................................................................................................ 33 4.6.1 Les évolutions des bases SPD et SAD .................................................................... 33 4.6.2 Les évolutions des protocoles AH et ESP ............................................................... 33 4.6.3 Le protocole IKEv2 ................................................................................................. 34 Conclusion ............................................................................................................................... 35 Sigles et acronymes ................................................................................................................. 37 Glossaire .................................................................................................................................. 39 Références ................................................................................................................................ 43 BERGEROT Stéphane 2006 2/44 Le protocole « IP Security » Introduction Les systèmes informatiques permettent l'accès à une grande quantité d'informations sensibles. Le stockage électronique des informations fait l'objet de nouvelles formes d'agressions clandestines. Bien que le protocole IPv4 (Internet Protocol version 4) du niveau 3 du modèle OSI (Open System Interconnect) soit devenu la base des réseaux informatiques, il n’offre aucun service de sécurité. En 1995, un groupe de travail, l’IETF (Internet Engineering Task Force), écrit donc une norme nommée IPsec (IP Security) dont l'objet est la sécurisation d'IP. Cette norme est facultative dans la version 4 du protocole mais obligatoire dans la version 6. Dans ce document, nous verrons en première partie la genèse de la norme. D’abord nous reviendrons sur l’histoire de la protection des données et sur le développement du protocole IPv4. Puis nous énumèrerons les différentes menaces qui existent sur les réseaux IP et les services de sécurité à implémenter pour s’en protéger. En seconde partie, nous décrirons le standard. En premier lieu, nous expliquerons les grands principes de la norme. Puis, nous détaillerons les concepts fondamentaux : les modes de protection, les associations de sécurité, les protocoles de sécurité et la gestion des paramètres de communication. En troisième partie, nous nous interrogerons sur les problématiques dans les infrastructures d'entreprise. Pour débuter, nous présenterons les architectures IPsec classiques. Ensuite, nous analyserons les limites de son implémentation et mesurerons l’impact sur les performances du réseau. En dernière partie, nous établirons un bilan d'IPsec. Nous listerons les implémentations dans les différents systèmes d’exploitation avant de faire la critique de ce standard. Et enfin, nous conclurons en ouvrant sur les évolutions des protocoles. BERGEROT Stéphane 2006 3/44 Le protocole « IP Security » BERGEROT Stéphane 2006 4/44 Le protocole « IP Security » Première partie - La genèse du standard 1.1 L’histoire de la protection des données Le protocole IPsec est une extension du protocole IP. La volonté de sécurisation des protocoles de communication était déjà présente dans l'antiquité où l'on avait compris l'importance de protéger l'information. Au 10ème siècle avant Jésus Christ, les grecques utilisaient à des fins militaires une technique de chiffrement par transposition. Ils enroulaient une bande en cuir en spire autour d'un bâton puis y inscrivaient un message. Ils déroulaient ensuite la bande de cuir. Seule la personne qui possédait un bâton identique pouvait reconstituer le message. Plus tard, au 1er siècle avant Jésus Christ, César inventa une technique de chiffrement basé sur le décalage de caractères alphabétiques. Cette technique était utilisée dans les armées romaines. Même si ces techniques étaient très basiques, elles étaient efficaces car le niveau d'alphabétisation des soldats était faible. Jusqu'au 20ème siècle, de nombreuses techniques de chiffrement furent inventées comme le chiffre de Vigenère et celui de Delastelle. Durant la seconde guerre mondiale les alliés et les armées nazies se livrèrent à une véritable guerre du chiffre. La capture de la machine Enigma permit le déchiffrement des messages allemands et orienta l'issue de la guerre. Maintenant, au 21ème siècle, les données sensibles sont autant militaires que commerciales. Ces informations ont, en général, une grande valeur monétaire. Elles attirent la convoitise de nombreux criminels appelés « pirates ». Leurs techniques sont à la mesure des systèmes de protection. Il est donc indispensable d'élaborer des protocoles assez robustes et fiables pour les décourager. Même si le protocole IP fut d'abord créé pour un réseau militaire, l'écriture d'une norme portant sur sa sécurisation apparut très tard. C'est l'histoire du développement d'IP qui permet de comprendre l'établissement tardif du standard IPsec. BERGEROT Stéphane 2006 5/44 Le protocole « IP Security » 1.2 Le développement d’IP Durant la guerre froide, les américains demandent à l'ARPA (Advanced Research Projects Agency), un groupe de scientifiques chargé de concevoir des innovations technologiques pour l'armée, d'élaborer un réseau capable de résister aux frappes nucléaires. En 1969, un réseau décentralisé nommé ARPANET (Advanced Research Projects Agency NETwork) est mis en place entre quatre grands centres universitaires américains. Le protocole NCP (Network Control Protocol) est utilisé pour les communications. 1.2.1 Ipv4 NCP devient vite insuffisant: il ne permet pas le contrôle d'erreur et son mode d'adressage est limité. Alors, Bob Kahn et Vinton Cerf décident de réaliser un protocole qui répond à ces critères. C'est ainsi que TCP et IP sont créés. En 1983, TCP et IP sont adoptés comme les protocoles de communication du réseau ARPANET. D'abord conçu pour les militaires, ce réseau devient universitaire. La protection des informations n'est pas une priorité pour les scientifiques qui l'utilisent. Cependant, dans les années 1990, le réseau s'ouvre aux activités commerciales et au grand public. IP devient la base des réseaux informatiques. Utilisé pour les communications d'entreprise, il sert à véhiculer des informations parfois sensibles. Le problème de sa sécurisation se pose alors. Ainsi, en 1992, l'IETF commence l'écriture d'une norme qui doit définir des règles d'implémentation de services de sécurité. Elle se concrétise par une première RFC (Request For Comment) en 1995 et une seconde en 1998. IPv4 devient lui aussi insuffisant. Le nombre d'adresses est limité et la demande ne cesse de croître. Ainsi, une version 6 du protocole est écrite pour répondre au nouveau cahier des charges. 1.2.2 Ipv6 L'effondrement d'IPv4 était prévu pour 1994. Heureusement, des solutions comme les systèmes de traduction d'adresses ont permis de reculer la fin de la version 4. Néanmoins, en 1992, l'IETF commence l'écriture de la version 6 du protocole. Cette nouvelle version doit permettre un mode d'adressage quasi illimité, on passe d'une adresse de 32 bits à 128 bits. Afin que la migration puisse s'effectuer progressivement, la version 6 doit être compatible avec la version 4. Certains champs d'IPv4 ont disparu et sont remplacés par un système d'options. La sécurisation du protocole est intégrée, l'implémentation d'IPsec est obligatoire. L'adressage de nouveaux éléments dans les réseaux comme les équipements domotiques et de sécurité vont nécessiter le passage à IPv6. Conséquence directe, le nombre croissant de ressources interconnectées va attirer la convoitise de plus en plus de criminels. BERGEROT Stéphane 2006 6/44 Le protocole « IP Security » 1.3 Les attaques sur les réseaux IP Les systèmes informatiques ont donné naissance à une nouvelle forme de criminalité: la cybercriminalité. Elle s'appuie sur la faiblesse des réseaux. Pour IP, il existe trois types répandus de menaces. 1.3.1 IP sniffing Elle consiste en l'écoute passive du réseau. Le but est l'obtention d'informations telles que les mots de passe. Elle peut être réalisée de deux manières : - La première utilise les propriétés de diffusion de données des protocoles. Pour Ethernet, il faut que la station soit placée sur un tronçon partagé du réseau. Le trafic peut alors être récupéré puis analysé. L'autre consiste à placer un analyseur de trafic à l'insu des administrateurs. L'analyseur récupère le trafic de son segment de réseau pour être analysé. Une fois les informations collectées, les pirates ont en général besoin de mettre en œuvre des techniques tel l’IP spoofing pour s’introduire insidieusement dans le réseau. 1.3.2 IP spoofing Elle consiste à usurper l'identité d'une autre station. Le but est d'obtenir des informations ou d'insérer des données dans une communication existante. Trois techniques peuvent être utilisées : - La première vise à modifier l'adresse matérielle de la station en la remplaçant par l'adresse de la station usurpée. Les données parviennent ainsi à l'usurpateur. La seconde consiste à créer des messages ICMP (Internet Control Message Protocol) afin de rediriger les paquets IP vers l'usurpateur. La troisième nécessite de compromettre le serveur DNS afin de renvoyer de fausses adresses IP. Les stations initiatrices des requêtes DNS sont alors trompées. L’ « IP sniffing » et l’ « IP spoofing » portent essentiellement sur la confidentialité des communications. Il existe des attaques plus brutes et destructives comme l’ « IP flooding ». 1.3.3 IP flooding Elle consiste à inonder de paquets IP un équipement ou un ordinateur du réseau afin qu'il ne puisse plus traiter les paquets valides. Le protocole IP n'a donc pas été initialement conçu pour faire face à la criminalité informatique. Cependant, l’étude des services de sécurité nous aide à définir comment lutter contre cette criminalité. BERGEROT Stéphane 2006 7/44 Le protocole « IP Security » 1.4 Les critères de sécurité La sécurité des systèmes d'information repose sur des critères de sécurité. Ils doivent être implémentés pour contrer les attaques informatiques. Quatre critères sont mis en œuvre dans le protocole IPsec : L'authentification, l'intégrité, la confidentialité et la non répudiation. 1.4.1 L'authentification Elle garantit l’identité de l’expéditeur. Elle consiste à introduire soit une signature soit un code d'authentification du message. La construction de ce code est effectuée à l'aide d’une fonction de hachage qui porte sur l'identité de l'expéditeur. Les fonctions de hachage permettent de créer une empreinte unique à partir d'une information initiale. Il est quasi impossible de retrouver l'information hachée à partir de l'empreinte. 1.4.2 L'intégrité Elle assure la légitimité des données : le message reçu doit être identique au message envoyé. Comme pour l'authentification, elle utilise des fonctions de hachage. Cependant, elle ne porte pas seulement sur l'identité de l'individu ou de l'équipement mais sur la totalité du message. 1.4.3 La confidentialité Elle assure le caractère réservé d'une information. Seules les personnes admises à la connaître doivent pouvoir la lire. Le chiffrement est employé pour rendre l'information illisible par une personne ne disposant pas du secret qui permet de la déchiffrer. 1.4.4 La non répudiation Elle empêche une personne de nier une action qu’elle a effectuée. Notamment, elle ne permet pas à un expéditeur de répudier un message qu’il a envoyé. Elle passe en général par la validation de l'identité de l’expéditeur par un tiers de confiance. Ce procédé est mis en œuvre dans les infrastructures de type PKI (Public Key Infrastructure). 1.4.5 Le non rejeu Il empêche un intrus qui a capturé des paquets sur un réseau de rejouer les messages. Même si IPv4 est devenu le protocole de base longtemps sans norme définissant sa sécurisation. réseaux d’entreprise et de l’internet commercial véritable standard. Les menaces grandissantes sur IPsec obligatoire dans la version 6 du protocole IP. BERGEROT Stéphane 2006 des réseaux informatiques, il est resté Il a fallu attendre le développement des pour que l'IETF en 1992 définisse un les systèmes ont amené l'IETF à rendre 8/44 Le protocole « IP Security » Deuxième partie - Le standard 2.1 Les grands principes de la norme Lors de son étude, l'IETF n'a pas seulement pris en compte les services de sécurité à implémenter. Il a été obligé de considérer les législations de chaque pays. 2.1.1 L'impact de la législation sur le choix des modes de sécurité L'implémentation du service de confidentialité par des moyens cryptographiques est soumise à autorisation, voir interdit dans certains pays alors que les services d'authentification et d'intégrité bénéficient de législation moins stricte. En France, par exemple, les systèmes de cryptographie avec des tailles de clés supérieures à 128 bits doivent faire l'objet d'une autorisation. Ainsi, l'IETF a défini deux modes de sécurité. Le premier, nommé AH (Authentication Header), rend des services d'authentification et d'intégrité. Il permet aussi de détecter le rejeu. Il évite par conséquent l'IP spoofing. Le second nommé ESP (Encapsulating Security Payload) rend le service de confidentialité en plus des services d'authentification, d'intégrité et de détection du rejeu. Il empêche par conséquent l'IP spoofing et l'IP sniffing. Les utilisateurs peuvent donc utiliser le mode adapté à la législation de leur pays. Après avoir considérer les difficultés légales, les cas de mise en œuvre ont été étudiés. 2.1.2 La protection « de bout en bout » ou « sur des segments du réseau » Afin de permettre un maximum de flexibilité, deux cas de mise en œuvre ont été définis: « de bout en bout » et « sur des segments du réseau ». La protection « de bout en bout » s'opère entre deux stations terminales. Seuls ces équipements possèdent les informations pour traiter les paquets IPsec. Les équipements intermédiaires ne peuvent effectuer que des opérations de routage. La protection « sur des segments du réseau » intervient entre deux passerelles de sécurité. La sécurisation n'est assurée qu'entre ces deux équipements qui sont des routeurs, des firewalls ou des serveurs. Ce type de protection est mis en œuvre dans les VPN (Virtual Private BERGEROT Stéphane 2006 9/44 Le protocole « IP Security » Network) où il faut sécuriser la communication entre deux sites distants qui sont connectés via un réseau externe. En fait, il existe un troisième cas dérivé de la protection « sur des segments du réseau ». La communication est établie entre une station en général nomade et une passerelle. Le principe de mise en œuvre est identique à la protection « sur des segments du réseau ». Ces types de protections posent les bases des architectures IPsec mais ne définissent pas comment ce protocole est implémenté au niveau de la couche du modèle OSI. L'implémentation est fonction du mode de protection. 2.2 Les modes de protection des communications Les modes de protections permettent d'établir deux niveaux de sécurisation d’IPsec. Ils ont une conséquence directe sur la sécurité mais aussi sur la complexité de mise en œuvre des protocoles. 2.2.1 Le mode transport Le mode transport (figure ci-dessus) est flexible mais moins sécurisé car seule la charge utile du paquet et certains champs de l'entête IP sont protégés. Il est en général utilisé pour faire communiquer deux équipements terminaux. C'est le mode utilisé dans les communications « de bout en bout ». 2.2.2 Le mode tunnel Le mode tunnel (figure ci-dessus) est plus complexe mais plus sécurisé car il assure la protection de tous les champs du paquet IP. Il consiste à encapsuler à l'entrée d'un tunnel le paquet IP d'origine dans un nouveau paquet IP. Le paquet est décapsulé puis traité en sortie de tunnel. Avant que les données utiles soient transmises entre deux équipements IPsec, une liste de paramètres est échangée afin de définir les bases de la communication. BERGEROT Stéphane 2006 10/44 Le protocole « IP Security » 2.3 Les associations de sécurité L'association de sécurité contient les paramètres nécessaires à l'établissement d'une communication IPsec. C’est elle qui détermine le protocole et les algorithmes mis en œuvre. 2.3.1 Les caractéristiques Le standard IPsec décrit les caractéristiques de l’association de sécurité ou SA (Security Association). Elle est définie de manière unique par le triplet : un indice nommé SPI (Security Parameters Index), l'adresse du destinataire du paquet IP et le protocole de sécurité. Elle est unidirectionnelle. Il faut donc deux associations de sécurité pour une communication bidirectionnelle. Le choix de l'association de sécurité est établi à partir d'un sélecteur qui peut dépendre des paramètres suivants: adresse IP de la source, l'adresse IP de destination, l’identité de l’utilisateur, l’identité de l’équipement, les numéros de port, le numéro de protocole du niveau transport et le niveau de sensibilité des données. Même si la définition du sélecteur est relativement libre, les constructeurs utilisent majoritairement les adresses IP de destination, les numéros de protocoles et les numéros de port. Après s'être intéressé à la définition globale de l'association de sécurité, il est nécessaire d'étudier le contenu de l'association. 2.3.2 Les informations échangées Comme IPsec peut être implémenté sous deux modes de sécurité avec une certaine liberté dans les algorithmes de hachage et de chiffrement, l'association de sécurité doit définir précisément les paramètres utilisés. Dans les cas où le service d'authentification est mis en œuvre, c'est à dire lorsque le protocole utilisé est AH ou lorsque le service d'authentification d’ESP est sélectionné, l’algorithme d'authentification ainsi que les clés de chiffrement sont échangés. Dans le cas ou le service d'intégrité est mis en œuvre, c'est à dire lorsque ESP est utilisé, l’algorithme, le mode et les clés de chiffrement ainsi que les paramètres de synchronisation sont échangés. Dans tous les cas, une durée de vie de l'association de sécurité est déterminée afin d'éviter la compromission des clés de chiffrement. Le mode de protection, tunnel ou transport, est toujours transmis. Les bases conceptuelles de l'association, c'est à dire ses caractéristiques et son contenu, laissent aux constructeurs un libre choix de mise en œuvre. Cependant, l'IETF propose une implémentation composée de deux bases de données : SPD (Security Policy Database) et SAD (Security Association Database). BERGEROT Stéphane 2006 11/44 Le protocole « IP Security » 2.3.3 Les bases de données SPD et SAD Les équipements réseau qui implémentent le protocole IPsec doivent être en mesure de gérer tous les flux IP. Ils doivent pouvoir déterminer la politique de sécurité à adopter et le cas échéant l’association de sécurité à utiliser. Pour cette raison, l'IETF a défini deux bases de données. La première (exemple ci-dessus), SPD (Security Policy Database), détermine en fonction du sélecteur la politique de sécurité. Trois actions sont possibles à la réception du paquet IP: « discard », il est supprimé si le flux n'est pas permis ; « bypass IPsec », il est autorisé sans traitement IPsec ; « apply IPsec », il est autorisé mais nécessite un traitement IPsec, il faut alors consulter l'autre base. Dans l’exemple ci-dessus, tous les flux subissent un traitement IPsec. La seconde (exemple ci-dessus), SAD (Security Association Database), contient les associations de sécurité. Le sélecteur permet de retrouver les informations de protection à mettre en œuvre pour un paquet IP. L'association de sécurité définit donc les bases de la communication. Elle détermine notamment le protocole de sécurité à mettre en œuvre. 2.4 Les protocoles de sécurité Alors que le protocole AH ne fournit que les services d'authentification et d'intégrité, le protocole ESP offre en plus le service de confidentialité. Cette différence a des conséquences sur le format du protocole et sa mise en œuvre selon les modes de protection. 2.4.1 Le protocole d'authentification AH Le protocole AH (Authentication Header) est défini par la RFC 2402. Il offre les services d'authentification et d'intégrité. La confidentialité n'est pas assurée. BERGEROT Stéphane 2006 12/44 Le protocole « IP Security » 2.4.1.1 Les services de sécurité L'authentification est réalisée au moyen d'une fonction de hachage et d'une clé partagée. Elle permet à l'expéditeur de calculer une empreinte unique d’un message que seul le destinataire peut recalculer. L’empreinte est nommée « authentificateur » et l’IETF préconise de la créer à partir d’algorithmes de hachages cryptographiques comme HMAC-SHA1 ou HMAC-MD5. L'intégrité est assurée par le calcul de l'authentificateur à partir de la quasi-totalité du paquet IP. Les champs dits « modifiables » comme la classe de trafic, le nombre de sauts et l'identificateur de classe ne sont pas intégrés. Si le message est modifié, le calcul de l'authentificateur devient différent. Le message est alors considéré comme corrompu puis rejeté. 2.4.1.2 Le format de l'entête AH Le format est présenté puis détaillé ci-dessous : (En-tête suivante) (Taille de l’en-tête) suivante) (Réservé) (Indice des paramètres de sécurité) (Numéro de séquence) (Authentificateur) - Le champ « Next Header » contient l'identifiant du protocole de niveau supérieur. Par exemple, il est égal à 6 pour TCP. Le champ « Payload Lenght » indique la taille de l'entête AH. Il est mesuré sur une base de 32 bits. Le champ « reserved » est réservé pour une utilisation future. Il est actuellement mis à 0. Le champ « Security Parameter Index » est un indice qui, combiné avec le protocole AH et l'adresse du destinataire, forme l'identifiant de l'association de sécurité. Le champ « Sequence Number » est un numéro de séquence incrémenté à l'émission de chaque paquet. Son utilisation permet d'éviter le rejeu. Le champ « Authentication Data » contient le résultat de la fonction de hachage. Sa taille est variable et multiple de 32 bits. BERGEROT Stéphane 2006 13/44 Le protocole « IP Security » 2.4.1.3 Les modes de protection Dans ce premier cas (figure ci-dessus), le datagramme IPv4 doit être protégé en intégrité. Il contient du TCP mais la mise en œuvre est identique avec de l’UDP. En mode transport (figure ci-dessus), l’entête AH vient se placer entre l'entête et le champ de données du paquet IP initial. Le champ « Protocol » de l'entête IP est mis à 51 pour identifier AH et le champ « Next Header » d’AH est mis à 6 pour indiquer l’utilisation du protocole TCP au niveau supérieur. En mode tunnel (figure ci-dessus), un nouveau paquet IP est créé par la passerelle de sécurité. Le numéro de protocole du nouvel entête est 51 pour identifier AH. Le paquet initial est placé dans le champ de données du nouveau paquet. Le champ « Next Header » d’AH est mis à 4 pour indiquer IP au niveau supérieur. C’est une encapsulation d’IP. En IPv6 et en mode transport, l'extension AH vient se placer entre l'extension de routage et les options de destination. Le champ « Next Header » de AH a la valeur 60 et pointe vers les options de destination qui, elles, renvoient vers le protocole de niveau supérieur. Le mode tunnel est quasi-identique à IPv4. Seul le champ « Next Header » diffère, il est à 41 pour indiquer l'encapsulation d'un paquet IPv6. BERGEROT Stéphane 2006 14/44 Le protocole « IP Security » 2.4.2 Le protocole de confidentialité ESP Le protocole ESP (Encapsulating Security Payload) est défini par la RFC 2406. Il assure les services d'authentification, d'intégrité et de confidentialité. 2.4.2.1 Les services de sécurité L'authentification/intégrité s'effectue uniquement sur les champs ESP. Le champ des données utiles est inclus et l'authentificateur est exclu. Il existe donc une différence majeure avec AH où l'intégrité porte sur l'ensemble du paquet IP. Comme pour l'extension AH les algorithmes de hachage préconisés sont HMAC-SHA1 ou HMAC-MD5. La confidentialité est assurée par le chiffrement de la concaténation du champ de données et de la queue ESP. Des algorithmes de chiffrement obligatoires sont fixés par l'IETF et sont actuellement au nombre de trois: DES-CBC, 3DES-CBC et AES. Il est possible de ne pas chiffrer les données avec ESP mais le service de confidentialité n'est plus rendu et les services authentification/intégrité sont plus limités qu'avec AH. 2.4.2.2 Le format de l'entête et de la queue ESP Le format est présenté puis détaillé ci-dessous : (Indice des paramètres de sécurité) (Numéro de séquence) (Charge utile plus éventuellement des données de synchronisation) (Bourrage) (Lg du bourrage) (En-tête suivante) (Authentificateur) - Le champ « Security Parameter Index » est un indice qui, combiné avec le protocole ESP et l'adresse du destinataire, forme l'identifiant de l'association de sécurité. Le champ « Sequence Number » est un numéro de séquence incrémenté à l'émission de chaque paquet. Son utilisation permet d'éviter le rejeu. BERGEROT Stéphane 2006 15/44 Le protocole « IP Security » - - Le champ « ESP Payload Data » définit la charge utile. Elle contient soit le paquet IP original complet pour le mode tunnel, soit les données utiles du paquet IP original pour le mode transport. Elle peut aussi contenir des informations nécessaires à l'algorithme de chiffrement. Le champ « Padding » sont des bits de bourrage qui sont nécessaires au bon usage de certains algorithmes de chiffrement. Leur présence est optionnelle et définie par l'association de sécurité. Le champ « Pad Lenght » indique la taille en octets du bourrage. Elle est comprise entre 0 et 255. Le champ « Next Header » contient l'identifiant du protocole de niveau supérieur. Par exemple, il est égal à 6 pour TCP. Le champ « ESP Authentication Data » contient le résultat de la fonction de hachage. Sa taille est variable et multiple de 32 bits. 2.4.2.3 Les modes de protection Dans ce second cas (figure ci-dessus), le datagramme IPv4 doit être protégé en intégrité et en confidentialité. Comme dans le cas précédent, le protocole encapsulé dans le datagramme IP est TCP mais la mise en œuvre est identique avec de l’UDP. En mode transport (figure ci-dessus), l'entête ESP vient se placer entre l'entête et le champ de données du paquet IP initial. La queue ESP ainsi que l'authentificateur se placent après les données du paquet initial. Le champ « Protocol » de l'entête IP est mis à 50 pour identifier ESP. Le champ « Next Header » d’ESP est mis à 6 pour indiquer l’utilisation du protocole TCP au niveau supérieur. BERGEROT Stéphane 2006 16/44 Le protocole « IP Security » En mode tunnel (figure ci-dessus), un nouveau paquet IP est créé par la passerelle de sécurité. Le numéro de protocole du nouvel entête est 50 pour identifier ESP. Le paquet initial est placé dans le champ de données du nouveau paquet. Le champ « Next Header » d’ESP est mis à 4 pour indiquer IP au niveau supérieur. C’est une encapsulation d’IP. En IPv6 et en mode transport, l'entête de l'extension ESP vient se placer entre l'extension de routage et les options de destination. Le champ « Next Header » de la queue ESP à la valeur 60 qui pointe vers les options de destination qui, elles, renvoient vers le protocole de niveau supérieur. Le mode tunnel est identique à IPv4. Seul le champ « Next Header » diffère, il est à 41 pour indiquer l'encapsulation d'un datagramme IPv6. Donc, si AH offre un service d'intégrité plus complet, ESP est le seul à proposer le service de confidentialité. Par conséquent, le choix se porte essentiellement sur le besoin de laisser l'information lisible ou non. Les deux protocoles sont cependant similaires dans l'usage des techniques cryptographiques. Ils sont donc tous les deux concernés par la gestion des clés. 2.5 La gestion des clés et des associations de sécurité Pour l’authentification et la confidentialité, il est utilisé des clés de chiffrement définies dans les associations de sécurité. L’enregistrement des clés, comme les associations de sécurité, est effectué sur chaque équipement IPsec du réseau. Plusieurs solutions existent pour les gérer. La gestion manuelle et le protocole IKE (Internet key Exchange) dans sa version 1 sont les plus couramment utilisés. 2.5.1 La gestion manuelle La gestion manuelle consiste à paramétrer directement chaque élément. C'est-à-dire à configurer les associations de sécurité et à entrer les clés sur chaque équipement. Le principal avantage de cette solution est sa simplicité. Aucun système de gestion supplémentaire et, en général complexe, n’est nécessaire. La problématique de transmission des clés dans le réseau est éludée. En effet, les clés sont définies de manière statique et ne sont donc pas transmises à travers le réseau. BERGEROT Stéphane 2006 17/44 Le protocole « IP Security » Mais, cette solution ne convient pas aux architectures de grande taille. Le paramétrage individuel d’un grand nombre d’équipements n’est pas concevable. Chaque création ou modification des associations de sécurité et des clés nécessite un temps important et coûteux avec un risque d’erreur accru. La gestion manuelle est donc valable pour les entreprises de petite taille. Cependant, pour les autres, il faut s’orienter vers un système de gestion automatisé comme IKEv1. 2.5.2 Le protocole IKEv1 Le protocole IKEv1 (Internet key Exchange version 1) est défini par la RFC 2409. Il offre une solution globale de gestion des paramètres. Il se compose d’un protocole de gestion des associations de sécurité nommé ISAKMP (Internet Security Association and Key Management Protocol) et d’un protocole d’échange de clés « SKEME et Oakley ». 2.5.2.1 Les protocoles de gestion ISAKMP et « SKEME et Oakley » Le protocole ISAKMP est exclusivement réservé à la gestion des associations de sécurité et est indépendant de tout protocole d’échange de clés. Le protocole « SKEME et Oakley » est donc utilisé pour remplir cette fonction. Le protocole ISAKMP définit le format des paquets et les procédures pour créer, modifier et détruire les associations de sécurité. Il permet aussi l’authentification des partenaires de la SA. Comme le protocole ISAKMP n’est pas spécifique au protocole IPsec mais peut être utilisé avec d’autres protocoles de sécurité, un cadre de définition nommé DOI (Domain Of Interpretation) décrit la syntaxe des paramètres échangés par les paquets ISAKMP. Pour IPsec, le DOI est documenté par la RFC 2407. Le protocole « SKEME et Oakley » est un protocole en mode connecté. Il sert à négocier un secret partagé de type « Diffie-Hellman ». Le secret permet ensuite de créer des clés de sessions pour les paquets ISAKMP. Elles sont utilisées pour chiffrer, authentifier ou dériver d’autres clés. Les protocoles « SKEME et Oakley » et ISAKMP s’associent donc pour former un système complet de gestion des associations de sécurité. Le protocole IKEv1 définit le fonctionnement conjoint de ces deux protocoles. 2.5.2.2 Le fonctionnement d’IKEv1 Le protocole IKEv1 comporte deux phases qui aboutissent à la création d’associations de sécurité. La première phase consiste à négocier une association de sécurité propre à la mise en œuvre du protocole ISAKMP. Elle est bidirectionnelle et sert aux échanges ISAKMP futurs. Elle met en œuvre le protocole « SKEME et Oakley » pour générer des clés de sessions dont l’une sert à dériver d’autres clés. La seconde permet de négocier des associations de sécurité IPsec. Chaque négociation aboutit à deux associations symétriques de sécurité. Pour ces échanges, on utilise soit une clé dérivée soit un nouvel échange « Diffie-Hellman ». Dans le second cas, on est assuré que la compromission des clés de sessions aura des conséquences limitées. Cette technique s’appelle le PFS (Perfect Forward Secrecy) et est détaillée dans la RFC 2409. BERGEROT Stéphane 2006 18/44 Le protocole « IP Security » L’intégration d’IKEv1 dans IPsec dépasse la création d’une simple SA. Dans une architecture complète, des mécanismes supplémentaires sont mis en œuvre. 2.5.2.3 La mise en œuvre d’IKEv1 dans une architecture IPsec Les architectures IKEv1 font intervenir quatre acteurs différents : l’administrateur, les bases de données SPD/SAD, le protocole IKE et le protocole IPsec. Les messages (figure cidessous) qui circulent entre eux assurent le fonctionnement de l’architecture. La mise en œuvre IKEv1 dans une architecture IPsec débute obligatoirement par la configuration (1) des politiques de sécurité par un administrateur. C’est la base de la gestion des associations de sécurité par IKE. Lorsqu’un équipement de sécurité envoie un paquet, il consulte (2) sa base de données SPD pour connaître la politique de sécurité à appliquer. Dans le cas d’un « apply IPsec », il consulte (3) la base SAD pour rechercher l’existence d’une association de sécurité correspondante. Si elle est absente, il demande (4) la création de la SA à IKE. Ensuite le protocole IKE interroge (5) la base SPD pour vérifier la validité de la requête. Si elle est légitime il crée (6) une association de sécurité qui peut finalement être mise en œuvre (7) par l’équipement. Le protocole IKEv1 fournit donc une réponse adaptée à la problématique de gestion des clés et des associations de sécurité des entreprises de grande taille. Néanmoins, la gestion automatisée et centralisée des politiques de sécurité n’est pas définie et est à la charge des constructeurs. Aussi, ce système impose une gestion du secret initial sur les équipements de sécurité sous la forme de clés partagées préconfigurées ou à l’aide d’une infrastructure à clés publiques. BERGEROT Stéphane 2006 19/44 Le protocole « IP Security » 2.5.3 Les infrastructures à clés publiques La gestion des clés partagées préconfigurées posent des soucis d’administration dans les architectures à grande échelle. La solution est dans un système de gestion centralisé. Les infrastructures à clés publiques offrent ce service. Il existe, actuellement, une solution majoritairement utilisée nommée PKI (Public Key Infrastructure) basée sur des certificats. Mais des solutions alternatives existent comme HIP (Host Identity Protocol). 2.5.3.1 Les infrastructures à certificats Les infrastructures à certificats offrent, en plus du service de gestion de clés, un service de non répudiation des entités. Les certificats permettent d’associer à une entité une identité et une clé publique. Les entités peuvent alors signer leurs messages. Actuellement, la norme de certificats majoritairement utilisée est X509 version 3. Une autorité de certification émet ces certificats et peut, à la demande, attester de leur validité. Cette validation permet de mettre en œuvre le service de non répudiation. La gestion de ces certificats s’effectue au moyen d’une infrastructure de type PKI qui nécessite une administration attentive. En effet pour garantir la non-compromission des clés les certificats sont régulièrement, de manière automatique ou volontaire, invalidés. La gestion des certificats reste donc complexe et nécessite un groupe d’administrateurs affecté uniquement à cette mission. Pour ces raisons, des solutions plus simples sont recherchées. 2.5.3.2 Une solution alternative : HIP Le protocole HIP (Host Identity Protocol) est un protocole d’identification d’équipement. Il consiste à marquer une différence entre un identifiant d’équipement et sa localisation. Actuellement les rôles d’identifiant et de localisateur sont tenus par l’adresse IP. Avec HIP, une nouvelle propriété de l’équipement, nommée HI (Host Identifier), sert d’identifiant et l’adresse IP continue à tenir le rôle de localisateur. Pour des raisons pratiques, comme dans le cas de la mise en œuvre d’IPsec, le HI peut contenir une clé publique. Un système de publication reliant le HI et l’adresse IP est alors déployé. La solution est donc très simple. Elle est bien adaptée au protocole IPsec dont le principal problème est l’échange des clés initiales précédant les communications. La norme IPsec définit donc un système complet et interopérable entre les équipements des différents constructeurs. Avec ses deux protocoles de sécurité, ses deux modes de protection et un système de gestion automatique des paramètres de sécurité, il est adaptable au besoin des entreprises. Cependant, il comporte des lacunes, comme l’absence de définition d’un système centralisé de gestion des politiques de sécurité, qui nous amènent à penser que son implémentation en entreprise sera problématique. BERGEROT Stéphane 2006 20/44 Le protocole « IP Security » Troisième partie - Les problématiques d'entreprise 3.1 Les architectures IPsec Les actions criminelles sont croissantes sur les réseaux d’entreprise. La lutte contre les menaces informatiques a un coût financier et humain important. Il faut donc que les organismes définissent clairement leur politique de sécurité et qu’ils mettent en œuvre les dispositifs de protection à la mesure des dangers. Trois scénarios nécessitent la mise en œuvre d’une architecture IPsec : Des réseaux privés sont interconnectés via un réseau externe ; un poste nomade doit accéder au réseau d’entreprise via un réseau externe ; un serveur sensible d’un intranet doit être protégé. 3.1.1 L’interconnexion de réseaux privés Avant les années 1990, les entreprises réparties sur des sites distants payaient des lignes spécialisées pour interconnecter leurs différents réseaux. Le passage aux réseaux publics a permis de réduire leurs coûts. Cependant ces réseaux externes d’interconnexion sont rarement considérés comme fiables et nécessitent donc la protection des communications. Les tunnels IPsec (figure ci-dessus) servent à sécuriser ces liens. Une passerelle de sécurité est placée aux frontières de chaque site. Des tunnels sont alors configurés entre les passerelles de sécurité. Au niveau du routage, ces passerelles sont quasi transparentes. En effet, les stations émettent des paquets comme si elles étaient sur des réseaux privés directement connectés. Seules les passerelles connaissent le réseau externe. Cette configuration est définie sous le nom de VPN (Virtual Private Network). Pour des raisons de sécurité, le secret initial qui sert à la communication IPsec entre les passerelles est souvent inséré manuellement par les administrateurs sur chaque passerelle. Le protocole IPsec appliqué au VPN offre donc une réponse conforme au besoin en sécurité des entreprises. Si la même logique est respectée, il est possible de considérer qu’un site distant d’entreprise peut se résumer à un équipement terminal. BERGEROT Stéphane 2006 21/44 Le protocole « IP Security » 3.1.2 L’extranet La connexion d’un équipement à son réseau d’entreprise via un réseau externe diffère peu de l’interconnexion des réseaux privés. L’équipement possède simultanément les rôles de passerelle de sécurité et de station terminale. Cette architecture (figure ci-dessus) est désignée par le nom d’extranet. Elle implique de gérer autant de tunnels que d’équipements. Néanmoins, elle permet a un employé, en déplacement ou à son domicile, d’accéder à son réseau d’entreprise à travers des communications sécurisées. Les entreprises gagnent en productivité : les administrateurs en déplacement ou à leur domicile peuvent dépanner les incidents sur le réseau d’entreprise, les commerciaux peuvent présenter des plateformes de test à leurs clients, etc. L’extranet est donc une architecture d’avenir. Elle est adaptée à la mobilité et la disponibilité des employés dans l’univers des entreprises. Dans les cas de l’interconnexion des réseaux privés et de l’extranet, le protocole IPsec sert à protéger les systèmes des attaques extérieures mais il existe aussi des cas d’utilisation interne. 3.1.3 La protection d’un serveur sensible dans un intranet La majorité des attaques sur les systèmes d’information est effectuée à partir de l’intérieur du réseau. Il est donc nécessaire de protéger des pirates les communications vers les serveurs sensibles. Dans ce cas (figure ci-dessus), seul l’accès aux ordinateurs dûment autorisés est permis. Le protocole ESP avec le service de confidentialité activé est le plus fréquemment utilisé pour ce type d’architecture. En effet, il chiffre les couches des niveaux supérieurs. Il ne permet donc pas aux pirates de lire les données et d’identifier les applications utilisées. Le protocole IPsec est donc approprié à la protection des systèmes d’information contre les attaques malveillantes internes ou externes. Il répond donc à de réels besoins en sécurité des entreprises. Cependant, certaines limites empêchent son extension. BERGEROT Stéphane 2006 22/44 Le protocole « IP Security » 3.2 Les limites La construction du standard IPsec a débuté durant la période où les réseaux informatiques étaient en pleine mutation. Certaines contraintes n’ont pas été considérées. 3.2.1 Les Firewall Le Firewall, ou pare-feu, filtre les flux de données en fonction de règles préconfigurées. Les paquets ESP qui sont codés ne peuvent pas être contrôlés par le pare-feu. Ils échappent donc à la politique de sécurité. La solution consiste à décoder les trames avant leur analyse par le pare-feu. Les trames peuvent alors être contrôlées mais le service de confidentialité n’est plus assuré. Les pare-feux traversés par des paquets IPsec doivent être configurés pour gérer les entêtes AH et ESP, c'est-à-dire supporter les numéros de port 50 et 51. Ils doivent permettre, si nécessaire, l’utilisation d’IKE et donc gérer le port UDP 500. La mise en œuvre des pare-feux implique donc un choix de sécurité. Il faut prioriser soit le service de confidentialité soit le service de filtrage. Les pare-feux ne sont pas les seuls équipements de sécurité dont la traversée est problématique. Le passage des systèmes de traduction d’adresses n’est pas sans difficultés. 3.2.2 Les systèmes de traduction d’adresse Le système de traduction d’adresses ou NAT (Network Address Translation) est une réponse apportée au problème de limitation du nombre d’adresses en IPv4. Ils permettent de réduire le nombre d’utilisation d’adresses publiques. Avant le NAT, chaque ordinateur qui accédait à Internet devait disposer d’une adresse publique. Les systèmes de traduction d’adresses ont permis d’utiliser une adresse publique pour plusieurs adresses privés. Une table contient les associations d’adresses publiques avec les adresses privées. Les enregistrements dans la table sont définis temporairement et les adresses publiques sont réutilisées. Lors de la traduction, l’adresse privée source d’un paquet IP et, parfois le port source, sont remplacés par une adresse publique et un nouveau port du NAT. Le paquet initial est donc significativement modifié. Dans le cas d’utilisation du protocole AH, le contrôle d’intégrité réalisé par le destinataire produira une erreur. En effet, le champ source est inclus dans le calcul de l’authentificateur et comme il est modifié, la fonction de hachage produit un résultat différent. Dans le cas d’utilisation du protocole ESP en mode transport avec les protocoles UDP ou TCP au niveau supérieur, le passage du NAT nécessite une modification du champ contrôle qui conduit à une erreur d’intégrité ou à une corruption du code chiffré. En effet, les protocoles TCP ou UDP effectuent un calcul de contrôle d’erreurs qui intègre les adresses IP. Pour que le destinataire ne détecte pas d’erreur, le système de traduction d’adresse recalcule un CRC (Cyclical Redundancy Check). Comme les données utiles du paquet sont protégées en intégrité ou en confidentialité, toute modification entraîne une détection d’erreur par la couche IPsec et donc un rejet du paquet. BERGEROT Stéphane 2006 23/44 Le protocole « IP Security » Une solution existe. Elle consiste à réaliser une encapsulation d’ESP dans un tunnel UDP. Le système de translation effectue l’encapsulation que si un paquet ESP arrive à l’entrée du tunnel IPsec. Donc, seuls les systèmes de traduction d’adresses qui implémentent l’encapsulation UDP supportent le passage d’IPsec avec ESP. 3.2.3 Le nomadisme et les VPN La conception de VPN (Virtual Private Network) qui intègre des équipements nomades dépend fortement du besoin de l’entreprise. Deux types de VPN sont communément utilisés : IPsec et SSL. Le nomadisme IPsec impose de configurer le poste client. Il ne permet donc pas d’utiliser un simple ordinateur connecté à internet comme une station dans un cybercafé. Cependant, IPsec est de niveau 3 et offre donc une protection complète des couches de niveau supérieur. Les VPN SSL fournissent des services plus limités mais plus souples. Aucune configuration particulière n’est nécessaire sur le client et un navigateur web suffit. L’application doit s’exécuter au dessus de HTTP (HyperText Transfer Protocol). Les difficultés de traduction d’adresse et de filtrage sont éludées. La protection IPsec est donc plus complète mais plus complexe à mettre en œuvre que des solutions telles que SSL. Le protocole SSL répond à des besoins applicatifs spécifiques alors que le protocole IPsec offre une protection de toutes les couches supérieures à 3. Le protocole IPsec permet donc de construire des VPN fiables. Il faut cependant rester conscient de ses limites actuelles. Il faut auditer l’impact de son déploiement sur les systèmes et les réseaux et, notamment, considérer le problème des performances. 3.3 Les performances Comme il opère au niveau de la couche 3, son implémentation dans la pile réseau reste simple. Mais, les algorithmes de hachages et de cryptages sont coûteux en ressources systèmes. Des mesures de performances réalisées par l’ISOC (Internet SOCiety) et l’Université de Columbia nous permettent d’apprécier l’impact du déploiement d’IPsec. 3.3.1 Comparaison des protocoles AH et ESP Les premières évaluations sont réalisées par l’ISOC au moyen de l’outil Netperf. Elles établissent des mesures de bandes passantes en Mbps. Elles permettent d’évaluer l’impact du choix du protocole de sécurité. BERGEROT Stéphane 2006 24/44 Le protocole « IP Security » Le schéma de la plateforme de test est détaillé à la figure ci-dessous : Les stations sont des Pentium II 450 MHz avec une mémoire de 128 MB. La carte réseau est une carte Ethernet 100 Mbps. Le système d’exploitation est un FreeBSD 2.2.8. Les routeurs sont des Pentium III 500 MHz avec une mémoire de 256 MB. Les interfaces réseaux sont des interfaces Ethernet 100 Mbps. Le système d’exploitation est un FreeBSD 2.2.8 avec Kame 19990908-stable. Deux flux « TCP_STREAM.1 » et « TCP_STREAM.2 » sont étudiés. Le MTU est identique et égal à 4096 octets. La taille du tampon TCP est de 57344 octets pour « TCP_STREAM.1 » et 32769 octets pour « TCP_STREAM.2 ». L’algorithme utilisé pour l’authentification est HMAC-SHA1 160 bits et l’algorithme utilisé pour la confidentialité est 3DES-CBC 192bits. Les résultats des évaluations sont présentés ci-dessous: IPv4 IPv6 L’utilisation du protocole AH dégrade les performances TCP d’environ deux tiers. Avec ESP, elles sont diminuées d’environ cinq sixièmes. La mise en œuvre conjointe de ESP et AH entraîne une baisse légère par rapport à ESP seul. La version d’IP et la taille du tampon n’ont pas d’incidences significatives sur les performances. Des mesures effectuées de manière assez similaire avec UDP donnent une diminution de deux tiers avec AH mais huit neuvième avec ESP. Les performances sont donc divisées au minimum par trois pour AH et par six pour ESP. Par conséquent, l’architecture IPsec doit faire l’objet d’une définition précise et adaptée du besoin. L’étude doit être réalisée au cas par cas et, si nécessaire, par segment du réseau. Aussi, l’algorithme de chiffrement est un choix décisif dans le déploiement d’IPsec. BERGEROT Stéphane 2006 25/44 Le protocole « IP Security » 3.3.2 Comparaison des algorithmes de chiffrement Les évaluations suivantes sont réalisées par l'université de Columbia. Elles établissent des mesures de bandes passantes en Mbps. Elles permettent d’apprécier les conséquences du choix de l’algorithme de chiffrement. Le schéma de la plateforme est identique au schéma précédent. Les liens sont en Ethernet gigabit. Les stations et les routeurs sont des Pentium III. Les interfaces sont toutes des interfaces Ethernet gigabit. Le système d’exploitation est OpenBSD 3.0. Les interfaces de chiffrement ont un seuil maximum de 300 Mbps. Les résultats des évaluations sont présentés ci-dessous: En fonction de l’algorithme et de ta technologie utilisée, les performances diminuent du quart au neuvième pour les paquets excédant 1024 octets. Pour les paquets plus petits, le ratio est plus bas, c’est-à-dire inférieur à deux. Les technologies matérielles ont des performances d’environ deux fois supérieures aux technologies logicielles. Les technologies matérielles présentées sont basées sur DES (Data Encryption Standard). Elles nous montrent que 3DES-HW équivaut à DES-HW pour une qualité de protection supérieure. Les technologies logicielles présentées sont basées sur DES et son successeur AES (Advanced Encryption Standard). AES est deux fois plus performant que 3DES quelque soit la taille de la clé. Il existe aujourd’hui des cartes matérielles AES-HW. Leurs performances en 256 bits sont légèrement supérieures à celles des 3DES-HW en 128 bits. Le chiffrement a donc un coût très fort pour les communications. Il faut privilégier les technologies matérielles pour réduire la baisse de performance. Par contre, il est peu utile d’économiser sur les tailles de clés pour AES vu les faibles différences. BERGEROT Stéphane 2006 26/44 Le protocole « IP Security » La mise en place d’une infrastructure IPsec nécessite donc un véritable travail d’ingénierie. Un audit doit être réalisé. Les services de sécurité nécessaires et suffisants doivent être clairement définis dans le cahier des charges. Pour l’extranet, il faut étudier la concurrence comme les VPN SSL. Les coûts et les performances doivent être considérés sérieusement. L’investissement dans des interfaces à chiffrement matériel limite la diminution du débit. Il permet ainsi d’économiser sur les coûts des liens. L’étude doit nous amener au choix d’implémentation le plus conforme du besoin de l’entreprise. BERGEROT Stéphane 2006 27/44 Le protocole « IP Security » BERGEROT Stéphane 2006 28/44 Le protocole « IP Security » Quatrième partie - Le bilan 4.4 Les implémentations Tous les principaux systèmes d’exploitation proposent une version de la norme. Il est nécessaire d’analyser leurs caractéristiques pour déterminer celle qui est la plus appropriée à son entreprise. 4.4.1 Windows Les infrastructures Windows sont les plus répandues. Avec le système d’exploitation « Windows Server 2003 », elles offrent un ensemble complet de services IPsec. Les systèmes de traduction d’adresses peuvent être traversés grâce à l’encapsulation dans UDP et la mise en œuvre du service « NAT-Traversal ». Un gestionnaire de connexions assure l’authentification au moyen de clés partagées. Il peut aussi effectuer leur distribution. Un gestionnaire de certificats est intégré au système d’exploitation et peut être déployé pour assurer la gestion des clés. Un groupe « Diffie-Hellman » avec un échange de clés de 2048 bits renforce IKE. Un outil sécurisé en ligne de commande nommé « NetSh » permet la configuration des serveurs IPsec. Une console sert de moniteur. Elle présente la configuration détaillée de la stratégie IPsec et des informations sur l’état de sécurité actif. Afin d’être conforme à la norme FIPS (Federal Information Processing Standard), le système comprend un module de cryptage en mode noyau. Les algorithmes de cryptage SHA-1, DES et 3DES sont implémentés. La multinationale Microsoft a donc clairement misé sur le développement d’IPsec. En plus de proposer une solution conforme au standard, elle fournit des outils complémentaires de gestion et de surveillance. Le monde libre propose aussi des solutions comme « FreesWan » et « USAGI » pour Linux. BERGEROT Stéphane 2006 29/44 Le protocole « IP Security » 4.4.2 Linux: Frees/WAN et USAGI Le développement des piles IPsec pour Linux a débuté par le projet « FreesWan » pour la pile IPv4. Le projet « USAGI » s’inscrit dans la continuité. Il consiste à implémenter la norme IPsec dans la pile IPv6. Le projet « FreesWan » se compose d’une partie noyau IPsec nommé KLIPS (KerneL IP Security) et d’un service IKE nommé « Pluto ». Une extension appelée « Opportunistic Encryption » basée sur des informations DNS (Domain Name System) permet de créer dynamiquement un tunnel au moyen de clés RSA sans configuration initiale. Les groupes « Diffie-Hellman » 2 de 1024 bits et 5 de 1536 bits sont implémentés. L’algorithme de chiffrement 3DES est défini par défaut. L’algorithme simple DES est présent pour permettre 3DES mais ne peut pas être utilisé pour son inefficacité. Les algorithmes d’authentification sont HMAC-MD5 et HMAC-SHA. La compression est possible grâce au module IPComp (IP Payload Compression). Le projet « FreesWan » n’est pas totalement conforme à la norme. D’abord, il ne permet pas d’utiliser simple DES et le groupe 1 de 768 bits de « Diffie-Hellman » car ils ne sont plus considérés comme fiables. Aussi, le mode agressif pour l’échange de clés ISAKMP SA est non présent car il permet à un intrus qui observe le réseau d’accéder à trop d’information. Le projet « USAGI » assure la continuité du projet « FreesWan » pour la pile IPv6. Le service « pluto » est repris. Mais, contrairement à KLIPS, les protocoles IPsec sont directement intégrés dans la pile IPv6 du noyau. Le traitement des paquets IPsec est donc optimisé. L’algorithme AES est ajouté pour assurer la continuité des algorithmes de chiffrement. Depuis la version 2.6 du kernel Linux, le protocole IPsec est complètement intégré au noyau. Il n’est plus nécessaire de le recompiler ou d’ajouter des patches. La communauté Linux a donc comme l’éditeur Microsoft décidé de suivre la norme IPsec. Les développeurs du noyau veulent rester proactifs et préparent notamment l’implémentation d’ IKEv2. 4.4.3 BSD: Kame Les systèmes BSD (Berkeley Software Distribution) sont la référence dans le domaine de la sécurité informatique. L’implémentation d’IPsec dans IPv6 est le résultat du projet « Kame ». Il s’inscrit dans la philosophie BSD qui impose une conformité des RFC et un code optimisé. Il est conforme aux RFC : 240[1-9] (AH, ESP, IKE); 2393 (IPComp); 2410 (null encryption); 2451 (TripleDES, Blowfish, RC5, CAST128); 2085 (HMAC-MD5); 1852 (HMAC-SHA-1). Il permet l’utilisation d’une grande diversité d’algorithmes. Pour ESP, les algorithmes de chiffrement sont DES-CBC, 3DES-CBC, simple, Blowfish-CBC, CAST128-CBC, DESDERIV, 3DES-DERIV et Rijndael-CBC. Pour AH, les algorithmes de hachage/chiffrement sont HMAC-MD5, HMAC-SHA-1, Keyed-MD5, Keyed-SHA1, HMAC-SHA2-256, HMACSHA2-384 et HMAC-SHA2-512. BERGEROT Stéphane 2006 30/44 Le protocole « IP Security » Les échanges de clés peuvent s’effectuer au moyen de clés partagées, de signatures RSA (Rivest Shamir Adleman) ou de certificats. En fonction des distributions, le service utilisé est soit « Racoon » soit ISAKMPD. Un outil sécurisé en ligne de commande nommé « setkey » permet la configuration des serveurs BSD. Contrairement à « FreesWan », le mode agressif et le groupe 1 « Diffie-Hellman » sont implémentés pour respecter la norme. Le projet « Kame » a donc été développé dans le respect des normes. Il est aussi l’implémentation IPsec la plus performante. Par conséquent, il respecte la philosophie BSD et son esprit sécuritaire. 4.4.4 Cisco IOS Cisco est le leader mondial d’équipements réseaux pour les entreprises. Le système d’exploitation de ses routeurs, Cisco IOS (Internet Operating System) 12.2, fournit une implémentation d’IPsec très proche de la norme. Il respecte les RFC 2401 à 2411 qui définissent le standard de 1998. Les algorithmes sont DES ou 3DES pour la confidentialité et HMAC avec MD5 ou SHA1 pour l’authentification. Il implémente le service de non rejeu. Le protocole IKE est présent. Il utilise des clés partagées, des signatures RSA ou des certificats numériques. Il peut aussi utiliser l’authentification RADIUS. Une CLI (Command Line Interface) qui utilise SSH (Secure Shell) permet de configurer les équipements. Le système d’exploitation Cisco IOS a peu à envier aux systèmes d’exploitation logiciels. De plus, il respecte la norme et présente l’avantage de fournir une solution matérielle fiable. Les systèmes Windows, Linux, BSD et Cisco offrent donc des solutions différentes mais assez proches du standard. Cependant, elles souffrent de maux communs inhérents à la norme. 4.5 La critique de la norme La norme IPsec a posé les bases de la sécurisation du protocole IP. Aujourd’hui, elle est implémentée dans les principaux systèmes d’exploitation. Il est donc nécessaire d’analyser les lacunes de sa conception pour mieux envisager les solutions. 4.5.1 Le multicast Le multicast est conçu pour la diffusion au sein d’un groupe. Il permet d’optimiser le trafic et est efficace dans de nombreux domaines de communication : la distribution de logiciels, la téléconférence, l’enseignement à distance, la radio, la télévision, les jeux multimédias et les applications militaires. BERGEROT Stéphane 2006 31/44 Le protocole « IP Security » Or, la protection des communications multicast est impossible. Les protocoles AH et ESP supporte bien le multicast. Mais, le gestionnaire d’association de sécurité IKE permet de négocier des SA qu’entre deux équipements. Il faut donc attendre les prochaines versions du standard qui prendront en compte les associations de sécurité multiple pour une source. 4.5.2 Les systèmes de traduction d'adresses Les systèmes de traduction d’adresses vont peut être disparaître avec IPv6. Cependant, ils offrent la possibilité de masquer les adresses privées et donc de protéger l’identité des expéditeurs. Pour permettre la traversé des NAT par les paquets IPsec, deux techniques conjointes ont été élaborées : l’encapsulation UDP et le « NAT-Traversal ». Ces techniques sont en cours de validation par l’IETF sous forme la forme de RFC. Le problème de la traduction d’adresse est donc bientôt résolu. Il faudra cependant attendre la généralisation de leur implémentation. 4.5.3 La fragmentation IP La mise en œuvre d’une infrastructure IPsec réduit les performances d’un réseau. La fragmentation IP est un facteur aggravant. Effectivement, les paquets IPsec doivent être réassemblés pour être authentifiés ou déchiffrés. L’opération de réassemblage vient augmenter la latence causée par les opérations de hachage et de déchiffrement. Aussi, les mécanismes de réassemblage fonctionnent avec des buffers. En période de forte charge, des paquets sont perdus. Les paquets IPsec sont alors acheminés avec un retard accru. La fragmentation IP peut donc nuire aux infrastructures IPsec. Une solution est de l’empêcher. On peut par exemple placer le flag « Don’t Fragment » du paquet IP à 1. 4.5.4 Les autorités de certification Le certificat est la solution pratique au problème de gestion des clés. Cependant, il n’existe pas actuellement une autorité centrale de certification. Par conséquent, les entreprises continuent à garder leurs propres autorités de certification et ne peuvent pas communiquer sans des configurations supplémentaires. En effet, elles doivent autoriser les certificats étrangers pour assurer les communications sécurisées extérieures. La résolution de ce problème n’est pas dans la technique mais dans une entente entre les autorités de certification. Le protocole IPsec est encore jeune et possède des lacunes. Mais, les maux dont il souffre n’ont rien d’insolubles. Le « NAT-Traversal » en est la preuve. Les constructeurs font évoluer la norme et les nouvelles RFC permettent de construire les nouvelles versions des protocoles. BERGEROT Stéphane 2006 32/44 Le protocole « IP Security » 4.6 Les évolutions Le protocole IPsec a été conçu de manière très conceptuelle. Aujourd’hui, il doit se rapprocher du besoin des entreprises. Il doit devenir plus simple et plus efficace. 4.6.1 Les évolutions des bases SPD et SAD Les évolutions des bases SPD et SAD ne sont pas fondamentales. Elles portent essentiellement sur la base SPD et anticipe les besoins futurs. Dans la prochaine version, la base SPD se divise en trois bases : - SPD-S enregistre les flux IPsec ; SPD-O enregistre les flux sortants qui ne nécessitent pas de protection ou qui sont interdits ; SPD-I enregistre les flux entrants qui ne nécessitent pas de protection ou qui sont interdits. Une nouvelle base PAD (Peer Authorization Database) permet de lier IKE à SPD. Des sélecteurs définis sur des plages d’adresses sont possibles. Ces évolutions vont permettre l’optimisation du traitement des paquets par les équipements de sécurité. Les évolutions des protocoles AH et ESP vont dans le même sens. 4.6.2 Les évolutions des protocoles AH et ESP Les évolutions des protocoles IPsec suivent l’évolution des réseaux ainsi que des systèmes de chiffrement. Elles visent à améliorer le traitement des paquets sécurisés et à offrir plus de choix d’algorithme. Le multicast est intégré à la norme IPsec. L’identification des associations de sécurité multicast est fixée par la valeur du SPI, l’adresse de destination et optionnellement l’adresse source. Le « NAT-Traversal » qui permet de gérer l’encapsulation dans UDP est spécifié dans les futures RFC. La liste des algorithmes obligatoires est tenue dans des documents indépendants, régulièrement mis à jour. Cette liste doit augmenter. Des algorithmes dits « combinés » qui chiffrent et protègent en intégrité sont inclus. Dans le protocole ESP actuel, les champs protégés en intégrité ne sont pas identiques aux champs chiffrés. Il faut donc, pour utiliser ces algorithmes, que certains champs soient répétés dans les données chiffrées. Dans les communications à très haut débits, la taille de 32 bits du numéro de séquence oblige à renouveler trop rapidement l’association de sécurité. La prochaine version d’AH prévoit la possibilité de négocier une taille de 64 bits. Afin d’éviter les attaques statistiques sur ESP, des données aléatoires de bourrage sont insérées. Les flux ESP sont identifiés en trois catégories : confidentialité, authentification ou authentification/intégrité. Le traitement des paquets peut donc être optimisé. BERGEROT Stéphane 2006 33/44 Le protocole « IP Security » Les prochaines versions d’AH et ESP fournissent des réponses aux problèmes d’implémentation comme le NAT et le multicast. La division des flux et l’augmentation du numéro de séquence suit l’évolution des réseaux à hauts débits. Aussi, l’optimisation d’IPsec passe obligatoirement par l’optimisation du gestionnaire d’association de sécurité IKE. 4.6.3 Le protocole IKEv2 Les évolutions du gestionnaire d’associations de sécurité et de clés IKE vont dans le sens de la simplification et de l’efficacité. Contrairement à IKEv1 qui avait un caractère générique, IKEv2 est spécifique à IPsec. La notion de domaine d’interprétation est ainsi supprimée. La négociation des deux phases passe de six messages à quatre. IKEv2 reste identique à IKEv1 en ce qui concerne l’établissement des associations de sécurité et la gestion des clés. Les futures versions des protocoles IPsec sont donc orientées vers les besoins des entreprises. Elles sont plus simples à mettre en œuvre et permettent d’optimiser le traitement des paquets par les équipements de sécurité. Un plus grand choix dans les algorithmes permet de trouver la solution adaptée qui concilie la sécurité et la performance. BERGEROT Stéphane 2006 34/44 Le protocole « IP Security » Conclusion Les développements des réseaux publics et de l’internet ont révélé les faiblesses d’IP et notamment le manque de sécurité. Pour répondre aux besoins des entreprises, l’IETF normalise le protocole IPsec en 1995. Cependant, la norme ne prend pas en compte tous les paramètres comme par exemples le NAT et les Firewall. Le protocole IPsec est néanmoins adapté à la sécurisation d’architecture particulière comme les VPN. Il se développe donc au sein des entreprises. Son extension motive les constructeurs et les fournisseurs de logiciels à améliorer la norme et des solutions comme le « NATTraversal » sont trouvées. L’avenir du protocole est assuré. Les solutions sont inscrites dans des RFC et les membres de l’IETF préparent leur implémentation dans les futures versions. Deux critères deviennent essentiels au développement du standard : la simplification et l’optimisation. Le protocole IPsec va donc devenir un acteur important de la sécurité des infrastructures informatiques. Comme les améliorations vont dans le sens des entreprises, il va s’étendre dans l’univers des réseaux. La volonté des constructeurs et des fournisseurs de logiciels à apporter toujours plus de services à leurs clients va aussi favoriser son développement. Par conséquent, dans les années avenir, il va certainement devenir le principal protocole de sécurité. Mais, parallèlement à son développement, il faut impérativement répondre à la problématique de gestion des clés. Et si l’avenir est dans les infrastructures à clés publiques, les autorités de certifications doivent s’accorder pour fournir un système fiable et universel. BERGEROT Stéphane 2006 35/44 Le protocole « IP Security » BERGEROT Stéphane 2006 36/44 Le protocole « IP Security » Sigles et acronymes 3DES Triple DES AH Authentication Header CAM Code d'Authentification de Message CBC Cipher Block Chaining DES Data Encryption Standard DOI Domain Of Interpretation ESP Encapsulating Security Payload HMAC a MAC mechanism based on cryptographic Hash functions ICMP Internet Control Message Protocol ICV Integrity Check Value IETF Internet Engineering Task Force IKE Internet Key Exchange IP Internet Protocol IPng IP new generation IPsec IP security protocol IPv4 IP version 4 IPv6 IP version 6 ISAKMP Internet Security Association and Key Management Protocol ISO International Standardization Organization MAC Message Authentication Code MDn Message Digest n OSI Open Systems Interconnection PFS Perfect Forward Secrecy RCn Rivest's Code n BERGEROT Stéphane 2006 37/44 Le protocole « IP Security » RFC Request For Comments RSA Rivest, Shamir, Adleman SA Security Association SAD Security Association Database SHA Secure Hash Algorithm SKEME a Versatile Secure Key Exchange Mechanism for Internet SPD Security Policy Database SPI Security Parameter Index SSH Secure SHell SSL Secure Socket Layer TCP Transmission Control Protocol UDP User Datagram Protocol VPN Virtual Private Network BERGEROT Stéphane 2006 38/44 Le protocole « IP Security » Glossaire 3DES (Triple Data Encryption Standard) Algorithme de chiffrement, défini par le NIST en 1999 pour pallier à la faiblesse de DES, apparue à cause de l'augmentation constante de la puissance de calcul des ordinateurs. C'est un chiffrement par bloc qui utilise trois fois de suite le DES. Comme celui-ci a une longueur de clé de 56 bits, 3DES utilise des clés de 168 bits, sur des blocs de 64 bits. Il a été remplacé officiellement par AES. AES (Advanced Encryption Standard). Algorithme de chiffrement commandé et utilisé par le gouvernement américain. C'est une variante du chiffre par blocs Rijndael [signalé par Philippe Gentric], et qui doit être fiable jusque 2015-2020. AH (Authentication Header). En-tête d'authentification, dans IP Sec. Algorithme cryptographique. Procédé ou fonction mathématique utilisée pour le chiffrement et le déchiffrement. Dans la cryptographie moderne, l'algorithme est souvent public et le secret du chiffre dépend d'un paramètre appelé clef. ARPA (Advanced Research Projects Agency). Organisme américain remplacé par le DARPA, qui a soutenu énormément de projets informatiques historiques, en particulier l'ARPANET, ancêtre de l'Internet. ARPANET (Advanced Research Projects Agency NETwork). Réseau ayant été mis en place en 1969, à commutation de paquets point à point, dépendant du DARPA américain, et qui a donné l'Internet. Blowfish. Algorithme cryptographique conçu par Bruce Schneier en 1993, chiffrant les données par blocs de 64 bits, avec une clé allant de 32 à 448 bits. Il est rapide et simple, et surtout, il est dans le domaine public. Très analysé, il est considéré comme solide. BSD (Berkeley Software Distribution). L'université de Berkeley est connue dans le monde Unix pour les nombreux logiciels qu'elle a développé puis mis dans le domaine public, principalement en réaction contre les tarifs exorbitants pratiqués par AT&T. BSD désigne en particulier une famille de versions d'Unix issue de l'université de Berkeley en Californie, conçue pour le VAX de DEC et le PDP-11, qui a été ensuite portée sur les PC sous le nom 386BSD, puis de FreeBSD. D'autres implémentations existent, voir NetBSD, OpenBSD. Pendant longtemps, Berkeley et sa version de Unix furent à la pointe du milieu, avec l'introduction de nombreuses nouvelles fonctionnalités (e.g. vi, le C-shell...) et beaucoup de grands constructeurs ont basé leur propre version sur celui-ci. BERGEROT Stéphane 2006 39/44 Le protocole « IP Security » CAST128 Algorithme de chiffrement. Certificat. Document électronique qui renferme la clef publique d'une entité, ainsi qu'un certain nombre d'informations la concernant, comme son identité. Ce document est signé par une autorité de certification ayant vérifié les informations qu'il contient. Chiffrement. Procédé grâce auquel on peut rendre la compréhension d'un document impossible à toute personne qui n'a pas la clef d'encodage. Les méthodes les plus connues sont le DES et le RSA. Un système de chiffrement est dit « Symétrique » quand il utilise des clés privées. Il est « Asymétrique » quand il utilise aussi des clés publiques. Clef. Paramètre d'un algorithme de chiffrement ou de déchiffrement, sur lequel repose le secret. CRC (Cyclical Redundancy Check). Méthode de correction d'erreur, consistant à générer un code à partir des données à contrôler que l'on divise par un nombre fixé d'avance. Il tient compte de la position des éléments, contrairement à la simple somme de contrôle. Il est utilisé aussi bien pour l'écriture sur une mémoire de masse qu'en transmissions, le receveur le recalculant et le comparant à celui de l’émetteur. Cryptographie. Discipline incluant les principes, moyens et méthodes de transformation des données, dans le but de cacher leur contenu, d'empêcher que leur modification passe inaperçue et/ou d'empêcher leur utilisation non autorisée. DARPA (Defense Advanced Research Project Agency). particulièrement concerné par les recherches en informatique. Département du DoD DES (Data Encryption Standard). Outil officiel de cryptographie du gouvernement américain, mis au point par IBM dans les années 1970, considéré actuellement comme non fiable. Diffie-Hellman Algorithme d'échange de clés de chiffrement à clé publique. DNS (Domain Name System). Service essentiel de l'Internet assurant la conversion des noms de domaine (e.g. www.linux-france.org) en adresse IP (e.g. 212.208.53.35). ESP(Encapsulating Security Payload). Protocole IPsec. Protocole IPsec qui encrypte toutes les données du paquet garantissant leur confidentialité. Empreinte. Chaîne de taille fixe obtenue par application d'une fonction de hachage à un ensemble de données. FIPS (Federal Information Processing Standard). Standards édictés par le NIST (Nationale Institute of Standards and Technologie), organisme américain. Firewall Barrière permettant d'isoler un ordinateur d'un réseau. Pour éviter le piratage. Fonction de hachage. Fonction qui convertit une chaîne de longueur quelconque en une chaîne de taille inférieure et généralement fixe ; cette chaîne est appelée empreinte (digest en anglais) ou condensé de la chaîne initiale. HMAC (Keyed-Hashing Message Authentication). Méthode d'authentification des messages définie dans la RFC 2104, utilisant des hachages cryptographiques, comme MD5 ou SHA-1. BERGEROT Stéphane 2006 40/44 Le protocole « IP Security » HTTP (HyperText Transfer Protocol). Protocole de transmission dédié aux clients et aux serveurs du web. IETF (Internet Engineering Task Force). Organisation dépendant de l'IAB et préparant les principaux standards de l'Internet. L'IETF compte plus d'une centaine de groupes de travail, qui œuvrent dans tous les domaines concernant le réseau. IPComp (IP payload compression). Protocole qui permet de compresser un paquet avant de le chiffrer avec ESP. IPsec (Internet Protocol SECurity). Ensemble de protocoles définis par l'IETF visant à permettre l'échange sécurisé de paquets au niveau de la couche IP. Basé sur des clés publiques, il fonctionne selon deux modes possibles : « Transport » et « Tunnel ». Dans le premier cas, seule la charge utile des paquets est chiffrée, dans l'autre l'en-tête est lui aussi protégé. IPv4 (Internet Protocol version 4). Version d'IP sur laquelle l'Internet s'est développé massivement dans les années 1990. Les années 2000 devraient voir le déploiement d'IPv6. IPv6 (Internet Protocol version 6).Aussi IPng, pour « New Generation ». Internet Protocol version 6. Nouvelle version d'IP qui devrait permettre de dépasser la limite des 4 milliards d'adresses. ISOC (Internet SOCiety). Organisme fondé en janvier 1992 et rattaché à l'IAB, chargé de promulguer les standards de l'Internet au niveau mondial. KLIPS (KerneL IP Security).Projet FreeS/WAN. Code noyau pour IPsec. MD5 (Message Digest 5). Fonction définie dans la RFC 1321. Il s'agit d'un hachage unidirectionnel, permettant d'identifier un message, car deux messages produiront deux hachages différents, et il est impossible de retrouver le message à partir de son hachage. NAT (Network Address Translation). Méthode de traduction d'adresse IP non routables en adresses routables et réciproquement, et qui permet de connecter de nombreuses machines au réseau en n'utilisant qu'un minimum d'adresses officielles. Surtout utilisé dans les routeurs et les firewalls. NCP (Network Control Protocol). Protocole utilisé sur l'Internet, avant la mise au point de TCP/IP, c'est-à-dire de 1970 à 1982. OSI (Open System Interconnect). Norme de réseau. Modèle en couches fournissant un cadre conceptuel et normatif aux échanges entre systèmes hétérogènes. Le modèle OSI comporte 7 couches (ici de bas en haut) : 1. Physique, 2. Liaison de données, 3. Réseau, 4. Transport, 5. Session, 6. Présentation, 7. Application. Paquet. C’est une suite de données binaires ne pouvant pas dépasser une longueur fixée. Il est obtenu en découpant un message en plusieurs segments et en ajoutant à chaque segment un en-tête contenant un certain nombre d'informations utiles à l'acheminement de ce paquet sur le réseau (options, destinataire...). PKI (Public Key Infrastructure). Ensemble de techniques, organisations, procédures et pratiques qui définissent l'implémentation et l'exploitation de certificat numériques basés sur BERGEROT Stéphane 2006 41/44 Le protocole « IP Security » la cryptographie à clés publiques RC5 (Rivest Cypher 5). Algorithme de chiffrement à clé secrète. Répudiation. Le fait, pour une des entités impliquées dans la communication, de nier avoir participé aux échanges, totalement ou en partie. Rejeu. Action consistant à envoyer un message intercepté précédemment, en espérant qu'il sera accepté comme valide par le destinataire. 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. Rijndael Algorithme de chiffrement par bloc conçu par Joan Daemen et Vincent Rijmen, avec à l'esprit une implémentation matérielle. La longueur des blocs et des clés est variable. RSA (Rivest Shamir Adleman). Algorithme de chiffrement à double clef dont une publique, qui rend donc aussi possible l'authentification des documents, l'identification de leurs auteurs et le scellement. SHA-1 (Secure Hash Algorithm). Algorithme de hachage qui produit une sortie de 20 octets SSL (Secure Socket Layer). Sockets sécurisées utilisées principalement par Netscape à l'origine, puis reconnues par l'ISOC. TCP/IP (Transmission Control Protocol / Internet Protocol). Les deux protocoles de communication qui forment les fondements de l'Internet, spécifiés dans la RFC 793. VPN (Virtual Private Network). Réseau privé virtuel. Dans le cadre de la sécurité des échanges, réseau composé par un ensemble d'hôtes et d'équipements qui utilisent des protocoles spécifiques pour sécuriser leurs communications. BERGEROT Stéphane 2006 42/44 Le protocole « IP Security » Références Les références historiques Histoire de la cryptologie : URL « http://fr.wikipedia.org/wiki/Histoire_de_la_cryptographie », Mots clés « histoire, cryptographie ». Histoire IP : Auteurs « Émilia Robin, David Madore, Marie-Lan Nguyen », URL « http://www.tuteurs.ens.fr/internet/histoire.html », Mots clés « histoire, ip ». La norme IPv6 - Théorique et pratique 4ème édition : Auteur « CIZAULT Gisèle », Chapitre 12 « Securité », p.241-282, O'REILLY, 2005. The TCP/IP Guide Version 3.0 : Auteur « KOZIEROCK Charles », p.449-474, NO STARCH PRESS, 2005 URL « http://www.tcpipguide.com/ », Chapitre « IP Security (IPSec) Protocols ». IPsec : Auteur « BRIEUC Jeunhomme », URL « http://www.frameip.com/ipsec/ », Mots clés « ipsec ». IP Security Protocol (ipsec) : URL « http://www.ietf.org/html.charters/OLD/ipsec-charter.html », Mots clés « ipsec, ietf ». IPsec : présentation technique : Auteur « LABOURET Ghislaine », URL « http://www.hsc.fr/ressources/articles/ipsec-tech/index.html.fr#11 », Mots clés « ipsec ». Les RFC : URL « http://www.ietf.org/rfc.html », Mots clés « RFC … 240[1-9] (AH, ESP, IKE); 2393 (IPComp); 2410 (null encryption); 2451 (TripleDES, Blowfish, RC5, CAST128); 2085 (HMAC-MD5); 1852 (HMAC-SHA-1) ». BERGEROT Stéphane 2006 43/44 Le protocole « IP Security » Les performances Performance Evaluation of Data Transmission Using IPSec over IPv6 Networks : Auteurs « ARIGA Seiji, NAGAHASHI Kengo, MINAMI Masaki, ESAKI Hiroshi, MURAI Jun », URL « http://www.isoc.org/inet2000/cdproceedings/1i/1i_1.htm », Mots clés « evaluation, ipsec, isoc ». A Study of the Relative Costs of Network Security Protocols : Auteurs « MILTCHEV Stefan, IOANNIDIS Sotiris ,KEROMYTIS Angelos », URL « http://www1.cs.columbia.edu/~angelos/Papers/ipsecspeed.pdf », Mots clés « evaluation, ipsec, columbia ». Les implémentations Guide de découverte technique de la famille Microsoft Windows Server 2003 : Auteur « Joachim GOMARD », Mots clés « Windows, IPsec ». USAGI Project - Linux IPv6 Development Project : URL « http://www.linux-ipv6.org/ », Mots clés « USAGI, Project ». IPSec and IPv6:the KAME snapshot for FreeBSD : URL « http://www.eurescom.de/~public-web-deliverables/P1100series/P1113/D1/41_ipsec_bsd.html », Mots clés « freebsd, ipsec, kame, ipv6 ». Linux FreeS/WAN Compatibility Guide : URL « http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/compat.html », Mots clés « freeswan ». IPSec VPN Services Module : URL « http://www.cisco.com/en/US/products/ps6635/products_ios_protocol_group_home .html », Mots clés « cisco, ipsec ». BERGEROT Stéphane 2006 44/44
