Protéger sa vie privée avec l’IPv6
Le futur d’Internet est l’adressage IPv6 en lieu et place de l’actuel protocole IPv4, puisque nous sommes en train d’atteindre les limites de ce dernier.
Malgré ses indéniables atouts, le protocole IPv6 pose certaines questions sur le respect de la vie privée lors de sa configuration automatique. Nous proposons dans cette dépêche de passer en revue les problèmes et d’esquisser des solutions afin de mieux protéger sa vie privée avec IPv6.
Sommaire
- Connexion aux réseaux en IPv6 avec l’autoconfiguration
- RFC 4941 : rendre les adresses auto-configurées temporaires
- RFC 7217 : créer par défaut des identifiants d’interface non-prédictibles et stables
- Conclusion
Le protocole IPv6 a un très grand avantage sur son ancêtre : la taille des adresses passe de 32 à 128 bits. Ça n’a l’air de rien comme ça, mais cette profusion d’adresses résout beaucoup de problèmes d’IPv4 sans nécessiter la complexité de ce dernier :
- il n’y a plus besoin de créer des réseaux « privés » (avec un NAT) puisque le nombre d’adresses disponibles est largement suffisant. Ainsi, si les règles de routage le permettent, les clients peuvent être connectés directement entre eux (ce qui facilite l’adoption des connexions P2P). Ne pas avoir à configurer de NAT est un grand avantage également pour l’auto-hébergement, car il n’y a pas besoin de gérer l’ouverture et la redirection des ports du routeur, ce qui simplifie grandement sa configuration, puisque "seul" le pare-feu doit être géré ;
- il n’y a plus de nécessité de coordinateur central pour gérer les baux d’adresses d’un sous-réseau (DHCP), puisqu’il suffit de tester si une adresse tirée au hasard est disponible, tester si quelqu’un l’utilise et l’utiliser (ou tester une nouvelle) ;
- les cartes réseau peuvent louer autant d’adresses que désiré, puisque les sous-réseaux contiennent suffisamment d’adresses disponibles (bien plus que les fameuses 255 adresses fournies par les réseaux privés installés par défaut) ;
- le routeur est capable de s’annoncer directement sur le réseau pour tous les appareils lui étant connectés par le réseau « lien-local » (i.e. physiquement branché sur le même réseau). Ainsi, les clients peuvent se configurer automatiquement pour avoir accès au reste d’Internet. Ceci est possible grâce à la possibilité d’avoir plusieurs adresses par interface : une adresse lien-local utilisée pour recevoir les informations et mises à jour du réseau local et une adresse globale pour se connecter au reste d’Internet.
Malgré tous ces avantages, un des inconvénients connus d’IPv6 est que le fichage du trafic des ordinateurs particuliers est plus aisé par les attaquants. En effet, une des propriétés du protocole NAT était d’utiliser une seule adresse IPv4 publique pour plusieurs appareils, ce qui rendait un peu plus difficile le fichage des utilisateurs, puisque plusieurs d’entre eux utilisaient la même adresse pour se connecter à Internet.
Avec IPv6, chaque ordinateur ayant sa propre adresse publique, l’attaquant peut faire un lien direct entre une adresse et un utilisateur particulier.
Un attaquant pourrait être un homme du milieu qui écouterait le trafic IP ou une personne ayant accès à des logs de différents serveurs. Avec de telles informations, l’attaquant pourrait faire des liens entre les différentes activités des utilisateurs, bien qu’elles ne soient pas liées directement.
Par exemple, il pourrait savoir quand un employé travaille sur Internet ou quand une personne est présente chez elle.
Il faudrait donc veiller à ce que les machines du réseau changent d’adresse IP publique régulièrement pour rendre le fichage plus difficile. Il pourrait changer à travers le temps et/ou selon le réseau auquel il se connecte.
Dans la suite de cette dépêche, nous vous proposons d’analyser les moyens à disposition des utilisateurs pour rendre difficile le fichage des utilisateurs par les serveurs au moyen d’adresses IPv6.
Connexion aux réseaux en IPv6 avec l’autoconfiguration
Pour commencer, il faut savoir que les adresses IPv6 sont définies en deux parties :
- le préfixe réseau qui est défini par le FAI. Il est annoncé sur le réseau par le routeur au moyen des adresses de type lien-local.
- l’identifiant d’interface qui se compose des bits restants et qui identifie une interface d’une machine dans le réseau.
Quand un appareil connecte son interface sur un réseau, ce dernier crée automatiquement une adresse de type lien-local avec le préfixe réseau [fe80::]/10. Ces adresses ne doivent être utilisées qu’à l’intérieur d’un même réseau (donc les routeurs ne doivent pas permettre de connexion sortante) et permettent de découvrir les autres appareils connectés sur le même réseau.
Grâce à cette adresse locale, la machine peut écouter les annonces diffusées par le routeur sur le réseau. Avec ces annonces, la machine reçoit de la part du routeur le préfixe réseau à utiliser pour communiquer avec l’extérieur.
Comme l’appareil est connecté au réseau local, il peut aussi communiquer avec les autres appareils du réseau et contrôler quels identifiants d’interface sont déjà utilisés par les autres (il crée un identifiant d’interface, il annonce qu’il souhaite l’utiliser et il peut l’utiliser si aucun des voisins ne l’utilise déjà).
Afin de trouver plus rapidement un identifiant d’interface réseau non-utilisé, si la taille du préfixe réseau le permet (inférieure ou égale à 64 bits), la machine peut tenter d’utiliser l’adresse MAC de son interface réseau comme identifiant. Cependant, comme l’adresse MAC devrait être unique à l’interface réseau de la machine, l’adresse IP trouvée sera non seulement globalement unique (après contrôles avec son voisinage), mais également invariable.
Les deux RFCs que nous allons analyser proposent des solutions pour ce système de configuration automatique qui utilise les adresses MAC, afin d’utiliser des identifiants moins constants à travers le temps et les réseaux. Leur objectif est de ne plus utiliser directement sur le réseau une adresse IP invariable, afin de protéger l’utilisateur d’un potentiel fichage.
RFC 4941 : rendre les adresses auto-configurées temporaires
Cet RFC propose de rendre le pistage du trafic d’un client IPv6 plus difficile en étendant la définition des types d’adresses IPv6 avec un type temporaire.
Il propose une solution pour résoudre les problèmes suivants :
- Comme l’identifiant d’interface reste constant à travers tous les réseaux auxquels le client se connecte, un attaquant, qui aurait accès aux logs de différents serveurs, peut trouver des corrélations entre les différentes activités du client.
- Un attaquant qui écouterait le trafic du réseau peut facilement retrouver les communications d’un client précis en lisant les données IPv6 des paquets réseau.
Il identifie également que sa solution ne peut pas résoudre la découverte de corrélation utilisant :
- les données utiles transportées par les paquets
- les caractéristiques des paquets telles que leur taille et leur chronologie
- le préfixe réseau pour les réseaux avec peu de machines (tels que ceux de nos domiciles) ; dans ce cas, la « confidentialité » permise serait la même qu’avec l’utilisation d’un NAT sur IPv4.
Pour résoudre les problèmes identifiés, le RFC propose de créer le principe de type d’adresse « temporaire », c’est-à-dire des adresses qui auront l’obligation de passer à un statut obsolète après un certain temps et qui ne seront pas devinables en utilisant des informations disponibles sur le réseau.
Ce RFC précise donc un algorithme qui remplacera l’utilisation de l’adresse MAC pour trouver rapidement un identifiant unique par l’utilisation du hasard. Il conserve les autres principes de l’auto-configuration, mais permet de créer directement un ensemble d’adresses temporaires (au lieu d’une seule adresse) et détermine une période de regénération et remplacement de ces adresses.
Cependant, il a été décidé que, par défaut, la génération des adresses temporaires crée une seule adresse par préfixe réseau pour lequel l’auto-configuration est active. Créer un nombre limité d’adresses évite d’obliger le client à rejoindre trop de groupes multicast (prévus par IPv6 et obligatoires), ce qui permet de ne pas avoir trop d’inquiétudes par rapport aux performances.
L’idée générale de l’algorithme est de tirer un nombre au hasard, de le coller à l’identifiant d’interface existant, d’appliquer une fonction de hashage sur ce nombre (MD5 est proposé, mais l’utilisation d’un autre algorithme est ouvert). Du résultat du hash, on prend les 64 bits les plus à gauche pour les utiliser comme bit d’interface et le reste est conservé comme nombre aléatoire pour la prochaine itération (qui arrivera au moins pour le renouvellement de l’adresse temporaire ou pour le prochain redémarrage de la machine).
Il aurait été possible de ne faire que le tirage de nombre aléatoire, mais il est difficile de trouver un nombre réellement aléatoire. C’est pour ça que l’algorithme a été prévu pour ne le calculer que la première fois et d’utiliser un historique pour générer les nombres suivants.
RFC 7217 : créer par défaut des identifiants d’interface non-prédictibles et stables
Le RFC précédent définit les adresses temporaires pour des communications sortantes, mais elles nécessitent toujours les adresses IP crées avec les adresses MAC pour l’établissement des communications entrantes (fonctionnalités de type serveur).
Le RFC 7217 propose une solution pour rendre plus opaques ces adresses stables nécessaires aux fonctions de type serveur. En effet, l’utilisation de l’adresse MAC permet encore à un attaquant de trouver des corrélations d’activités sur Internet et il peut également plus facilement réduire le nombre d’adresses en cours d’utilisation à scanner (puisque l’adresse MAC réduit le nombre d’identifiants possibles, notamment en connaissant le constructeur des interfaces réseau).
Comme ce RFC travaille sur les adresses stables, il peut être utilisé de manière complémentaire aux adresses temporaires, sans en être dépendant. Ainsi, si un réseau interdit l’usage des adresses temporaires, les risques de découverte d’adresses utilisées et de corrélations d’activité peuvent quand même être réduites.
Dans les grandes lignes, l’algorithme produit des identifiants d’interface stables pour un réseau donné. C’est à dire qu’à chaque changement de réseau, les identifiants changent, mais lors du retour sur un réseau, il devrait reprendre la même valeur qu’auparavant (si l’identifiant n’a pas été utilisé par un autre appareil entre temps). Malgré cette stabilité, les identifiants ne sont pas prédictibles, car l’algorithme utilise une clé privée connue uniquement par le système local.
Ainsi, l’algorithme est capable de créer des identifiants d’interfaces assez stables pour des fonctionnalités de type serveur (connexion entrantes) pour un réseau donné. Il permet d’éviter la corrélation des activités sur différents réseaux (par exemple, l’activité au bureau et à la maison d’une machine portable n’est plus liée par une adresse unique), tout en permettant d’utiliser une adresse non-temporaire pour certains services de la machine.
Conclusion
Finalement, avec l’activation de ces 2 RFCs dans les gestionnaires de réseau des machines, il est possible d’avoir les avantages de l’auto-configuration d’IPv6 avec une protection de la vie privée au moins égale à celle de l’utilisation d’un NAT avec IPv4.
En effet, le RFC 7217 permet de toujours créer des adresses non-prédictibles (et différentes sur chaque réseau) et le RFC 4941 permet de créer des adresses temporaires qui auront l’obligation d’être abandonnées après un certain temps d’utilisation.
Le travail des attaquants est donc rendu bien plus difficile pour créer des corrélations des activités d’une machine sur les réseaux tout en gardant l’avantage d’IPv6 où la configuration manuelle n’est pas nécessaire et où les adresses IPs utilisées sur le réseau sont toutes des adresses publiques facilitant le P2P.
Cette dépêche a été proposée car un développeur de Network Manager a annoncé l’implémentation de ces 2 RFCs pour la release 1.2.
Aller plus loin
- "Network Manager and privacy in the IPv6 Internet" par Lubomir Rintel
- Notes de l’IETF à propos de l’utilisation des adreses MAC comme adresse IP sur Internet
- RFC 4941: Extensions de confidentialité pour l’autoconfiguration IPv6
- RFC 7217: Méthode de génération d’interfaces opaques avec l’autoconfiguration IPv6
- RFC 4862 : Autoconfiguration d’adresses IPv6
- Wikipédia: IPv6