34C3 - Modern key distribution with ClaimChain

Une PKI décentralisée qui supporte la vérification sociale privacy-friendly

[Musique d'introduction dynamique]

Présentateur : Je pense que beaucoup d'entre vous utilisent PGP ici.

Levez la main.

Bon(s) hacker(s), c'est bien.

Si vous voulez une introduction pour quelqu'un de nouveau, quelqu'un qui as une clé, vous devez demander, et la personne,

bon, il a peut etre pas les clés sur un serveur de clé ce qui est ennuyeux

mais c'est comme ça qu'il faudrai le faire normalement

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 se porter garent de vos clés de façon meilleure que les attacher à la signature des clés PGP.

Notre prochain speaker va vous parlez du système ClaimChain, un système qui doit résoudre ce problème. Merci de l'applaudir chalereusement, Marios Isac Kidis (?)

Conférencier : Bonjour, bons hackers !

C'était une bonne description de ce que je vais faire, que je vais présenter ClaimChain, le mécanisme de distribution de clé, ... .

Nous l'avons fait avec ... et ... , l'Université de Londres, et puis le collège université de Londres. Donc en quelques mots,

ClaimChain est une infrastructure décentralisé de clé publique

qui soutient la vérification bonne pour la vie privée.

Si vous avez lu notre synopsys, vous avez vu que l'on parle bcp de blockchain, et oui, bien sûr c'est une mode. Blockchain peut etre utilisé

de très bonnes propriétés qui peuvent être utilisées pour l'infrastructure de clés publiques.

Par exemple, ils offrent une grande intégrité pour les données qui sont stockées. Et puis c'est difficile de modifier les valeurs stockées,

temps-proof en anglais

et puis on peut être

avec tous ses signatures cryptographiques qui se passent et puis par définition blockchain c'est décentralisé

donc ils peuvent donner la disponibilité, vous pouvez aller sur n'importe quel endroit bitcoin, et puis c'est résistant à la censure, donc il faut utilisez tout les noeuds.

Et puis ils ont résolu le problème du consensus, il y a beaucoup de mécanismes de prove of work, donc plus on l'utilise, plus on manipule le système, plus on as de billets de lotterie.

Donc la première génération d'infrastructures basée sur blockchain est basée sur cette preuve de concept.

Blockchain, c'est appelé le stack de blocs

Ils utilisent un token Bitcoin pour l'identité.

Donc on peut acheter des identités, à d'autres. Et ils vous appartiennent.

C'est une plus puissante abstraction que ce que nous avons utilisé aujourd'hui.

Si vous avez

en NameCoin

tout le monde va vous reconnaitre comme le propriétaire de cette identité.

De l'autre coté ils ne vous donne pas

propriétaire de cette identité

si je dis, je suis dans ce système "Alice".

Comment on va pouvoir vérifier que cette personne est Alice ?

identités soit liées.

Il y a des frais inhérents, qu'il doit payer pour acheter des coins et pour les transactions.

bien sûr, avec une latence de 10 minutes pour chaque bloc, avec un nombre de transactions inclus.

Il y a un nombre spécifié de transactions, qui est inclus.

Ensuite la génération suivante de blockchains

ça peut être fait par email.

ils ont remplacé par

Le fournisseur est responsable des clés qu'il publie sur les utilisateurs.

Donc si l'email utilise CONIX, on peut aller chercher la clé public du serveur public

tout le monde obtient à ce moment précis

on as aussi une discovery facile.

Parce que ce que on sait que Alice a Zmail

c'est très facile, à vérifier

Ils peuvent donner des preuves en quelque Ko très efficace que c'est vraiment les bonnes données.

On peut détecter l'identification, mais jusqu'à un certain point.

Ils ont un seul point de défaillance.

Et les fournisseurs dans cette position privilégiée.

(..)

Dans ce cas là, il n'y a rien qui empêche le fournisseur de service de révéler le graphe social de l'utilisateur.

Donc j'ai parlé des arbres de, des arbres binaires.

imaginer moi, j'ai ma clé privée

trier les noeuds terminaux, au lieu d'utilisé des hashs

sorties uniques

clé privée qui est compatible avec cette fonction

Et ma fonction produira

qui a l'air aléatoire pour tout le monde

ça nous assure que tout les gens qui insèrent des données avec un label en particulier

qui insèrent des données avec un label en particulier

toutes ses assertions se retrouvent

Ce principe ça s'appelle la non-équivocation.

C'est à dire que si deux personnes vont voir

par exemple Gmail

le même noeud final de l'arbre

Comment on utilise ?

Ce que l'on fait différement. un système décentralisé

pour ça on a les utilisateurs qui hébergent

ClaimChain séparé

du coup on n'as pas besoin d'avoir un consensus global.

n'importe qui peut vérifier

Toute personne peut vérifier la chaine en entière.

deux blocs valides apparaissent

un compromis

ou j'ai essayé de faire une équivocation

un controle d'accès très fin, très précis.

À cause de

On peut décider de qui peut lire un claim, en particulier

on as quand même besoin de savoir

comment es ce que je peux

comment ça fonctionne dans un systeme comme ça

un tampon, une certification de dernier bloc de la chaîne

Alice, redistribue une attestation

de Bob

..

Le dernier point est peut être ancien,

mais c'est pas grave

C'est comme ça, que ça se passe chez les humains, d'ailleurs

ce n'est pas une histoire de protocole réseau.

On peut utiliser ce mécanisme pour présenter deux de nos amis.

préserver le graphe social des propriétaires des

claimchains

authentifié

Cela peut supporter

une PKI, un système de distribution de clé

stocker

contrôler un botnet ou ce que vous voulez.

...

meme si tout est chiffré

tant que vous ne publiez pas la clé qui permet de le déchiffrer

la vie privée peut etre utilile

l'équivocation permet d'éviter, d'assurer que deux personnes voit la même chose

que plusieurs

des compromis dans les claimchains.

puisque

les informations publiées restent valides

il n'y a pas de répudiation possible.

Donc on as bcp travaillé sur la scalabilité.

Github, là où on as notre papier.

les limites

combien de temps ça prend de ?

très flexible en terme de scénario

ça peut marché aussi avec des scénarios ad-hoc.

quand vous incluez les preuves dans un email

quand vous faites pièce jointe

à vos amis

les claims que les veux

de la chaine de claim

la preuve d'inclusion est

regardons maintenant sous le capot.

j'espère que l'on as du temps.

une timestamp

pour les capacités

les métadonnées de claimchain. toutes les identités

le handle Twitter

quelques clés publiques que l'on as besoin

pour signer les nouveaux blocs

Et une autre clé pour les capabilités techniques.

ensuite le principal élement

sous forme d'arbre de préfix. préfixes

c'est comme ça que l'on

comme le payload

On le signe et on attache la signature et on a une information qui se tiens.

dans un email

enregistré en ligne

Si on veut ajouter un claim, par exemple

Alice, la route du préfixe

On veut ajouter un claim

À partir de maintenant ça sera [e-mail]

[e-mail] plus le nonce

Ensuite on calcule l'index du noeud final

on prend juste

on fait un lookup.

on va vers une clé de chiffrement symétrique

ensuite, on va tout chiffrer, tout le contenu

sûr que la claim key

avec un mécanisme

la preuve VRF

la claim key

C'est comme cela que l'on as le noeud final à Bob

scénario suivant : On veut ajouter une capabilité

pour lire Bob

d'abord on va ... un défi DH

ensuite on va utilisé

pour générer la clé lookup

l'index de la clé de lookup ...

le Nonce

et pour charger

Ça permet de cacher quelles capacités ont été révoquées.

de là, on dérive

la clé de claim

à partir de

et avec la clé symétrique que l'on a dérivé à l'étape 3

on génère ce noeud terminal

maintenant si GF veut récupérer la derniere MaJ

il va faire l'inverse, c'est à dire,

si

la derniere maj

de l'arbre

Alice

DH

va récupérer la clé de capacité

aller

l'arbre de préfixe de M

ensuite il va pouvoir déchiffrer

Donc, si vous avez suivi,

ça inclus le hash

il peut récupérer

et le déchiffrer

ça c'est fait

à l'étape n° 4

la preuve VRF

pour vérifier

(...) (...) (...)

on est une équipe très multi-disciplinaire, on as des sociologues, des crytographes 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, ça nous permet nous d'utiliser les connaissances de toutes les personnes qui ont travaillées là dessus pour arriver à ce produit fini.

On cherche aussi à être dans ce que l'on appelle l'openinovation, c'est à dire l'inovation ouverte, tout le travail ouvert au public tout le monde peut prendre la structure de la claimchain et l'utiliser dans un autre but

donc c'est comme ça que l'on a fait une claimchain extensive

au final. On as maintenanant un peu de temps pour les questions, merci beaucoup pour votre temps.

Applause

Donc nous avons 4 micros. Posez vos questions.

Question d'Internet, j'ai compris

vous utilisez ce système

en faisant

GPG

aussi

vos amis de

l'accès de lecture

encore plus difficile à utiliser que GPG ?

Alors vous avez parfaitement compris qu'effectivement il faut tjr faire ces manipulations de signatures de clés, de signature parties

ça c'est si vous voulez etre certain que vous avez les bons claims, que vous avez la bonne identité.

alors, par contre,

avec ce mécanisme

les choses deviennent

je vais vous montrer, cela fait parti de la simulation

vous pouvez voir à gauche

on simule le scénario

complètement centralisé où l'on a juste

des présentations dans les emails

on peut voir que ça marche quand même

sans qu'on est besoin, confiance à la personne

on peut dire

les emails qui passent sont chiffrés avec la bonne clé

on a la confiance

micro n°1, je m'intéresse à l'expressivité

de la révocation des crédentials, le soutien de la délégation de l'accès, ce genre de chose, tout cela peut etre fait, c'est ce que l'on fait par ex, on dit

que sémantique

avec ça, clé à seuil,

autre question, vous utilisez SHA-256 pour générer les clés ?

es ce que c'est difficile de changer ça, ou cela serait cassé ?

Alors, étant donné que l'on as, des versions du protocole de la claimchain, en haut du bloc, ici, c'est comme ça que l'on peut mettre à jour le rythme de hashage

mais effectivement cela ne serait pas très facile

autre question, merci c'était très intéressant

je veux vous demander sur CrytoBit, la dérivation de clé

pk vous utilisez la fonction de hash SHA et pas d'autres fonctions de dérivations de clé comme DPKDF ?

Alors, je pense que c'est une question de simplicité ici, mais je n'ai pas de bonne réponse. Il est possible que votre suggestion soit meilleure;

si vous voulez on peut en parler après cette présentation, merci bcp.

une autre question, la dernière

Comment es ce que la vie privée du droit social assuré par le cross hashing

la confidentialité du graphe social, comment on la protège ?

la confidentialité du graphe social, en utilisant le hashing, le cross hashing

le claim ici

le contenu du claim

que l'on met dans notre arbre de préfixe

ici

ce contenu est chiffré, et il ne laisse fuire aucune information sur le contenu

du claim

donc, à cause de ce système de capabilité, qui ne permet à certains individus de lire un claim en particulier