Dans le premier volet, nous avons découvert les fondements techniques des paiements silencieux de manière générale. Il est maintenant temps d’examiner de plus près les paiements silencieux dans des portefeuilles matériels tels que BitBox.

Nous vous recommandons vivement de lire d’abord la première partie, car cet article s’appuie sur les connaissances que nous y avons posées, en particulier sur ce que sont les clés privées et publiques et sur le fonctionnement des paiements silencieux. Comme dans la première partie, nous utilisons des lettres minuscules pour les clés privées et des lettres majuscules pour les clés publiques. Par exemple : A = a × G.

Pour récapituler, lorsqu’Alice effectue un paiement silencieux à Bob, la sortie de transaction destinée à Bob est dérivée dynamiquement de l’adresse de paiement silencieux de Bob et des clés privées d’Alice :

P = B_spend + hash(input_hash × S) × G

...où S est le secret partagé. Le portefeuille matériel d’Alice peut le calculer avec sa clé privée a et la clé publique B_scan de Bob :

S = a × B_scan

Ici, Alice prend B_spend et B_scan de l’adresse de paiement silencieux de Bob, tandis que a est la somme des clés privées qu’elle utilise dans la transaction.

Créer ou signer des transactions

La première chose à comprendre est à quel point les paiements silencieux modifient le rôle des portefeuilles matériels dans le traitement des transactions Bitcoin.

Dans les paiements traditionnels, le portefeuille hôte (le logiciel sur votre ordinateur ou votre téléphone, comme BitBoxApp) crée la transaction, et le portefeuille matériel (comme votre BitBox02) se contente de la vérifier et de la signer pour l’approuver.

Avec les paiements silencieux, cela change. Le portefeuille matériel est désormais responsable non seulement de la signature de la transaction, mais aussi de la génération d’une partie de celle-ci, en particulier la sortie de transaction vers Bob. En effet, les clés privées d’Alice sont nécessaires pour générer la sortie de transaction de Bob, et seul son portefeuille matériel connaît ces clés privées.

Ce changement introduit de nouveaux risques :

  • Corruption mémoire : si le portefeuille matériel contient un bug ou subit un problème de mémoire, il pourrait dériver une sortie incorrecte, ce qui pourrait envoyer des fonds vers une adresse inutilisable et les perdre définitivement.
  • Comportement malveillant : si le portefeuille matériel est compromis, il pourrait créer une sortie qui dirige les fonds vers un attaquant au lieu de Bob, sans que le portefeuille hôte ne s’en aperçoive.

Ce problème peut être résolu élégamment en demandant au portefeuille hôte de vérifier l’exactitude de la sortie de paiement silencieux générée par le portefeuille matériel. Sur le plan conceptuel, cela ressemble à anti-klepto, qui constitue un autre cas où le portefeuille hôte vérifie que le portefeuille matériel ne se comporte pas de manière incorrecte.

Preuves d’égalité de logarithmes discrets

Comment le portefeuille hôte pourrait-il vérifier que la sortie de paiement silencieux générée par le portefeuille matériel est correcte ?

Le portefeuille hôte ne peut pas la vérifier directement, car il n’a aucun moyen de la recréer par lui-même. Il lui faudrait soit la clé privée a d’Alice, soit la clé privée b_scan de Bob afin de pouvoir calculer le secret partagé S, mais il n’a accès à aucune des deux.

À la place, nous utilisons un outil cryptographique qui permet à l’hôte de vérifier que le portefeuille matériel a correctement créé la sortie de paiement silencieux. Cet outil s’appelle une preuve d’égalité de logarithmes discrets (DLEQ).

Une preuve d’égalité de logarithmes discrets (DLEQ) permet de montrer que la même clé privée a a été utilisée pour générer deux clés publiques différentes, même lorsqu’on emploie des « points de départ » différents (appelés points de base).

La première clé publique est A1 = a × G, où G est un point de base commun (générateur). La seconde clé publique est A2 = a × P2, où P2 est un autre point de base. La preuve garantit que les deux clés publiques proviennent de la même clé privée a, sans révéler la clé privée elle-même.

En termes simples, vous prouvez que le même secret (la clé privée a) a été utilisé dans les deux cas, même si des points de base différents (G et P2) ont été employés.

En termes techniques, c’est une preuve que le logarithme discret de A en base G est le même que le logarithme discret de A2 en base P2.

Vérifier l’exactitude

Le protocole permettant à l’hôte de vérifier l’exactitude de la sortie de paiement silencieux générée fonctionne alors comme suit :

Le portefeuille matériel crée la sortie de paiement silencieux et, avec elle, une preuve DLEQ que sa clé privée a est le même secret à la fois dans A = a × G et dans le secret partagé S = a × B_scan.

Puisque A et S sont tous deux dérivés de la même clé privée a, la preuve DLEQ garantit que le secret partagé S est correctement généré à partir de la clé privée d’Alice.

Le portefeuille matériel envoie au portefeuille hôte la sortie de paiement silencieux générée P, ainsi que la preuve DLEQ et le secret partagé S.

Le portefeuille hôte vérifie la preuve DLEQ à l’aide de trois éléments :

  1. La clé publique A, obtenue comme la somme des clés publiques des entrées de transaction qu’Alice dépense,
  2. B_scan de l’adresse de paiement silencieux, et
  3. S, qui est fourni par le portefeuille matériel

Si la preuve est valide, l’hôte peut avoir l’assurance que S a bien été calculé comme a × B_scan, même sans connaître la clé privée a.

Le portefeuille hôte peut désormais vérifier la sortie de paiement silencieux en la recalculant de manière indépendante :

P = B_spend + hash(input_hash × S) × G

Pour cela, le portefeuille hôte prend B_spend de l’adresse de paiement silencieux, calcule input_hash de manière indépendante à partir des entrées de transaction et utilise le S fourni, dont l’exactitude a été vérifiée à l’étape précédente.

Si la sortie de paiement silencieux recalculée correspond à celle renvoyée par le portefeuille matériel, le portefeuille hôte peut finaliser et diffuser la transaction en toute sécurité, en sachant que la sortie de paiement silencieux est correcte et n’a pas été altérée.

Résumé du processus

  • Le portefeuille matériel d’Alice crée la sortie de paiement silencieux et prouve, à l’aide d’une preuve DLEQ, qu’il a utilisé la bonne clé privée.
  • Le portefeuille hôte vérifie la preuve pour s’assurer que le secret partagé a été calculé correctement.
  • Le portefeuille hôte recalcule et vérifie la sortie de paiement silencieux à l’aide du secret partagé et des valeurs connues de la transaction, puis finalise la transaction si tout est conforme.

Cette approche garantit que le portefeuille matériel ne se comporte pas de manière incorrecte, que ce soit à cause d’une corruption ou d’une activité malveillante.

Déploiement

La fonctionnalité permettant d’effectuer des paiements silencieux de manière sécurisée, y compris la vérification d’exactitude dans BitBoxApp telle que décrite dans cet article, sera bientôt disponible dans la prochaine version 4.45 de BitBoxApp avec la version 9.21 du firmware BitBox02.

Le BitBox02 est le premier portefeuille matériel à prendre en charge l’envoi de paiements silencieux. Pour d’autres portefeuilles, plateformes d’échange, services, etc., il est difficile de justifier l’effort nécessaire pour ajouter la prise en charge des comptes de paiement silencieux si l’écosystème au sens large ne permet pas de leur envoyer des fonds. C’est un problème de type poule ou œuf. Nous espérons contribuer ainsi à l’adoption des paiements silencieux.

Remerciements et un mot sur la collaboration open source

Nous avons découvert pour la première fois les paiements silencieux lors d’une présentation des auteurs du BIP josibake et Ruben Somsen à la BTC Azores unconference en 2023. Le BIP lui-même a reçu un nombre impressionnant de revues de très haute qualité.

Lorsque nous avons rédigé la première version de l’implémentation pour le BitBox02, j’ai commencé à réfléchir aux risques mentionnés plus haut et j’ai publié un tweet décrivant mes préoccupations. Josie, Ruben et Andrew Toth ont rapidement mentionné DLEQ comme solution potentielle et m’ont orienté vers quelques lectures très utiles sur le sujet. La seule pièce manquante était de disposer d’une bonne implémentation de DLEQ, déjà relue.

Lorsque Andrew Toth a commencé à rédiger un projet de BIP pour spécifier DLEQ, le cryptographe Tim Ruffing s’est souvenu qu’une implémentation existait déjà dans la bibliothèque de code secp256k1-zkp, sur laquelle le BitBox02 s’appuie déjà. Elle avait été fournie par jesseposner dans un autre contexte, mais heureusement il s’est avéré que cette implémentation convenait aussi bien aux paiements silencieux.

Armés des vecteurs de test du BIP, de l’implémentation DLEQ ci-dessus et d’une implémentation de référence utile (que nous ne pouvions pas utiliser directement, car les portefeuilles matériels ont des exigences différentes), nous avons pu intégrer en douceur la prise en charge de cette fonctionnalité dans BitBox.

C’est toujours gratifiant lorsque tant de personnes donnent de leur temps et de leurs efforts pour construire quelque chose de manière ouverte, et que tout finit par s’assembler.

Un grand merci à Josie, Ruben, Andrew et à bien d’autres pour nous avoir aidés à mener cette fonctionnalité à bien.

Vous n’avez pas encore de BitBox ?

Sécuriser vos cryptos n’a pas besoin d’être compliqué. Le portefeuille matériel BitBox02 stocke hors ligne les clés privées de vos cryptomonnaies. Vous pouvez ainsi gérer vos actifs en toute sécurité.

Le BitBox02 existe aussi en version Bitcoin-only, avec un firmware radicalement focalisé : moins de code signifie une surface d’attaque réduite, ce qui améliore encore votre sécurité si vous ne stockez que du Bitcoin.

Procurez-vous-en un dans notre boutique !

Shift Crypto est une société privée basée à Zurich, en Suisse. Notre équipe de contributeurs Bitcoin, d’experts crypto et d’ingénieurs en sécurité développe des produits qui permettent aux clients de passer sereinement du niveau débutant à la maîtrise de la gestion des cryptomonnaies. Le BitBox02, notre portefeuille matériel de deuxième génération, permet aux utilisateurs de stocker, protéger et transférer Bitcoin et d’autres cryptomonnaies en toute simplicité, avec l’aide de son compagnon logiciel, BitBoxApp.

This post was translated with the help of AI