 Je pense que beaucoup d'entre vous utilisent PGP. Levez la main. Bon à cœur, c'est bien. Donc si vous voulez une introduction pour quelqu'un de nouveau, quelqu'un qui a une clé, donc vous devez demander les clés, et la personne, il n'a peut-être pas les clés sur un clé de serveur, ce qui c'est ennuyeux, mais enfin c'est comme ça qu'il faudrait faire normalement. Et si je vous disais qu'il y a une façon meilleure de le faire, que vos amis et les amis de vos amis peuvent supporter garants de vos clés de façon meilleure que les attachés à la signature des clés PGP, notre prochain speaker va vous parler du système Claim Chain, un système qui doit résoudre ce problème. Merci de l'applaudir chaleureusement. Marios Izakidis. Bonjour, bon à cœur. C'était une très bonne description de ce que je vais faire, que je vais présenter Claim Chain. Une mécanisme de distribution de clés, le protocole et l'implémentation. Nous l'avons fait avec Carmela Troncozo et George Daneckis de IPFL, le collège d'université de Londres. En quelques mots, Claim Chain est une phrase structure décentralisée de clés publiques qui soutient la vérification bonne pour la vie privée. Donc si vous avez lu notre synopsis, vous avez vu que nous parlons beaucoup de blockchain. Oui, donc bien sûr, c'est une mode. Blockchain peut être utilisé dans plein d'applications, mais cela donne de très bonnes propriétés qui peuvent être utilisées pour la phrase structure de clés publiques. Par exemple, ils offrent une grande intégrité pour les données qui sont instaurées. Et puis, c'est difficile de modifier les données, donc t'as un peu proof en anglais. Et puis, on peut être sûr de l'authenticité des données, parce qu'avec tous ces signatures cryptographiques qui se passent. Et puis, par définition, blockchain est décentralisée. Donc ils peuvent donner la disponibilité. Vous pouvez aller sur n'importe quel endroit bitcoin et vérifier vos transactions. Et puis, ils sont résistants à la censure. Donc il faut utiliser tous les nœuds. Et puis, ils ont résolu le problème du consensus global. Donc il y a beaucoup de mécanismes de proof of work. Donc plus on l'utilise, plus on manipule le système, plus on a de bagages dans la loterie, plus on a de tickets, de billets de loterie. Donc la première génération d'infrastructures basée sur blockchain est basée sur cette preuve de concept blockchain. Donc c'est appelé le stack de blocs, où ils utilisent un token bitcoin pour l'identité. Donc on peut acheter des identités, les vendre à d'autres et ils vous appartiennent. Donc c'est une plus puissante abstraction que ce que nous garantisons aujourd'hui. Et cela vous donne aussi un namespace global. Si vous avez cette identité en namecoin, c'est vous et tout le monde va vous reconnaître comme le propriétaire de cette identité. De l'autre côté, ils ne donnent pas de mécanisme pour la validation sociale. Donc si quelqu'un dit par exemple je suis dans ce système Alice. Donc comment est-ce qu'on va pouvoir vérifier si cette personne est Alice ? Toutes les transactions sont publiques. Donc il y a des implications pour la vie privée. On peut par exemple craindre que les identités soient liées entre elles. Il y a des frais inhérents qu'il doit payer pour acheter des coins et pour les transactions. Et puis bien sûr il faut pas mal de ressources avec une latence de 10 minutes pour chaque bloc. Il y a un nombre spécifique de transactions qui inclut, etc. Donc ensuite la génération suivante de blockchain c'est l'infrastructure de clés. Ça peut être fait par email. Donc qu'est-ce qu'ils font ? Ils ont remplacé le bloc de transactions avec un merkel prefix tree, un arbre de prefix de merkel. Le fournisseur est responsable des clés qu'il publie sur les utilisateurs. Donc si l'email utilise conX, on peut aller chercher la clé publique pour l'utilisateur d'email du serveur conX. Et on a aussi une preuve que c'est la même clé que tout le monde obtient à ce moment précis. Donc on a aussi une discovery facile parce qu'on sait que Alice a zemel et au provider zemel et donc c'est très vérifiable. Parce que c'est Google qui maintient cette structure et il peut donner des preuves très efficaces en quelques kilos octets que c'est vraiment les bonnes données. Mais de l'autre côté, on peut détecter l'identification mais jusqu'à un certain point ils centralisent l'infrastructure de clés publiques ce qui leur permet, ce qui les rend vulnérables aux attaques parce qu'ils ont un single point of fail et un seul point de défaillance. Donc on ne peut pas avoir le matériel PGP pour les utilisateurs zemel et les fournisseurs dans cette position privilégiée. Dans ce cas là, il n'y a rien qui empêche le fournisseur de services de révéler le graph social d'utilisateurs par exemple. J'ai parlé des arbres à prefix de Merkel donc c'est ces arbres obinaires comme vous pouvez le voir mais la différence c'est que pour trier les nœuds terminaux au lieu d'utiliser les haches on utilise une fonction vérifiable ça c'est une fonction qui donne une sortie unique quand il prend une clé privée en entrée. Donc imaginez moi j'ai une clé privée qui est compatible avec cette fonction et ma fonction sortira une sortie produire une sortie qui a l'air aléatoire pour tout le monde mais si je vous donne la clé publique vous pouvez vérifier que c'est la bonne valeur de sortie de cette fonction et ça quand on l'applique aux arbres de Merkel ça nous assure que tous les gens qui insèrent des données avec un label en particulier toutes ces insertions se retrouvent dans le même nœud terminal de l'arbre de Merkel. Donc ça c'est une propriété qu'on appelle la non équivocation c'est à dire que si deux personnes vont voir le fournisseur conyx par exemple gmail à cause de cette propriété ils obtiendront tous les deux le même nœud final de l'arbre donc comment est-ce qu'on utilise ces arbres à préfixe de Merkel dans claimshane et qu'est-ce qu'on fait de différents de conyx par exemple alors ce qu'on fait différemment c'est d'abord que nous on a pour but d'avoir un système décentralisé pour ça on a les utilisés de l'arbre pour ça on a les utilisateurs qui hébergent chacun la claimshane eux-mêmes donc chaque utilisateur ou chacun de leur machine ou chacun de leur identité a une claimshane qui les héberge et s'ils veulent avoir plus d'identité ils ont une claimshane séparée donc Alice a une claimshane et Bob a une claimshane etc toute personne sur internet a sa claimshane du coup on n'a pas besoin d'avoir un consensus global et les compromis apparaissent en forme de branchement dedans n'importe qui peut vérifier qu'une séquence de blocs quand on a ajouté un bloc à la fin toute personne peut vérifier la chaine entière si il y a un embranchement puisque 2 blocs valides apparaissent à la sortie d'un bloc donné on peut interpréter ça comme un compromis c'est-à-dire que quelqu'un d'autre amacle les privés et y a publié quelque chose de différent ou j'ai essayé de faire une équivocation pour quelqu'un qui lit ma chaine et enfin ce que ça permet c'est d'avoir un contrôle d'accès très fin très précis à cause de ces capacités qu'on a puisque on peut, grâce à ça, décider de qui peut lire un claim en particulier et grâce à notre amacle préfecturier on peut s'assurer que tous les lecteurs obtiennent le même contenu alors on a quand même besoin d'avoir une façon de propager l'information comment est-ce que moi je peux apprendre que mon ami a updéter sa chaine comment est-ce que la distribution de clés fonctionne dans un système comme ça on utilise un mécanisme qu'on appelle le crosshashing pour lequel on inclut un tampon ou une certification du dernier bloc de la chaine et on distribue cette attestation à nos amis, donc par exemple Alice reçoit et redistribue une attestation du dernier bloc de Bob, Bob peut aussi inclure cette attestation pour certifier le dernier point qu'il connaît d'être ancien mais c'est pas grave le consensus se propage quand même dans ce système donc ici on a une propagation des mises à jour de clés c'est une forme de gossiping c'est comme ça que ça marche aussi chez les humains d'ailleurs c'est pas qu'il y a une question de protocole réseau et on ne se condamne pas d'ajouter des signatures cryptographiques pour les clés des autres utilisateurs ce qu'on fait aussi c'est qu'on certifie le dernier état qu'on peut observer de la chaine des autres en petits mécanismes pour présenter par exemple de nos amis donc c'est un mécanisme similaire à ce point dans les web of trust et ça nous permet de préserver le graph social des propriétaires des claim chains donc pour lister les différentes propriétés les claim chains sont à forte intégrité des espaces de stockage authentifiés à cause de toutes les signatures bien sûr qu'on a partout et ça ça peut supporter des assertions génériques donc nous on s'en sert pour faire une PKI un système de distribution de clés mais on pourrait par exemple s'en servir pour stocker des informations de contrôle d'accès ou pour contrôler votre botnet ou ce que vous voulez en même temps ça respecte la vie privée même si tout est privé comme le contenu est chiffré même si vous publiez votre contenu ça ne révèle rien sur le contenu de ce que vous affirmez tant que vous ne publiez pas la clé qui permet de les déchiffrer donc ça c'est quelque chose qui est permis par notre mécanisme de capacité donc je vais parler un petit peu plus tard la vie privée peut être utile donc l'explication permet d'assurer que deux lecteurs de la chaîne voient la même chose et ce système d'assurance du dernier état de la claim chaine permet de réconcilier d'obtenir des compromis dans les claims chaines puisque les informations cryptographiques ne peuvent pas être répudiées les informations qu'on a publiées restent valides une fois qu'elles ont été publiées il n'y a pas de répudiation possible si on a des choses non vérifiables sur un bloc dans le passé on peut détecter que la claim chaine est invalide donc on a beaucoup travaillé sur la calabilité comment garder la propagation et quelles sont les limites de ces spécifications combien de temps ça prend pour calculer etc donc vous regardez sur github la claim chaine est très flexible en termes de déploiement et de scénarios fédérés sur UNIX elle peut travailler avec une grande disponibilité et ça peut marcher aussi dans le gossiping dans des scénarios ad hoc vous voulez ? quand vous faites pièces jointes avec l'email que vous envoyez vos amis et on peut faire ça de façon très efficace en incluant juste les claims qu'on veut inclure pour ce lecteur plus quelques preuves que ces claims sont partis de la chaine de claims et que la preuve d'inclusion est dedans donc maintenant regardons un peu sous le capot j'espère qu'on a du temps donc la structure des blocs de claim chaine quelques informations de protocoles comme la version une timestamp, l'index des séquences de blocs annonce qu'on utilise pour les capacités de lier différents blocs les métadonnées de claims chaine toutes les identités connectées donc le handle twitter que l'utilisateur veut connecter à cette claims chaine et quelques clés publiques qu'on a besoin pour les opérations de claims chaine on a la clé publique pour signer les nouveaux blocs pour vérifier les fonctions qu'on utilise et une autre clé pour les capacités techniques et ensuite le principal élément le bloc c'est le bloc map, c'est là où on met tous les claims et les capacités sous forme d'arbre de prefix donc bien sûr des pointeurs c'est comme ça qu'on connecte les blocs entre eux dans la chaine donc si on considère tous les champs à gauche comme le payload on le signe et on attache la signature et c'est une information qui se tient en elle qu'on peut attacher, qu'on peut être en pièce jointe dans un email que l'on peut enregistrer en ligne et on peut toujours sûr que personne ne peut changer ses informations si on veut ajouter un claim par exemple Alice, on est dans le c'est la route du prefix et on veut rajouter un claim de Bob donc on doit définir le label qu'on va utiliser pour Bob à partir de maintenant ce sera Bob at riseup.net et on a le claim là donc tout d'abord on va calculer la clé du claim avec une fonction vérifiée en utilisant le nom et la clé privée de Alice de Bob à riseup.net plus le nom donc on va pouvoir calculer ça, ensuite on calcule l'index du nœud du nœud final donc on va enregistrer ce nœud final dans l'arbre donc en fait on prend juste la clé de claim et on fait un lookup et on va vers une clé on prend la clé K qu'on a fait dans la première étape et on va l'ajouter à la fin de l'encréption et ensuite on va chiffrer tout le contenu de la clé avec un mécanisme de chiffrement symétrique et on va inclure la preuve VRF que les gens peuvent aller chercher pour être sûrs que la clé Mki est bien celle qu'ils veulent donc c'est comme cela qu'on a le nœud final qui correspond à Bob donc on va mettre ça dans l'arbre donc scénario suivant on veut ajouter une capacité à GFox pour lire Bob d'abord on va utiliser un défi pour partager le secret S entre Alice et GFox ensuite on va utiliser le certificate encore avec un nom c'est un lookup pour générer la clé de lookup de capacité donc c'est l'index de la clé de lookup le nom c'est 1 et pour charger ça permet de cacher quelle capacité ont été révoquées de là on dérive une clé symétrique de chiffrement comme on a fait auparavant et à partir de là on peut chiffrer la clé de claim à partir du nœud en bleu que l'on a ajouté auparavant et ça c'est un chiffre avec la clé symétrique qu'on a dérivé dans l'étape 3 avec ça GFox peut déchiffrer ce bloc donc on génère ce nœud terminal et on le stock dans l'arbre maintenant si GFox veut récupérer GFox récupère la dernière mise à jour à propos de Bob dans l'arbre d'Alice il va faire le protection vers sa clé il va d'abord établir le secret partagé de GFox il va récupérer la clé de lookup de capacité de la même façon qu'Alice l'a fait et il va ensuite aller regarder dans l'arbre de claim d'Alice donc l'arbre de trafic de Merkel et va calculer quel est le nœud terminal ensuite il va pouvoir déchiffrer ce nœud final avec la clé symétrique qui est la calculée à l'étape 3 avec ça il peut récupérer la clé de claim à propos de Bob donc si vous avez suivi la clé pour le claim sur Bob c'est inclus le H du VRF donc il peut récupérer le claim à propos de Bob dans l'arbre d'Alice et le déchiffrer et ça c'est fait en utilisant la clé VRF qui est calculée à l'étape numéro 4 et on n'a pas tout à fait fini GFox doit aussi vérifier la preuve VRF qui est dans le claim déchiffré pour vérifier que la preuve qui l'a reçu c'est la seule que Alice peut avoir produit à partir de cette clé VRF alors c'était un peu rapide mais toutes ces informations vous pouvez les lire plus en détail dans l'article de recherche et si vous voulez plus d'obligations il y a plus en détail qui explique comment la preuve d'inclusion fonctionne et comment la vérification de la preuve VRF fonctionne une chose importante quand même si GFox essaye de récupérer un bloc de capacité et ne peut pas le trouver ça veut dire que Alice n'a pas donné à GFox la capacité de lire ce bloc de lire par exemple le claim à propos de Bob GFox n'a pas de moyen de savoir si la capacité pour Bob existe donc quand on a fourni ce talk c'était pour la piste des présentations sur la résilience on sait que c'est quelque chose d'académique mais c'est un sujet qui nous tient à coeur la résilience des systèmes pourquoi nous on s'intéressait à ce sujet on a commencé d'abord en cherchant à comprendre les besoins des utilisateurs donc on a discuté avec beaucoup de chercheurs puis on a pu collaborer avec eux et avec des communautés qui s'intéressent à la résilience donc ça nous a permis d'avoir des vrais projets communautaires on a fait ça par exemple avec une organisation en Allemagne et on travaille aussi en proche collaboration avec Autocrypt et on a utilisé des techniques des techniques qui sont des techniques très communes des techniques très habituelles dans le monde académique il y a des techniques bien connues dans le monde de la recherche appliquée qui cherchent à vérifier formellement les propriétés du code que l'on produit en particulier pour CleanChain nous avons une implémentation des propriétés de sécurité et de privé qui sont définies et vérifiées formellement donc on peut vérifier formellement quelles sont les conditions dans lesquelles on peut lire telle ou telle donnée dans la chaîne l'implémentation est également vérifiée formellement pour toutes les parties cryptographiques avec Fstar donc on peut vérifier l'implémentation du l'arbre prefix de la fonction VRF et quand on parle de résilience il faut aussi qu'on sache est-ce que notre système peut croître avec les données donc on a fait des simulations disant des données du monde réel qui viennent de diverses dataset notamment on a utilisé les e-mail d'Iron qui ont été liquées ça c'est quelque chose qui est utilisé souvent dans le monde académique et du coup c'est utilisé quand on doit simuler des communications réalistes entre des individus donc en utilisant ces données on a pu calculer l'efficacité de notre protocole de crosshaching et de la propagation du dernier état des clés d'autres individus on s'intéresse aussi bien sûr à l'interoperabilité et des façons qu'on a de déployer ça graduellement on est très flexible sur le déploiement on a choisi nous on sait qu'en matière d'implémentation et de distribution aux utilisateurs on sait qu'on doit être compatible avec ce qui existe en système de chiffrement pour les e-mails donc on veut être combattis avec le BG par exemple donc c'est du travail qui reste à faire mais l'utilisabilité du chiffrage des e-mails comment est-ce qu'on fait de la gestion de clés d'une façon que les utilisateurs comprennent et dans laquelle les utilisateurs ne font pas d'erreur comment se que les utilisateurs savent comment et ne font pas accentuellement de révocation de clés comment se que les utilisateurs découvrent les clés des autres utilisateurs comment initier le premier contact surtout ces problèmes c'est quelque chose qui nous tient vraiment à coeur il y a énormément de débats autour de ça c'est encore un sujet qui n'est pas résolu et nous ne l'avons pas résolu non plus mais ce qui nous intéresse c'est de mettre en place la structure et ses propriétés qui permettent de simuler la croissance d'une claim chain pour vérifier la scalabilité alors on pense qu'on a pu faire tout ce qui est dessus parce qu'on est une équipe très multidisciplinaire on a des sociologues, on a des philosophes, des cryptographes et c'est très intéressant pour nous d'avoir ce projet européen qui s'intéresse aux communications sûres et sécurisées à la vie privée ça nous permet nous d'utiliser vraiment les connaissances de toutes les personnes qui ont travaillé là-dessus pour arriver à ce produit fini on cherche aussi à être dans ce qu'on appelle l'open innovation, l'innovation ouverte donc tout notre travail est ouvert au public tout le monde peut prendre la structure de la claim chain et l'utiliser pour d'autres buts d'autres types d'applications donc c'est comme ça qu'on a fait une claim chain extensible au final et donc maintenant on a un peu de temps pour la question merci beaucoup pour votre temps donc nous avons quatre micros poser vos questions question d'internet oui, j'ai compris vous utilisez ce système en faisant dessiner la danse de la signature comme avec GPG et aussi demander à vos amis de vous donner l'accès sur la structure, sur la grave sociale est-ce que c'est pas encore plus dur à utiliser et à élargir que GPG alors vous avez parfaitement compris qu'effectivement il faut toujours faire ces manifestations de signature de clé des key signing parties et ça c'est si vous voulez être sûr que vous avez les bons claims pour l'autre personne que vous avez la bonne identité alors par contre que nous on pense c'est qu'avec ce mécanisme d'introduction de présentation les choses deviennent attendez je vais vous montrer donc ça ça fait partie de la simulation comme vous pouvez voir à gauche on simule le scénario complètement centralisé on attache juste des présentations dans les e-mails et on peut voir que ça marche sans qu'on ait besoin tant qu'on fait confiance à la personne qui vous présente quelqu'un d'autre on peut dire qu'on a qu'on a que les e-mails qui passent sont chiffrés avec les bonnes clés donc on a la confiance micro numéro 1 s'il vous plaît je m'intéresse à l'expressivité de la révocation des crêtes le soutien de la délégation de l'accès ce genre de choses c'est... ce qu'on fait par exemple on dit que avec ça vous pouvez faire ce que vous voulez par exemple des clés à seuil, de la révocation et tout ça ça peut être stocké dans la structure c'est pas des choses qu'on a vraiment fait mais c'est possible autre question vous utilisez SHA256 alors étant donné qu'on a des versions du protocole de la claim chain en haut du bloc ici c'est comme ça qu'on peut mettre à jour l'algorithme de hachage mais effectivement ce serait pas quelque chose de facile autre question bonjour merci c'était très intéressant je vais vous demander la dérivation de clés le processus de dérivation de clés pourquoi vous utilisez la fonction de SHA et pas d'autre fonction de dérivation de clés comme HKDF ou DPKDF alors je pense que c'est une question de simplicité ici mais je sais pas de bonne réponse pour ça c'est possible que votre suggestion soit meilleure si vous voulez on peut en parler après cette présentation merci beaucoup une autre question la dernière comment est-ce que la privée du graf social assurée par le cross à China je ne suis pas sûr qu'on aurait bien compris ça la confidentialité du graf social comment est-ce qu'on la protège la confidentialité du graf social en utilisant le haching le cross-haching si vous regardez quand on a le claim ici le contenu du claim qu'on met dans notre arbre ce contenu est chiffré il ne laisse fuir aucune information sur le contenu du claim donc à cause de ce système de capacité qui ne permet qu'à certains individus de lire un claim en particulier et un cross-hach en particulier c'est ça qui garantit la confidentialité du graf social merci à tout le monde malheureusement nous n'avons plus de temps mais vous pouvez discuter dehors avec Marius autour d'une bière merci beaucoup encore