Proposition d'amélioration de la sécurité de la toille de confiance

Protocols DUBP
1

Bonjour,

Alors après de nombreuse réflexions je vous propose les modifications suivantes sur le fonctionnement de la toile de confiance, pour avoir un niveau de sécurité satisfaisant selon moi (il est possible qu’il reste quelques points à améliorer):

:rotating_light: 1- Chaque compte doit publier signé par sa clef un identifiant avant de pouvoir devenir membre, un hash de la chaine de caractère suivante:

“[NOM en majuscule] [Prénom en majuscule séparés par des virgules] [date de naissance ‘dd.mm.yyyy’] [Ville de naissance]”

tel que figurant sur les document d’identité officiel, et sans ecart possible sur la syntaxe.

Exmaple pour moi: “PARENT PIERRE,PATRICE 20.03.1989 ROUEN”

Lors d’une validation du compte membre, le certificateur doit vérifier la validité du hash et qu’il correspond bien a l’identité de la personne, via un document d’identité. La blockchain vérifie que deux comptes différents ne peuvent avoir le même hash

:rotating_light: 2- Séparation des comptes membres et comptes certificateur. Ajout de deux types de validations de compte dans la blockchain, que seule les comptes certificateurs peuvent émettre:

  • La validation membre correspond à une simple vérification de l’identité tel que définit dans le 1°). Valables 4 ans.

  • La validation de compte Certificateur correspond en plus de cette vérification d’identité à une marque que l’on attribue à la personne une confiance quand à son intégrité et son honnêteté. Valables 2 ans.

On devient membres si on reçoit n validations membres.
On devient certificateur si l’on reçoit m validation certificateur, [edit] et si l’on s’est auto-certifié (que l’on est volontaire).

:rotating_light: 3- Révocation des comptes certificateurs. Chaque compte certificateur peuvent emmètre des révocations sur d’autres comptes certificateur. Si un compte certificateur reçoit n révocations, il perd immédiatement son statut certificateur (et pas son statut membre), et toutes ses validations deviennent nulles, pouvant ainsi mener à la perte immédiate de statut d’autres membres. Les révocation sont valables 2 ans et le compte perd son statut certificateur aussi longtemps qu’il existe n révocations valables.

:rotating_light: 4- Audit des comptes certificateurs. Chaque compte certificateur doit passer un audit tous les ans. La phase d’audit commence un an après le dernier audit validé (au bout d’un an la première fois), et le certificateur a 6 mois pour valider son audit.

Au début de la phase d’audit, le système désigne semi-aléatoirement, un auditeur parmi tout les comptes certificateurs, et qui effectuera toutes les vérifications qui lui paraissent nécessaire pour s’assurer de l’intégrité des actions de l’audité. L’audité et l’auditeur se contacteront par message chiffré et signés par leur clef afin de s’échanger leur coordonnées.

A l’issue de l’audit, l’auditeur peut emmètre un avis:

  • Positif, dans ce cas l’audit est validé et cela vaut en plus pour 2 validation certificateur.
  • Neutre, dans ce cas un autre auditeur est immédiatement désigné de manière aléatoire
  • Négatif, cela vaut pour 2 révocations, et un autre auditeur est immédiatement désigné de manière aléatoire
  • Injoignable (il ne peut joindre l’audité), dans ce cas un autre auditeur est désigné 3 mois après la désignation de l’auditeur actuel.
  • Aucune réponse de l’auditeur : Un nouvel auditeur est désigné un mois après la désignation de l’auditeur actuel s’il n’y a aucune réponse.

Si au bout de 6 mois l’audit n’est pas validé le compte certificateur est temporairement incapable d’émettre des certifications, jusqu’à ce que l’audit soit validé. (Le processus d’audit se poursuit).

2

Rasoir d’occam :slight_smile:
La solution la plus simple est la meilleure.

  • Point 1 dépend d’une centralisation d’identité comme preuve. Nous n’y tenons pas.
  • Point 2 pourquoi pas… je ne sais pas.
  • Point 3 Abordé souvent, risque de réaction en chaine entrainant une modification importante du DU.
  • Point 4 extrêmement contraignant, et si 6 auditeurs s’en cognent, un membre honnête se retrouve suspendu.
1 Like
3

Point 1: Ok mais désolé entre le rhume et le collera, je choisit le rhume. Après on a peut-être pas le même point de vue sur ce qui est le collera, mais de mon point de vue les problèmes de sécurité que j’ai exposé dans l’autre topic, rendent cette monnaie complètement inutilisable à grande échelle.

si 6 auditeurs s’en cognent

Dans ce système seules les personnes supposés intègres et honnêtes et volontaires se retrouveraient certificateurs, et donc potentiellement en position d’auditeur. A mon avis il faudrait aussi prévoir un fond pour rémunérer le travail des certificateurs (potentiellement sur la base du don).

4

C’est marrant, certains trouvent pourtant la licence et les paramètres de la Ğ1 particulièrement paranoïaques.
Comme quoi la perception des choses…

4 Likes
5

Et le droit a l’anonymat ? Seule mes certificateurs savent qui je suis, pourn le reste de la toile de confiance, je reste anonyme, et c’est mieux comme çà :slight_smile: )
De plus les informations d’état civil type date et lieu de naissance sont des informations très personnelles que peu de gens sont près a divulguer publiquement.

Enfin nous avons déjà expliquer moulte fois que la wot ne doit pas dépendre d’un document d’identité, l’état émetteur de ce document d’identité peut alors émettre des faux documents en masse pour faire de l’entrisme dans la monnaie.

Créer une caste et casse la symétrie des pouvoirs entre les membres. de plus cela complique considérablement un protocole déjà bien compliqué. Enfin ça ne fait que déplacer le problème : une personne malhonnête sera la 1ère volontaire pour avoir un compte certificateur, et montrer patte blanche pour l’obtenir.
Cette proposition n’est pas cohérente avec tes propos :

  • Soit les utilisateurs seront suffisamment intègres comme je le pense et dans ce cas rajouter cette couche ne sert çà rien.
  • Soit les utilisateurs seront en grande partie malhonnête comme tu le suppose, et dans ce cas rajouter une couche n’y changera rien.

Si quelqu’un dev ça je hard-fork pour maintenir une monnaie sans sanction, et je suis très sérieux, une telle monnaie ne marchera pas tout simplement par ce que la majorité des gens percevrons négativement ce système. Sans compter tout les problèmes de faux positifs et d’abus de révocation, bref pour moi c’est hors de question !

C’est la seule idée pertinente de mon point de vue, cet audit aléatoire est d’ailleurs proche de ce que m’avais suggéré un chercheur en théorie des graphes : seulement ce serait très complexe a mettre en œuvre dans le protocole blockchain et ça peut être mal perçue par les utilisateurs, je pense que la G1 fonctionnera beaucoup mieux sans ça :slight_smile:

Au final la G1 est avant tout une expérience grandeur nature, elle est la 1ère monnaie libre réelle mais ne sera pas la dernière, je te propose donc la chose suivante :

Laissons voir comment vas évoluer la G1, et si un jours il y a vraiment des gros problèmes de confiance dans le réseau alors on durcira les règles, mais il est fort possible que ce jours n’arrive jamais, donc plutôt que de surfliquer les gens faisons leur confiance et voyons :slight_smile:

4 Likes
6

C’est un hash, personne ne peut retourner à la chaine originiale à partir du hash.

Laissons voir comment vas évoluer la G1, et si un jours il y a vraiment des gros problèmes de confiance dans le réseau alors on durcira les règles

Ok.

7

Je t’invite à relire ce post : Question sur la toile de confiance - #33 by Inso

8

Casse un algo de hash ne permet pas de retourner à la chaine originale, ça permet simplement de forger des faux hashs.

Il suffit de choisir un hash qui contient moins d’information que la chaine d’origine et il est complètement impossible d’y revenir, même en cassant l’algo.

9

Ok, en supposant que la crypto future ne sera pas capable de casser les hash actuel, il y a toujours le problème de dictionnaire. Le dictionnaire qui génère les données d’identité est petit et connu à l’avance (il n’existe pas une infinité de nom, prénom, villes de naissances, etc).

Il suffit de choisir un hash qui contient moins d’information que la chaine d’origine

C’est à dire ?

10

Bah par exemple si tu prends un hash de 10 bits tu ne risques pas de pouvoir retrouver la chaine originale, même avec une puissance de calcul infinie, car il en a trop de possiblement associés.

Tout l’enjeu est d’avoir un hash suffisamment petit pour que l’on ne puisse pas retrouver la chaîne originale, et suffisamment grand pour que la probabilité que 2 humains aient le même soit très faible.

11

Vu que l’ensemble des chaînes possibles est fini (nombre fini de nom, prénoms, date de naissance et vile) alors il est possible en un temps fini de retrouver ce qui a donné le hash. On peut trouver potentiellement plusieurs entrées, mais on en trouvera un nombre fini.

Un hash est “incassable” si l’ensemble des données d’entrée est infini et donc qu’une infinité d’entrée peuvent donner le même hash, empêchant de savoir quelle est la vraie entrée.

2 Likes
12

Pour le hash, on y avait déjà pensé du temps d’OpenUDC. Personnellement je n’ai pas retenu l’idée pour uCoin devenu Duniter, tout simplement car celui qui vérifie l’identité a de fait accès à la pré-image et peut diffuser l’information sans être pris.

Bref c’est trop dangereux je trouve. Surtout avec les problèmes d’usurpation d’identité possibles aujourd’hui avec des informations de naissance.

4 Likes
13

Je ne sais pas à quel moment ces informations sont devenues particulièrement confidentielles… La majorité des gens fêtent leur anniversaire et l’info de leur date de naissance est très facilement trouvable par déduction si on la connait. Pareil pour le nom et prénom. Si on continue bientôt la question de demander à quelqu’un comment il s’appelle serait trop intrusif… J’ai l’impression que c’est tirer les choses par le bout de la lorgnette.

14

Ne voit tu pas une différence entre :

  • révéler ses informations perso à une personne que l’on connaît (et en qui on place de la confiance, peut être)

et

  • rendre ces informations publique et donc consultable par tout un chacun
15

Oui, mais je n’ai pas proposé de les rendre publiques, puisqu’il s’agit d’un hash.

16

N’importe qui qui veut vérifier l’information auprès de l’utilisateur se verra remettre la pré-image pour qu’il vérifie la validité du hash, or il peut ensuite en faire ce qu’il veut, comme la rendre publique par exemple.

2 Likes
17

Oui, comme mon ami qui me connaît, ou la personne qui vérifie ma carte d’identité pour récupérer un colis, peut déjà la rendre publique dès aujourd’hui sans besoin de la monnaie libre!

18

Du coup les données sont bien publiques.

19

Elle ne sont pas publiques, mais potentiellement publique si les personnes qui y ont accès les publient.

20

Donc on peut considérer qu’elles sont publiques :wink: