IPSECKEY (pour plus d’informations concernant l’architecture DNS et les RR, cf. Section
5.1). Mais afin de sécuriser ce lien et de pouvoir garantir l’intégrité de la clé publique ainsi récupérée, il est nécessaire de déployer l’extension DNS Domain Name Server security (DNSSEC) [AAL+05]. La deuxième méthode permettant "une authentification" pour
IKEv2 est connue sous le nom de Better-Than-Nothing Security (BTNS) [WR08]. Avec cette méthode, il est fait la supposition qu’il n’y a pas de nœud malicieux essayant de faire une attaque du type Man-in-the-Middle (MitM) durant IKE_SA_INIT et ainsi aucune authentification n’est nécessaire durant IKE_AUTH ...
4.3
Intérêt d’utiliser les adresses CGA dans l’authentifica-
tion IKEv2
Comme nous l’avons vu dans la Section 1.2.4, les propriétés cryptographiques des adresses CGA permettent de prouver la possession d’une telle adresse, et ainsi de fournir une authentification de son possesseur. Celles-ci peuvent être réutilisées afin de pallier les inconvénients des méthodes d’authentification actuelles de IKEv2, identifiés dans la Section4.2.
Un de ces inconvénients, l’existence nécessaire d’une infrastructure de confiance, a en- traîné par le passé la non-adoption de IPsec pour sécuriser des services, comme la RO pour MIPv6 (cf. Section1.6.2). L’utilisation des adresses CGA avec IKEv2 pourrait remédier à cela.
4.3.1 Avantages et limitations
L’utilisation des adresses CGA avec IKEv2 apporte des avantages mais aussi des li- mitations. Pour chacune de ces limitations, nous proposons des solutions potentielles per- mettant de les pallier.
Approche sans infrastructure
L’utilisation des adresses CGA n’oblige pas à déployer une infrastructure dédiée. En effet, une adresse CGA est générée par son propriétaire et toutes les informations né- cessaires pour vérifier la véracité de cette adresse, et le message associé à celle-ci, sont envoyées directement au destinataire du message.
Il est intéressant de comparer cette propriété avec les certificats auto-signés. En ef- fet, cette famille de certificats nécessitent seulement une paire de clés publique/privée et aucune infrastructure, comme pour les adresses CGA. Maintenant, il est impossible de vérifier si les informations contenues dans ce genre de certificats, en particulier l’adresse IP si elle est incluse, sont correctes ou pas. En effet, il est possible de mettre n’importe quelle information dans ce type de certificat. Par comparaison, une adresse CGA est le résultat d’un algorithme fixé (cf. Section1.2.4). Il n’est pas possible de générer l’adresse CGA désirée à moins de réussir une attaque par préimage (i.e., pour une valeur h donnée, trouver un message m tel que h soit le résultat de la fonction de hachage appliquée à m). Ou alors, avec de la chance, un attaquant devra trouver une collision afin de pouvoir modifier des informations liées à cette adresse. Ceci est plus complexe que falsifier un certificat auto-signé et donc on peut considérer les adresses CGA comme plus sûres que cette famille de certificats.
De plus, le destinataire d’un message sécurisé par une adresse CGA a obtenu tout le matériel nécessaire à sa vérification contrairement à l’utilisation d’un certificat X.509. En
effet, pour vérifier un certificat X.509, il est nécessaire d’avoir un chemin de certification jusqu’à un certificat de confiance. Or, ceci nécessite généralement le déploiement d’une Public Key Infrastructure (PKI). Comme illustré dans la Figure4.4, une PKI comprend plusieurs entités comme la CA ou la Registration Authority - dans certaines architectures de déploiement, ces deux entités sont co-localisées. Les entités constituant la PKI et les messages échangés entre elles peuvent introduire de potentielles failles de sécurité. Si, l’une d’entre elles était correctement exploitée, comme cela a été déjà le cas il n’y a pas si longtemps1 2, toute la chaîne de confiance serait brisée et le niveau de sécurité serait identique à celle avec une utilisation de certificats auto-signés.
Figure 4.4 – Architecture d’une PKI
Niveau de sécurité
Les adresses CGA ont le même niveau de sécurité que des certificats X.509 lors d’un usage avec IKEv2. En effet, IKEv2 requiert 2 vérifications avec des certificats utilisés pour l’authentification :
1. le certificat doit être valide (i.e., lien sécurisé entre l’identité et la clé publique dans le certificat)
2. le certificat doit être utilisé seulement par son propriétaire
Pour le premier point, IKEv2 vérifie qu’il existe un chemin de certification jusqu’à un certificat de confiance (i.e., généralement un certificat émis par une autorité de certifica- tion, Certification Authority) (CA). Si cela est possible, IKEv2 peut aussi vérifier que le certificat utilisé n’a pas été révoqué. Concernant le deuxième point, IKEv2 vérifie que la signature, contenue dans le payload AUTH, a bien été effectuée avec la clé privée associée à la clé publique du certificat utilisé.
En comparant avec l’utilisation des adresses CGA, il y a les mêmes 2 vérifications. Pour le premier point, IKEv2 vérifie que l’adresse CGA est valide, à savoir qu’il y a un lien sécurisé entre l’identité, l’adresse CGA, et la clé publique, incluse dans les CGA Parameters. Pour cela, IKEv2 vérifie qu’il peut regénérer l’adresse CGA à partir de ces éléments (cf. Section 1.2.4). Pour le deuxième point, IKEv2 vérifie que la signature dans
1. http://isc.sans.org/diary/DigiNotar+breach+-+the+story+so+far/11500
4.3. Intérêt d’utiliser les adresses CGA dans l’authentification IKEv2
le payload AUTH a été générée avec la clé privée associée à la clé publique incluse aux CGA Parameters liés à l’adresse CGA (cf. Section4.5).
Identification
Les adresses CGA sont avant tout des adresses IPv6. Celles-ci sont difficiles à mémoriser pour un humain car elles sont plus longues que les adresses IPv4 (i.e., passage de 32 bits à 128 bits) mais surtout sont représentées en code hexadecimal. De plus, le destinataire d’un message, émis à partir d’une adresse CGA, ne connaît généralement pas qui est l’expéditeur derrière cette adresse. En effet, les adresses CGA peuvent être utilisées pour rendre anonymes les connexions IPv6 en s’en attribuant une nouvelle fréquemment : il n’y a aucun lien entre l’adresse MAC d’une interface et l’IID d’une adresse CGA, rendant aussi les communications d’un même nœud intraçables.
Afin de pallier ce problème d’identification, logiquement, la première idée serait d’as- socier une adresse CGA à un FQDN et de l’enregistrer dans un serveur DNS. Cependant, cela introduirait du coup les failles de sécurité inhérentes à l’architecture DNS, en parti- culier au niveau des échanges DNS, comme l’attaque DNS Cache poisoning [AA04]. Le niveau de sécurité apporté par l’utilisation d’adresses CGA serait alors perdu.
Pour solutionner cette perte de sécurité, nous avons besoin que les mises à jour DNS ainsi que les résolutions DNS soient sécurisées. Les mises à jour DNS permettent à un nœud IPv6, propriétaire d’une adresse CGA, d’enregistrer dans un serveur DNS l’associa- tion de celle-ci avec son FQDN. Les résolutions DNS sont utilisées par un nœud IPv6 afin de récupérer l’adresse IPv6, et donc ici l’adresse CGA, associée à un FQDN spécifique. Afin de sécuriser les mises à jour DNS, il est possible d’utiliser TSIG [VGrW00] (cf. Section
5.2.3) et SIG(0) [3rd00] (cf. Section5.2.4). Cependant, ces protocoles souffrent d’inconvé- nients comme nous le verrons plus tard (cf. Chapitre5). Les résolutions DNS peuvent être sécurisées grâce au déploiement de Domain Name Server security (DNSSEC) [AAL+05]. Avec de tels outils de protection mis en place, il ne reste comme option à un attaquant potentiel que de trouver une collision au niveau de l’adresse CGA.
Il est à noter que l’utilisation de CGA combinée avec DNSSEC sera meilleure que la solution se basant sur le RR IPSECKEY combinée avec DNSSEC pour un serveur DNS. En effet, cette dernière solution augmente la taille des informations à signer dans le DNS et par conséquence le temps nécessaire à cette signature. Ce qui est en particulier critique quand des informations sont mises à jour fréquemment dans le serveur DNS (i.e., nécessitant une nouvelle signature).
Algorithmes cryptographiques
Les spécifications des adresses CGA [Aur05] n’autorisent que l’utilisation de deux al- gorithmes cryptographiques : l’algorithme à clé publique RSA [RSA78] et la fonction de hachage SHA-1 [iost02].
Concernant l’algorithme à clé publique RSA, il est connu pour être coûteux d’un point de vue ressources et temps de calcul (i.e., contraintes au niveau du processeur et de la bat- terie). Aussi, l’algorithme RSA n’est pas réellement adapté pour des nœuds IPv6 à faibles capacités, comme les terminaux mobiles ou les capteurs par exemple. Malheureusement, les spécifications actuelles des adresses CGA n’autorisent pas l’usage d’algorithmes alter- natifs comme ceux basés sur les courbes elliptiques, Elliptic Curve Cryptography (ECC), malgré la publication d’articles [CBL10] ou de propositions de standards à l’IETF [SXZ11]. Concernant la fonction de hachage SHA-1, en se basant sur les dernières cryptanalyses rendues publiques, la communauté en sécurité s’attend à ce que cette fonction de hachage
soit "cassée" d’ici un futur proche et que, du coup, il soit facile de générer des collisions. Aussi, la communauté en sécurité est actuellement en train de travailler sur la prochaine génération de fonction de hachage : SHA-3. Mais, encore une fois, les spécifications actuelles des adresses CGA n’autorisent pas l’usage d’algorithmes alternatifs pour le moment.
Enfin, il est important de mentionner que l’usage d’algorithmes cryptographiques peut être réglementé dans certains pays ou entreprises. C’est par exemple le cas en Russie, où l’algorithme GOST R 34.11-94 [Dol10] doit être obligatoirement utilisé en lieu et place de toute autre fonction de hachage.
Révocation
Une adresse CGA fournit une relation forte entre une adresse IPv6 et son propriétaire mais rien n’empêche un nœud malicieux d’être capable d’utiliser cette même adresse dans le futur dans le cas où elle aurait été compromise grâce à une collision. Les certificats X.509 peuvent être révoqués lorsqu’ils sont combinés avec une PKI et que le mécanisme Certificate Revocation List (CRL) [CSF+08] ou le mécanisme Online Certificate Status Protocol (OCSP) [MT07] a été déployé. A l’inverse, une adresse CGA ne repose pas sur une infrastructure et donc ne peut être révoquée.
Une solution potentielle pour pallier ce problème serait d’utiliser à nouveau DNS, combiné à DNSSEC afin de garder le même niveau de sécurité. En effet, si la valeur du champ Time To Live (TTL), dans le RR AAAA (cf. Section 5.1) pour le FQDN associé à l’adresse CGA, était fixée de telle sorte qu’elle soit plus courte que le temps nécessaire à la découverte d’une collision pour cette même adresse CGA, alors cela pourrait limiter l’attaque. Maintenant, cette solution deviendrait inutile dans le cas où l’attaquant essaierait de calculer à l’avance les collisions pour un grand nombre d’adresses CGA.