Le mécanisme SEND possède plusieurs limitations, tout d’abord au niveau des algo- rithmes cryptographiques employés. Ensuite, ce mécanisme n’est pas mature d’un point de vue standardisation et comporte du coup certaines lacunes dans ses spécifications.
2.4.1 Limitations cryptographiques
Les spécifications du mécanisme SEND ne permettent d’utiliser uniquement que 2 algo- rithmes cryptographiques : SHA-1 [iost02] et RSA [RSA78]. Tout d’abord, cette contrainte va à l’encontre de certaines réglementations nationales ou politiques au sein d’entreprises. De plus, le niveau de sécurité du mécanisme SEND s’en trouve affaibli. Enfin, cela ralentit le déploiement du mécanisme SEND dans certains environnements.
Aspects réglementaires
Certains pays ou sociétés réglementent l’utilisation des algorithmes cryptographiques. C’est le cas par exemple en Russie, où l’algorithme GOST R 34.11-94 [Dol10] doit être obligatoirement utilisé comme fonction de hachage. Aussi, les spécifications de DNSSEC ont été modifiées [DCU10] afin d’autoriser l’utilisation d’un tel algorithme. En l’état actuel, le mécanisme SEND ne pourrait être utilisé en Russie à moins d’une modification de ses spécifications autorisant des algorithmes alternatifs, comme GOST.
2.4. Limitations de SEND
Figure 2.12 – Message NDP sécurisé avec SEND
Figure 2.13 – Format du message CPS
Niveau de sécurité de SHA-1
Les dernières cryptanalyses rendues publiques concernant SHA-1 indiquent que cette fonction de hachage risque de ne plus être sûre dans un proche futur car il sera aisé de gé- nérer des collisions. Cela impactera l’utilisation des adresses CGA : pour une adresse CGA donnée, et donc une paire de clés publique/privée RSA spécifique, grâce à une collision, il sera possible de générer la même adresse CGA avec une paire de clés publique/privée RSA différente.
Aussi, il est nécessaire que les mécanismes utilisant les adresses CGA, comme le méca- nisme SEND, tiennent parfaitement compte de la clé publique ayant servi à la génération d’une adresse CGA, qui est fournie dans les CGA Parameters. En effet, en plus de trouver une collision, l’attaquant devra utiliser la même paire de clés RSA que sa victime et donc avoir réussi à la casser pour usurper l’adresse CGA.
Maintenant, l’alternative la plus sûre, pour éviter des collisions, est de permettre l’em- ploi de la prochaine génération de fonction de hachage dans les spécifications des adresses CGA et du mécanisme SEND : SHA-33.
Coût de l’emploi de RSA
L’algorithme à clé publique RSA est connu pour être coûteux aux niveaux ressources et temps de calcul (i.e., contraintes au niveau du processeur et de la consommation éner- gétique). Ainsi, cet algorithme n’est pas réellement adapté pour certains nœuds IPv6.
Tout d’abord, cela est le cas pour les nœuds à faibles capacités, comme les terminaux mobiles ou les capteurs. Malheureusement, les spécifications actuelles des adresses CGA n’autorisent pas l’usage d’algorithmes alternatifs comme ceux basés sur les courbes ellip- tiques, Elliptic Curve Cryptography (ECC), malgré la publication d’articles [CBL10] ou de propositions de standards à l’IETF [SXZ11].
C’est aussi le cas avec les routeurs, dont la tâche prioritaire est de router le plus rapidement les paquets : les ressources doivent être utilisées le moins possible pour d’autres tâches (e.g., effectuer des calculs cryptographiques lourds). Nous avons proposé à l’IETF une méthode [XKH+08] permettant d’utiliser la cryptographie symétrique, à la place de celle asymétrique, entre un nœud IPv6 et un routeur pour le mécanisme SEND. Dans cette méthode, le nœud IPv6 réclame au routeur une clé secrète partagée grâce à un message
Figure 2.14 – Format du message CPA
Figure 2.15 – Format de l’option Trust Anchor
RS sécurisé avec le mécanisme SEND (i.e., le message RS est signé avec la clé publique associée à l’adresse CGA du nœud). Le routeur lui répond avec un message RA sécurisé avec le mécanisme SEND et incluant la clé secrète partagée qui est chiffrée avec la clé publique associée à l’adresse CGA du nœud. Par la suite, tous les échanges NDP entre ce nœud IPv6 et le routeur seront sécurisés grâce à cette clé secrète partagée.
2.4.2 Faiblesses dans les spécifications
Le mécanisme SEND souffre aussi de faiblesses dans ses spécifications pouvant engen- drer des failles de sécurité ou alors empêcher son utilisation.
Attaque par rejeu
La première faiblesse du mécanisme SEND concerne une faille de sécurité, que nous avons publiée [CC08], autorisant une attaque par rejeu lors d’une procédure DAD (cf. Section1.4.2) même si elle est sécurisée grâce à ce mécanisme.
Pour rappel, lors d’une telle procédure, un nœud IPv6 s’informe avec un message NS si l’adresse IPv6 qu’il va s’assigner n’est pas déjà utilisée par un autre nœud. Dans le cas où il recevrait un message NS comportant la même adresse IPv6, et indiquant qu’un autre nœud applique une procédure DAD pour la même adresse IPv6, aucun de ces deux nœuds ne pourrait l’utiliser. Avec le mécanisme SEND, le nœud peut regénérer une adresse CGA en incrémentant le compteur Collision Count (cf. Section1.2.4) et retenter la procédure DAD pour cette nouvelle adresse. Le nœud IPv6 utilisant le mécanisme SEND peut effectuer jusqu’à 3 tentatives de génération d’adresse CGA, alors qu’avec le mécanisme SLAAC, le nœud IPv6 a seulement 1 tentative de génération d’adresse IPv6. En employant le mécanisme SEND, les messages échangés durant la procédure DAD sont sécurisés et en particulier grâce à l’option TimeStamp qui permet de contrer le rejeu de paquets. En effet, pour qu’un paquet provenant d’un nouveau correspondant (i.e., pas d’entrée dans le Neighbor Cache concernant ce nœud IPv6) soit valide, il est nécessaire que la différence entre le temps indiqué par l’horloge interne lors de la réception de ce paquet et la valeur contenue dans l’option Timestamp de ce même paquet soit comprise dans une fenêtre de temps paramétrable. Par défaut, cette fenêtre est de 10 minutes. Ainsi, un attaquant fera échouer une procédure DAD sécurisée par le mécanisme SEND s’il arrive à rejouer durant
2.4. Limitations de SEND
Figure 2.16 – Format de l’option Certificate
la fenêtre de temps les paquets NS envoyés par sa victime : la victime pense qu’un autre nœud a généré la même adresse CGA (i.e., les paquets NS sont correctement signés) et essaie aussi de se l’assigner.
Il est possible de détecter ce genre d’attaque. Lors des 3 tentatives de procédure DAD, la valeur de l’option Nonce ainsi que les CGA Parameters reçus dans les paquets NS seront tout le temps identiques à ceux émis par la victime : la probabilité que cela arrive est normalement négligeable. Donc, une des solutions à cette attaque est d’assigner l’adresse CGA obtenue à la troisième tentative.
Une autre solution serait d’utiliser l’option Nonce : durant la procédure DAD, ne tenir compte que des messages NS reçus dont la valeur de l’option Nonce est différente de celle dans l’option Nonce des messages NS émis.
Sécurisation du message RA
Une autre faiblesse du mécanisme SEND concerne la taille des clés RSA utilisées. Les spécifications CGA définissent que cette taille doit être au minimum de 384 bits. Par ailleurs, avec le mécanisme SEND, un routeur doit signer les messages RA émis avec la clé privée associée à son certificat (i.e., clé publique) prouvant qu’il est bien autorisé à être routeur. Si un routeur utilise une adresse CGA aussi, la paire de clés publique/privée ayant servi à la génération de cette adresse devra être la même que pour le certificat car il n’y a qu’une option RSA Signature dans un message sécurisé avec le mécanisme SEND. Du coup, dans ce dernier cas, se pose le problème du choix de la taille des clés RSA employées par un routeur. Si celle-ci est trop petite, la génération des adresses CGA du routeur ainsi que la signature des messages émis seront rapides. Mais, il sera plus facile de compromettre les clés RSA et du coup le certificat du routeur : l’attaquant sera capable de se faire passer pour le routeur, avec les conséquences décrites auparavant (cf. Section
2.1.2). D’un autre côté, si la taille des clés est trop grande, la génération des adresses CGA et la signature des messages émis occuperont trop les ressources du routeur.
Une solution serait de modifier l’option RSA Signature afin d’indiquer si la signature est basée sur une adresse CGA ou sur un certificat. Il faudrait alors autoriser l’inclusion de deux options RSA Signature pour un routeur utilisant une adresse CGA : une contiendrait la signature basée sur l’adresse CGA et l’autre contiendrait la signature basée sur le certificat. Ceci permettrait d’avoir deux paires de clés RSA : une "courte" pour l’adresse CGA et une "robuste" pour le certificat. Les messages NDP, autres que les messages RA, ne seraient signés qu’avec la clé privée associée à l’adresse CGA, réduisant ainsi le temps de calcul pour le routeur.
Usurpation de privilèges dans la mobilité IPv6
Le mécanisme SEND permet à un routeur de prouver qu’il est bien habilité à l’être et qu’il a le droit d’avertir certains préfixes IPv6. Cela signifie que seules les informations concernant ces 2 points sont couvertes par la sécurité fournie par le mécanisme SEND.
Le mécanisme Dynamic Home Agent Address Discovery (DHAAD) est employé avec MIPv6 (cf. Section1.6.1) pour permettre à un MN de découvrir dynamiquement un HA pour un préfixe IPv6 donné. Chaque HA, sur le sous-réseau ayant ce préfixe IPv6, a une base de données, la Home Agents List, contenant les informations concernant chaque HA dans ce sous-réseau. Cette base de données est mise à jour grâce aux messages RA envoyés par chaque HA, qui incluent une option nommée Home Agent Information.
Comme expliqué dans un document que nous avons soumis à l’IETF [DCLM08], le mécanisme SEND ne couvre pas les informations concernant un HA. Ainsi, sur un sous- réseau, n’importe quel routeur "légitime" peut se faire passer pour un HA et corrompre la Home Agents List de chaque HA légitime sur ce même sous-réseau. Le problème est encore plus critique avec le mécanisme de mobilité IPv6 Network Mobility Basic Support Protocol (NEMO) [DWPT05]. En effet, dans un tel contexte, la majorité des nœuds sur le sous-réseau où se trouvent les HA, sont des routeurs mobiles et donc des routeurs légitimes pouvant polluer la Home Agents List de chaque HA légitime.
Utilisation d’une même adresse par plusieurs nœuds
Une adresse CGA générée par un nœud IPv6 permet à celui-ci de prouver qu’il en est bien le possesseur. Cette propriété cryptographique est la base du mécanisme SEND. Or, comme nous l’avons décrit dans une Request for Comments (RFC) de l’IETF [CKD10], il existe des scénarios où plusieurs nœuds doivent utiliser une même adresse IPv6.
Le premier scénario concerne MIPv6 où le HA, afin d’intercepter les paquets à desti- nation du MN quand celui-ci ne se trouve pas dans son Home Network, usurpe la HoA du MN en falsifiant les messages ND (cf. Section1.3.1) : il annonce qu’à la HoA du MN correspond sa LLA.
Le deuxième scénario est ressemblant au premier et concerne IPsec et IKEv2. Lors d’une connexion sécurisée IPsec à un réseau distant, un nœud IPv6 se voit attribuer une adresse IPv6 interne à ce réseau par la passerelle IPsec le protégeant grâce à IKEv2 [ELM10]. Afin de pouvoir tunneliser les paquets provenant de ce réseau à destination du nœud IPv6, la passerelle doit se faire passer pour ce nœud. Une des techniques est de faire comme dans le cas précédent, à savoir, falsifier les messages ND.
Le troisième scénario est lors de l’utilisation du mécanisme ND Proxy (cf. Section
1.5). L’entité intégrant ce mécanisme doit falsifier les messages NDP comme expliqué précédemment.
Le dernier scénario concerne l’usage par plusieurs entités (i.e., deux ou plus) d’une même adresse : c’est avec les adresses de type anycast (cf. Section 1.1.3) ou alors avec le mécanisme de mobilité IPv6 Proxy Mobile IPv6 (PMIPv6) [GLD+08] où les routeurs d’accès font croire aux nœuds mobiles IPv6 qu’ils n’ont pas changé de routeur.
Dans tous ces scénarios, le mécanisme SEND ne peut être utilisé en l’état car il faudrait que les différentes entités partageant une même adresse CGA, partagent aussi le matériel de sécurité associé (i.e., paire de clés publique/privée et CGA Parameters). Or d’un point de vue sécurité, cela n’est pas une bonne solution : il suffit qu’une des entités soit compromise pour que la sécurité apportée par le mécanisme SEND, utilisés par toutes les autres entités, soit mise en péril.
A la suite de notre information, le groupe de travail CGA & SEND maIntenance (CSI)4 a été créé à l’IETF afin de standardiser une solution pour ces scénarios.
2.5. Synthèse du chapitre
Cas des réseaux privés
Il existe une autre situation où le même matériel de sécurité pour SEND doit être employé par plusieurs entités distinctes mais cette fois-ci, cela concerne les certificats X.509 prouvant qu’un routeur est habilité à avertir des préfixes IPv6 donnés.
Le scénario dans lequel cela peut se produire est lorsque ces préfixes sont de type ULA (cf. Section1.1.1). En effet, n’importe qui peut les utiliser dans son réseau et donc il peut y avoir plusieurs réseaux les employant. Dans ce cas là, si le mécanisme SEND est déployé, il faudrait que les routeurs dans chacun des réseaux en question soit en possession d’un certificat l’autorisant à avertir le préfixe FC00::/7. Du coup, comment serait-il possible de différentier, d’un point de vue sécurité, deux réseaux différents utilisant ce même préfixe ? Dans le cadre de nos travaux, nous avons défini les spécifications d’une solution basée sur ORCHID (cf. Section 1.2.5) permettant de répondre à cette problématique et qui a été brevetée [eDM11] [CM12]. Dans cette solution, les routeurs génèrent leur propre préfixe d’une manière cryptographique comme avec ORCHID. Ensuite, ils génèrent des certificats auto-signés avec le matériel de sécurité ORCHID, fournissant l’unicité de leur préfixe "privé", qui seront utilisés dans le cadre du mécanisme SEND. Ce dernier doit être modifié afin de prendre en compte ce nouveau type de certificat.
Faute de temps, nous n’avons pas pu terminer les travaux sur cette problématique et avoir une spécification finalisée de notre solution.
2.5
Synthèse du chapitre
Dans ce chapitre, nous avons tout d’abord présenté les failles de sécurité concernant le mécanisme NDP (cf. Section2.1), qui rendent l’utilisation du protocole IPv6 impossible. Dans le cadre du projet ANR MobiSEND, nous avons développé des scripts en Python les reproduisant.
Ensuite, nous avons présenté des solutions palliatives à ces failles (cf. Section2.2). Elles permettent de les limiter mais ne sont pas toujours fiables et peuvent être compliquées à mettre en place. Par la suite, nous avons décrit le mécanisme SEND (cf. Section2.3),qui est la solution de sécurisation standardisée à l’IETF et le principal mécanisme connu utilisant des identifiants cryptographiques, les adresses CGA.
Finalement, nous avons décrit différentes limites au mécanisme SEND ainsi qu’aux adresses CGA (cf. Section 2.4). Soit, elles sont dépendantes de la contrainte des algo- rithmes cryptographiques employés. Soit, elles sont liées à l’immaturité des spécifications du mécanismes SEND et des adresses CGA. Ainsi, comme nous l’avons montré dans une de nos contributions (cf. Section2.4.2), il est encore possible de mettre en place une attaque par rejeu contre le mécanisme SLAAC, malgré la protection fournie par le mécanisme SEND. Autre exemple d’immaturité des spécifications, comme nous l’avons détaillé dans une RFC à l’IETF (cf. Section2.4.2), il est impossible d’utiliser le mécanisme SEND dans de nombreux scénarios. Notre contribution a résulté à la création du groupe de travail CGA & SEND maIntenance (CSI) à l’IETF dont l’objectif est de spécifier la solution comblant cette lacune majeure. Pareillement, nous avons découvert un autre scénario où le mécanisme SEND ne peut être employé mais qui concerne cette fois-ci l’utilisation par plusieurs réseaux du même préfixe ULA, et donc d’un même certificat X.509 (cf. Section
2.4.2). Nous avons spécifié, et breveté, une solution pour y remédier mais, faute de temps, nous n’avons pu la finaliser. Enfin, une autre de nos contributions (cf. Section2.4.2), que nous avons soumise à l’IETF, démontre les limites de la protection du mécanisme SEND dans un contexte de mobilité IPv6. Pour la majorité de ces limites, nous avons proposé
des améliorations permettant de les combler.
Ainsi, en supposant qu’elles sont appliquées, on peut considérer les adresses CGA, et donc le mécanisme SEND, comme fiables au niveau sécurité. A partir de ce constat, comme nous le verrons dans la suite de nos travaux, des solutions de sécurisation IPv6 peuvent se baser sur la réutilisation du mécanisme SEND, comme décrit dans le Chapitre 3, ou des adresses CGA, comme décrit dans les Chapitres4 et5.
Chapitre 3
Protection contre l’usurpation
d’adresse IP basée sur SAVI
L’adresse IP dans l’Internet sert à la fois à identifier et à localiser un nœud IP. Ainsi, afin de ne pas pouvoir remonter à la source d’une attaque, des nœuds IP malveillants peuvent falsifier leur adresse IP source, en usurpant soit une adresse appartenant à un autre nœud IP, soit une adresse non attribuée. Afin de lutter contre cette falsification, l’Internet Engineering Task Force (IETF) a standardisé et encouragé le déploiement de la technique appelée "Network Ingress Filtering", dont la déclinaison la plus connue est unicast Reverse Path Forwarding (uRPF). Malheureusement, cette technique a certaines limites dont la principale est sa précision. Aussi, l’IETF a lancé des travaux, au sein du groupe de travail Source Address Validation Improvements (SAVI), pour standardiser des mécanismes complémentaires permettant une meilleure lutte contre l’usurpation d’adresses IP source. Ceux-ci reposent sur l’observation de la signalisation d’assignation d’adresses, telles que les mécanismes NDP ou SEND qui ont été présentés respectivement dans les Sections1.3 et2.3.
Dans ce chapitre, tout d’abord, nous rappelons les diverses attaques pouvant s’ap- puyer sur l’usurpation d’adresse IP source. Ensuite, nous présentons la technique de "Net- work Ingress Filtering" et expliquons ses limites. Ensuite, nous décrivons alors les diffé- rentes solutions standardisées dans le groupe de travail SAVI, sous notre responsabilité, à l’IETF. Après cela, nous décrivons notre proposition d’intégration de SAVI, dans le cas concret du réseau d’accès IPv6 ADSL/Fibre, à l’IETF et nous donnons les implémenta- tions/déploiements existants à ce jour. Enfin, nous concluons avec les limites propres à SAVI et les potentiels futurs travaux sur le sujet.
3.1
Menaces liées à l’usurpation d’adresses IP source
Les attaques capables d’utiliser l’usurpation d’adresses IP source peuvent être clas- sifiées selon leurs conséquences [MBH11]. Tout d’abord, il y a celles dont l’objectif est de corrompre des bases de données, connues sous le terme technique de Poisoning, afin généralement de pouvoir enchaîner avec une autre attaque. Ensuite, celles dont l’objectif est de bloquer l’accès à un service en le mettant à terre, connues sous le nom de Denial of Service (DoS). Enfin, celles dont le but est la reconnaissance et l’infiltration dans les systèmes.
3.1.1 Poisoning
L’objectif d’attaques de type Poisoning est d’introduire, dans une base de données, des informations erronées. Celles-ci pourront alors servir pour la mise en place d’un autre type d’attaque comme, par exemple, celle du type Man in the Middle (MitM) permet- tant de dérouter le trafic vers l’attaquant et ainsi d’obtenir, et modifier s’il le désire, les informations échangées entre 2 nœuds IP. Voici quelques unes des attaques de ce type les plus connues :
– ARP Poisoning
L’Address Resolution Protocol (ARP) est un mécanisme [Plu82] qui permet à un nœud IPv4 de connaître l’adresse de niveau 2 (e.g., adresse MAC) associée à une adresse IPv4 attribuée à un autre nœud IPv4. La réponse à une requête ARP est