Sécurisation des virements - Validation de la clef publique de destination

Ça pourrait être présenté comme un type de paiement différent, on aurait :

  • paiement classique
  • paiement sécurisé

Avec une recommandation ou/et obligation de privilégié les paiement sécurisés uniquement pour les très gros montants par exemple :slight_smile:

une tel fonctionnalité aurait permis d’éviter l’erreur à 13000 G1 lors des RML14 :sweat_smile:

5 J'aimes

Dans ce cas, j’approuve :wink:

1 J'aime

Il me semble qu’il y a deux besoins différents, qui doivent être adressés de manière différente :

  1. Le besoin de prévenir des erreurs de saisie de la clé publique du destinataire -> solution le checksum
  2. Le besoin de gérer le problème de l’envoi a la mauvaise personne (par copier/coller ou scan d’une clé publique qui n’appartiens pas a la bonne personne, que ce soit par inadvertance comme l’erreur a 13000G1 des rml14 ou par attaque de type phishing) -> solution le paiment double check*.

Le paiment double check : pour une transaction A -> B le logiciel client envoi les fonds avec les conditions (SIG(B) && HXH(code)) || (SIG(A) && CSV(5jours).
L’utilisateur ayant émis le paiement transmet alors le code au destinataire (oralement, par mail, par sms, qu’importe), ça peut être un code très court genre un code pin à 4 chiffres.

  • Soit le destinataire récupère les fonds dans les 5 jours à l’aide du code pin et tout le monde est content.
  • Soit le destinataire ne récupère pas les fonds (car les fonds se trouvent sur un compte qui n’existe pas ou qui n’appartient pas a la bonne personne), et l’émetteur peut alors récupérer a tout moment une fois le délai de 5 jours écoulés.

On peut évidemment remplacer 5 jours par n’importe-quel autre délai, ce n’est qu’un exemple.

Ainsi, « savoir si un compte existe » ne me semble pas être un besoin. Toutefois cela est déjà possible actuellement sans rien ajouter en blockchain, car par définition un simple portefeuille n’existe que s’il a déjà reçue au moins 1 fois de la monnaie.
Il suffit donc au logiciel client de vérifier si le portefeuille destinataire a déjà reçu au moins de la monnaie, et si tel n’est pas le cas d’afficher un message d’avertissement du genre « Ce compte n’a jamais eu aucune activité, vous vous êtes peut-être trompé de destinataire. Envoyez 1 G1 et demandez au destinataire de vous la renvoyer pour vérifier qu’il gère bien ce compte la, ou passez par un paiement double-check ».

Dans le cas particulier de Cesium, il peut même se baser sur les fiches profil Cs+ pour considérer qu’on compte « existe » s’il a une fiches profil Cs+.

Ce que je veut dire @bpresles, c’est que dans 99,99% des cas d’usage il a un moyen de répondre au besoin utilisateur sans ajouter quoi que ce soit en blockchain, et que c’est toujours ces pistes la qu’il faut explorer en 1er. C’est seulement en dernier recours, après avoir évaluer en long en large et en travers toutes les moyens de répondre au besoin utilisateur hors-blockchain, après avoir envisagé que le besoin utilisateur identifié n’est peut-être pas indispensable, c’est seulement tout ça que la question du stockage en blockchain peut éventuellement se posée.

C’est pour cela que ta proposition de rajouter une info en blockchain m’a parue extrèmement disproportionnée, j’espère que tu comprend mieux ma réaction :slight_smile:

1 J'aime

Cesium reconnais déjà le format pubkey:checksum définit par @Tortue.
Dans les QRCode scanner, l’annuaire, le login, etc.
Le controle du checksum est effectué, quand le pattern pubkey:checksum est détecté.

Exemple, dans « Annuaire » :

Il manque, en revanche, l’affichage de ce checksum dans :

  • les QR Code générés (la lecture le prend déjà en compte, s’il est présent)
  • les champs où sont visibles les clefs publiques en entier (notamment utilisé par les copier/coller).
  • les clefs publiques tronqués ? En plus des 8 premier caractères, on pourrait mettre le checksum à la fin (séparé par un caractère).
2 J'aimes

Oui l’idéal serait que le checksum soit systématiquement affiché, pour que l’utilisateur le saisisse avec.
Idéalement, il faudrait que la pubkey sans checksum n’apparaisse jamais nul part :slight_smile:

Bonjour,

Je viens mettre un peu le bordel :smiley:

De mon observation, les utilisateurices se basent souvent sur le début de la clef pub (5-6 caractères)pour valider que le compte est le bon, et regardent rarement la fin.

Compte tenu de cette observation, serait-il adapté de placer la checksum avant la clef pub, de manière à ce que les utilisateurices voient en même temps la checksum et le début de la clef ?

format :

<checksum>:<clefPub>

Ae3:Bgx8…

1 J'aime

C’est une bonne idée !
Mais est-ce que ça ne va pas porter à confusion l’utilisateur peu avertis ?
Croyant que le checksum est la clé publique en rétrécie.
L’information importante est d’habitude mise en premier.

2 J'aimes

Oui, c’est vrai que du coup iels vont peut-être se mettre à contrôler uniquement la checksum… Ce qui est le contraire de l’effet attendu.

Donc pas si bonne idée que ça. Disons que ça demanderait des tests d’ergonomie que nous n’avons pas les moyens de faire :smiley: . Je retire ma proposition.

A moins qu’on retire les :, du coup l’ensemble deviendrait comme une clef pub rallongée et seuls les clients sauront que :

  • si la longueur est {43.44}, c’est une clef pub
  • si la longueur est {46,47}, les 3 premiers caractères sont la checksum

Ae3Bgx8…

Mais globalement oui, l’info principale est la clef pub, c’est mieux de la garder en 1er.

2 J'aimes

Excellente idée, ce caractère séparateur est inutile, il vaut mieux le retirer :slight_smile:

Cela ne me paraît pas un bonne idée. Il y a plein de manière de calculer un checksum. Celle utilisée par Cesium pour parser les QR code est celle de la spécifications des wallet paper réalisée par Tortue. Cependant, elle est un peut compliqué à réaliser, et même à vérifier. Cela pourrait être plus simple dans un autre version qui deviendrait alors la norme.
Mieux vaut séparer clairement ce contrôle (qui pourrait changer) de la clef (qui ne changera pas).

Sakia offre un checksum aussi, mais je n’ai pas regardé comment il est fait.

Il faut impérativement séparer le checksum avec un « : » ce évitera de mélanger des pubkey avec ou sans et de devenir fou à ne pas comprendre pourquoi la pubkey est invalide (ben t’as pas vu, y a trois caractères en plus… :grimacing: ).

Sinon, pour sécurisé un virement, Sakia permet d’envoyer un virement récupérable simplement après une semaine en cas de problème.

Bonjour à tous,
Premier message sur le forum, et utilisateur de la June depuis peu, je tiens d’abord à remercier toutes les personnes qui participent au développement des outils de la June, bravo !

Je profite du sujet car il m’est arrivé une histoire semblable et je voudrais savoir si il y a une solution pour « corriger le tir ».

J’ai donné ma clé publique à une amie afin qu’elle me paie, mais elle n’a pas fait de copier/coller, elle a commencé à rentrer manuellement les premiers caractères (5 ou 6), et Cesium lui a proposé une clé, sur laquelle elle a cliqué (le 15/07). Hors ce n’était pas la mienne.

Et ce compte liée à cette clé publique ne contient, encore aujourd’hui (le 30/07), que les junes versées par mon amie. C’est comme si, le fait d’avoir cliquer sur la clé proposée par Cesium lorsqu’elle à commencée à saisir la mienne manuellement, avait généré un nouveau compte portefeuille.

Voici les clés publiques des 2 comptes
Clé publique du compte crédité par erreur : Ab1MsqBxaT1cNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsm

Clé publique de mon compte Matwall1 : Ab1MsqBxaT1oNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsM

Je voudrais savoir si il est possible de vérifier si ce compte appartient bien à quelqu’un ou si c’est un compte « fantôme » comme j’en ai l’intuition ?
Auquel cas, y a t-il une solution pour re transférer ces junes sur le compte de mon amie ?

Merci beaucoup
Mathieu

Bonjour,

Si la clé erronée diffère d’un unique caractère d’une clé dont vous avez les identifiants, c’est très, très probablement un compte inaccessible à jamais, peut-être même dont les identifiants n’existent pas.

Il existe 256^32 = 115792089237316195423570985008687907853269984665640564039457584007913129639936 clés publiques, la probabilité d’en trouver une utilisée par hasard est pratiquement nulle.

bon compte : Ab1MsqBxaT1oNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsM
mauvais : Ab1MsqBxaT1cNU4id5Jp4yvwR8wF4SVpqhM34QEPLTsm

Impossible à vérifier. Mais c’est très probablement un compte au hasard. Il existe (il a de la monnaie), mais personne n’en connaît les accès.

Non (enfin si, mais ça reviendrait à effacer toutes les transactions sur tous les comptes G1 depuis le 15/07, et ça demanderait des manips de la part de tous les noeuds, donc non, on ne va pas le faire).

Pouvez-vous nous dire précisément sur quel champs c’était ? (recherche dans l’annuaire, recherche lors de l’envoi d’une transaction, autre ?) Pouvez-vous confirmer, assurer, sûr 100% que la clef publique n’a pas été recopiée en entier, mais que qeuls les premiers caractères ont été entrés et que c’est Cesium qui a proposé cette mauvaise clef publique ? (demandez à votre amie)

Il est prudent de vérifier la propriété du compte avant, en envoyant 1G1 dessus et en demandant au propriétaire de la renvoyer.


Troisième cas d’erreur de destinataire de ce type en deux semaines. Et vraisemblablement, pour deux cas, ce ne sont pas des fautes de frappe, mais une proposition de Cesium après avoir entré 6-8 premiers caractères !? ça me paraît très, très étrange, comme comportement.

2 J'aimes

Suite à ces deux cas (l’autre est ici), je pense comme @Vit que les clients devraient :

  • toujours afficher le checksum des clefs publiques
  • toujours accepter le format <pubkey>:<checksum> (c’est déjà le cas)
  • harmoniser l’affichage

Pour ce qui concerne l’affichage, il arrive pour des questions de place de ne vouloir afficher que les premiers caractères de la clef publique. Dans ce cas, il me semble tout aussi essentiel d’afficher le checksum, pour éviter les mêmes mésaventures. Je propose donc deux formats d’affichage :

  • complet : J4c8CARmP9vAFNGtHRuzx14zvxojyRWHW2darguVqjtX:KAv
  • condensé : J4c8CA…:KAv

Ping @Moul @kimamila qui sont directement concernés.

pour référence, le format de checksum utilisé est décrit là (en bas de la page) : https://tmp.tednet.fr/paperwallet/AddressFormat.html

4 J'aimes

Oups, je n’avais pas vu qu’il y avait deux passes de SHA256. Quelle est la motivation d’en mettre deux plutôt qu’une ? (apparemment c’est comme ça en bitcoin aussi)

Je vais corriger natools. Edit: fait.

Oui, c’est une des raisons qui me freine de l’implementer partout au niveau de l’affichage, dans Cesium : les deux passes de sha256 ne risque elle pas de ralentir certaines fonctionnalités ? Par exemple l’annuaire. Faudra que nous testions cela…

Bonjour,
Je vous confirme que la clé publique n’a pas été recopier entièrement, Cesium lui a proposé une clé publique en cours de saisie, avec le début idem mais dont la suite ne correspondait pas à la mienne.
Mon amie dit que c’est pendant la phase du virement. Elle a commencé à rentrer la clé du destinataire manuellement, et arrivé à une dizaine de chiffres, Césium (apli mobile) lui a proposé une clé.
Elle n’a pas contrôlé pensant que c’était ma clé, et a cliqué dessus.

pourquoi avoir utiliser dans certains cas pubkey!sum et dans d’autres pubkey:sum ?
Sachant que le ! n’est, si je ne me trompe, pas safe coté url alors que le : oui.

C’est un choix qui a été fait à l’époque par le projet Silkaj pour pouvoir séparer les clés publiques pour l’envoi de transactions multi-destinataires. C’est le seul projet client Duniter à avoir fait ce choix.
Silkaj < v0.6.0 :

tx --output <pubkey>:<checksum>

Silkaj v0.6.0 qui implémente les tx multi-destinataires − v0.7.6 :

tx --output <pubkey1>!<checksum1>:<pubkey2>!<checksum2>

Silkaj v0.8.0-dev qui utilise à présent une fonctionnalité de Click. Retour à la case départ avec : comme séparateur :

tx --recipient <pubkey1>:<checksum1> --recipient <pubkey2>:<checksum2>
2 J'aimes