 Le prochain up is going to be Practical Mix Network Designs, Strong Metadata Protection for Us and Cronus Messaging. Bienvenue dans cette présentation sur la protection des métadonnés. Vous avez présenté par David et Jeff, qui a organisé quelques sessions au Congrès de l'an dernier. Jeff, qui est un mathémathécien qui peut être pratique. Ils vont donc vous parler des composants du réseau. Je suis Jeff, voici David. Nous allons vous parler de plusieurs aspects de MixNet. À propos de comment fonctionne l'orception, nous avons un grand nombre d'entretien. Nous avons plein de slides. Nous savons dans le monde besoin de nous méfier de la fuite de tout ce qui pourrait être metadata. Alors actuellement, la principale solution pour s'emprimulir, c'est l'usage de torre. Même la NSA considérait que torre était suffisamment efficace pour empêcher toute forme de localisation massive. Torre avait été conçue de manière à empêcher une localisation entre deux usages même au sein du réseau torre. Si vous avez un site, vous pouvez voir si vous accédez au site par torre. On ne va pas se laisser défaire si rapidement. Est-ce qu'on peut envoyer un petit message à nos amis de chez Torre ? Le problème d'utiliser Torre comme transport de messages, c'est que fréquemment, les personnes que l'on veut protéger sont dans le même pays ou sur le même ISP. Donc les propriétés originales des adversaires qui peuvent voir les deux côté de la connexion, la connexion peut rapidement être vue. Comment est-ce qu'on peut garder les métadonnées de nos messages privés ? On va dire qu'on va passer sur le mix network. C'est orienté message contrairement à ce qui est orienté stream. C'est un réseau de switching de paquets. On a plusieurs étapes de chiffrement, plusieurs stratégies. Donc voilà un diagramme d'architecture. On voit qu'il n'y a pas de notes sorties. Il n'y a pas de conversations avec internet comme dans Torre. On a un PKI, c'est une autorité, un système autoritaire. Et on a quelques différences entre mixnet et Torre. Une différence importante, c'est qu'on peut faire du decoy de communication quand on voit sur le diagramme entre les mixnodes et la destination. Un des problèmes avec Torre, c'est que même si on voulait faire de la déviation de trafic, on ne peut pas parce qu'on peut toujours voir la connexion qui arrive de l'autre côté. Donc on a toujours une analyse qu'on peut faire avec Torre. Donc un peu d'histoire ici. Les réseaux mix, c'est une des anatomies les plus vieilles qui existent depuis 1981. On a pas mal d'outils qui ont été proposés. Là, c'est la récupération de données privées, PIR, quand on veut par exemple récupérer des informations sur des bases de données, mais la scalabilité est très mauvaise. Mais il y a une autre proposition qui est généralement posée comme une alternative et c'est le Dining Cryptographers Network, les DCNets. Littéralement, chacun des PIR par utilisateur a son propre coût. La topologie reste très petite et si on pouvait construire quelque chose de petit, on se demande qui on veut protéger. On ne protège pas les whistleblowers, parce qu'ils vont essayer de communiquer avec les journalistes. Mais la personne que ça protège, c'est la personne qui a déjà beaucoup de pouvoir. Donc ce qu'on veut faire, on veut vraiment avoir un set d'anonymités si grand possible. Les attaques épistémiques ou non sont ce pour quoi on veut se prévenir. Il y a pas mal de documents qui listent comment se connecter sur les PKI et récupérer les informations d'un côté à l'autre. Je pense qu'il faut mentionner que notre PKI est nécessaire et que tous les clients l'utilisent et que tous les clients connaissent la structure du réseau. D'habitude, les chercheurs, quand ils parlent de PKI, se demandent qui peut avoir connaissance de l'intégralité du réseau et ce qui pose problème de scalabilité. Pour rendre le réseau plus secure pour certaines personnes, on le rend de moins en moins scalable. David va vous parler de l'attaque épistémique et de la scalabilité. Les MixNet peuvent utiliser des topologies de cascading. Tout le monde utilise la même structure de la caméra. David va vous parler de l'attaque épistémique et de la scalabilité de cette topologie. Les mixnets peuvent utiliser des topologies de cascading. Tout le monde utilise la même route. C'est un peu différent de tord. La non-predactibilité du routing est utilisée comme une propriété de base. Dans la partie mixnet, on peut utiliser la même route que tout le monde. Mais c'est un problème de scalabilité. Donc on a ce qu'on appelle les routes libres Free Route. Ou les topologies stratifiées. Mais les routes libres Free Route, on a des documents qui documentent ça. C'est un autre... voilà. Donc tord a grandi avec ces concepts là. Et la partie Free Route peut être une alternative intéressante. Donc ici on a un autre diagramme sur la stratification et les couches. Donc chaque couche mix 0 peut se connecter avec une couche mix 1 etc. Donc ici c'est le design stratifié. On va en parler un peu plus en l'image. Ce qui est intéressant ici c'est que c'est très simple de calculer le chaque nœud. C'est plus simple que dans Free Route pour retrouver la topologie. Et la scalabilité est très bonne également. Donc... Oui ce diagramme est très utile pour pouvoir comprendre la suite. Pourquoi est-ce que tord n'est pas un mix network ? Vous devez savoir certainement la stratégie des mix networks. Ils ajoutent en fait de la latence. Ajoutant du délai entre les paquets. Par exemple sur cet exemple. Nous avons un réseau qui peut prendre jusqu'à 4 messages, qui est un seuil de 4. Ils prennent jusqu'à 4 messages avant de les laisser sortir. Si j'étais victime d'une attaque, l'attaque devrait attendre que le réseau mix soit vide. A ce moment-là je pourrais envoyer les messages dans le réseau, le saturant. Je reconnais tous les textes de mon propre message. Je ne reconnais pas le message du target. Vous pouvez continuer à faire ça pour chaque hop. C'est un type d'attaque N-1. C'est ce qu'on appelle l'attaque N-1, ou blending. Il y a plusieurs variations de ce type d'attaque qui consiste à envoyer un message sur chaque hop. Pour remonter vers le client en utilisant chaque couche de chaque hop. Donc si un attaqueur veut utiliser cette technique, il doit d'abord vider la queue du mix. En vivant tous les messages existants. Ou alors utiliser un slot pendant lequel la queue est certainement vide. On peut ensuite prendre le message cible et le faire entrer dans la mix queue. Et attendre que ce message soit ressorti de la queue. C'est ce type d'attaque où on peut s'en prémunir. Par exemple en utilisant des protocoles heartbeat. Comme qui est documenté dans plusieurs papiers, plusieurs documents. Donc on a un mélange de différents trafics, différentes loops qui vont se vérifier les uns les autres. Et qui va passer dans le mix network et revenir. Et donc si le heartbeat n'est pas reçu, on a un time out qui peut signifier une attaque. Ou alors simplement un problème réseau. Donc on peut faire des corrélations entre une attaque et plusieurs erreurs de heartbeat. Il y a d'autres défenses possibles. Une a été publiée il y a très peu de temps mais on ne va pas en parler maintenant. La prochaine catégorie d'attaque, c'est la révélation statistique. Donc ici l'adversaire fait une abstraction de tout le réseau du mix. En le considérant comme une topologie réseau, un message rentre, un message sort. C'est ce qu'on utilise dans des réseaux PTP. Donc par exemple, deux personnes reçoivent leur message sur un réseau AIP, sans NAT, sans éventuellement avec des queues. Ici c'est un concept qui utilise le design loopix. Donc loopix a plusieurs types de decoy, de méthodologie pour ajouter des bruits et des perturbateurs au niveau du message, au niveau du signal. Donc on a le drop qui permet à l'utilisateur d'envoyer un message test qui est dropé par le provider suivant. On a aussi les loops clients et je dois mentionner, si on fait ce type d'attaque de révélation statistique, on ne sait pas comment ça va fonctionner réellement dans la vraie vie parce que ça va dépendre d'une application spécifique et la possibilité de prédire les actions de l'utilisateur. Donc ça dépend du nombre d'informations qui sont révélées par le système mais les mix network révèlent toujours un certain nombre d'informations. Donc c'est pouvoir mesurer la hauteur du leak et savoir si l'utilisateur est assez dynamique. Ces attaques ne peuvent pas toujours converger vers un succès donc ça dépend vraiment d'un système particulier, la manière dont ce système est uné dans ce système de queue. L'adversaire doit compromettre le provider de destination. Donc ici, dans cette situation-là, c'est un peu la situation PTP. Les clients utilisent des informations de leur mix node directement vers leur IP, donc l'adversaire est passif. Dans une architecture plus moderne, où les messages sont queueés, un peu plus moderne, c'est le design Loupix, dont je parlais. Donc cette attaque devient une attaque active. Et donc on a un certain nombre de receveurs qui reçoivent un certain nombre d'informations quand ils reçoivent les messages. Donc on a parlé de l'attente et de la trafic. Est-ce que c'est suffisant ? Est-ce que je peux m'en sortir avec moins que ça ? La réponse à ça semble être non. Les mesures artificielles, mais l'anonymisation ne peut pas vraiment ce qu'elle est mieux que le trafic chiffré et la latence, multiplié par la latence. Donc est-ce que rajouter du trafic couvert, est-ce que ça pourrait vraiment aider ? Pour des petits messages, oui. Donc l'anonymité et l'anonymisation à l'air d'être carré, mais pas au niveau des utilisateurs et la corrélation avec les connexions réseaux et les cours réseaux. Mais c'est faisable. Donc on a des différentes paroles religieuses qui ont été faites de temps en temps. Mais ce qui est important, c'est que le chiffrement c'est quelque chose de libre, de gratuit, mais pour anonymiser et pour le mix network, il y aura un coût associé. Donc une chose sur les mix networks que tu ne veux pas utiliser ton propre format de paquet. Donc Sphinx a énormément investi dans les designs de ce genre de design. Donc designé par Denesis et Colberg. Donc... Donc on a les deux parties du message qui sont différenciées l'une de l'autre, le body et le header. Donc voilà le format du paquet. Donc on a le header qui a trois parties. La première partie c'est la clé, public, puis le point éliptique. Ensuite on a le body, donc le contenu. Donc qui est chiffré. Une manière de penser à ça, c'est qu'on a un échange de clé entre les mix nodes qui est faite pour chaque paquet au niveau du header et le mix node suivant pour le paquet. Donc le mix node doit gérer toutes ces différentes informations. Donc ce qui est important c'est les règles. Ce que Sphinx fait c'est définir les règles de gestion du chiffrement. Donc pourquoi est-ce que... pourquoi est-ce que c'est Delta? Pourquoi est-ce qu'on ne mague pas le Delta? C'est très dangereux. Si on utilisait un panmac, le message sortant serait arbitraire avec un check au moment de l'arrivée du message. On n'utilise pas de string, on utilise un wide block, on n'utilise pas d'un 1-bit tagging. C'est toujours un tagging, pourquoi on t'attache d'un 1-bit tagging? Et la réponse est que les receivers anonymes sont vraiment importants. Il y a quelques choses importantes pour les journalistes, les sources des journalistes, certains services pour des téléchargements, des interactions avec des services si on a besoin d'un acknowledgement par exemple. Et donc c'est ce protocole qui agit comme message. Donc il faut l'acknowledge du protocole. Donc pourquoi on fait des receivers anonymes? Il faut créer une couche de clés cryptographiques. Le receiver fait un mix du serbe qui l'attache au... C'est ça, génial. Maintenant, on va passer sur quelque chose de plus compliqué. Si vous regardez à l'échange de clés, l'expéditeur, la sécurité de Tor ne fait pas de négociations en live avec chaque hub. Donc il faut une sorte de sécurité et transmise et transférer. Et on l'a pas, la priori. Donc ce qu'il faut, d'abord, c'est au niveau des mix nets, il faut une sorte de protection des attaques replays. Donc ça demande une structure de données qui se remplira ou qui créera un overflow éventuellement. Donc pour prévenir ça, il faut faire une rotation de clés. Donc une manière, c'est de faire une rotation des clés plus vite. Le problème, c'est qu'on pourrait stresser le PKI un peu trop. Qui a déjà un problème de scalabilité. Ok, donc un autre problème, c'est que le temps de vie des serveurs ne peut pas excéder le nombre de... de la durée de vie des clés. Donc si on a un... une fenêtre moins élevée, on doit trouver une autre solution. Donc on a plusieurs idées. George... En 2003. On peut avoir, voilà, plusieurs types de paquets, mais pas dans le maire mordre que celui dans lequel on les envoie. Donc voilà, l'idée de George, c'était d'utiliser des paquets avec différentes durées de vie. Donc la possibilité, c'est d'utiliser une loop entre les mixnodes pour faire un échange de clés. Et ensuite, sur les mixnodes, on peut utiliser une construction double... double... double lecture, double chiffrement. Mais bon, c'est un peu de la triche. Et on voudrait pas le faire sur tous les... sur tous les hops, parce qu'on n'aura pas de l'expression des paquets. Donc en général, on demanderait qu'est-ce qu'on veut... comment on veut faire pour gérer la sécurité de nos mixnodes. Je veux pas trop en parler, mais voilà, en général, on peut parler des différences entre les technologies de base pour l'échange de clés et les propriétés qu'on peut en sortir dans le contexte de Sphinx. Donc... tout ce qui est basé sur... les courbes... Voilà, on voulait pas couvrir ça dans le contexte post-quantum. On sait pas si ça fonctionne avec LWE. Donc notre... notre stratégie de triche nous donne pas mal de... ... ... ... ... ... On peut utiliser la stratégie elliptique et l'échange de clés. Si vous essayez de mettre en place ce genre de construction, la partie LWE pourrait ne pas recevoir le problème à cause des assumptions cryptographiques du protocole. Mais voilà, LWE est probablement un des meilleurs moyens pour gérer l'échange de clés. Mais je pense qu'on peut probablement trouver quelque chose qui éventuellement qui pourrait avoir un peu le même schéma que LWE mais avec une ponctuation et des connexions un peu différentes. Donc je suspecte que ça pourrait être fait de manière plus rapide avec LWE. Donc les mixtes ne sont pas super fiables pour switcher des paquets. Les attaques par répétition automatique ... ... ... ... ... ... ... ... ... ... ... Donc, Turning Angel a écrit un layer cryptographique basé sur le noise cryptographique network qui est basé sur les liens, les couches de liens. On a la partie MixNet dont Jeff a parlé tout à l'heure avec Sphinx. Et on a le client end to end. Donc ici on a encore un diagramme Loupix. Voilà, on a Alice qui envoie un message à Bob et Bob peut récupérer son message plus tard à partir du provider avec des changements relativement simples. Dans ce design Loupix on peut avoir pas mal de stratégies possibles pour éviter que Alice et Bob ne parlent de manière directe mais pour permettre à Bob de récupérer le message de manière anonyme ce qui pourrait augmenter les latences. Donc, une des choses qu'on voudrait utiliser hier pour la récupération un des problèmes ici c'est qu'on va avoir beaucoup d'assomptions la manière dont on modèle la topologie pour être très complète. C'est très complexe, c'est sympa quand tu es un étudiant tradué mais sinon c'est très compliqué à mettre en place dans la vie réelle. Ici le mixnet va vous donner les propriétés de l'endroit caché pour le message. Si on voit ici avec le design Loupix simple on a pas vraiment de propriétés complexes pour cacher le lieu sur lequel le message arrive mais c'est très facile de trouver où est Bob au moment où son IP adresse se connecte. Un modèle, c'est ce que David disait, le message peut être hacké à beaucoup d'endroits mais il y a un moyen de fixer ça, ça demande de modifier un peu le string l'idée c'est qu'au milieu on a l'image du stockage donc c'est une sorte de serveur de mail et le récepteur ici peut se déplacer autant qu'il veut et ses contacts et ses messages peuvent l'atteindre de différentes manières au moment où le receveur se déplace. L'idée c'est que le receveur ici peut envoyer des informations vers ce point central et quand il se reconnecte le message lui sera envoyé donc on peut vraiment découpler le message ce qui est intéressant à la fin de la journée c'est qu'on a la possibilité de jouer avec le temps pour garder l'anonymité mais ça c'est quelque chose qui est encore en cours de développement donc c'est pas encore quelque chose de sûr et de fixe donc on a parlé de use case pour la partie messaging mais il y a d'autres idées d'autres implémentations possibles pour vous donner des exemples concrets donc il y a la partie monnaie anonyme donc il y a pas mal de concepts pour gérer des monnaies et des échanges de monnaie anonyme on a zcash c'est surtout une inversion du hash et sinon on a RSA tout à l'heure RSA qui sont quasiment impossibles à pirater d'autres applications plus web donc pour envoyer des choses à travers le réseau les mix networks sont très intéressants et il y a aussi des applications fondamentalement l'intérêt c'est d'utiliser des outils collaboratifs et de pouvoir travailler à plusieurs et le problème ça va être les soucis qui risquent d'arriver c'est pour tout ce qui est merge, accès, latence qui vont avoir un impact sur les utilisateurs comme en réussir à rendre les gens satisfaits tout en ayant une latence qui va augmenter de manière explicative quand vous regardez aujourd'hui des gens qui développent de nouvelles applications ils ne supportent pas la latence il serait injuste de notre part de dire qu'il ne faut pas utiliser l'application de messaging mais effectivement vous avez choisi une application vous payez pour ça et donc vous avez la sécurité qui va avec le papier loopx explique quand en réduisant la latence vous n'avez pas la possibilité de rajouter du trafic decoy les mix networks ne sont pas aussi rapide que le réseau Tor depuis qu'il y a dix ans la fiabilité des mesures prises on doit se situer au dessus du mix network donc si on peut réaliser les tests tout en gardant la sécurité sur notre réseau donc je voulais remercier les chercheurs avec lesquels on travaille j'aimerais remercier Yannick Angel pour le super design George pour ses conseils et Claudia Excel et également avec son excellent papier Christian Nick Mathison du projet Tor m'a aidé beaucoup aussi pour les spécifications PKI il a écrit la part des designs pour Tor et Max Minion et Trevor aussi nous a aidé pour notre recette de PKI voilà ici les informations sur le projet sur ce nouveau projet de mix network et c'est ça, c'est tout merci beaucoup si vous avez des questions dans la salle on va prendre des questions maintenant pas de question d'internet mais une question microphone 1 t'as mentionné les latences plus élevées dans Tor est-ce qu'on parle de secondes, de minutes donc les latences seraient plus élevées que Tor on sait pas trop en attendant tant qu'on n'a pas attuné notre mix network pour le moment donc le but c'est vraiment pas de délivrer un système général global comme Tor, c'est vraiment pour des applications spécifiques donc chaque application a des schémas spécifiques par rapport à l'utilisation des données et donc la latence sera pas forcément là après le tuning donc on a une idée de l'ordre des minutes éventuellement donc certains chercheurs sont en train de publier des papiers sur le découplage du réseau et des latences dans les mix network vous avez mentionné que les mix network avait une meilleure scalabilité que le réseau Tor donc si on essaye de construire un réseau le fait de centraliser les PKI et n'importe quel autre système c'est 10 millions de fois mieux qu'on voyait les messages à tout le monde ça c'est un concept standard donc on a besoin il y a ça la chose spécifique quand j'ai dit que c'était moins un problème chez Tor le secteur peut faire des choses assez intelligentes comme quand ils ont publié la liste des PKI et les notes ne téléchargent pas tout toutes les informations ça pointe vers un endroit où les infos sont stockés et récupèrent un approval que la formation vient du bon nom donc ça permet d'avoir le bon nom microphone numéro 3 ça a l'air d'être du bon boulot ma question c'est si les applications multiples ont différents types de tuning est-ce qu'ils peuvent utiliser le même réseau et partager le même réseau donc effectivement ça serait bien s'ils pouvaient s'aider et utiliser les propriétés mais le tuning spécifique pour le decoy a nécessité d'autres une phase structure spécifique toutes les données doivent être contenues dans un paquet donc si on a la use case de mail par exemple on va avoir détail de 50K donc si on peut faire du chat on va envoyer des messages plus petits et si on envoie des gros paquets de 50K on va pas faire la même chose pour plusieurs applications on ne va pas utiliser la même topologie si on utilise du banking par exemple des transactions financières on va utiliser un réseau qui est optimisé pour des plus petits paquets pour tout ce qui est application de chat on va avoir peut-être une structure plus symétrique parce qu'on va envoyer le même nombre de données de chaque côté pour tout ce qui est web on a des opérations qui sont plus hétérogènes en lecture et moins en écriture donc voilà c'est ce que je voulais dire en disant que certaines applications ne peuvent pas être compatibles avec d'autres applications par rapport au decoy on espère que la plupart des pierres-to-pierres comme ECAPAD ou les réseaux de paiement tout ça sera optimisé pour le use case précis comme pour email mais si on a besoin ce qui est message réinstantané, ça c'est une autre question Est-ce que tu peux nous donner plus d'exemples sur des vrais use cases pas juste des papiers donc en ce moment on est en train de tester le mix network sur plusieurs machines qu'on a et ça marche très bien on n'a pas vraiment de système près ou proche de la production donc la réponse à ta question c'est non on a rien que la théorie mais bientôt mais on y travaille je pensais à ça dans le monde réel une app par laquelle les gens peuvent communiquer j'ai peur plutôt des téléphones mobiles parce que si tu as des gens qui communiquent en utilisant cette app quelqu'un envoie un message et voilà, une autre personne récupère le message quand l'écran est allumé donc il y a énormément de choses qu'on peut contrôler à l'intérieur du mix network avec sur la topologie loopy c'est très simple de récupérer les informations donc j'ai aucune idée en fait dans mon monde idéal ce qui rendra les gens heureux au niveau des latents c'est que le téléphone ne fasse plus dingue mais c'est que les gens puissent checker leurs téléphones quand ils veulent checker leurs téléphones est-ce que ça rendra pas les gens satisfaire des latents on ne veut pas les gens veulent utiliser leurs téléphones quand ils veulent utiliser leurs téléphones merci merci beaucoup pour cette présentation merci de nous avoir suivi sur cette traduction simultanée