L'anonymisation

De Page Personnelle de Cédric Blancher.

L'envie ou la nécessité d'être anonyme sur Internet a effleuré l'esprit de chaque utilisateur du réseau. Cette problématique n'est pas nouvelle et continue de susciter de nombreux articles dans les journaux scientifiques. Des solutions pratiques s'inspirant de ces travaux existent et peuvent être utilisées par la plupart des gens avec plus ou moins de facilité de mise en œuvre. Nous allons présenter les concepts généraux à respecter pour rester anonyme, puis les illustrer au travers de deux logiciels : Mixmaster et Tor.

Sommaire

[modifier] Introduction

L'anonymat peut être utilisé dans plusieurs buts qu'ils soient légitimes ou non. On peut par exemple vouloir surfer anonymement pour respecter notre droit à la vie privée, pour contourner une censure imposée par un état (un fournisseur d'accès, une entreprise, ...), pour obtenir des informations sans que le serveur sache qui est le demandeur (utile pour surveiller ce que fait le concurrent, surtout s'il modifie les pages suivant les adresses sources), etc. Mais cela peut aussi servir à mettre en communication d'une manière sûre des personnes ne désirant pas dévoiler leur identité (pour offrir un service, un témoignage, des informations, ...). Malheureusement ces services peuvent être aussi la proie d'usage illégaux tels que le piratage de systèmes, l'échange illégal de fichiers via le peer-to-peer, etc.

Le premier service offrant de l'anonymat pour surfer sur Internet est très simple et se résume à un simple proxy entre le client et le serveur. Un site bien connu pour cela est Anonymizer[1]. Cependant n'importe qui peut se rendre compte que cet anonymat est superficiel : certes le serveur ne sait pas qui l'on est mais le proxy peut associer un client à une requête. On doit donc avoir absolument confiance dans cette entité qui agit comme une boîte noire pour l'utilisateur. Pouvons-nous être certains qu'elle n'est pas une entreprise dirigée par un service de renseignements d'un gouvernement ? À partir de ce simple constat on réalise que notre communication doit passer par un nuage de machines qui ignoreront tout de l'émetteur et du destinataire.

Pour satisfaire à notre exigence les machines par lesquelles transite notre requête doivent tout ignorer de son contenu. Des mécanismes cryptographiques - notamment asymétriques - sont nécessaires pour assurer la confidentialité de notre information dans le nuage.

De plus notre système doit résister à différents types d'attaques :

  • l'interception de paquets ;
  • la possibilité d'avoir un ou plusieurs nœuds malveillants dans notre réseau ;
  • les attaques globales (c'est-à-dire en observant le réseau d'une manière macroscopique, en analysant le trafic entrant et sortant par exemple) ;
  • le déni de service sur les machines composant le réseau ;
  • la ré-utilisation du même chemin ;
  • etc.

Certains de ces problèmes sont résolus par une utilisation adéquate des technologies cryptographiques actuelles. D'autres ne peuvent être empêchés que grâce à une utilisation massive du réseau. Plus de machines participeront au système, plus il y aura de nœuds, plus le réseau sera immunisé aux attaques globales ou de type déni de service. Ici rentre donc en jeu la facilité d'utilisation du logiciel afin qu'un grand nombre de personnes l'adopte et qu'il ne soit pas réservé à une minorité.

Nous allons voir dans les deux logiciels Mixmaster et Tor comment ces solutions ont été mises en œuvre.

[modifier] Mixmaster

[modifier] Introduction

Mixmaster[2] est un système collaboratif de relais anonymes de courrier électronique[3]. C'est l'implémentation la plus utilisée de ce qu'on appelle les relais de 2e génération (Type II Remailers). Ce système vise à fournir l'anonymat aux expéditeurs de courrier d'une part, et une résistance à l'analyse de trafic que ne fournissait pas complètement les relais de type I.

[modifier] Les relais de type I

Fig. 1 : fonctionnement des relais de type I

Le relais de type I sont plus généralement connus sous le nom de Cypherpunk Remailers, dont Reliable[4] est un exemple d'implémentation. Le système, largement fondé sur l'usage de la cryptographie à clé publique, constitue la première implémentation d'un mécanisme de relais réellement anonyme. Le principe de base est la chaînage de nombreux relais qui fourniront deux services :

  • effacement des traces générées par le précédent saut ;
  • relais du message vers son prochain saut.

L'émetteur, pour envoyer son message, commence par choisir une chaîne arbitraire de N relais par lesquels il voudra voir transiter son message. Des listes de relais sont disponibles sur Internet, afin que les utilisateurs puissent construire leurs chaînes. Chaque relais publie une clé publique qui permet de chiffrer les messages qu'il doit traiter. Une fois sa chaîne choisie, l'utilisateur chiffre son message avec la clé publique du dernier relais (rang N), celui choisit pour délivrer le courrier à son destinataire final. Ce message se voit ajouter une en-tête identifiant ce relais, et indiquant ainsi au relais de rang N-1 la destination suivante. On chiffre alors le tout avec la clé publique du relais N-1 et répète l'opération jusqu'au rang 1 comme illustré en figure 1. On obtient ainsi un message emballé d'autant de couches de chiffrement qu'il aura à franchir de relais.

Le principe de transmission du message est alors évident. Le relais de rang 1 reçoit le message qu'il déchiffre avec sa clé publique. Il lit l'en-tête (puis la supprime) qui lui indique le relais de rang 2 auquel il transmet le bloc chiffré résultant. Celui-ci reçoit le message, le déchiffre, lit et supprime l'en-tête, puis relaie le message et ainsi de suite jusqu'au relais de rang N. Ce dernier relais obtient alors après déchiffement un message clair (au sens SMTP) qu'il ne lui reste plus qu'à expédier en se comportant comme un relais de courrier électronique classique (cf. figure 1). On transmet ainsi le message comme on pèle un oignon...

L'idée qui sous-tend ce système est que chaque nœud, hormis le dernier, soit dans l'impossibilité de connaître sa position réelle dans la chaîne. Par conséquent, il ne connaît pas la position du relais précédent, ni celle du relais suivant, ce qui permet au système de se protéger par lui-même d'un relais compromis ou espion, en lui interdisant l'accès au message et au reste de la chaîne de transmission, aussi bien en amont qu'en aval. Même le premier relais n'est pas capable de savoir si le message qu'il vient de recevoir provient d'un autre relais, ou bien directement d'un émetteur. C'est grâce à se fonctionnement en aveugle que le système s'auto-protège.

En fait, ceci n'est pas tout à fait vrai. Les relais de type I sont en effet vulnérables à l'analyse de trafic. Leur fonctionnement de type store and forward simple offre la possibilité à un attaquant de corréler de manière efficace l'arrivée d'un message à sa réexpédition vers le relais suivant en examinant les flux reçus et émis par le nœud. Trois faiblesses majeures rendent possible l'analyse de trafic :

  • La possibilité pour un attaquant de rejouer des messages capturés l'autorise en observant l'entrée et la sortie d'un relais de déterminer le saut suivant très simplement. Cette attaque peut en outre profiter du système en ajoutant ses propres en-têtes pour réinjecter le message à un point arbitraire du nuage.
  • La taille globale du message diminue à chaque hop de la taille d'une en-tête, augmentant ainsi la capacité d'un attaquant à corréler, même si ce n'est pas linéaire, l'entrée et la sortie du relais.
  • À supposer que cet attaquant soit capable d'observer successivement chaque relais de la chaîne, il est capable de tracer un message arbitraire jusqu'à sa destination finale.

Ainsi, même si le système fournit très correctement sa fonction d'anonymisation, il ne met en jeu aucun mécanisme pour se protéger d'un observateur suffisament bien équipé et introduit dans le système (via des nœuds compromis) de tracer les messages émis par une source identifiée utilisant ce système. Si on considère que tous les liens réseau du monde puisse être écoutés par une entité unique, le système ne tient pas sans avoir recours à des moyens externes supplémentaires.

Enfin, Cypherpunk implémente un mécanisme permettant aux destinataires des courriers anonymes d'y répondre. Il y a donc une persistance du chemin dans le nuage de relais de manière à permettre le retour de la réponse. Cette persistance peut être mise à profit pour tracer l'expéditeur du message et in fine découvrir son identité.

[modifier] Les relais de type II

Fig. 2 : fonctionnement des relais de type II

Pour palier les limitations précédemment évoquées, le système a été amélioré pour donner naissance au relais de type II, dont Mixmaster est l'implémentation la plus répandue. Il part du principe que tous les liens réseau par lesquels transite l'information sont écoutés et vise à rendre difficile la déduction d'information à partir d'une analyse de trafic. Il élimine également la possibilité de répondre à un courrier, éliminant de facto la possibilité de tracer l'origine par ce biais.

Comme pour les relais de type I, le système s'appuie sur des chaînes de relais. Mais au lieu d'envoyer son courrier complet dans un message unique, il l'éclate en plusieurs paquets de taille fixe qui seront chacun émis dans une chaîne de relais différente de 20 sauts maximum. Pour décorréler le nombre de paquets émis et le contenu du message, et ainsi rendre l'analyse plus ardue, le système supporte la compression, le bourrage des paquets et la réémission à des fins de redondance.

Chaque paquet dispose d'une en-tête de 20 sections, une pour chaque relais possible. Supposant un nombre N de relais choisis, les N premières sections du message initial contiendront des informations pertinentes chiffrées, et les 20-N suivantes des données aléatoires. Ce remplissage systématique des 20 sections sera conservé tout au long du chemin. Il sera ainsi impossible pour un observateur, ou un relais compromis, de déduire la moindre information sur sa position dans la chaîne. Comme pour les relais de type I, on utilise le surchiffrement itératif. La section i (i compris entre 1 et N) contient d'une part des informations pour que le relais i-1 puisse identifier le relais i, ainsi que des données chiffrées avec la clé publique du relais de position i. Ces données chiffrées contiennent en particulier la clé de chiffrement pour déchiffrer le reste du message, à savoir le corps et les sections suivantes. Lorsque le relais de rang 1 reçoit le message, il déchiffre la section 1, extrait la clé et déchiffre le reste du message. Il identifie donc le relais de rang 2. Il efface alors la section 1, remonte les sections suivantes d'un rang (2 devient 1, 3 devient 2, etc.) et génère une 20e section aléatoire avant de ré-émettre le tout au prochain relais. Ainsi, tous les paquets échangés sur le réseau auront une structure identique d'une part et une taille égale d'autre part, quelque soit leur contenu et leur position dans la chaîne d'expédition.

Chaque section contient un champ Packet Type Identifier grâce auquel chaque relais sait s'il est un relais intermédiaire ou un relais final. S'il est final, ce champ lui indique également si le paquet contient un message complet ou un fragment. Dans ce dernier cas, on lui indique le nombre total de fragments composant le message (champ Number of Chunks). Il lui reste donc à attendre tous les fragments du message avant de le transmettre à son destinataire final. Chaque message possède un identificateur de message (champ Message ID), généré aléatoirement à l'émission et placé dans l'en-tête destinée au dernier relais. Les autres relais peuvent recevoir des numéros arbitraires, évitant grâce à cela qu'un observateur omnipotent puisse identifier les fragments d'un même message de manière triviale. Cet identificateur a deux fonctions :

  • à l'instar du champ Identification de IP, il identifie les fragments d'un même message dans la mesure où leur numéro est le même ;
  • il sert également à supprimer les doublons en cas d'émission redondante. Une fois le message reconstitué et délivré, l'identifiant de message est conservé en mémoire pendant 7 jours par le dernier relais de manière à éliminer tout paquet reçu portant ce même numéro.

L'utilisation systématique de la fragmentation augmente de manière très significative la résistance du système à l'observation, à condition que chaque nœud présente un comportement stable dans le temps. Pour atteindre ce comportement, des fonctions de mise en queue, de temps de garde variables et d'émission groupée de paquets sont implémentées de manière à décorréler les trafics entrant et sortant. Cependant, ceci suppose que le nœud traite un volume de trafic suffisant. La circulation d'information est donc vitale à la survie même du système : plus il est utilisé, plus le nuage se charge, plus le comportement des nœud devient uniforme dans l'espace et dans le temps.

Le système reste cependant vulnérable aux analyses par rejeu. Il suffit pour un attaquant d'attendre l'expiration du temps de garde d'un identificateur de message donné pour pouvoir faire retraiter des paquets capturés et vérifier une hypothèse de corrélation.

[modifier] Mixminion et serveurs de Nyms

Fig. 3 : transmission d'un paquet à l'aide d'un SURB

Les systèmes que nous venons de voir présentent des vulnérabilités, qui bien que difficiles et coûteuses à exploiter, ont conduit à la création d'un système de type III dont l'implémentation de référence est appelée Mixminion[5]. Cette troisième version, cependant très proche de Mixmaster, introduit en particulier un mécanisme anti-rejeu amélioré, une rotation des clés utilisées lors de l'expédition des fragments et enfin un mécanisme de génération de bruit pouvant charger artificiellement le nuage et obtenir un comportement uniforme, même en l'absence de transmissions. Enfin, SMTP comme méthode de transport est abandonnée en faveur de sessions TLS sur TCP. Initiant une convergence des différents systèmes anonymisant vers ce type de transport, le but final est de camoufler jusqu'à la nature même de la communication grâce à un nuage multi-fonctions. Le système se veut en définitive résistant à une observation complète des liens réseau et une compromission de la moitié des nœuds du nuage.

Mixminion apporte en outre une réelle amélioration du concept de Nymserver[6], ou serveur de pseudonymes. Les systèmes décrits jusqu'alors protègent efficacement les envois d'une personne anonyme, mais rien n'est prévu pour qu'elle reçoive du courrier. Les serveurs de pseudonymes remplissent cette fonction. Très schématiquement, un nymserver publie une adresse de courrier électronique banalisée pour un individu et la met en relation avec une véritable identité à travers le nuage au moyen d'une clé publique. Les premières implémentations étaient trop simplistes pour être efficaces (cf. Cypherpunk). Mixminion introduit un système appelé SURB pour Single Use Response Blocks. Un SURB est un bloc d'information chiffré adressé à un nymserver pour qu'il obtienne des informations de routage à usage unique vers une destination cachée, pour un bloc de données de taille limitée. Techniquement, un SURB est construit comme un message anonyme de type II dont le contenu serait l'adresse du destinataire final. Cette adresse est donc chiffrée dans un paquet de taille fixe par couches successives avec les clés des serveurs choisis pour constituer la chaîne de retour des informations. Lorsqu'un serveur doit émettre un paquet, il déchiffre sa couche du SURB (i.e. celle de dessus) pour trouver l'identité du prochain relai. La clé publique de ce dernier sera alors utilisée pour chiffrer les données. Le paquet est alors envoyé avec le SURB au système suivant. Le fonctionnement est illustré en figure 3.

On notera qu'il est impératif pour l'expéditeur de chiffrer son message avec la clé publique du destinataire avant de l'envoyer. En effet, ce dernier ne disposera que d'une couche de chiffrement, retirée puis regénérée par chaque relais. Ainsi, le passage d'un message émis en clair par un relais compromis entraine la perte de la confidentialité.

D'abord créé pour recevoir des réponses sécurisées à un message anonyme, ce système a été étendu pour pouvoir publier des pseudonymes de deux manière différentes :

  • On fournit plusieurs SURBs à un nymserver pour qu'il fasse suivre plusieurs messages sur le réseau. Cette approche a comme désavantage majeur la localisation sur un serveur associé au pseudonyme de plusieurs SURBs valides qui, utilisés ensembles, pourraient faciliter le traçage du véritable destinataire. En outre, elle est vulnérable aux dénis de service par inondation : une fois les SURBs épuisés, les messages à destination du pseudonyme sont perdus.
  • Le nymserver place les message dans une queue que l'utilisateur peut consulter de manière anonyme et sécurisée. Il choisit alors les messages qu'il veut rapatrier et émet le nombre de SURBs nécessaires. Ainsi, le serveur ne stocke pas de SURB et un déni de service par inondation se résume à flooder une boîte mail. Par contre, le serveur stocke des messages, ce qui peut s'avérer dangereux, d'autant que la consultation fréquente de l'état de sa boîte augmente les risques de localisation.

Dans les deux cas, les systèmes de publication de pseudonymes restent fortement vulnérables à la compromission. Un nymserver compromis met en danger tous les pseudonymes qu'il héberge, d'abord parce qu'il sert à consulter les messages qui lui sont destinés, ensuite parce qu'il contient des SURBs valides pouvant être mis à profit. Il est donc impératif pour un utilisateur de changer fréquemment de nymserver, et donc de pseudonyme. Pour y parvenir, il existe des serveurs de publication associant une clé publique, invariante, avec un ou plusieurs pseudonymes, pour qu'un individu ait le moyen de joindre son correspondant.

[modifier] Conclusion

Les systèmes d'anonymisation de courrier électronique atteignent un niveau de sécurité extrêmement élevé lorsqu'ils sont utilisés correctement. Cette sécurité tient d'une part à un travail colossal de réflexion et d'intégration cryptographique, et d'autre part à la nature même de l'envoi du courrier électronique, qui ne nécessite qu'un chemin de sortie pour s'effectuer. On voit en effet combien il est difficile d'atteindre des niveaux de sécurité équivalents dès lors qu'il s'agit de recevoir du courrier...

Il ne faut cependant pas oublier que la technique propose ici une solution limitée par les comportements humains. Il est en effet possible de retrouver l'identité d'un utilisateur en examinant ses messages soit parce qu'ils contiennent des informations techniques contenues dans le courrier lui-même (entêtes par exemple), soit parce que leur teneur et leur style permet de les rapprocher d'autres messages précédemment identifés par des techniques de profiling.

[modifier] Tor

[modifier] Introduction

Tor est la deuxième génération d'Onion Routing. La première[7] avait vu le jour au milieu des années 90 sous l'égide de l'US Navy. À cause de problème de license, la distribution et l'utilisation du logiciel n'ont pas connu l'essor escompté. Depuis le milieu de l'année dernière Tor[8] est disponible sous une license BSD à trois clauses et remédie aux erreurs et oublis de la première version. Remarquons que les développeurs sont aussi ceux du projet de messagerie anonyme Mixminion.

[modifier] Principes

Tor est un réseau anonyme destiné aux sessions TCP interactives ou nécessitant peu de latence. Typiquement cela concerne le traffic web, les connexions distantes (ssh), la messagerie instantanée, IRC, etc. Le maître mot est la simplicité aussi bien pour l'élaboration du logiciel et du protocole que pour l'utilisation. En effet, plus de personnes utiliseront ce logiciel plus grandes seront les capacités d'anonymisation du réseau. Le confort pour l'utilisateur n'est donc pas une option mais un pré-requis : il faut donc qu'il soit déployable facilement (sans modification du noyau par exemple) sur le plus grand nombre de plate-formes possibles. Le logiciel est ainsi disponible pour Windows et les différents Unix, MacOS X compris.

Pour réaliser des connexions anonymes Tor crée un circuit passant par plusieurs nœuds (choisis arbitrairement) du réseau. Les échanges entre ces nœuds sont chiffrés. Plusieurs flux TCP sont transportés par ce circuit jusqu'à l'établissement d'un nouveau. Chaque nœud connaît seulement son prédécesseur et son successeur empêchant ainsi de pouvoir établir qu'un client donné est connecté à un serveur donné sans coopération.

Dans les parties suivantes nous regardons plus en détails les caractéristiques et le fonctionnement de Tor. Libre au lecteur de se reporter aux références[9] pour de plus amples précisions.

[modifier] Caractéristiques

[modifier] Utilisation de standards

Au lieu de recourir à des protocoles de chiffrements propriétaires ou obscurs, les concepteurs ont choisi des standards : TLS pour les communications entre les nœuds du réseau, AES et RSA pour le chiffrement (et la signature pour RSA), SHA-1 pour le hachage.

De la même manière, comme l'utilisation devait être quasi-transparente pour la majorité des applications, l'interface entre Tor et les logiciels est assurée par un proxy SOCKS[10]. Il devient donc inutile de développer des proxies applicatifs dédiés (comme c'était le cas lors pour la première génération) puisque un grand nombre de clients supportent la connexion via SOCKS. Toutefois, si tel n'est pas le cas, on peut avoir recours à des programmes détournant les appels systèmes[11][12]. Voir les références[13] pour plus de précisions. Pour la normalisation des données envoyées (connexion HTTP par exemple qui va révéler des informations sur le navigateur et la machine cliente) un proxy applicatif tel que Privoxy[14] peut (doit !) être utilisé.

[modifier] Architecture réseau

Les caractéristiques originelles de l'Onion Routing sont :

  • des cellules de taille fixe (512 octets) circulent entre les nœuds ;
  • lorsqu'un circuit est établi plusieurs flux TCP peuvent être multiplexés à l'intérieur.

De nombreuses améliorations ont également été apportées par rapport à la première version :

  • La topologie est dîte en "tuyau percé" (leaky-pipe) : il est possible de sortir du réseau au milieu du circuit établi (moyen pour échapper aux attaques d'analyse de flux par exemple).
  • Un contrôle sommaire de la congestion est effectué au niveau de chaque nœud pour empêcher l'apparition de goulots d'étranglement. On évite ainsi une gestion du trafic passant par une vue globale du réseau et des communications entre les nœuds.
  • Dans l'ancien Onion Routing les nœuds étaient découverts en noyant le réseau d'informations, ce qui s'est avéré complexe et peu efficace. Dans la nouvelle version certains nœuds servent d'annuaires (Directory Servers) stockant et signant une liste des différents nœuds existants et leur état. Ces serveurs sont peu nombreux et bien connus (afin de pouvoir leur faire confiance) et leur synchronisation suit un protocole simple. Les administrateurs de ces serveurs approuvent les nouveaux nœuds pour éviter qu'un adversaire ne pollue le réseau avec des nœuds malicieux. Cependant les concepteurs et développeurs du projet sont conscients que cette solution n'est viable que pour un petit réseau et cherchent donc des solutions alternatives.
  • Dans un tel réseau les nœuds sont administrés par des volontaires. Il est donc nécessaire qu'ils puissent choisir le rôle de leur nœud. Celui-ci peut donc être seulement un nœud intermédiaire ou bien un nœud de sortie avec la possibilité de configurer les ports en sortie (empêchant par exemple l'accès au port 25).

[modifier] Autres améliorations et ajouts

Dans la première génération d'Onion Routing aucune vérification de l'intégrité des données n'était faîte. N'importe quel nœud dans le circuit pouvait donc modifier les données et les transmettre. Un contrôle d'intégrité de bout en bout a donc été mis en place.

D'autre part, un nœud pouvait enregistrer le traffic et ensuite le faire déchiffrer par les autres nœuds. L'un des buts majeurs pour cette nouvelle version a été la mise en place du Perfect Forward Secrecy qui garantit que si une clé de session est compromise elle ne pourra pas aider à déchiffrer les sesssions antérieures.

Une possibilité a été ajoutée à Tor : afin d'échanger de l'information entre deux nœuds du réseau il est possible aux utilisateurs de créer des services cachés accessibles seulement par les membres de Tor. Un point de rendez-vous sert alors pour relier les deux correspondants (le client et le serveur) et assurer ainsi l'anonymat des deux participants.

[modifier] Fonctionnement

[modifier] Établissement d'un circuit

Fig. 4 : création d'un circuit

Le réseau de Tor est composé de différents nœuds : les Onion Routers (OR) qui constituent l'infrastructure du réseau et les Onion Proxies (OP) supportant le protocole SOCKS qui sont installés sur les machines clientes.

Pour se connecter au réseau Alice lance sur sa machine son OP. Il télécharge en HTTP la liste des nœuds depuis un des Directory Servers. Son OP choisit alors au hasard son OR de sortie suivant le port qu'il souhaite atteindre : OR2 (on a dit précédemment que les nœuds pouvaient configurer la politique de sortie). Il sélectionne enfin un OR au hasard en guise de nœud d'entrée sur le réseau : OR1.

L'OP envoie une cellule de demande de création d'un circuit à OR1 avec la première partie d'un échange Diffie-Hellman chiffrée avec la clé publique de OR1 (cellule create). Celui-ci la déchiffre et renvoie la seconde partie accompagnée d'un hachage d'un dérivé de la clé de session négociée (cellule created). D'après [9] ce protocole assure qu'Alice authentifie OR1 ainsi que la caractéristique de Perfect Forward Secrecy.

Alice demande alors à OR1 d'étendre le circuit. Pour cela elle envoie une cellule relay chiffrée avec la clé de session de OR1 contenant une cellule extend. Cette dernière est composée du nom de OR2 ainsi que de la première partie d'un échange Diffie-Hellman chiffrée avec la clé publique de OR2. OR1 désencapsule la cellule et la transforme en cellule create qu'il transmet à OR2. Les réponses sont alors assurées respectivement par les cellules created et extended. OR1 ne connaît donc jamais la clé de session partagée par Alice et OR2.

Lorsque Alice souhaite dialoguer avec le serveur web elle envoie ses données chiffrées avec la clé de session de OR2 puis chiffre le chiffré avec la clé de OR1. Elle transmet ensuite le paquet à OR1. Celui-ci déchiffre le paquet et le renvoie à OR2 qui le déchiffre à son tour et envoie la commande au serveur web. La réponse est chiffrée respectivement par OR2 puis OR1. Il ne reste plus à Alice qu'à déchiffrer les deux niveaux (d'où le nom d'onion).

La figure 4 synthétise toutes ces étapes.

[modifier] Accés à un service caché

Une des nouveautés de Tor par rapport à la première génération d'Onion Routing est la possibilité qu'ont les clients de fournir un service anonyme aux autres membres du réseau. L'anonymat fournit par cette méthode protège le serveur des dénis de service distribués car personne ne peut le localiser, laissant comme seule possibilité de s'attaquer au réseau Tor dans son ensemble.

Supposons que Bob veuille mettre en place un serveur web. La mise en place du service et de la communication avec Alice suit les points suivants :

  1. Il génère un couple clé publique - clé privée pour ce service et choisit certains nœuds du circuit (les Introductory Points) qui servent de points d'entrées. Il crée un message signé contenant le nom de ces points mais aussi sa clé publique.
  2. Il construit un circuit pour chaque point qu'il a choisi.
  3. Il crée un circuit jusqu'à chacun des Directory Servers et leur envoie le message créé en 1.
  4. Alice reçoit une adresse du type y.onion\[:port\]. Elle se connecte à son OP et lui demande une connexion pour y.onion\[:port\].
  5. Alice se connecte à un Directory Server et récupère les informations associées au service.
  6. Elle choisit ensuite un point de rendez-vous (qui est un nœud du réseau Tor) et construit un circuit jusqu'à lui.
  7. Elle se connecte à un Introductory Point via un circuit et lui donne le nom de son point de rendez-vous et la première moitié d'un échange Diffie-Hellman, le tout chiffré avec la clé publique du service de Bob.
  8. L'Introductory Point transmet le message à Bob via le circuit.
  9. Bob choisit ou non de parler à Alice et se connecte à son point de rendez-vous dans l'affirmative. Il envoie alors la seconde partie de l'échange Diffie-Hellman, relayé par le point de rendez-vous.
  10. Alice la reçoit et initie la connexion vers Bob via son circuit en chiffrant sa requête avec la clé de session issue de l'échange.

[modifier] Conclusion

Tor est un projet jeune mais prometteur. Il est en pleine évolution et des modifications majeures sont toujours possibles (pour remplacer les Directory Servers par exemple). La liste de diffusion[15] est très dynamique et montre la réactivité des développeurs lors de la découverte d'un buf. Depuis décembre Tor est sponsorisé par l'EFF (Electronic Frontier Foundation)[16].

Est-ce la cause de l'augmentation du réseau de Tor ? Toujours est-il que le nombre de nœuds s'est accru à la même époque : le réseau est passé de 40 nœuds vérifiés (très peu non vérifiés) pour 15 Mo/s de traffic en sortie à 80 vérifiés et 30 non vérifiés en janvier pour 30 Mo/s[17]. Cependant, que ces chiffres ne leurrent pas l'utilisateur potentiel : ils ne réflètent pas la lenteur relative du réseau (notamment pour le traffic web). Si on utilise Tor c'est pour l'anonymat proposé et non le confort pour le surf. Il vaut mieux oublier le P2P même si certains profitent de ces réseaux pour éviter les risques de poursuites judiciaires[18]. La réponse des développeurs est de limiter la bande passante décourageant ainsi les éventuels petits malins :-)

D'autre part certains problèmes persistent. Il n'y a toujours pas eu d'analyse extérieure pour juger de la sécurité du protocole et de l'implémentation. Plus grave : le traffic d'un utilisateur sort par une machine unique qui initie la connexion en lieu et place de cet utilisateur. Que se passe-t-il si la personne est malveillante et passe par Tor pour lancer son attaque sur www.nsa.gov ou surfe sur des sites pédophiles ? Tout dépend du pays où se trouve la machine de sortie nous rétorquerez-vous à juste titre. Or à l'heure de la rédaction de l'article deux nœuds se trouvent en France[19] par exemple ... Que dira la justice française ?

[modifier] Conclusion

L'anonymat sur Internet n'est pas chose aisée. Il est difficile d'inventer un protocole sûr et de l'implémenter comme en témoignent nos deux logiciels qui sont les évolutions d'une première génération présentant de nombreux défauts et dont les spécifications s'améliorent encore. Il est cependant incontestable que ces systèmes vont continuer à fleurir au vu des différentes menaces pesant sur l'utilisateur d'Internet.

[modifier] Références

  1. Anonymizer - http://www.anonymizer.com/
  2. Mixmaster - http://mixmaster.sourceforge.net/
  3. EFF Email Privacy, Remailer - http://www.emailprivacy.info/remailers
  4. Reliable - http://www.skuz.net/potatoware/reli/
  5. Mixminion - http://mixminion.net/
  6. Nymserv Email Pseudonym Server - http://sourceforge.net/projects/nymserv/
  7. The Onion Routing - http://www.onion-router.net/
  8. Tor: An anonymous Internet communication system - http://tor.eff.org/
  9. DINGLEDINE R., MATHEWSON N., SYVERSON P. Tor: The Second Generation Onion Router - http://tor.eff.org/cvs/tor/doc/design-paper/tor-design.html
  10. The Source for SOCKS Technology - http://www.socks.permeo.com/
  11. tsocks - Transparent SOCKS Proxying Library http://tsocks.sourceforge.net/
  12. socat - Multipurpose relay - http://www.dest-unreach.org/socat/
  13. TORifying software HOWTO - http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO/
  14. Privoxy - http://www.privoxy.org/
  15. Liste de diffusion or-talk - http://archives.seul.org/or/talk/
  16. Electronic Frontier Foundation - http://www.eff.org/
  17. Number of Running Tor routers - http://www.noreply.org/tor-running-routers/
  18. How to set up Azureus to work with Tor - http://azureus.sourceforge.net/doc/AnonBT/Tor/howto_0.5.htm
  19. Tor Exit Node Status - http://serifos.eecs.harvard.edu:8000/cgi-bin/exit.pl



  • Cédric blancher - Ingénieur-chercheur en Sécurité des Systèmes d'Information, Centre Commun de Recherche, EADS France - cedric dot blancher at eads dot net
  • Arnaud Guignard - Ingénieur-chercheur en Sécurité des Systèmes d'Information au CEA/DAM - arno at rstack dot org
Navigation
autres
Locations of visitors to this page

No software patents !

Valid XHTML 1.0 Transitional

Valid CSS 2.1