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

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 :

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 :

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 :

Il identifie également que sa solution ne peut pas résoudre la découverte de corrélation utilisant :

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