Revision as of 10:34, 13 April 2006

Etude pratique du déploiement du multicast IPv6

Table des matières

Orientations choisies par l'IETF

Profitant de la définition du protocole IPv6, l'IAB a mis l'accent sur la nécessité d'intégrer des services de sécurité dans le protocole IP en vue de protéger le trafic IP. Le réseau IPv4 étant largement déployé, il est vite apparu intéressant de définir des mécanismes de sécurité qui soient communs à la fois à IPv4 et IPv6. Ces mécanismes sont couramment désignés par les protocoles IPsec (IP SECurity).

Le placement de mécanismes de sécurité au niveau de IP présente l'avantage d'être exploitable par bon nombre d'applications et de mécanismes (seule l'auto-configuration peut poser un problème) et d'offrir ainsi un moyen de protection unique. En particulier, IPsec peuvent servir à protéger des VPNs (Virtual Private Network) dans un contexte d'interconnexion de sites ou de connexion à distance depuis un nomade.

Toutes les implémentations IPv6 conformes doivent obligatoirement intégrer IPsec. Par contre, les protocoles IPsec sont optionnels pour IPv4 et ne sont pas fournis en standard sur la plupart des systèmes courants. Lorsqu'IPv6 sera en place, il sera donc possible à tout utilisateur désirant des fonctions de sécurité d'avoir recours à IPsec.

Dans la suite du chapitre, deux extensions IPsec sont présentées de façon détaillée ainsi que plusieurs aspects liés à la gestion de la sécurité sur les réseaux IP, c'est-à-dire la gestion des associations de sécurité et la gestion des clés publiques. Deux architectures classiques de l'utilisation d'IPsec sont décrites. Afin d'illustrer nos propos, des exemples de configuration des protocoles IPsec basés sur le système d'exploitation BSD sont proposés. Le chapitre se termine par une critique d'IPsec et une comparaison entre l'usage qu'on peut faire d'IPsec dans IPv4 et dans IPv6.

Généralités

Pour une bonne compréhension de ce chapitre, quelques notions de base de sécurité sont nécessaire. En cryptographie, deux familles d'algorithmes de chiffrement existent :

• les algorithmes à clés symétriques qui utilisent le même secret (ou clé de chiffrement) pour chiffrer et déchiffrer des données et
• les algorithmes à clés asymétriques qui sont basés sur un couple de clés privées et publiques. La clé privée ne doit être connue que d'une seule entité et la clé publique peut être largement diffusée sur le réseau. Ces clés sont complémentaires dans la mesure où le chiffrement avec l'une de ces clés nécessite le déchiffrement avec l'autre clé.

Les services de sécurité étudiés sont :

• La confidentialité des données, qui permet, grâce à des mécanismes de chiffrement, de protéger les données émises sur le réseau de telle sorte qu'elles ne soient compréhensibles que par les entités du réseau autorisées. Pour des raisons de performance, elle fait généralement appel à des algorithmes à clés symétriques. La clé utilisée pour chiffrer les paquets IP est appelée clé de session. Comme cette clé est fréquemment utilisée et comme en sécurité, plus une clé est utilisée plus elle est vulnérable, il est nécessaire de régulièrement renouveler les clés de session. Pour cela, on distingue deux niveaux de clés, les clés de session qui sont de courte durée et qui sont exploitées de façon intensive pour chiffrer les données et les clés de longue durée qui sont utilisées avec parcimonie exclusivement pour renouveler les clés de session de façon protégée.
• La confidentialité du flux de données, qui garantit qu'aucune information portant sur une communication (quantité d'informations échangées, fréquence,...) ne peut être déduite par analyse de trafic.
• L'authentification de l'origine des données, qui garantit que les données reçues proviennent de l'entité déclarée. Ce service consiste à adjoindre aux données émises un authentificateur (ICV : Integrity Check Value), terme générique pour désigner soit un code d'authentification de message (MAC : Message Authentication Code), soit une signature numérique.

Dans les deux cas, on utilise une fonction de hachage, c'est-à-dire, une fonction satisfaisant plusieurs propriétés (1), et qui, à partir d'un message de taille quelconque, retourne le condensat (ou empreinte) de ce message avec une taille de condensat fixe dépendant de la fonction de hachage. SHA-1 (Secure Hash Standard) en est un exemple avec une taille de condensat fixée à 160 bits.

• Dans le cas du MAC, l'authentificateur consiste en une suite de concaténations des données avec une clé symétrique et de calculs de condensats à l'aide d'une fonction de hachage. Ce type de MAC est appelé HMAC, et en particulier si la fonction de hachage SHA-1 est utilisée, on parle de HMAC-SHA1. Noter que seul le partenaire en possession de la clé symétrique utilisée sera capable de vérifier l'authenticité du MAC.
• L'utilisation de la cryptographie à clé publique pour produire une signature numérique est également possible. La signature est construite en chiffrant un condensat des données à l'aide de la clé privée. La cryptographie à clés publiques est avantageuse car elle offre en plus des services d'authentification et d'intégrité, le service de non répudiation (voir ci-dessous). Cependant, du fait qu'elle est gourmande en ressources, elle n'est pas utilisée en pratique pour protéger les volumineux échanges de données d'un réseau.
• L'authentification mutuelle, qui permet à deux entités de se prouver mutuellement leur identité. Ce service est généralement rendu par l'utilisation d'"échange d'authentification" qui implique un certain dialogue entre les entités.
• L'intégrité des données, qui garantit que les données reçues n'ont subi aucune modification au cours de leur transfert sur le réseau. Ce service fait lui aussi appel à des mécanismes d'authentificateur en général.
• La prévention contre le rejeu de données, qui assure que les données reçues n'ont pas été précédemment jouées, c'est-à-dire déjà reçues. Un rejeu pourrait se produire si un intrus réussissait à capturer des datagrammes et à les réémettre vers le même destinataire.
• La non répudiation, qui permet de prouver, en cas de litige, que des données ont bien été émises ou reçues par des entités.

Pour fournir ces services de sécurité, on a recours à des mécanismes cryptographiques dont la plupart nécessite de partager des clés secrètes, ce qui implique de mettre en oeuvre un protocole d'échange de clé. Il existe de nombreux protocoles d'échange de clé, qui se différencient suivant les prérequis qu'ils imposent et les propriétés qu'ils vérifient.

Parmi ces propriétés, celle dite de Perfect Forward Secrecy (PFS) est particulièrement intéressante. Elle garantit que la découverte par un adversaire d'une ou des clés de longue durée ne compromettra pas les clés de session générées précédemment. Ainsi le trafic chiffré avec ces clés de session restera confidentiel. On considère généralement que cette propriété assure également que la découverte d'une clé de session ne compromet pas les clés de longue durée.

D'autre part, on parle d'anonymat ou protection de l'identité (Identity Protection) lorsque le protocole garantit qu'aucune information sur les identités des entités en communication ne pourra être déduite des échanges effectués sur le réseau.

La plupart des protocoles d'échange de clé développés pour la protection des échanges sous IP se basent sur le protocole Diffie-Hellman. Inventé en 1976 par Diffie et Hellman, ce protocole permet à deux entités de générer un secret partagé sans partager d'information préalable. Chaque entité possède pour cela un couple (valeur publique, valeur privée) pour lequel la valeur privée ne peut être déduite de la valeur publique. Chacun envoie sa valeur publique à son interlocuteur. A l'aide de la valeur publique de son interlocuteur et de sa propre valeur privée, chaque entité calcule un secret, qui est également calculé par son interlocuteur. Le secret partagé ainsi généré peut être utilisé pour dériver une ou plusieurs clés secrètes. Une personne qui espionnerait les échanges (les valeurs publiques) sur le réseau ne pourrait pas déduire le secret partagé car cela nécessite la connaissance d'une des valeurs privées.

En revanche, Diffie-Hellman est vulnérable à l'attaque de l'intercepteur, qui consiste, pour une personne malveillante, à intercepter les échanges de valeurs publiques et à faire croire aux entités légitimes que la valeur publique de leur interlocuteur est la sienne. Ainsi, à la fin du protocole Diffie-Hellman, chaque entité partagera une clé propre avec l'intercepteur. Chaque message émis par une entité sera intercepté, déchiffré avec la clé partagée par la source et l'intercepteur, puis rechiffré avec la clé partagée par le destinataire et l'intercepteur. Les entités auront l'impression de communiquer ensemble directement de façon sûre alors que l'intercepteur pourra en fait lire tous les messages, voire même forger de faux messages. Une façon de résoudre ce problème de sécurité est d'authentifier les valeurs publiques utilisées pour la génération du secret partagé.

Analyse des risques

Par la suite, il est fait référence à un "intrus". Un intrus désigne en fait toute personne adoptant un comportement malveillant sur le réseau. Trois attaques classiques peuvent être réalisées dans un environnement de réseaux IP :

• IP sniffing : L'IP sniffing consiste pour un intrus à "écouter" le trafic en transit sur un réseau. Il peut ainsi parvenir à prendre connaissance du contenu de messages électroniques échangés sur le réseau ou des mots de passe utilisés par ses collègues.

L'IP sniffing peut être réalisé de deux façons :

• • L'intrus est placé sur un réseau permettant naturellement la diffusion de données (Token Ring ou Ethernet, par exemple). L'intrus peut alors, à partir de sa station de travail, récupérer l'ensemble du trafic en transit sur le réseau et l'analyser.
  • L'intrus réussit à utiliser un analyseur de protocoles réseau à l'insu des administrateurs du réseau. Il peut alors capturer l'ensemble du trafic en transit. Bien entendu, cette analyse est limitée au trafic échangé sur le segment de réseau sur lequel se trouve branché l'analyseur.
• IP spoofing : L'IP spoofing consiste à usurper l'identité d'une personne. Le but de cette attaque est d'établir une communication avec une station en se faisant passer pour quelqu'un d'autre ou d'insérer des données dans une communication existante. Plusieurs techniques sont utilisables :
  • La modification de l'adresse matérielle de la station de l'intrus. Ainsi, la station de l'intrus peut récupérer les données à destination d'une autre station de même adresse matérielle.
  • La création de messages ICMP de toute pièce en vue de rediriger des paquets IP vers la station de l'intrus.
  • La compromission d'un serveur de nom (DNS) peut servir à rediriger une requête DNS vers une station contrôlée par un intrus qui peut alors retourner une mauvaise adresse IP à la station initiatrice de la requête DNS.
• IP flooding : Le but de l'IP flooding est d'envoyer une multitude de paquets IP vers une même destination de telle sorte que le traitement de ces paquets empêche une entité du réseau (un routeur ou la station destinatrice) de traiter les paquets IP légitimes.

Dans le cas de l'utilisation de la pile TCP/IP, cette attaque peut prendre la forme du SYN flooding qui consiste pour une station cliente à émettre une multitude de messages SYN de demande d'ouverture de connexion TCP. Le serveur destinataire doit retourner, pour chaque message SYN reçu, un message SYN-ACK d'acquittement et conserver dans sa mémoire système l'ensemble des connexions en attente d'un message ACK d'acquittement de la part du client. Cette mémoire système étant de taille finie, l'envoi d'un grand nombre de messages SYN-ACK conduit à sa saturation et à l'impossibilité d'accepter d'autres demandes d'ouverture de connexion TCP.

La meilleure façon de réaliser cette attaque est de la combiner avec de l'IP spoofing. C'est-à-dire, un intrus envoie des messages SYN en faisant croire qu'ils proviennent d'autres stations clientes. Les messages SYN apparaissent ainsi légitimes au serveur. Cependant les stations clientes dont l'identité est usurpée sont incapables de répondre aux messages SYN-ACK.

Le serveur reste donc en attente de messages d'acquittement et si sa mémoire est pleine, il refuse toute nouvelle ouverture de connexion. Normalement, comme un temporisateur est associé à chaque connexion en attente d'un acquittement, la mémoire système est amenée à se vider progressivement, ce qui permet au serveur d'accepter de nouvelles ouvertures de connexions TCP. L'intrus peut cependant empêcher le serveur de servir ces nouvelles connexions en émettant des demandes d'ouverture de connexion TCP à un rythme plus soutenu que le temps d'expiration des temporisateurs.

Si l'IP flooding (ou SYN flooding) est combiné à l'IP spoofing, il est impossible, pour le destinataire, de connaître l'adresse source exacte des paquets IP. De ce fait, à moins que le destinataire ne limite ses échanges avec certaines stations, il lui est impossible de contrer ce type d'attaques.

(1) Une fonction de hachage se doit de satisfaire les deux propriété suivantes :

• La modification d'un seul bit d'un message aboutit à un condensat dont au moins la moitié des bits es différent ;
• A partir d'un condesat, il n'est pas possible de remonter au message correspondant.

Etude pratique du déploiement du multicast IPv6

Table des matières

Orientations choisies par l'IETF