L’administration d’un réseau virtuel passe aussi et surtout par une parfaite maîtrise de la sécurité. Sur Internet, SSL a la cote. Utilisé pour chiffrer et authentifier les sessions de connexions, le protocole Secure Socket Layer (SSL) s’est imposé dans nombre d’applications de commerce électronique telles que le service bancaire. Cependant, SSL montre ses limites, dès lors qu’il ne s’agit plus seulement de protéger les échanges applicatifs, mais de sécuriser l’intégralité du trafic réseau. Il s’efface alors devant un autre mécanisme de sécurisation, IPSec (IP security), à la destinée duquel veille un groupe de travail de l’IETF.
Bien qu’immature, IPSec passe du stade de la spécification théorique à celui de l’implémentation concrète dans les matériels réseaux et dans les systèmes d’exploitation.
Une suite protocolaire complexe
Avec cet ensemble de protocoles, la problématique de la sécurisation du trafic Internet descend de la couche session à la couche de transport, puisque c’est le trafic IP (IP v. 4 et IP v. 6) qui est sujet à protection. IPSec intervient, en effet, au niveau du datagramme IP.
La cible d’un mécanisme de protection si intime est donc toute trouvée : la protection des réseaux virtuels et, plus précisément, des canaux d’échanges de données privés reliant les n?”uds – host, routeurs et coupe-feu – des réseaux virtuels. IPSec est un édifice complexe. D’abord, à cause des architectures auxquelles il peut conduire – il peut être implémenté selon deux modes : Transport ou Tunnel – ; ensuite, à cause des services (authentification, chiffrement, intégrité des données et administration des clés de cryptage) qu’il recouvre.
Dans ses grandes lignes, il s’agit d’une suite protocolaire d’authentification, de chiffrement et d’administration. IPSec s’appuie principalement sur deux protocoles : AH, pour l’authentification des trames ; et ESP (Encapsulating security payload), pour l’encryptage des données, ce dernier s’appuyant sur des algorithmes d’encryptage symétriques et asymétriques. Ces deux protocoles sont complétés d’un troisième : ISAKMP (Internet security association and key management protocol) dont la finalité est, notamment, de négocier les paramètres de sécurisation des sessions IPSec. Dans le jargon de l’IETF, on parle de définition d’associations de sécurité. IPSec comporte également des mécanismes d’audit des erreurs de validation des datagrammes ainsi que des mécanismes de gestion de clés de chiffrement. AH et ESP sont utilisables indépendamment l’un de l’autre ou de façon conjointe. La mise en ?”uvre de ces deux protocoles amène à intercaler des en-têtes de trame spécifiques entre les en-têtes IP et TCP des datagrammes.
Six champs d’information pour l’en-tête AH
Pour que les matériels réseaux compatibles avec IPSec puissent identifier la présence de tels en-têtes de sécurité, il faut qu’un drapeau, au sein des en-têtes IP, puisse en signaler la présence. Dans IP v. 6, le rôle du champ identifiant la nature de l’en-tête suivant l’en-tête IP sera de notifier la présence d’un en-tête AH (valeur du champ Next header mise à 51) ou ESP (valeur mise à 50). L’en-tête AH se compose, quant à lui, de six champs d’information : Next header ; Payload length (longueur de l’en-tête AH) ; Reserved, pour des usages futurs ; Security parameters index (SPI), destiné à identifier le datagramme ; Sequence number (numéro de séquence) ; et, enfin, Integrity check value (ICV), d’une longueur de 64 bits, pour le contrôle d’intégrité du paquet. Le compteur Sequence number est d’une importance primordiale pour gérer les sessions IPSec. Initialisé à zéro lors de l’établissement d’une session sécurisée, il sera incrémenté par pas de 1 à chaque émission de datagrammes. En autorisant de bloquer la réception des paquets à numéro de séquence préalablement transmis, il contribue à limiter les risques d’attaques par rejet de trames ou de crypto-analyse du trafic.
Garantir l’authenticité et l’intégrité du corps des datagrammes
D’une longueur de 32 bits, ce champ introduit cependant une limite (232) au nombre de datagrammes pouvant être échangés lors d’une session. Au-delà de cette limite – pour le moins élevée -, la session doit donc être réinitialisée. Le mécanisme d’authentification proposé par AH s’appuie sur le champ ICV. Son objectif est de garantir l’authenticité et l’intégrité du corps des datagrammes. Pour calculer le code d’authentification ICV, AH combine des fonctions de hachage (appliquées par l’émetteur d’un datagramme à certains champs des en-têtes IP, AH et TCP) avec des algorithmes de chiffrement symétriques ou asymétriques.
Du côté du destinataire, l’ICV théorique sera recalculé sur la base des contenus des en-têtes des datagrammes réceptionnés, puis comparé à l’ICV, tel que réellement transmis. Toute divergence entre les deux valeurs de l’ICV conduira à un rejet du datagramme. ESP, quant à lui, a pour vocation de garantir la confidentialité des corps de datagrammes.
Comme AH, l’en-tête ESP implémente un compteur de séquences. ESP est, par ailleurs, en mesure d’utiliser différents algorithmes de chiffrement à clé symétrique. Il gère, notamment, une variante de triple DES (Data encryption standard).
Mais, pour que les protagonistes d’une session IPSec puissent échanger des clés de chiffrement-déchiffrement de données, encore faut-il qu’ils aient pu, auparavant, initialiser la communication et définir les paramètres de la session. C’est la raison d’être d’un troisième mécanisme, le protocole d’administration ISAKMP. Ce dernier fournit un mécanisme d’échanges d’informations de configuration, de type Request-Reply, permettant d’initialiser les sessions IPSec. Reste que les transactions ISAKMP nécessitent au préalable l’ouverture de canaux de communication sécurisés. De plus, la charge de générer les clés certifiées utilisées par les mécanismes d’authentification et de décryptage IPSec ne revient pas directement à ISAKMP. Il lui faut donc, à son tour, s’appuyer sur un quatrième protocole, IKE (Internet key exchange), qui négocie l’ensemble des paramètres nécessaires au bon déroulement des transactions ISAKMP.
IKE va procéder en deux phases pour initialiser une session IPSec. D’abord, il intervient pour établir des canaux de communication sécurisés et certifiés. Pour cela, il peut mettre en ?”uvre un mécanisme de chiffrement asymétrique nécessitant l’échange de clés publiques. Ensuite, IKE négocie les paramètres de sécurisation des sessions IPSec, avec définition d’une security association, et génère les clés de chiffrement symétriques utilisées après cela pour les échanges transactionnels ISAKMP, ESP et/ou AH. Pour assurer ces fonctions, IKE se doit de gérer différents algorithmes de hachage, de chiffrements symétriques (DES et triple DES) et de mécanismes d’authentification certifiés à clé publique de type RSA.
ne immaturité qui freine l’interopérabilité
IPSec doit maintenant franchir le fossé qui sépare la théorie de la réalité commerciale. Certains éditeurs, à commencer par Hi/fn et son outil IPSecure, se sont spécialisés dans les kits de développement destinés à enfouir des fonctionnalités IPSec au sein des matériels réseaux. Tous les éditeurs de systèmes d’exploitation se préoccupent d’intégrer IPSec dans leurs services TCP-IP.
Néanmoins, comme toute technologie émergente, IPSec aura à souffrir des défauts d’interopérabilité que connaîtront les premières générations d’équipements compatibles avec ce standard. D’aucuns commencent à s’intéresser à la mise en place des procédures de tests de conformité des matériels avec les standards IPSec.
Ainsi les laboratoires de l’ICSA.net entretiennent-ils une liste de matériels certifiés par leurs soins, sur la base d’un banc de test qui leur est propre, IPSec Product Certification. Symptomatique de l’immaturité de la technologie IPSec, ce banc de test, aujourd’hui en version 1.1, reste incomplet. Il teste, pour l’essentiel, la qualité de la gestion des protocoles IKE et ESP en mode Tunnel pour des équipements IP v. 4 uniquement.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
