Tor, conception, fonctionnement et limites

PAGE EN COURS D'ECRITURE !!!

Tor (Acronyme de "The Onion Router", le routage en oignon), est un réseau mondial décentralisé de serveurs mis à disposition par des bénévoles, et dont l'objectif est l'anonymisation des connexions internet. Il ne faut pas confondre Tor et le Tor browser. Tor désigne le réseau de serveurs. Le Tor browser est un client firefox modifié qui envoie les connexions dans le réseau Tor. L'origine de l'appellation "routage en oignon" fait référence à l'encapsulation des données envoyées ou reçues à l'intérieur de plusieurs "couches" de chiffrement qui sont "épluchées" ou reconstituées au fur et à mesure du trajet dans le cuircuit tor, à l'instar des couches d'un véritable oignon.

Histoire

• A VENIR*

Conception

Généralités

Tor est un réseau mondial décentralisé de serveurs mis à disposition par des bénévoles et dont l’objectif est d’anonymiser les connexions à Internet. Tor est devenu assez populaire depuis les révélations d’Edward Snowen en 2013. En Juin 2017, on estime le nombre d’utilisateurs de Tor à 2 375 000 par jour. La plupars de ces utilisateurs sont situés aux états unis (20,62% du total), aux Emirats Arabes Unis (21,52%, Alors que Tor est illégal là bas, voir chapitre légalité), et en Russie (10,64%). La France arrive en 5ème position avec 4,65% des utilisateurs. L’idée de base, c’est que lorsque votre machine voudra accèder à Internet via le réseau Tor, elle va sélectionner au hasard 3 serveurs (Appelés des relais ou des noeuds) dans ce réseau, elle va chiffrer 3 fois cette requête, et va l’envoyer aux serveurs qui vont la relayer en “pelant” chacun au passage une couche de chiffrement. Il existe donc 3 types de relais, chacun d’entre eux assurant des missions distinctes et ayant des modes de fontionnement différents :

• Le noeud d’entrée
  • Noeud Gardien
  • Bridge
• Le noeud intermédiaire
• Le noeud de sortie

Tor assure l’anonymat dans un sens (Protection du client), mais pas nécessairement celui du serveur. Par exemple, quand vous vous connectez sur www.psychoactif.org, le serveur n’est pas anonyme puisqu’il est indexé dans les serveurs DNS. Tor permet également d’assurer l’anonymat d’un serveur hébergeant un site web qui sera alors typiquement en .onion (au lieu d’être en .fr .com .org, etc). Par exemple, certains moteurs de recherches tels que duckduckgo (https://duckduckgo.com) peuvent utiliser ce mécanisme (en l’occurence : https://3g2upl4pq6kufc4m.onion/). Un tel site web est alors appellé un “service caché” (sous entendu : dans le réseau Tor) et ne peut pas être tracé. L’ensemble de tous les services cachés est communément appellé le “Deep Web”, bien que cette appellation ne soit pas appréciée par de nombreux hacktivistes qui la jugent trop péjorative. Le nombre de services cachés, c’est à dire la taille du “Deep Web”, est estimée à 60000 à la date d’aujourd’hui (*Date d’aujourd’hui*)

Cette animation montre le flux Tor à travers le monde et au cours des années : https://torflow.uncharted.software/#?ML=34.98046875,31.12819929911196,3&C=ru,RUS

Le noeud d'entrée

Cette catégorie comporte deux sous-catégorie : les noeuds gardiens et les bridges. Dans les deux cas, ce noeud va servir de point d’entrée dans le réseau Tor. Concrètement, votre machine se connectant à Internet via Tor va envoyer la requête au noeud d’entrée, lequel va la transmettre au noeud intermédiaire. La différence entre un noeud gardien et un bridge, c’est que la liste des noeuds Tor (hors bridges) est publique, tandis que la liste des bridges est tenue secrète par le Tor Project. Ceci a pour conséquence que le bridge masque le fait que vous utilisiez Tor auprès de votre FAI ou de toute personne qui se placerait entre vous et le bridge. Si vous utilisez un noeud gardien (ce qui est le cas par défaut), votre FAI verra que vous utilisez Tor et pourra potentiellement vous bloquer (même s’il ne connaîtra ni la destination, ni le contenu de la requête). L’utilisation de bridge est intéressante dans les pays ou Tor est bloqué ou illégal (voir chapitre légalité). Pour utiliser un bridge, il faut en faire la demande au Tor project, qui distribue une ou deux IP de bridges à la demande. Vous pouvez par exemple obtenir des bridges ici : https://bridges.torproject.org/bridges.

Par sécurité, Tor renouvelle le circuit toutes les 10 minutes pour brouiller les pistes et limiter les information qu’un attaquant controllant un noeud pourrait récupérer. Cependant, Le noeud d’entrée, qu’il soit bridge ou gardien, est fixe et ne change que tous les 2 à 3 mois pour un noeud gardien. Ce temps est appellé la “période de rotation”. Le Tor Project est même en train de réfléchir pour faire passer la période de rotation à 1 an. Alors, pourquoi ça ? C’est vrai que ça peut sembler contre-intuitif comme ça. Mais il y a des bonnes raisons :

1 : Supposons qu’un attaquant fasse tourner plusieurs relais en vue d’analyser le traffic pour desanonymiser les utilisateurs de Tor et ce qu’ils font sur internet. Si jamais votre connexion Tor entre et sort par des relais contrôlés par cet attaquant, c’est l’un des pires scénarios qui puisse arriver car il peut faire des corrélations et vous griller (Voir chapitre “vulnérabilités”). Le fait d’avoir un noeud d’entrée (bridge ou gardien) qui soit fixe, et un noeud de sortie mobile, bien que ne changeant pas le risque que ce scénario se produise pour un circuit donné, diminue le risque cumulatif au fur et à mesure que vous changez de circuit.

2 : Supposons qu’un attaquant veuille faire passer les connexions à travers des relais qu’il contrôle. On pourrait immaginer que cet attaquant va faire une attaque DoS (Denial of Service) sur des relais qu’il ne contrôle pas, par exemple en les saturant de requêtes pour les planter. Si le noeud d’entrée n’était pas fixe, l’attaquant pourrait alors augmenter les probabilités que ses machines soient choisies pour concentrer le traffic Tor et l’analyser. Le fait que les noeuds d’entrée soient fixes permet d’éviter ce scénario.

3 : Un noeud ne devient pas bridge ou gardien comme ça. Si un serveur veut acquérir le statut de gardien, il doit remplir certaines conditions, notamment de bande passante, de stabilité, et surtout d’ancienneté. De plus, une fois que le serveur a acquit le statut de gardien, il faudra encore du temps pour que les clients Tor le choisissent en fonction de leurs périodes de rotation respectives.

Le noeud de sortie

Le noeud de sortie est le plus critique des 3 noeuds. En effet, le noeud de sortie va “peler” la dernière couche de chiffrement et va donc avoir accès à la requête en clair, dans laquelle peut se trouver des informations sensibles telle que des identifiants, des mots de passe, des informations personnelles, les fichiers téléchargés, etc. Ca veut dire que même si le noeud de sortie ne connaît pas l’IP de votre machine, vous pouvez quand même être desanonymisé. Pire : il est même théoriquement possible de modifier le contenu, voire de pirater purement et simplement votre machine en y insérant des virus, des backdoors ou d’autre saloperies de ce genre. Le problème se pose aussi pour les sites en https car il est possible de modifier les requêtes pour les rediriger en http. Bref, pour un attaquant (Un pirate ou un gouvernement), contrôler un noeud de sortie, c’est du pain béni.

Pour cette raison, le Tor Project surveille très étroitement les noeuds de sortie. Un projet de recherche appellé “Spoiled Onions” conduit en octobre 2013 et publié en janvier 2014 avait pour objectif de trouver les “oignons pourris” du réseau Tor. Pour celà, ils ont dévelloppé deux outils de scan de noeud de Sortie : Exitmap et HoneyConnector.

Exitmap permet de détecter les manipulations du traffic en établissant une connexion Tor vers un leurre controllé par le Torproject (En sécurité informatique, on appelle ça un “pot de miel”, référence à un véritable pot de miel pour pièger les insectes). On sait ce qu’on envoie dans le réseau, et on regarde ce qui arrive sur le pot de miel. Si le traffic a été modifié, alors ça veut dire que le noeud de sortie modifie les trames réseau.

Honeyconnector permet de détecter le sniffage passif du traffic (C’est à dire la récupération des information sans les modifier). Concrètement, on envoie via Tor un couple unique “identifiant/mot de passe” sur un pot de miel toujours controllé par le Torproject. Ensuite, si une tentative de connexion a lieu ulterieurement sur ce pot de miel, alors on sait que le noeud de sortie par lequel ce couple d’identifiant est passé l’a intercepté.

Ce projet de recherche a mis en évidence 65 oignons pourris sur 1000 analysés, 40 qui modifiaient activement le traffic, 27 qui le sniffaient passivement, et 2 qui faisaient les deux. Le tor project fait régulièrement tourner Exitmap et Honeycollector pour trouver et bannir les oignons pourris. Pour la petite histoire sordide, sachez que cette étude a mis en évidence que les oignons pourris avaient beaucoup de similitudes et qu’on pouvait les classer en groupes. Un de ces groupes était constitué de 20 oignons pourris localisés en Russie qui collaboraient entre eux et étaient contrôlés par la même entité. La même chose a été observé pour un groupe localisé en Inde et un groupe décentralisé. De plus, les attaques ne sont pas systématique, mais avaient des destinations cibles spécifiques. Ainsi, le groupe russe ciblait exclusivement les connexions à Facebook. Ca veut dire que les oignons pourris ne sont pas tenus par des scripts kiddies ou des loups solitaires, mais par des entités organisées qui ont les moyens de faire tourner plusieurs dizaines de serveurs et d’analyser le gros paquet de données qui en résulte.

Le consensus

A la date du 06/06/2017, le réseau Tor comporte 7199 noeuds dont 2439 noeuds gardiens, 814 noeuds de sortie, ainsi que 3541 bridges (non comptabilisés dans ce total). Cet inventaire est actualisée tous les jours sur le site de Tor Metrics. La liste de tous les noeuds Tor disponibles, à l’exception des bridges, est publique et consultable librement (Voici la référence du consensus du 04/06/2017 à 21h00 contenant les IPs de tous les noeuds disponibles à ce moment ).

Un tel nombre de noeud, associé à leur volatilité (Les noeuds peuvent rentrer et sortir à leur gré du réseau, ou changer d’état et passer noeud gardien, ou alors être bannis parce que ce sont des oignons pourris) pose un problème de maintenance. Le Torproject a donc déployé une poignée de serveurs particuliers appellés les autorités d’annuaire. Les IPs de ces autorités d’annuaires sont codées en dur à l’intérieur de chaque client Tor. Elles sont au nombre de 9 :

IP	Nom de code	Localisation
171.25.193.9	Maatuska	Stockolm, Suède
86.59.21.38	Tor26	Vienne, Autriche
199.254.238.52	Longclaw	Seattle, USA
194.109.206.212	Dizum	Amsterdam, Pays-Bas
131.188.40.189	Gabelmoo	Erlangen, Allemagne
128.31.0.39	Moria1	Cambridge, Massachusetts, USA
193.23.244.244	Dannenberg	Hambourg, Allemagne
154.35.175.225	Faravahar	Washington, USA
37.218.247.217	Bifroest	Amsterdam, Pays-Bas

Le rôle de ces autorités d’annuaire est de maintenir toutes les heures un annuaire de tous les relais Tor disponible. Cet annuaire est appellé le consensus. Sur ces 9 serveurs, 8 gèrent les relais publics et 1 (Bifroest) gère les bridges.

Concrètement, toutes les heures, les 8 autorités d’annuaires vont :

1 : Compiler chacun de leur côté une liste de tous les relais connus, avec leurs informations respectives. En effet, les relais envoient périodiquement leurs données aux autorités.

2 : Calculer toujours séparément des informations relatives à ces relais, et décider si les relais sont “bons pour le service”. C’est notamment à ce moment là que les noeuds peuvent se voir attribuer le statut de gardien, et les oignons pourris recevoir le statut de “Bad Exit”.

3 : Se concerter et voter pour atteindre un consensus au niveau de l’annuaire ainsi créé.

4 : Publier le consensus (l’annuaire) à la disposition de tous les clients Tor.

Du coup, quand votre machine voudra utiliser Tor pour se connecter à Internet, elle va commencer par télécharger le consensus, et elle va établir un circuit aléatoire à partir des informations contenue dans le consensus.

Fonctionnement

Connexion classique non torrifiée

Connexion http non chiffrée à www.psychonaut.com sans passer par Tor

Connexion https à www.psychoactif.org sans passer par Tor

Supposons que vous vouliez vous connecter à www.psychoactif.org. Par exemple, vous rentrez sur un moteur de recherche “psychoactif” et vous cliquez sur le lien correspondant. Votre ordinateur va envoyer l’URL www.psychoactif.org à votre fournisseur d’accès à internet (FAI). Le problème, c’est que le FAI ne sait pas ce que veut dire www.psychoactif.org. Il ne comprend que les IP. Il faut donc qu’il convertisse l’URL en IP. Il fait donc appel pour cela à ce qu’on appelle un serveur DNS (Domain Name Server) via ce qu’on appelle une “Requête DNS”. Un serveur DNS, c’est en gros une sorte d’annuaire qui converti une URL (www.psychoactif.org) en IP (178.33.8.209) avec les informations correspondantes (Hébergé chez OVH). Une fois que le FAI a récupéré tout ça, il envoie à OVH la requête “A.B.C.D (votre IP) souhaite avoir le contenu de 178.33.8.209 qui est chez toi”. Une fois que OVH a envoyé les informations demandées, le FAI transfère les données sur votre poste.

On peut immédiatement voir que :

• Le FAI peut voir ce que vous faites sur internet.
• Le FAI peut, sous décision judiciaire par exemple, refuser de vous fournir le contenu de telle ou telle IP.
• Le FAI peut, sous décision judiciaire ou à des fins publicitaires, modifier les requêtes DNS ou avoir recourt à des DNS menteurs pour vous donner du contenu alternatif sans que l’utilisateur ne s’en apperçoive.
• 178.33.8.209 et par extension, OVH peut voir que vous êtes allé chez lui.
• Si le site n’est pas en https, tout transite en clair sur internet depuis votre ordinateur jusqu’au site que vous contactez. Le FAI, OVH, ou tout pirate placé entre les deux extrémités peuvent donc intercepter vos identifiants et mot de passe, et les donner/revendre à la police. Ce problème ne se pose pas avec Psychoactif qui est en https. En revanche, il se pose avec psychonaut.com.

Connexion à l'internet classique via Tor

Etablissement d'un circuit Tor

Voici ce que fait votre machine quand vous voulez accéder à www.psychoactif.org via Tor :

• 1 : Télécharger le consensus
• 2 : Sélectionner aléatoirement un noeud gardien, un noeud intermédiaire et un noeud de sortie à partir du consensus

Une fois que c’est fait, c’est là que ça se complique un peu, parce qu’il va falloir négocier des clés de chiffrement avec chacun des relais de façon anonyme, au moins pour le 2èm et le 3èm. Votre machine va donc :

• 3 : Récupérer les 3 clés publiques des 3 relais depuis un serveur de clés. Ces clés vont servir pour l’authentification

Négociation avec le noeud gardien

• 4 : Entamer un handshake avec le noeud gardien. Au cours de cette poignée de main, le noeud gardien va s’autentifier en signant la poignée de main avec sa clé privée (l’algorithme utilisé par Tor est RSA 1024 bits. Tor est actuellement en train de migrer vers une courbe elliptique Curve25519 plus sécurisée). Le client (votre machine) va vérifier la signature à l’aide de la clé publique récupérée en 3.

• 5 : Négocier une clé de chiffrement symétrique (AES 128), qu’on appelle une clé de session (Clé1), avec le premier noeud suivant le protocole d’échange de Diffie-Hellman. Le protocole de Diffie Hellman permet de négocier une clé symétrique sans avoir à se l’échanger directement.

Négociation avec le noeud intermédiaire. Un peu plus difficile car il ne faut pas que le noeud intermédiaire connaisse le client.

• 6 : Handshake avec le noeud intermédiaire (NI) à travers le noeud gardien (NG). Le client envoie une demande de connexion au NG chiffré avec Clé1 en lui demandant de la transmettre au NI. Le NG déchiffre avec la clé de session et découvre qu’il doit transmettre au NI. Le NI répond au NG en signant avec sa clé privée (toujours RSA 1024 ou Curve25519). Le NG chiffre avec la clé de session Clé1 et transmet ensuite au client. Le client déchiffre la réponse avec Clé1 et vérifie la signature.
• 7 : Négociation de Diffie-Hellman pour une deuxième clé de session symétrique (Clé2), toujours en passant par le NG.

Négociation avec le noeud de sortie (NS). Encore plus difficile parce que le NS ne doit connaitre ni le client, ni le NG, et le NG ne doit pas connaitre le NS non plus.

• 8 : Handshake avec le NS à travers les 2 noeuds précédents. Le client envoie une demande de connexion chiffrée 2 fois avec Clé1 et Clé2 et l’envoie au NG. Le NG déchiffre la première couche avec clé 1, mais ne peut toujours pas lire le contenu puisqu’il est chiffré aussi avec Clé2 et qu’il n’a pas cette clé. Il envoie donc le contenu chiffré avec Clé2 au NI. Le NI déchiffre avec Clé2 et transmet au NS. Le NS signe et renvoie au NI. Le NI chiffre avec Clé2 et envoie au NG. Le NG chiffre avec Clé1 et renvoie au client. Le client déchiffre avec Clé1 et Clé2 et vérifie la signature avec la clé publique du NS.
• 9 : Négociation de Diffie Hellman avec le NS.

Echange des données

Connexion https à www.psychoactif.org sans passer par Tor

Connexion https à www.psychoactif.org sans passer par Tor

Supposons que vous vouliez vous connecter à www.psychonaut.com

Votre machine va d’abord établir un circuit Tor comme expliqué ci dessus. Ensuite, il faudrait normalement faire la résolution DNS (Rapellez vous, c’est ce qui permet de convertir psychonaut.com, incompréhensible pour une machine, en adresse IP). Or il n’est pas possible de faire cette résolution DNS soi même pour des raisons évidentes d’anonymat. En effet, celà voudrait dire que vous devriez envoyer la requête (www.psychonaut.com) au FAI pour demande aux serveurs DNS, et le FAI saurait alors quels sites vous visitez. Notez que ce petit problème s’est déjà présenté avec certains utilisateurs de Tor, et surtout de VPN. On appelle ça un DNS leak (fuite DNS). Du coup, impossible de faire la requête DNS. Le client va donc envoyer la requête telle quelle dans le réseau TOR et c'est le NS qui va se charger de la résolution DNS.

Connexion à un service caché

Un service caché est un site en .onion. C'est ce que l'on appelle communément le deep web. L'intérêt d'un service caché réside principalement dans le fait qu'il n'est pas localisable. En effet, c'est l'adresse IP, attribuée par le fournisseur d'accès à internet, qui permet de localiser un site internet. L'accès à un service caché ne fait pas intervenir son IP. De plus, les entités qui ont accès à l'IP (comme le FAI) n'ont pas accès au contenu qui n'est accessible que via le réseau Tor.

Prenons à titre d'exemple le moteur de recherche Grams, inspiré de google (http://grams7enufi7jmdl.onion). Supposons qu'un utilisateur veuille se connecter à ce service caché. Voici comment se déroule l'établissement de la connection.

Etape 1 :

Etape 1

Le service caché va établir quelques circuits et demander aux relais de sortie de servir de point d'introduction (Je n'en ai représenté que deux dans l'exemple). Concrètement, le service caché commence par récupèrer les IP de ces points d'introduction, en l'occurence 198.50.159.155 et 41.231.53.101 (exemples réels d'IP de noeuds de sortie).

Etape 2 :

Etape 2

Le service caché va ensuite demander aux points d'introduction de maintenir la connection. Pendant ce temps, il va établir un circuit TOR vers un Hidden Service Directory (HSDir) et y uploader un descripteur de service caché. En effet, les services cachés ont besoin de signaler leur existence afin d'être contacté. Ce descripteur se compose de :

• Les IP des points d'introduction
• La clé publique du service caché
• La signature des deux éléments précédents, faite avec la clé privée correspondante.

Un HSDir est un relai Tor comme un autre, mais qui va assurer une fonction supplémentaire. Il va recevoir des informations sur les services cachés afin de permettre aux utilisateurs de Tor de les contacter. Un relai acquiert le statut de HSDir via le consensus, au même titre que les noeuds de sortie ou les noeuds gardiens .

Etape 3 :

Etape 3

Supposons maintenant que vous, utilisateur, souhaitiez contacter Grams. Votre machine, après avoir téléchargé le consensus et trouvé dedans les IP des HSDir, va les contacter, toujours en passant par le Réseau Tor. Votre client va télécharger le descripteur de service caché et vérifier la signature. Votre machine connaît maintenant les IP des points d'introduction.

Etape 4 :

Etape 4

Votre machine va maintenant établir un circuit aléatoire. Le noeud de sortie choisi sera le point de rendez-vous. Après avoir établi la connexion, votre machine va communiquer au point de rendez-vous un secret (sous la forme d'un cookie) qui servira à authentifier le service caché.

Etape 5 :

Etape 5

Votre machine va garder la connexion au point de rendez-vous en attente. Elle va ensuite établir un circuit aléatoire vers un des points d'introduction, dont les IP ont été téléchargées depuis le HSDir. Le point d'introduction va ensuite relayer les données jusqu'au service caché.

Concrètement, le client Tor va envoyer au service caché l'IP du point de rendez-vous, la première partie de l'échange de Diffie-Hellman qui servira à négocier une clé symétrique entre le client et le service caché, et le secret qui a été dit au point de rendez-vous. Ces informations sont chiffrées avec la clé publique du service caché (téléchargée depuis le HSDir), et ensuite protégée dans le traditionnel oignon de chiffrement de Tor. Les 3 relais côté client épluchent chacun une couche de l'oignon, et les 3 relais côté service caché en reconstituent chacun une.

Etape 6 :

Etape 6

Le service caché contacte le point de rendez-vous en lui disant le secret qu'il a reçu du client. Ceci permet au point de rendez-vous d'authentifier le service caché.

Etape 7 :

Etape 7

Dernière étape : le client et le service caché s'occupent de la deuxième partie de l'échange de Diffie-Hellman. Ceci aboutit à la création d'une clé symétrique AES qui permettra au client et au service caché de communiquer en chiffré de façon symétrique.

résultat final :

Résultat final.

Voici à quoi ressemble une connexion établie à un service caché. Notez que cette fois, il n'y a pas trois, mais six relais. Quel que soit le sens, les 3 premiers relais épluchent une couche de l'oignon et les 3 dernier en reconstituent une. La présence de six relais au lieu de trois explique pourquoi le deep web est bien plus lent que le web classique.

Vulnérabilités de Tor

Javascript

Javascript est un langage de programmation qualifié de "client side". Concrètement, quand vous vous connectez à un site hébergé sur un serveur, vous êtes le client et le code s’exécutera de votre côté. Javascript est un langage extrêmement répandu sur internet au point que beaucoup de sites internet ne puissent tout simplement pas fonctionner s'il est désactivé.

Javascript est sans doute l'un des points les plus sensibles lorsqu'on utilise Tor. D'un côté, comme on vient de le voir, beaucoup de sites ne fonctionnent pas sans. De l'autre côté, il existe des exploits javascript qui peuvent être envoyés par le serveur pour faire exécuter du code malicieux par votre ordinateur.

C'est de cette façon qu'une vulnérabilité affectant le navigateur firefox qualifiée de critique par Mozilla a été publiée en 2013. Etant donné que le Tor browser est un firefox customisé, il est donc également concerné. Cette vulnérabilité concerne en théorie tous les systèmes d'exploitation, et comme elle permet de faire exécuter du code arbitraire sur votre ordinateur, il est en théorie possible d'en prendre le contrôle.

Concrètement, cette vulnérabilité a été exploitée en 2013 par le FBI pour démanteler un ensemble de services cachés pédopornographiques. L'attaque consistait à faire injecter le code javascript exploitant la vulnérabilité par l'hébergeur de service cachés (en l'occurence Freedom hosting). Ensuite, le code éxécuté par la machine cible de l'utilisateur (le payload) récupérait le nom de la machine et l'adresse mac, et l'envoyait sur un serveur via une connexion non torrifiée, ce qui permettait également de récupérer l'IP réelle .

En 2016, une nouvelle vulnérabilité javascript inconnue à ce jour (On appelle ça une faille 0-day) a été exploitée 2016 pour desanonymyser des utilisateurs de Tor . Aujourd'hui, nous ne connaissons pas encore l'identité des attaquants. Cependant, le payload étant extrêmement proche de celui de 2013, il est possible qu'il s'agisse encore une fois d'une organisation gouvernementale.

Il est cependant très facile de prévenir cette attaque. Il suffit d'interdire le Javascript via le plugin "NoScript" installé par défaut sur le TorBrowser. Cependant, comme expliqué ci dessus, beaucoup de sites du clearweb ne fonctionnent pas sans Javascript. En revanche, à cause de ces vulnérabilités maintenant connues, aucun service caché sérieux n'incluera de Javascript dans le code source de sa page. En d'autres termes, vous pouvez (vous devriez) désactiver Javascript sur le deep web sans vous poser de questions. Si un service caché a besoin de Javascript pour fonctionner, n'y allez pas.

Analyse de traffic

Le concept d’une attaque par analyse de traffic est assez simple. Supposons que deux personnes s’échangent des messages chiffrés et qu’un attaquant surveille cet échange. Etant donné que les messages sont chiffrés, l’attaquant n’a pas accès au contenu. En revanche, la fréquence d’échange des messages ainsi que leur taille sont des indications qui permettent à un attaquant de faire des déductions quant à leur contenu ou leur destination.

Prenons un exemple très concret. Normalement, Tor est censé réactualiser le circuit Tor toutes les 10 minutes. Or il existe quelques exceptions à cette règle : lorsque vous maintenez un échange de données ininterrompu avec un serveur en passant par Tor (par exemple, en téléchargeant ou en uploadant), le circuit ne peut pas être réactualisé pendant l’échange . Supposons que vous téléchargiez vraiment un gros fichier, genre un film de 2h30 en full HD de 10Go sur youtube via le logiciel youtube-dl, et que ça prenne, mettons, 5 heures. Pendant 5 heures, vous allez garder le même circuit (Exemple quasi réel : j’ai déjà de cette façon réalisé des téléchargements qui ont duré plus de 10 minutes). Si un attaquant qui controle des relais Tor voit que le serveur de youtube fait rentrer par un relai un énorme fichier pendant 5 heures, et qu’à un autre endroit, un autre relai envoie à un utilisateur un autre gros fichier pendant 5 heures, il peut raisonnablement en conclure que vous êtes en train de télécharger un film sur youtube (sans pour autant avoir accès au fichier en question). Quant à vous, vous êtes grillés !

Il y a de multiples façons de faire de l’analyse de traffic. La plus simple est par exemple de regarder les demandes de connexions entrantes et sortantes et de les corréler entre elles . Il est également possible de compter les paquets entrant et les paquets sortant. D’autres attaques un peu plus sophistiquées impliquent de router un traffic initié par l’attaquant à travers un relai Tor spécifique et à destination d’un serveur controllé par l’attaquant. Ce traffic va devoir être processé par le relai Tor en question, ce qui va influencer la latence de tous les traffics qu’il doit processer, leur imprimant à tous un pattern de débit. Il suffit ensuite au serveur compromis d’analyser le pattern de débit qui lui est personnellement destiné, et de voir où est ce que ce pattern se retrouve dans le réseau pour en déduire que ces traffics sont passé par ce relai spécifique

Il existe des tas et des tas d’autres façon de faire de l’analyse de traffic. Je terminerai en expliquant une dernière attaque très compromettante. Il s’agit d’imprimer activement des perturbations de débit dans les connexions à destination ou en provenance d’un serveur (comme un site web) en détournant le traffic avant qu’il n’entre dans le réseau Tor. Il suffit de voir ensuite où est ce que ces perturbations se retrouvent pour desanonymiser les gens qui ont contacté ce serveur, y compris à travers Tor. C’est de cette façon que 81% des utilisateurs de Tor peuvent être desanonymisés avec un taux de faux positifs de 6%.

C’est réellement un problème car les solutions qui permettraient de fixer ce problème risquent de gravement nuire à l’utilisabilité de Tor. Par exemple on pourrait imaginer introduire du traffic “parasite” qui serait trié de façon transparente directement par le client et le serveur, mais on augmenterait alors drastiquement la bande passante de Tor. On pourrait également introduire des perturbations aléatoires de débit, mais celà ralentirait considérablement les connexions Tor qui sont déjà réputées être lentes. Cependant, le TorProject a mitigé les résultats de l’analyse par perturbation de traffic en argumentant que 6% de faux positifs, celà peu sembler peu, mais c’est en réalité énorme, suffisemment pour rendre l’attaque inexploitable en tant que tel .

C’est précisément pour cette raison qu’il est dangereux d’utiliser un VPN en entrée du réseau Tor. Malgré ce que peuvent dire les conditions d’utilisation et la politique de confidentialité des prestataires de VPN, vous n’avez que leur seule parole qu’ils ne conservent pas de logs et qu’ils n’analysent pas votre traffic. Tor est un logiciel open source maintenu par le Torproject, une association à but non-lucratif. De plus, le TorProject fait activement la chasse aux relais qui analysent ou interagissent avec le traffic comme on l’a vu dans la rubrique “Noeuds sortants”, et l’analyse de traffic nécessite justement bien souvent de controller au préalable des relais (idéalement, les deux tiers, c’est à dire les relais d’entrée et de sortie). Or les VPN échappent complètement à la surveillance du TorProject et n’ont de compte à rendre qu’à ceux qui font pression sur eux. Le VPN devient donc de fait le maillon faible de la chaîne, ce qui réduit le nombre de relais Tor à controller. Si on prend l’attaque par injection de pattern temporel dans le débit et qu’il y a un VPN en entrée, il n’y a même pas besoin de controller un seul relai pour desanonymiser.

Fingerprinting de la souris

Lorsque vous naviguez sur internet, votre façon de cliquer, de scroller et de déplacer la souris est unique. Ceci est particulièrement vrai lorsqu’on utilise un pavé tactile. Une part dépend de votre matériel (toutes les souris n’ont pas le même nombre de boutons, petit clin d’oeil aux gamers (-; ), et une pârt dépend purement de vous.

Un chercheur a récemment mis en évidence qu’il était possible de récupérer les données relatives à la souris, à ses mouvements et à sa façon d’interagir avec l’unité centrale

Voici une démonstration de ce qu’il est possible de faire (nécessite que javascript soit activé). Allez sur cette page :

http://jcarlosnorte.com/assets/fingerprint/

Cette page a été réalisée par le chercheur en question. Mettez votre souris dans le carré rouge, et scrollez jusqu’à ce qu’elle en sorte. Le premier et le troisième graphique représentent la même chose : en abscisse le nombre de fois où vous avez scrollé, et en ordonnée le temps écoulé entre deux scroll. Le deuxième graphique représente le delta, c’est à dire la quantité de défilement par incrément de scroll. Si vous utilisez une vraie souris, ce nombre est une constante et est souvent égal à 3.

Voici une autre page qui montre ce qu'on peut obtenir comme information :

http://jcarlosnorte.com/assets/ubercookie/

Cette autre page montre d’autres informations qu’il est possible d’obtenir, à savoir la vitesse de défilement de la souris, mais aussi d’autres statistiques annexes comme la position exacte d’un élément en particulier dans la fenêtre ou encore la puissance du processeur. Autant d’éléments qui peuvent servir à vous tracer.

Pour l’instant, cette attaque est purement théorique et n’a jusqu’à aujourd’hui jamais été utilisée en pratique pour desanonymiser des utilisateurs de Tor. Cependant, La preuve de concept apportée par ce chercheur met en lumière une grave faille de sécurité de Tor. Si un attaquant commence à établir des bases de données relative à la souris des utilisateurs sur le clearweb (donc non-anonyme) et fait la même chose pour les utilisateurs de Tor, il peut par corrélation desanonymiser ses utilisateurs.

Et devinez quoi ? Tout ces processus de tracking utilisent… Javascript !!!

Il est donc extrêmement important d’interdire le Javascript à chaque fois que c’est possible, et systématiquement sur le Deep Web.

Faiblesse des clés d’authentification

NB : Ce chapitre nécessite d’avoir lu et compris l’annexe “Protocoles cryptographiques”.

Lors de l’étape d’autentification entre le client et le serveur (c’est à dire le relai), le relai utilise une clé de 1024 bits, ce qui est trop faible et crackable avec un supercalculateur. Concrètement, un attaquant qui arrive à casser ces clés peut usurper l’identité d’un relai Tor et obliger les connexions à transiter par sa machine au lieu du relai Tor légitime. Ceci est du au fait que 90% des relais Tor tournent sur des vieilles version du protocole et ne sont pas mise à jour. Les machines utilisant la version 2.4 du protocole utilisent des courbes elliptiques pour l’autentification, ce qui est plus sécurisé.

De plus, des recherches ont montré que beaucoup de relais Tor ont des vulnérabilités dans leurs clés publiques servant au processus d’autentification. En particulier, des relais Tor possèdent des clés qui partagent certaines caractéristiques mathématiques rendant théoriquement possible la reconstruction des clés privées.

Enfin, et le plus inquiétant, ces recherches ont montré que 122 noeuds utilisaient des clés ne répondant pas aux standards mathématiques imposés par le protocole Tor et normalement codé en dur dans chaque relai. Ces relais Tor ont donc volontairement été modifiés afin de desanonymiser des services cachés. Il a été montré qu’une des cibles était Silk Road.

Légalité

France et Europe

Tor est légal en France et dans tous les pays d’Europe. Cependant, l’anonymat et la possibilité de pouvoir échapper à la censure et à la surveillance gouvernementale et policière, c’est quelque chose qui inquiète beaucoup les états. C’est de cette façon qu’en 2015, Bernard Cazeneuve, alors ministre de l’intérieur, a envisagé entre autre de bloquer Tor en France. Une telle mesure est techniquement possible, mais elle pourrait être renforcée par exemple en déclarant Tor illégal et en prévoyant des sanctions dissuasives pour les contrevenants.

Ce projet de loi n’a pas abouti. En revanche, Tor utilise des protocoles cryptographiques très robustes et l’utilisation de la cryptographie est en partie règlementée par la loi française. Concrètement, le refus de donner des clés de déchiffrement sur injonction judiciaire est un délit passible de 3 ans de prison et de 270000€ d’amende. De plus, l’utilisation de la cryptographie lorsqu’elle est utilisée pour préparer ou comettre un crime ou un délit est une circonstance aggravante qui alourdit les peines. Etant donné que le principe même de Tor repose sur des protocoles cryptographiques pour assurer l'anonymat de ses utilisateurs, son utilisation à des fins illégale tombe définitivement sous le coup de cette dernière loi.

Chine

La Chine est certainement un des cas les plus extrême en matière de censure. Déjà, il faut savoir qu’il n’y a pas que Tor qui est concerné. La Chine dispose d’un système appellé le “grand pare-feu chinois” qui bloque des pans entiers d’internet en bloquant de grosses plages d’adresses IP. http://www.greatfirewallofchina.org/ permet de tester l’accessibilité de sites web depuis la Chine. Parmis les sites censurés, on trouve évidemment tout ce qui est “politiquement sensible” là bas comme tout ce qui a trait de près ou de loin avec le Tibet. Ainsi, si vous testez le site officiel du Dalai Lama (https://www.dalailama.com/), vous verrez qu’il n’est pas accessible. La Chine a également blacklisté la plupart des réseaux sociaux comme facebook et twitter, ainsi que des services comme gmail ou wikipedia.

En ce qui concerne Tor, l’utilisation est bloquée et la Chine est vraiment à la pointe en ce qui concerne le blocage de Tor, plus que les autres pays. Déjà, étant donné que la liste de tous les relais Tor est publique via le consensus, il est facile de tous les bloquer. Le problème, c’est que la Chine est en mesure de détecter les bridges. Pour ce faire, elle envoie régulièrement sur des plages entières d’IP du protocole Tor. Toutes les IPs qui répondent se trahissent en tant que bridges et sont bloquées .

Les solutions pour contourner ce blocage sont :

• Utiliser un VPN ou un proxy, si possible personnel et monté soi même au préalable dans un pays étranger, comme point d’entrée. Par exemple obsproxy.

• Configurer un ordinateur personnel installé dans un pays étranger comme un bridge personnel.

Enfin, il est à rapeller que en plus du blocage, la loi encadre rigoureusement toute activité sur internet. En 2001, un dissident chinois (mr. Wang Xiaoning) a été condamné a 10 ans de prison pour avoir diffusé via un compte mail yahoo du contenu jugé politiquement sensible en chine. Si malgré tout, vous arrivez à utiliser Tor en Chine et que vous vous faites prendre, vous vous exposez à passer quelques années en prison.

Emirats Arabes Unis

La loi n’interdit pas Tor explicitement. Cependant, la loi dit ceci :

« Quiconque utilise une adresse IP frauduleuse en recourant à une fausse adresse ou une adresse tierce par n’importe quel moyen dans le but de commettre un crime ou d’empêcher sa découverte, sera puni d’un emprisonnement temporaire et d’une amende d’au moins 500 000 dirhams [environ 120 000 euros] et jusqu’à 2 000 000 de dirhams [près de 490 000 euros] ou bien de ces deux sanctions. »

Or la censure sur internet est également très présente là bas. De nombres services sont censurés tel que les sites parlant de la drogue, les sites de rencontre, les sites pornographiques, les sites politiquement sensibles, les sites critiquant l’Islam, les sites qui portent atteinte à “l’éthique”, etc... Donc le fait d’accéder à des services censurés via Tor ou via un VPN tombe sous le coup de cette loi.

Il est d’ailleurs intéressant de noter que c’est aux Emirats Arabes Unis que les bridges sont le plus utilisés. D’après le site de Tor Metrics, Les Emirats Arabes Unis serait le deuxième pays ou Tor serait le plus utilisé avec 320490 utilisateurs par jour, totalisant 14,67% du total des utilisateurs de Tor par jour (statistique consultée le 18/07/2017). De plus, c’est aux EAU que les bridges sont le plus utilisés avec 13682 utilisateurs journaliers, totalisant 21,65% des utilisateurs journaliers de bridges dans le monde entier (statistique consultée le 18/07/2017).

Ailleurs

Tor est également partiellement bloqué en Iran et en Turquie. Il est d'ailleurs intéressant de noter que, comme aux Emirats Arabes Unis, le nombre d'utilisateurs de Tor en Turquie a dramatiquement augmenté lors de l’interdiction du réseau Tor. Le nombre d’utilisateur est passé de 25000 à 70000 en l’espace de deux semaines lorsque le blocage a été mis en place.

Annexe : protocole cryptographique

Notions de Cryptographie

Chiffrer un message/document/fichier/whatever, c'est le rendre illisible sauf pour qui de droit. Prenons un exemple tout bête. Voici un message que j'ai chiffré en utilisant une méthode toute simple :

"fh phvvdjh hvw fkliiuh"

Le message est incompréhensible. Pour le déchiffrer, il vous faut une information secrète que vous partagerez avec votre correspondant. Cette information s'appelle une clé (Retenez bien ce terme, c'est un concept fondamental en cryptographie). En l'occurence c'est vraiment un truc ultra simple, certains d'entres vous l'auront peut être tout de suite vu : il s'agit d'un bête décalage dans les lettres de l'alphabet, en l'occurence +3 (c'est à dire que A devient D, B devient E, C devient F, etc...). En inversant le processus, on tombe sur le message original :

"ce message est chiffre"

Concrètement, dans un ordinateur, un fichier, quel qu'il soit, n'est qu'une suite de 0 et de 1 (des bits). Chiffrer un documents consiste donc à modifier sa séquence de bits en une autre séquence illisible par l'ordinateur (Par exemple 01101101 (lisible) --> chiffrement --> 10101110 (illisible)).

Il existe deux types de cryptographie :

• La cryptographie symétrique
• La cryptographie assymétrique

La cryptographie est qualifiée de symétrique quand la même clé est utilisée à la fois pour le chiffrement et le déchiffrement. Par exemple, le chiffre de César mentionné ci dessus est un exemple de cryptographie symétrique : La connaissance de la clé (en l'occurence, 3) vous permet à la fois de chiffrer ou de déchiffrer. Aujourd'hui, avec l'avènement de l'informatique, un tel algorithme est devenu bien sûr complètement obsolète. Aujourd'hui, nous disposons d'algorithmes bien plus performant tel qu’AES (Advanced Encryption Standard) qui est l’algorithme symétrique utilisé par Tor et qui sera explicité un peu plus loin.

La cryptographie assymétrique repose sur la séparation du processus de chiffrement et de déchiffrement. Le processus implique cette fois non plus une, mais deux clés possédant les deux propriétés suivantes : - Ce qui est chiffré par une clé peut être déchiffré par l’autre - En aucun cas une des deux clés ne peut déchiffrer ce qu’elle a chiffré

Du coup, une dés clés servira pour le chiffrement et sera déclarée publique, et l’autre clé sera déclarée privée et ne devra jamais être communiquée à quiconque.

Les deux ont leurs avantages et leurs inconvéniens. L'avantage de la cryptographie symétrique est qu'elle est rapide d'éxécution, ce qui n’est pas le cas de la crypto assymétrique. Ceci peut être un enjeu majeur lorsqu'on doit transmettre des données, en particulier lorsque la connexion doit transiter par plusieurs relais comme c’est le cas dans Tor. C’est pour cette raison que la cryptographie symétrique est toujours utilisée pour protéger concrètement les données. En revanche, la cryptographie symétrique a un très gros problème de sécurité : elle repose entièrement sur l'existence d'un secret partagé, c'est à dire sur la nécessité que les deux personnes se mettent d'accord sur une clé sans qu'elle ne soit interceptée par un tiers (Car mon canal est par définition non-sécurisé. S’il l’était, le recourt à la crypto serait inutile, autant s’échanger directement les données). Ce problème ne se pose pas avec la crypto assymétrique.

Chiffrer les communications, c’est bien, mais malheureusement, ce n’est pas suffisant. En effet, si je me plante lors de la négociation d’une clé symétrique, mes échanges ne sont plus sécurisés. Parreillement, si quelqu’un usurpe l’identité de mon correspondant, j’aurai beau chiffrer, je transmettrai mes données à l’attaquant. C’est pour cette raison que le chiffrement https et le chiffrement dans tor est accompagné de tout un tas de procédures rôdées contituant un protocole destiné à sécuriser au maximum les communications. Ce protocole se passe en plusieurs étapes et dans cet ordre :

• L’authentification du serveur
• La négociation sécurisée d’une clé symétrique
• L’échange de données chiffrées
• La vérification de l’intégrité des données.

Authentification du serveur

Comme nous l'avons expliqué, Tor implique de faire transiter la connexion par plusieurs relais avant d’atteindre sa destination. Il est donc absolument nécessaire que le client qui va établir le circuit (c’est à dire votre machine) soit sûre que les relais contactés sont bien ceux du réseau Tor et pas ceux d’un attaquant qui essaierait d’en usurper un. Le processus d’authentification fait intervenir la cryptographie assymétrique. Comme cette étape n’a besoin que d’être faite une seule fois, le problème de lenteur inhérent à la cryptographie assymétrique ne se pose pas vraiment.

Le serveur, en l’occurence le relai Tor, va disposer d’un couple de clés publique/privée. La clé publique est signée par un tiers de confiance afin de garantir que cette clé appartient bien au relai Tor.

Lors du processus d’authentification, le client va récupérer la clé publique du serveur. Il va chiffrer un secret à l’aide de la clé publique et va envoyer le secret chiffré au serveur. Le serveur va déchiffrer ce secret à l’aide de sa clé privée et renvoyer le secret déchiffré au client. Le client vérifie ensuite que ce qu’il a envoyé correspond bien à ce qu’il a reçu. Si c’est le cas, l’authentification est correcte. Pour ce faire, Tor utilise 2 algorithmes.

L’algorithme majoritairement utilisé est l’algorithme RSA et la taille de la clé fait 1024 bits. Cependant, Tor est actuellement en train de migrer vers les courbes elliptiques qui sont plus sécurisées.

Echange de Diffie-Hellman

Tor utilise le chiffrement symétrique pour protéger les informations qu’il véhicule pour des raisons de rapidité. Or comme on l'a vu, le chiffrement symétrique souffre d’un gros problème de sécurité, car il nécessite que les deux parties souhaitant communiquer se mettent d’accord sur une clé sans qu’elle ne soit interceptée, c’est à dire sur un secret partagé. Or, le problème, c’est qu’il n’est pas possible de faire circuler cette clé sur le canal de communication puisque je suppose par définition qu’il n’est pas sécurisé et donc susceptible d’être écouté. Et s’il était sécurisé, le recours au chiffrement serait inutile : autant s’échanger les données directement.

Nous avons vu également qu'il n'est pas possible d'utiliser le chiffrement assymétrique exclusivement pour s'échanger les données, toujours à cause de problèmes de rapidité. Donc pour répondre au problème de l’échange des clés symétriques, il y a 2 solutions :

• Une des parties peut créer une clé symétrique et l’envoyer à l’autre en la chiffrant à l’aide du chiffrement assymétrique. Le problème, c’est qu’on pourrait immaginer qu’un attaquant intercepte l’échange de la clé et tous les échanges chiffrés symétriquement qui s’ensuivent, et stocke tout ça en attendant que les progrès technologiques et l’évolution de la puissance de calcul des ordinateurs lui permettent de déchiffrer l’échange de la clé symétrique plus tard. Une fois que la clé symétrique est déchiffrée, il peut déchiffrer toutes les communications qu’il aura préalablement stocké.

• Une autre solution, plus sécurisée, est d’avoir recours au protocole de Diffie-Hellman, du nom de ses créateurs Whitfield Diffie et Martin Hellman.

Prenons un exemple concret. Supposons que je veuille communiquer avec le serveur hébergeant www.psychoactif.org. Etant donné que ce site est en https, il est nécessaire de négocier une clé de chiffrement.

• Etape 1 : Psychoactif et moi commençons par nous mettre d’accord sur un nombre quelconque. Par exemple 5. Cette partie de la négociation n’a pas besoin d’être sécurisée.

Moi	Attaquant	www.psychoactif.org
5	5	5

• Etape 2 : Psychoactif et moi même choisissons chacun de notre côté un nombre secret quelconque.

Moi	Attaquant	www.psychoactif.org
5	5	5
3		4

• Etape 3 : Psychoactif et moi élevons à la puissance choisie le nombre premier choisi en étape 1 :

Moi	Attaquant	www.psychoactif.org
53 = 125	5	54 = 625

• Etape 4 : Psychoactif et moi nous échangeons ces deux nombres. Cet échange n’a pas besoin d’être sécurisé. En pratique, il peut être chiffré et signé de façon assymétrique.

Moi	Attaquant	www.psychoactif.org
53 = 125	5	54 = 625
625	625 125	125

Etape 5 : Psychoactif et moi même élevons le nombre échangé à la puissance secrète choisie à l’étape 2. Et ô magie des mathématiques, on tombe sur le même nombre sans se l’être échangé.

Moi	Attaquant	www.psychoactif.org
53 = 125	5	54 = 625
6253 = 244140625	625 125	1254 = 244140625

Quant à l’attaquant, le seul moyen qu’il aurait éventuellement pour casser la clé serait de retrouver les deux puissances secrètes à partir de 5, 125 et 625. Sauf qu’ici, j’ai pris un exemple simplifié. En réalité, les opérations de mise à la puissances sont réalisé dans ce qu’on appelle en mathématiques un “corps fini”. Un corps fini, on peu l’appréhender pour vulgariser un peu comme un ensemble fini d’entiers dans lequel le décompte est periodique.

Par exemple si vous comptez l’ensemble des heures de la journée, c’est un ensemble comptant 24 élément allant de 0 à 23. Dans cet ensemble, “l’heure 27“ est équivalente à 3 heures du matin (1 tour de cadran de 24 heures, plus 3 heures) et on note 27 ≡ 3 mod(24) (27 équivaut à 3 plus ou moins (modulo) 24)

C’est un peu de cette façon là qu’on compte dans un corps fini.

Dans l’échange de Diffie Hellmann, l’étape 1 consiste en réalité à se mettre d’accord sur un nombre quelconque (en l'occurence 5), mais aussi sur un corps fini qui servira de base pour compter. Par exemple 17. Donc lorsqu’on calculera 5³ dans la base 17, on trouve que c’est égal à 6 modulo 17. Pour reprendre l’exemple de l’horloge, qui est cette fois un peu particulière puisque c’est une horloge à 17 subdivisions, si vous comptez jusqu’à 125, vous faites 7 fois le tour de l’horloge, et à la fin, il vous reste 6 (125 = 7*17 + 6). En suivant le même raisonnement, 5⁴ ≡ 13 mod(17). Pour un attaquant, ça devient extrèmement compliqué de retrouver les puissances parce qu’il ne dispose que du résultat final, c’est à dire 6 et 13, et qu’il ne sait pas combien de “tours de cadran” ont été fait. Or il y a une infinités de puissances possibles qui donneront comme résultat 6 ou 13 (Par exemple 5¹⁹ ≡ 6 mod(17). C’est ce qui fait toute la force de l’échange de Diffie Hellman.

Advanced Encryption Standard

L'algorithme symétrique utilisé par Tor pour protéger les données est l'Advanced Encryption Standard, plus communément appellé AES. C'est l'un des algorithmes les plus robustes qui existe à ce jour. Accessoirement, c'est aussi l'algorithme qui sécurise vos échanges de données quand vous allez sur Psychoactif. AES fonctionne de la façon suivante. Supposons que je veuille chiffrer le mot suivant : "Acide Lysergique". Les caractères en informatique sont codés via la table ASCII qui permet d'associer des nombres (de 0 à 255) à 256 symboles, ces nombres étant codés sur 8 bits (1 octet). Par exemple le L majuscule correspond à 76 (01001100 en binaire) dans la table ASCII. Donc :

A	c	i	d	e		L	y	s	e	r	g	i	q	u	e
65	99	105	100	101	32	76	121	115	101	114	103	105	113	117	101

L'algorithme AES travaille sur des blocs de 4*4 éléments qui font 128 bits (126/16 = 8 bits, on retrouve bien nos 8 bits qui codent les lettres). Là, j'ai bien choisi mon mot pour qu'il y aie pile poil 16 caractères. Mais si il faut chiffrer plus de données, AES crée d'autre blocs à la suite et remplit les blocs incomplets avec des données bidon.

Du coup, voici mon bloc :

65	99	105	100
101	32	76	121
115	101	114	103
105	113	117	101

La clé de AES est une clé maîtresse de 128, 192 ou 256 bits en fonction de la force de l'algorithme, et à partir de laquelle seront déduites des sous-clés de 128 bits. Ces sous-clés auront le même format qu'un bloc, c'est à dire qu'elles se présenteront sous la forme d'une matrice aléatoire de 4*4.

Et du coup, voici une sous-clé créée pour l'occasion qui est constituée de nombres aléatoires compris entre 0 et 255 :

177	75	103	21
136	203	117	146
43	199	147	187
250	194	10	172

Ensuite, AES se déroule "tours" comportant 4 étapes plus un tour préliminaire.

Tour préliminaire (AddRoundKey) :

Il s'agit ici d'appliquer la fonction XOR (OU exclusif) entre chaque nombres du bloc à coder et chaque nombres de la clé. Pour bien comprendre, il faut passer en binaire. La fonction XOR renvoie 1 si les 2 bits en entrée sont différents et 0 s'ils sont identiques. Par exemple prenons notre première lettre (65) et le premier nombre de notre clé (177) :

65	01000001
XOR 177	XOR 10110001
= 240	11110000

A ce stade, notre matrice devient donc :

240	40	14	113
237	235	57	235
88	162	225	220
147	179	255	201

Tours :

1ère étape (Générique) : SubBytes

On applique à chaque élément du bloc à chiffrer une fonction non-linéaire prédéfinie. L'idée de cette étape, c'est de changer drastiquement tous les éléments du bloc. En cryptographie, on appelle cette propriété la confusion, et les transformations non-linéaires sont parfaites pour ça (si vous voulez les détails technique, ça consiste à prendre l'inverse de ces éléments dans un corps de Galois GF(256) et d'y appliquer une relation affine). Concrètement, étant donné que cette étape est générique, on peut établir une table de conversion qu'on appelle une S-box (Substitution box) et qui est disponible ici en hexadécimal (https://en.wikipedia.org/wiki/Rijndael_S-box). Du coup, mon bloc devient :

240	40	14	113
237	235	57	235
88	162	225	220
147	179	255	201

140	52	171	163
85	233	18	233
106	58	248	134
220	109	22	221

Deuxième étape (Générique) : ShiftRows :

C'est très simple, on décale les lignes de la matrice suivant l'exemple donné ci dessous. L'idée, cette fois ci, est d'assurer ce qu'on appelle en cryptographie la diffusion. C'est à dire que le moindre changement dans le message de départ se répercutera de façon considérable dans l'algorithme et aboutira à un chiffré radicalement différent.

140 52 171 163 140 52 171 163 85 233 18 233 233 18 233 85 106 58 248 134 248 134 106 58 220 109 22 221 221 220 109 22

3ème étape (Générique) : MixColumns

Il s'agit cette fois ci de multiplier chaque colonne de la matrice par une matrice spéciale appellée MDS (Maximum Distance Separable). Cette matrice a été calculée pour optimiser la propriété de diffusion citée ci dessus. Concrètement, tous les éléments de la colonne vont s'influencer les uns les autres. Cette matrice est la suivante :

2 3 1 1 1 2 3 1 1 1 2 3 3 1 1 2

Exemple avec la première colonne. La multiplication s'effectue dans un corps de Galois GF(2⁸)

140 233 248 221

2 3 1 1 (2x140 XOR 3x233 XOR 1x248 XOR 1x221) = 50 1 2 3 1 (1x140 XOR 2x233 XOR 3x248 XOR 1x221) = 139 1 1 2 3 (1x140 XOR 1x233 XOR 2x248 XOR 3x221) = 242 3 1 1 2 (3x140 XOR 1x233 XOR 1x248 XOR 2x221) = 63

Donc la matrice devient :

140 52 171 163 50 4 106 142 233 18 233 85 139 93 177 81 248 134 106 58 242 78 21 184 221 220 109 22 63 107 191 135

4ème étape (Dépendante de la clé) : AddRoundKey

Il s'agit de la même chose que le tour préliminaire avec la fonction XOR, mais à partir d'une nouvelle sous-clé aléatoire déduite de la clé maîtresse (Une sous-clé aléatoire différente par tour), mettons :

184 116 102 114 50 4 106 142 138 112 12 252 222 163 60 91 139 93 177 81 85 254 113 10 145 53 23 15 XOR 242 78 21 184 = 99 123 2 183 181 222 21 75 63 107 191 135 138 181 170 204

Ensuite, on recommence toutes ces étapes 10, 12 ou 14 fois en fonction de la taille de la clé maîtresse (AES 128/192/256 bits). A cette étape, si on reprend notre table ASCII, notre message initial (Acide Lysergique) ressemblerait à :

138 112 12 252 85 254 113 10 99 123 2 183 138 181 170 204 Š p *FF* ü U þ q *LF* c { *STX* · Š µ ª Ì

Šp*FF*üUþq*LF*c{*STX*·ŠµªÌ