Trois dispositifs de signature de différents vendeurs, liés en un multisig

Le 30 juillet 2026, un attaquant a vidé 1196 adresses appartenant à des utilisateurs de Coldcard, volant plus de 1000 BTC. D'autres vagues ont suivi jusqu'au 6 août. Le montant exact varie d'un rapport à l'autre, mais l'ordre de grandeur semble être autour de 1700 BTC volés en environ une semaine selon Galaxy, jusqu'à 2400 adresses suspectes, soit plus de 100 millions de dollars. La cause n'était ni un logiciel malveillant ni une erreur d'utilisateur, mais un simple bug de génération de nombres aléatoires (RNG) dans le firmware, qui n'a pas été détecté pendant plus de 5 ans. Nous avons déjà raconté l'histoire de ce qui s'est passé (en anglais) le 1er août, puis publié l'autopsie technique du bug (en anglais) le 11 août.

Depuis, 2 conseils tournent beaucoup sur X : « vous auriez dû générer votre seed avec des dés » et « vous auriez dû utiliser une passphrase ». Ces 2 pratiques ont sauvé certains des utilisateurs de Coldcard. Cependant, les transformer en règle générale est un raisonnement erroné, et je vais essayer de montrer pourquoi dans cet article.

La question à se poser n’est pas « qu’est-ce qui aurait arrêté cette faille particulière ? », mais « quel modèle de sécurité tient toujours lorsque le prochain bug, celui que personne n’a encore trouvé, frappera l’appareil en qui vous avez confiance ? ».

Ma réponse : le multisig multi-vendeurs avec des chemins de récupération à verrouillage temporel.

Dans cet article, j’explique pourquoi il bat les dés et les passphrases, quels sont les véritables inconvénients de ce type de configuration, et je vous donne également des configurations concrètes à mettre en place avec Liana, en fonction de votre budget.

TL;DR

• La faille Coldcard (un bug RNG) a fait réapparaître deux conseils sur X : générer votre seed avec des dés, et ajouter une passphrase. Ces 2 techniques ont sauvé certains utilisateurs cette fois, mais en faire une règle est une conclusion hâtive, aggravée par un biais de survie . Elles contrecarrent le dernier bug, mais pas le prochain.
• Un multisig multi-vendeurs est un multisig dans lequel aucun chemin de dépense ouvert ne se contente des clés d'un seul vendeur. Il s’agit de la « redondance dissimilaire » du monde de l’aviation, appliquée au Bitcoin : un micrologiciel, une entropie, une signature ou un défaut de la chaîne d’approvisionnement n’expose qu’une seule clé, en dessous du seuil du chemin primaire.
• Combiné aux chemins de récupération à verrouillage temporel de Liana, c’est le seul modèle à la portée de tout utilisateur, qui réduit à la fois le risque de vol et le risque de perte, sans troquer l’un pour l’autre.
• Une seed entièrement générée à la main à l'aide de dés, n'existe pas dans la pratique : personne ne calcule la somme de contrôle SHA-256 manuellement, de sorte que la seed se retrouve sur une machine qu'elle n'était jamais censée toucher. Saisis dans un portefeuille matériel qui applique un nombre minimum de lancers, les dés ne règlent qu'un problème, et font confiance au RNG du vendeur.
• La passphrase n'a pas de somme de contrôle, est sensible à la casse, est difficile à générer hors-ligne d'une manière vraiment aléatoire, est pénible à taper pour chaque dépense, et crée un deuxième point d'échec unique contre la perte. Elle passe par le même firmware que la seed, de sorte qu'elle ne protège pas contre un bug de signature, un firmware malveillant ou une chaîne d'approvisionnement compromise.
• La loi de Tesler : un multisig est plus difficile à comprendre mais plus simple à utiliser, car la complexité réside dans le logiciel, pas avec l'utilisateur.
• Les seuls inconvénients du multisig avec un chemin de récupération : une empreinte plus reconnaissable sur la chaîne et un rafraîchissement périodique nécessaire des UTXO verrouillés temporellement.
• La sauvegarde se résume aux seeds et au descripteur ; le descripteur .bed chiffré (BIP-138) peut être copié n'importe où sans risque.
• Il n'y a pas de seuil de montant : si la perte vous mettait en difficulté réelle, c'est que vous méritez le meilleur système. Et pour les budgets serrés, il existe des configurations multisig multi-vendeurs qui ne nécessitent qu'un seul portefeuille matériel.

Qu'est-ce qu'un multisig multi-vendeurs ?

Un portefeuille multisig est un portefeuille dont les bitcoins ne peuvent être dépensés qu’avec plusieurs signatures, produites par plusieurs clés distinctes. C’est ce que nous appelons un schéma « M-sur-N » : sur les clés N, au moins M clés sont nécessaires pour signer. Dans un 2-sur-3 par exemple, vous avez 3 clés, et n'importe lesquelles d'entre elles suffisent à dépenser (minimum 2).

Le mot « multi-vendeurs » ajoute une contrainte sur la façon dont ces clés sont stockées : chaque clé doit résider sur un dispositif de signature d'une marque différente. Un Ledger, un BitBox02, et un Jade, par exemple, plutôt que 3 Ledgers. Le principe est qu'aucun chemin de dépense utilisable aujourd'hui ne devrait être possible avec les clés d'un seul et unique vendeur. Nous verrons plus loin comment les chemins de récupération verrouillés temporellement, qui restent inaccessibles tant que vous restez actif, s'intègrent dans cette règle.

Cette contrainte a un nom dans l'ingénierie des systèmes critiques : la redondance dissimilaire.

Pour tolérer une panne matérielle, la duplication d'un composant suffit. Cependant, pour tolérer une erreur de conception, la duplication ne suffit pas, car si les 2 copies partagent le même défaut, elles souffriront toutes les deux du même bug. Les composants redondants doivent donc être conçus par différentes équipes, avec différentes pièces et différents logiciels. C'est pourquoi les commandes fly-by-wire d'un avion de ligne moderne reposent sur plusieurs ordinateurs construits sur des processeurs distincts et un logiciel développé séparément, de sorte qu'un seul bug ne puisse pas tous les toucher en même temps.

Vous pouvez appliquer le même principe pour protéger vos sats. Un 3-sur-3 construit avec 3 Coldcards est un multisig, mais il n'est pas différent : la faille de juillet 2026 a affecté les 3 clés à la fois, et le seuil aurait permis de voler les fonds. Les mêmes 3-sur-3 construits sur 3 appareils de différents vendeurs protègent les fonds de cette faille, car seulement 1 clé sur 3 est exposée, et une seule clé à elle seule ne vaut rien pour un attaquant.

Cependant, la marge de sécurité se rétrécit : avec 1 clé présumée compromise, le portefeuille n'offre désormais que la résistance au vol d'un 2-sur-2 sur les 2 appareils restants, même si les dépenses nécessitent encore les 3 signatures. Vous remplacez donc l'appareil affecté à votre rythme, sans devoir aller plus vite que l'attaquant.

Ces appareils ne partagent, en principe, pas de matériel, pas de firmware, pas de générateur de nombres aléatoires, pas de chaîne d’approvisionnement, pas d’équipe de développement... Pour qu’une attaque réussisse, l'attaquant aura besoin d’autant de failles indépendantes qu’il y a de vendeurs dans le seuil défini, 3 pour ce 3-sur-3, 2 pour un 2-sur-3, et il aura besoin de les exploiter en même temps sur le même portefeuille, ce qui est évidemment beaucoup moins probable qu’avec une faille chez un seul vendeur.

Aucun vendeur de portefeuille matériel n'est épargné

Évidemment, avec ce qui vient de se passer, tous les yeux sont tournés vers Coinkite. La faille Coldcard est en effet la plus grave dans ses conséquences, mais ce n'est pas un cas isolé :

• En 2018, Saleem Rashid a contourné la vérification du firmware du Ledger Nano S, ce qui aurait en théorie permis d'expédier un dispositif avec une seed prédéterminée ;
• La même année, il a reconstruit les clés d'un portefeuille caché BitBox01 ;
• Fin 2018, Thomas Roth, Dmitry Nedospasov et Josh Datko (wallet.fail), puis en 2019 le Donjon de Ledger, ont extrait la seed d’un Trezor One par injection de défaut ;
• Fin 2019 sur le KeepKey, puis début 2020 sur le Trezor One et le Model T, Kraken a fait de même en environ 15 minutes, avec un outil coûtant moins de 100 $ ;
• En 2020, Shift Crypto a montré qu’un Coldcard pouvait valider une transaction de testnet et la signer pour mainnet, puis, quelques mois plus tard, qu’il ne détectait pas la substitution du xpub d’un co-signataire dans un multisig ;
• En 2023, notre PDG Kévin Loaec a trouvé une faille dans l'encodage Miniscript de l'application Bitcoin de Ledger ;
• La même année, le paquet connect-kit npm de Ledger a été compromis par l’intermédiaire d’un ancien employé victime de fishing ;
• En 2024, le Donjon a lu et modifié le firmware d'un Trezor Safe 3 grâce à une injection de défaut ;
• En 2025, Blockstream a fixé un débordement de pile dans le Jade ;
• Et en août 2026, BitBox a révélé et corrigé 3 failles dans le BitBox02, dont l'une aurait permis à un attaquant, après une attaque de phishing réussie, de tromper l'utilisateur en lui faisant installer un firmware malveillant sur un appareil authentique.

Cette liste n'est qu'un échantillon. Il y a des dizaines d'autres vulnérabilités divulguées dans l'écosystème, et l'objectif ici n'est pas de toutes les lister. Gardez également à l'esprit qu'un vendeur avec moins de failles listées n'est pas nécessairement plus sûr, car le décompte reflète surtout qui est audité et qui publie.

Aucun de ces incidents ne fait de ces vendeurs de mauvais vendeurs, et la conclusion n'est pas de rechercher un vendeur parfait, car ça n'existe pas. Ce que l’incident de Coldcard et toutes ces autres vulnérabilités devraient nous apprendre, c’est simplement d’accepter le fait que les portefeuilles matériels, et plus largement n’importe quel système, peuvent avoir des défauts. Il n'y a pas de risque zéro, dans aucun système.

Cependant, protéger des bitcoins, ce n’est pas comme protéger n’importe quelle autre donnée. Un mot de passe volé peut être changé, les frais de carte frauduleuses remboursés, un fichier supprimé, restauré à partir d’une sauvegarde... Une transaction Bitcoin, en revanche, ne peut pas être annulée. Et Bitcoin, c’est de l’argent, des années de travail, le filet de sécurité d’une famille, la liberté, un projet, une retraite... Une perte comme celle-là n’est pas facilement récupérée. C'est pourquoi un niveau de risque que nous tolérerions dans d'autres systèmes informatiques devient inacceptable ici. L’objectif pour les utilisateurs de Bitcoin est donc de construire un portefeuille qui survit à une faille dans l’un des appareils utilisés pour stocker ou gérer des clés privées.

Notez également que la dissimilarité n'est jamais totale. Par exemple, le Trezor One et le KeepKey ont partagé le même microcontrôleur STM32. Coldcard et BitBox02 utilisent également le même élément sécurisé, l’ATECC608 de Microchip. Coldcards a longtemps utilisé une bibliothèque cryptographique dérivée de Trezor (avant l’introduction de la vulnérabilité). Tous les appareils mettent en œuvre BIP-32 et reçoivent tous leurs transactions à partir du même ordinateur. Vous pouvez encore aller plus loin : ils se connectent tous sur la courbe secp256k1, la plupart d'entre eux avec la même bibliothèque libsecp256k1 de Bitcoin Core ou l'un de ses forks.

Choisir différents vendeurs ne garantit donc pas l'isolation parfaite des modes de défaillance. Il y aura toujours des composants, d'aussi bas niveau soient-ils, partagés par deux appareils de marques différentes. Mais le choix du multisig multi-vendeurs vous rapproche à ce jour le plus possible de la dissimilarité, et chaque couche partagée en moins est un mode de défaillance en moins, et donc une surface d'attaque plus petite. L'avantage du multisig multi-vendeurs est qu'une décision simple permet de contrer un grand nombre des points d'échec uniques sur votre portefeuille (SPOF).

Contre quoi un multisig multi-vendeurs protège-t-il ?

Pour évaluer un modèle de sécurité, vous devez le tester au regard des 2 façons de perdre vos bitcoins : le vol et la perte. Le vol, c'est quelqu'un d'autre qui dépense vos fonds. La perte, c'est quand plus personne ne peut les dépenser, y compris vous.

Presque toutes les solutions proposées aux particuliers réduisent un risque aux dépens de l’autre. La passphrase réduit le risque de vol et aggrave le risque de perte. Garder 3 copies de la seed réduit le risque de perte et aggrave le risque de vol. Un multisig seul, à plein seuil (N-sur-N), réduit le risque de vol mais aggrave le risque de perte, puisque vous devez maintenant garder plusieurs seeds, et en perdre une seule condamne vos fonds.

Contre le vol, le multisig multi-vendeurs couvre une classe de risques beaucoup plus large qu'un seul appareil :

• Un défaut de RNG comme celui de Coldcard : seulement 1 clé sur N est prévisible, ce qui est inférieur au seuil ;
• Un firmware buggé ou malveillant qui signe incorrectement ou exfiltre la seed à l'intérieur d'une signature : chaque appareil ne fournit qu'une seule des signatures requises et ne connaît que sa propre clé ;
• Un appareil altéré dans la chaîne d'approvisionnement, pour la même raison ;
• Un écran-menteur : un appareil compromis peut afficher une fausse adresse, mais chaque appareil de signature vérifie l'adresse de destination et l'adresse de change par rapport à la politique enregistrée, et vous pouvez afficher une adresse de réception sur l'un de vos appareils. L'attaquant devrait tromper tous les appareils que vous vérifiez, avec la même fausse adresse ;
• Vol physique d'un appareil ou d'une seed : une clé à elle seule est inutile ;
• Un défaut dans une puce ou un élément sécurisé spécifique à un vendeur : les autres appareils utilisent différentes puces ;
• Une signature nonce réutilisée ou biaisée, qui révèle la clé privée du dispositif défectueux : elle ne révèle que celle-ci ;
• Une mise à jour compromise du firmware ou une clé de signature de firmware volée à un vendeur : elle n'affecte que les appareils de cette marque ;
• etc.

Dans tous ces cas, le raisonnement est le même : l'attaquant doit réussir, en même temps, son attaque contre plusieurs cibles indépendantes.

Les chemins de récupération à verrouillage temporel entrent en jeu contre le risque de perte. Un portefeuille Liana peut faire beaucoup plus qu'un système M-sur-N fixe, grâce à Miniscript. Il définit un chemin principal, dépensable à tout moment, et un ou plusieurs chemins de récupération, verrouillés pendant une durée exprimée en blocs, qui ne deviennent utilisables que si les bitcoins n'ont pas bougé depuis pendant la-dite durée. En pratique, un 3-sur-3 pour un usage quotidien peut être mis en place de sorte qu'après 6 mois d'inactivité, 2 clés suffisent, et après 12 mois, seule une suffira. Vous avez perdu un appareil ? Pas de panique : vous attendez que la durée de verrouillage soit terminée, puis vous déplacez les fonds avec les clés restantes. Vous en avez perdu 2 ? Même chose, un peu plus tard. Ces conditions sont écrites dans le script Bitcoin lui-même, via Miniscript, et appliquées par consensus. Personne ne peut ouvrir une voie de récupération à l'avance.

Cette combinaison est ce qui rend le modèle intéressant. Le multisig multi-vendeurs réduit le risque de vol, le chemin de récupération à verrouillage temporel réduit le risque de perte, et aucun des deux n'augmente l'autre, puisque les chemins de récupération ne sont pas immédiatement accessibles. La protection contre le vol reste à seuil complet au jour le jour, et le risque de perte est couvert par le temps qui passe, plutôt que par des clés supplémentaires à protéger. Aucune autre solution sans confiance ne réduit les deux risques à la fois sans troquer l’un pour l’autre.

Maintenant, regardons les alternatives et pourquoi je pense qu’elles sont en deçà de multisig multi-vendeurs pour les utilisateurs de Bitcoin.

Les soit-disant bonnes solutions face à la faille

Revenons aux 2 autres conseils qui ont inondé X depuis le 30 juillet.

« Lancez vos propres dés »

La première réaction à la faille a été de dire que le problème venait de la confiance placée dans le générateur de nombres aléatoires du vendeur, et que la solution était de produire votre propre entropie, avec des dés. Le raisonnement n'est pas faux, mais il est incomplet. Il n'y a que 2 façons de transformer les lancers de dés en une seed.

La première est de tout faire à la main sur papier. Convertir les lancers en mots est facile, mais la somme de contrôle ne l'est pas. Le dernier mot d'une seed BIP-39 contient une somme de contrôle (4 bits pour 12 mots, 8 bits pour 24) calculée à partir d'un hachage SHA-256 de l'entropie. Le calculer à la main est possible en théorie, mais personne ne le fera. Cela prend beaucoup trop de temps et la moindre erreur vous oblige à recommencer.

Donc, dans la pratique, une seed entièrement faite à la main à partir de dés n'existe pas. Soit un portefeuille matériel termine le travail, et vous êtes dans la deuxième méthode ci-dessous, soit vous finissez par enregistrer vos lancers dans un ordinateur, au mieux sur Tails OS et hors ligne pour limiter l'exposition pendant la génération, mais c'est toujours un ordinateur, avec son énorme surface d'attaque. Et vous mettez sur cet ordinateur la seed, qui, par la définition-même d'un portefeuille matériel, n'était jamais censée quitter l'appareil. Cela en fait une très mauvaise pratique.

BitBox propose une option pour contourner la somme de contrôle : générez vos 23 premiers mots avec des dés, et BitBox calcule le 24e pour vous. Cela atténue mon premier argument, puisqu'un portefeuille matériel termine le travail au lieu d'un ordinateur. Mais il doit s'agir d'un BitBox02, même si ce n'est pas le portefeuille que vous aviez prévu d'utiliser, et les risques humains autour des lancers de dés, auxquels nous allons arriver, restent les mêmes.

La seconde méthode consiste à entrer les résultats des dés directement dans un portefeuille matériel qui offre cette option, comme Coldcard ou SeedSigner. C'est beaucoup mieux, car la conversion des lancers et le calcul de la somme de contrôle se produisent à l'intérieur de l'appareil, et c'est ce qui a protégé les utilisateurs de Coldcard affectés. Mais il y a encore une condition importante : l'appareil doit appliquer un nombre minimum de lancers d'un dé à 6 faces : 50 pour 128 bits et 99 pour 256 bits. S'il ne l'applique pas, l'utilisateur peut créer une seed très faible sans le savoir.

Et même à l'intérieur de l'appareil, la qualité de la seed dépend toujours de ce que l'humain fournit, car l'appareil le construit en hachant vos lancers, mais n'ajoute aucune entropie. Le problème ne vient pas des dés eux-mêmes. Un dé ordinaire est très bien : la plus grande étude sur le sujet, 4,38 millions de lancers enregistrés, conclut que la précision parfaite de dés de casino est quasi-indiscernable de celle des dés bon marché avec des points creusés. Les dangers sont humains, parce qu'un chiffre dactylographié à partir de la mémoire au lieu d'un vrai lancé n'apporte presque pas d'entropie, les lancers ignorés en diminuent la quantité totale, et une série de lancers qui a été observée ou photographiée n'est plus un secret. Coinkite résume en 3 adjectifs dans sa documentation : des lancers équitables, indépendants et privés. Mais chacun des 3 est l'occasion de se tromper sans qu'aucun voyant d'avertissement ne s'allume.

Vous avez également besoin de preuve que l'appareil a réellement transformé vos lancers en seed, et que les clés proviennent de cette seed. Le vérifier directement, sans faire confiance au vendeur, signifie refaire le calcul sur un deuxième appareil à partir d'une autre marque (mêmes lancers, mêmes mots, les deux utilisent la même méthode de dérivation, puis importer les mots et comparer les xpubs). À ce stade, vous possédez déjà 2 appareils de 2 vendeurs différents, la première étape d'un multisig multi-vendeurs, sauf qu'ici les deux détiennent la même seed, donc une faille dans l'un ou l'autre l'expose. Il y a un contrôle plus léger et indirect : exécutez des lancers, et à travers l'appareil, reproduisez le résultat attendu avec un programme sur un ordinateur, et s'ils correspondent, recommencez avec de vrais lancers, cette fois sans jamais les exposer. C'est une façon de découvrir un bug, mais pas un firmware qui se comporte mal de manière sélective. Et ces tests sont à eux seuls plus complexes que la mise en place d'un multisig.

Et même bien fait, ce mode règle une seule question : la confiance dans le générateur de nombres aléatoires du vendeur. Il ne protège pas contre le firmware qui signe incorrectement, un écran-menteur, une chaîne d'approvisionnement compromise, l'exfiltration de seeds à l'intérieur d'une signature, ou tout autre élément qui peut arriver à un singlesig sur un seul appareil.

Ajoutez à cela le fait que générer une seed avec des dés est complexe et presque impossible à faire correctement en dehors d'un appareil, et que nous n'allons pas demander à chaque débutant de le faire. Lorsque les gens objectent qu'un multisig multi-vendeurs c'est compliqué, je réponds que la seed générée par des dés l'est beaucoup plus.

« Ajouter une passphrase »

Le deuxième conseil est encore plus répandu : utiliser un singlesig avec une passphrase.

La passphrase BIP-39 est un texte de forme libre que le portefeuille ajoute comme un sel dans la fonction qui transforme la phrase mnémonique en seed binaire utilisée pour la dérivation des clés, de sorte que connaître la phrase mnémonique seule ne suffit pas à dériver les clés privées, et donc à dépenser les bitcoins du portefeuille. Vous avez besoin à la fois de la phrase mnémonique et de la passphrase pour dériver les clés.

Cette construction a 3 conséquences directes :

• Tout d'abord, il n'y a pas de somme de contrôle. Chaque passphrase génère une seed valide, et donc un portefeuille valide (et vide), sans aucun message d'erreur ;
• Deuxièmement, la passphrase est sensible à la casse et aux espaces ;
• Troisièmement, la passphrase est un deuxième secret : le sauvegarder n'est pas plus facile que de sauvegarder une deuxième clé.

La spécification nécessite également la normalisation Unicode (NFKD), que toutes les implémentations n'appliquent pas : bitcoinj, par exemple, dérive la seed avec la passphrase brute, contrairement à d'autres portefeuilles tels que Sparrow qui suivent BIP-39. Ainsi, une passphrase contenant un « é » peut donc ouvrir 2 portefeuilles différents selon les logiciels.

Rien de tout cela n’est évident pour un débutant, c’est pourquoi, si vous voulez utiliser une passphrase, je crois que vous avez d’abord besoin d’une solide compréhension de l’architecture du portefeuille HD et de ses implications, sinon vous vous dirigez vers un désastre.

Mais au-delà du fonctionnement de la passphrase, la générer est la partie vraiment difficile. Une passphrase est aussi forte que son entropie, pas d'avantage, et les humains sont de terribles sources d'aléatoire. Pour qu'il s'agisse d'une véritable protection si la phrase mnémonique est un jour compromise, la passphrase doit être générée aléatoirement et hors ligne. Ce n’est pas quelque chose que vous faites naturellement, à l’instinct, en choisissant un mot de passe qui signifie quelque chose pour vous. Il prend des dés et une méthode éprouvée, et la passphrase ne doit jamais être tapée ou générée sur un ordinateur. À en juger par ce que les gens publient sur les réseaux sociaux depuis la faille de Coldcard, je pense que la plupart des utilisateurs de passphrases n'ont pas suivi ce genre de méthode, et que leur passphrase est beaucoup plus faible qu'ils ne le croient.

De plus, la passphrase n'est pas destinée à être mémorisée. Les longueurs nécessaires pour qu’elle soit vraiment efficace la rendent presque impossible à retenir. Donc, au-delà du fait que la garder seulement dans votre tête est extrêmement risqué, si vous connaissez la vôtre par cœur, il est très probable qu'elle ne soit pas assez longue ou pas vraiment aléatoire.

Pour autant, supposons que vous avez généré, hors ligne, une passphrase assez longue et vraiment aléatoire. Maintenant, vous devez vivre avec. Au jour le jour, la passphrase n'est pas stockée sur l'appareil par défaut ; vous la retapez à chaque session (sauf si vous utilisez une option que certains appareils offrent pour la stocker, comme un registre avec la passphrase attachée à un code PIN secondaire).

La saisir n'est pas une tâche facile sur de petits appareils à 2 boutons. Vous devez sélectionner chaque caractère dans une longue liste, un par un, sans une seule erreur, ou vous devrez recommencer. Quiconque a déjà essayé d'entrer une passphrase sur une Coldcard Mk ou une Nano S, par exemple, sait à quel point c'est long et fastidieux.

L'argument selon lequel les dépenses quotidiennes seraient plus simples avec une passphrase attachée à un singlesig, qu'avec un multisig est, à mon avis, faux. Un multisig prend certes plus de temps à configurer initialement, mais une fois configuré, il est beaucoup plus simple de brancher 2 ou 3 appareils et de signer avec eux que de taper manuellement pour chaque transaction sur un appareil à 2 boutons, une passphrase de 40 caractères que vous ne connaissez pas par cœur.

Ensuite, vous devez sauvegarder cette passphrase. Il s'agit d'un deuxième élément de sauvegarde critique, à graver sur un support durable, et stocké à un endroit différent de la phrase mnémonique, sans mécanisme de réinitialisation ou de récupération. En d'autres termes, la passphrase ne réduit pas les points d'échec uniques ; elle en crée un second. Perdre la phrase mnémonique, tout est perdu. Perdre la passphrase, tout est perdu aussi. La passphrase réduit le risque physique de vol de la phrase mnémonique, c'est un fait. Mais il double le risque de perte, alors que le multisig avec un chemin de récupération réduit les deux à la fois, tout en simplifiant encore d'avantage la sauvegarde, surtout si vous optez pour la non-sauvegarde des seeds (plus de détails ci-dessous).

Cela laisse la question de savoir ce qu’elle protège et ce qu’elle ne protège pas (à condition qu’elle soit assez longue et aléatoire). Elle protège contre le vol physique de la phrase mnémonique, contre l'extraction de la phrase mnémonique d'un dispositif éteint, et, dans le cas spécifique de Coldcard, contre l'énumération d'un espace mnémonique réduit. Tous les autres types de défauts passent à travers elle, pour une raison simple : la passphrase va dans le même firmware, sur le même appareil, que la phrase mnémonique. Le firmware qui signe avec de mauvais nonces, ou qui exfiltre délibérément la phrase mnémonique dans les nonces de quelques signatures, peut tout aussi facilement exfiltrer la clé-maître déjà dérivée avec la passphrase. Un appareil compromis dans la chaîne d'approvisionnement, un écran affichant une fausse adresse, une faille de dérivation, un attaquant vous forçant à taper votre passphrase devant eux : dans tous ces cas, il n'y a toujours qu'une seule clé à compromettre.

Un multisig multi-vendeurs, en revanche, met chaque signature sur un appareil différent, de sorte qu'un appareil compromis ne fait fuiter qu'une fraction de ce qui est nécessaire pour dépenser, chaque dispositif de signature vérifie la destination par rapport à la politique enregistrée, et un attaquant doit rassembler plusieurs signatures à plusieurs endroits.

Le sophisme derrière le bug du cas Coldcard

Ce qui me dérange le plus dans les 2 conseils précédents, ce n’est pas qu’ils soient inutiles ; c’est le raisonnement derrière eux : « dés et passphrases ont sauvé les utilisateurs de Coldcard, donc les dés et les passphrases vous sauveront ». C'est une généralisation hâtive, tirant une règle d'un cas isolé, aggravée par le biais de survie. Nous regardons les Mk3 qui ont été sauvés ; nous ignorons les passphrases oubliées, les passphrases faibles qui se sont faites hackées, et les bugs qui n'ont rien à voir avec l'entropie.

C’est ce que les stratèges appellent « combattre la dernière guerre ». Le cas d'école est la ligne Maginot : après 1918, la France a tiré les leçons de la guerre de tranchée et a passé les années 1930 à construire une ligne de fortification le long de sa frontière avec l'Allemagne, prête à tenir le front de la guerre précédente. En mai 1940, la Wehrmacht l'a simplement contournée par les Ardennes et la Belgique, et la France est tombée en 6 semaines. La faille de juillet 2026 était une faille RNG, et des dés répondent exactement à ce type de problème. Construire toute votre défense autour de ce problème, c'est construire votre propre ligne Maginot : la prochaine faille peut être une signature, un problème d'écran, une dérivation ou un défaut de la chaîne d'approvisionnement, et ni les dés ni une passphrase ne feront de différence.

Un modèle de sécurité ne doit pas être évalué par sa capacité à contrer le dernier bug connu, mais par sa capacité à survivre au prochain, dont personne ne connaît encore la nature. C'est précisément ce que fait la redondance dissimilaire : elle n'assume rien de la nature de la faille, seulement qu'il est peu probable de frapper plusieurs vendeurs indépendants en même temps.

Les 2 inconvénients qui méritent d'être mentionnés

Pour être tout à fait honnête, le modèle que je défends présente 2 véritables inconvénients à prendre en compte.

Confidentialité on-chain

Le principal inconvénient objectif du multisig par rapport au singlesig, avec ou sans passphrase, réside dans son empreinte sur la blockchain. Lorsque vous dépensez depuis un singlesig P2WPKH, la transaction révèle une signature et une clé publique, comme des dizaines de millions d'autres. Lorsque vous dépensez à partir d’un multisig P2WSH, cependant, la transaction doit révéler le script complet afin que les nœuds puissent le vérifier : le nombre de clés, le seuil, toutes les clés publiques, y compris celles qui n'ont pas signé, et, dans le cas de Liana, les chemins de récupération et leurs verrouillages temporels. Cette empreinte est très distinctive. Sur l'ensemble des UTXO établi en avril 2025, selon le rapport mempool.space, les sorties P2WSH représentaient à peine 1 % du total, contre 26,5 % pour P2WPKH. Vous êtes dans un ensemble d'anonymat beaucoup plus petit, et même dans cet ensemble, votre portefeuille a des caractéristiques distinctives que les autres n'ont pas.

Taproot atténue le problème sans le faire disparaître. Liana prend en charge Taproot depuis la version 5. Si le chemin principal est une seule clé, cette clé devient la clé interne, les dépenses quotidiennes passent par le chemin de clé, et rien ne distingue votre portefeuille d'un singlesig Taproot tant que vous n'utilisez pas un chemin de récupération. Mais si le chemin principal est un multisig, les dépenses de chemin de clé ne sont pas encore possibles : il nécessite une agrégation de signatures, qui viendra avec le support MuSig2 dans Liana, actuellement en cours de développement. Pour l'instant, le multisig réside dans une feuille de script Taproot, et les dépenses révèlent cette feuille (les clés du chemin utilisé et le seuil), même si les autres chemins et leurs verrouillages temporels restent cachés. C’est mieux que P2WSH, mais l’empreinte reste distinctive, à l’intérieur d’un petit ensemble d’anonymat mondial.

Il y a 2 choses à préciser pour mettre cet inconvénient en perspective, à mon avis :

• La première est qu'il s'agit d'un compromis, et la plupart des gens ont raison de le régler en faveur de la sécurité : une empreinte sur chaîne plus reconnaissable ne vous coûte pas de bitcoin ; une faille du firmware sur un seul appareil vous les fera tous perdre ;
• La deuxième est que cela ne rend pas une confidentialité multisig ingérable, et vous pouvez toujours utiliser un portefeuille de dépenses à chaud avec de petites sommes, où le maintien de la vie privée est beaucoup plus simple. Rester privé demande simplement un peu plus de soins, car le point de départ est plus reconnaissable.

Rafraîchir vos pièces

Le deuxième inconvénient vient avec les chemins de récupération. Un chemin de récupération s'ouvre lorsque les bitcoins n'ont pas bougé depuis un certain nombre de blocs. Donc, avant la date limite, vous devez les déplacer : c’est-à-dire effectuer une transaction du portefeuille vers lui-même, signée par le chemin principal, qui réinitialise le compteur de chaque UTXO à zéro. Cela coûte des frais de transaction ordinaires, et vous devez vous rappeler de le faire. Notez que cette durée de verrouillage a un plafond, et qu'il ne vient pas de Liana. Le verrouillage relatif est encodé en 16 bits dans le champ nSequence, et est plafonné à 65 535 blocs, soit environ 15 mois. C’est une règle de consensus, la même chose pour tous les logiciels, indépendamment des choix de mise en œuvre de Liana.

Cet inconvénient a un avantage que je trouve intéressant. Avec un portefeuille d’épargne classique, vous rangez la seed, ne touchez à rien pendant 5 ans, et le jour où vous en avez besoin, vous ne vous souvenez plus tout à fait de la façon dont tout fonctionne. Le rafraîchissement vous oblige à ouvrir le portefeuille, à brancher vos appareils et à signer une transaction tous les 6, 12 ou 15 mois. C'est un contrôle forcé : la possibilité de vérifier que les appareils démarrent et que vous savez toujours comment les utiliser. Vu de cette façon, la rafraîchissement est le coût d'entretien de votre garde : des frais de transaction tous les 6 à 15 mois, probablement moins que les frais annuels de tout compte bancaire ou police d'assurance. Un portefeuille que vous ne vérifiez jamais est un portefeuille dont vous découvrez l’état le jour où vous en avez le plus besoin.

Plus difficile à comprendre, plus simple à utiliser

Ensuite vient un argument que j'entends souvent : un multisig avec des chemins de récupération est plus compliqué. C'est vrai. Comprendre un 3-sur-3 qui devient un 2-sur-3 après 6 mois demande plus d’efforts que de comprendre « une seed plus un mot de passe ». Cependant, vous devez distinguer la complexité de la compréhension, de la complexité de l'utiliser, et sur ce deuxième point, la situation se retourne complètement.

Larry Tesler, un pionnier de l’interaction homme-ordinateur, a formulé au milieu des années 1980 ce qui est depuis connu sous le nom de loi de Tesler, ou la loi de conservation de la complexité : chaque application contient une quantité irréductible de complexité, qui ne peut être ni enlevée ni cachée. La seule question est de savoir qui la porte : le logiciel ou l'utilisateur.

Appliquons cette théorie aux 2 modèles :

• La passphrase est triviale en code informatique : il s'agit juste d'un sel ajouté à une fonction de dérivation. Toute la complexité est reportée sur l'humain : générer suffisamment d'aléatoire hors ligne, retaper la passphrase pour chaque dépense, sauvegarder un deuxième secret sans somme de contrôle sur un support durable dans un endroit séparé, écrire l'empreinte principale du portefeuille pour détecter une faute de frappe...
• Un multisig avec des chemins de récupération est complexe à coder : Miniscript, descripteurs, verrouillages relatifs, gestion de chemins, tout cela est géré dans Liana et dans le firmware des appareils. Ce que l'utilisateur voit, quant à lui, est très simple : des seeds ordinaires de 12 ou 24 mots, chacune avec sa somme de contrôle, un fichier descripteur à copier partout, et une transaction qui vous demande de brancher un appareil et de confirmer.

Un multisig n'est pas compliqué à sauvegarder

La complexité d'une sauvegarde de multisig était réelle il y a 5 ou 6 ans : mettre en place un multisig vous-même signifiait comprendre que les seeds ne suffisent pas, que vous deviez également garder les xpubs de tous les co-signataires, ainsi que les chemins de dérivation. Sinon, vous risquiez de vous retrouver avec 2 seeds valides sur 3 et des fonds inaccessibles faute de certaines données publiques. Et en plus de cela, il n'y avait pas de standardisation à travers les logiciels.

Depuis, les descripteurs ont tout changé. Un descripteur est une chaîne de texte standardisée qui décrit entièrement le portefeuille : le type de script, les clés publiques étendues de chaque co-signataire avec leur origine, les seuils, les chemins de récupération et leurs verrouillages temporels le cas échéant. Un portefeuille Liana se résume ainsi à 2 choses à sauvegarder : les seeds (une par clé, à moins que vous ne choisissiez de ne pas sauvegarder celles du chemin primaire, comme je le montrerai ci-dessous) et le descripteur.

Maintenant, ces 2 choses ne présentent pas le même type de risque. La seed est secrète : celui qui la trouve peut signer en votre nom, vous voulez donc le moins d'exemplaires possible. Le descripteur a seulement un caractère privé : celui qui le trouve ne peut pas dépenser un seul satoshi ; il ne peut lire que votre solde et votre historique de transactions. La bonne stratégie est donc peu de copies de la seed, beaucoup de copies du descripteur. La seule chose qui devait limiter ces copies était la vie privée, puisqu’un descripteur en texte clair sur un service en ligne expose vos avoirs.

C'est le problème que le chiffrement du descripteur résout. Depuis la version 13, Liana produit par défaut, à la création de portefeuille, un fichier .bed (Bitcoin Encrypted Descriptor), dont le schéma a depuis évolué en un projet de norme, BIP-138, écrit par Pythcoiner à partir d'une idée de Salvatore Ingala. Le principe est le suivant : au lieu d'inventer une clé de chiffrement qui, à son tour, aurait besoin d'être sauvegardée, le descripteur est chiffré avec les clés publiques qu'il contient déjà, ses propres xpubs. N'importe laquelle de ces xpubs est alors suffisante pour le déchiffrer, et vous les avez déjà, car elles peuvent être re-dérivées de vos seeds ou lus à partir de vos appareils. Aucun nouveau secret n'est créé. Le résultat est un fichier illisible par quiconque ne détient aucune des xpubs du portefeuille, et que vous pouvez donc copier n’importe où sans aucune précaution : sur Google Drive, par courrier électronique, sur une clé USB, sur votre ordinateur, chez un proche... Sauvegarder le descripteur cesse d’être une question de complexité et devient une question de redondance, et la redondance ne coûte plus rien.

Un multisig n'est pas trop cher pour les particuliers

Enfin vient l'argument du prix. Acheter 2 ou 3 portefeuilles matériels de différentes marques est un investissement, et certains concluent qu'un multisig est fait seulement pour ceux qui détiennent plus d'un certain montant. Je ne crois pas qu'il y ait un seuil au-dessus duquel un multisig devient nécessaire. La seule limite est en bas : si le prix d'un portefeuille matériel est hors de proportion avec ce que vous détenez, aucune configuration n'est justifiée et un portefeuille mobile fera l'affaire. Au-delà de ce cas, la bonne question n’est pas « combien j’ai » mais « ce que je perdrais ». Si perdre cette somme vous mettait en difficulté réelle (financière, psychologique ou familiale), alors elle mérite le meilleur système de sécurité que vous pouvez raisonnablement configurer, et ce meilleur système aujourd'hui est le multisig multi-vendeurs avec un chemin de récupération à verrouillage temporel.

D'autant que « multi-vendeurs » ne signifie pas forcément acheter plusieurs appareils. La première configuration que je décris ci-dessous n'en nécessite qu'un seul, complété par une clé sur votre ordinateur, et elle bat déjà un singlesig, avec ou sans passphrase, à la fois au niveau du risque de vol et de perte.

Configurations concrètes dans Liana, en fonction de votre budget

Tout ce qui précède reste théorique jusqu'à ce que l'on passe au concret sur ce qu'il faut installer. Voici donc 5 configurations, de la plus accessible à la plus complète. Toutes sont construites dans l’installateur Liana avec le mode « Construire la vôtre », qui vous permet de définir librement chaque chemin, son seuil et sa durée avant activation.

Liana prend en charge tout portefeuille matériel qui implémente Miniscript, et nous en ajoutons de nouveaux dès que leur prise en charge est officielle. Voici la liste complète à jour (17 août 2026) :

• Ledger : Nano S Plus, Nano X, Stax, Flex, et Nano Gen 5 ;
• BitBox : BitBox02 et BitBox Nova ;
• Jade : Jade, Jade Plus, et Jade Core (notez que les Jade ne prennent en charge Miniscript qu'en SegWit natif, pas en Taproot) ;
• Specter DIY ;
• Krux.

Quelle que soit la règle que vous choisissez, le principe est toujours le même : aucun chemin de dépense ouvert ne devrait être satisfaisant avec les clés d'un seul vendeur. Pour le chemin principal, cela tient en tout temps. Pour les chemins de récupération qui ont besoin d'une seule clé, il tient aussi longtemps que vous rafraîchissez vos UTXO avant la date limite.

1. Un seul portefeuille matériel et une hot key

C'est la configuration d'entrée de gamme, et elle nécessite d'acheter un seul portefeuille matériel. Le chemin principal est un 2-sur-2 entre ce portefeuille matériel et une hot key, c'est-à-dire une clé stockée sur votre ordinateur, que Liana peut générer directement dans le programme d'installation. Le chemin de récupération est un 1-sur-2 avec ces 2 mêmes clés, qui s'ouvre après 12 mois d'inactivité, soit environ 52 600 blocs.

La hot key réside sur un ordinateur connecté, et son mnémonique de 12 mots est stocké en texte clair sur le disque. Pris seul, il est beaucoup moins sécurisé que la clé du portefeuille matériel. Mais il n'est jamais utilisé seul, et c'est précisément ce qui le rend acceptable ici. Pour voler vos fonds avant l'ouverture du chemin de récupération, un attaquant doit compromettre à la fois votre ordinateur et votre portefeuille matériel, et il y a très peu de chances qu'un seul bug frappe un système d'exploitation grand public et le firmware d'un appareil dédié en même temps. Il est multi-vendeurs au sens large : les 2 ne partagent ni le même code ni les mêmes attaquants.

Si demain votre portefeuille matériel souffre d’un défaut de la taille de celui de Coldcard, un attaquant qui récupère sa seed ne peut rien faire sans la clé de votre ordinateur tant que le chemin de récupération reste verrouillé, alors qu’un singlesig sur ce même appareil, avec ou sans passphrase, pourrait être vidé.

Du côté de la perte, le chemin de récupération fait le travail : si l’ordinateur meurt et que vous n’avez plus la seed de la hot key, le portefeuille matériel récupère à lui seul les fonds après 12 mois, et si le portefeuille matériel disparaît, la hot key fait seule la même chose (avec le descripteur, bien sûr).

Au jour le jour, ce genre de portefeuille est très simple à gérer, puisqu'une dépense nécessite une signature du portefeuille matériel et une à partir de la hot key, que Liana ajoute elle-même. Vous branchez l’appareil, vous le confirmez, et c’est tout, comme un singlesig classique.

2. Multisig à dégradation programmée

Si vous pouvez mettre la main sur plusieurs appareils, la configuration la plus générale est le multisig à dégradation programmée. Le chemin principal est un 3-sur-3 composé de 3 portefeuilles matériels de 3 vendeurs différents. Un premier chemin de récupération le transforme en 2-sur-3 après, par exemple, 6 mois d'inactivité, et un second en 1-sur-3 après 12 mois.

Le 3-sur-3 au quotidien est le niveau maximum de protection contre le vol : 3 appareils de 3 marques différentes devraient être compromis. Le 2-sur-3 après 6 mois couvre la perte ou la défaillance d'un appareil, sans avoir besoin de se précipiter. Le 1-sur-3 après 12 mois couvre la perte de 2 appareils. Vous pouvez même ajouter un chemin d'héritage avec une quatrième clé verrouillée appartenant à un parent.

Un seul défaut chez un vendeur, comme celui de juillet 2026, ne crée de faiblesse fatale pour le 3-sur-3 ni pour le 2-sur-3

3. Multisig extensible

Le multisig extensible fait le contraire : au lieu d'abaisser le seuil dans le temps, il ajoute des clés. Le chemin principal est un 3-sur-3 avec vos 3 appareils. Après n mois d’inactivité, un chemin de récupération devient un 3-sur-4 en ajoutant une clé, par exemple une clé de sauvegarde conservée ailleurs ou une clé confiée à un parent ; après encore n mois supplémentaires, un 3-sur-5 en ajoutant une autre clé, qui peut être celle d’un fournisseur de services si vous le souhaitez.

Le but est de ne jamais concentrer le pouvoir de dépenser dans moins de clés qu'au départ. Le seuil reste à 3 tandis que des clés sont ajoutées, ce qui convient aux cas où les clés ajoutées sont détenues par d'autres personnes : aucune d'entre elles ne peut agir seule, ni 2 d'entre elles ensemble, et pourtant la perte de l'un de vos appareils est couverte dès que le premier chemin s'ouvre, et la perte de 2 dès que le second s'ouvre.

4. Multisig avec clé de récupération séparée

Rien ne vous oblige à réutiliser les clés du chemin principal dans les chemins de récupération. Un 2-sur-2 ou un 3-sur-3 pour une utilisation quotidienne peut, après 12 mois d'inactivité, activer un chemin de récupération contrôlé par une clé entièrement différente. Cette clé peut être la vôtre, stockée ailleurs, qui vous protège d’une catastrophe qui enlèverait chaque appareil appartenant au chemin principal ; ou un héritier, qui n’a aucun pouvoir tant que vous êtes actif et que vous rafraîchissez vos UTXO, et qui, si vous décédez, peut alors récupérer les fonds sans vous et sans tiers.

5. Devenir seedless sur multisig

Cette dernière configuration est moins une configuration qui lui est propre qu’un add-on aux configurations 1, 2 et 4, et elle répond directement à ceux qui trouvent les multisigs « overkill » pour un individu, car ils multiplient le nombre de seeds à protéger.

Avec les chemins de récupération à verrouillage temporel, le chemin principal n'a pas besoin de sauvegarde des seeds. En pratique, vous configurez vos portefeuilles matériels, vous n’écrivez jamais leurs 12 ou 24 mots (ou vous détruisez la sauvegarde par la suite), et vous sauvegardez uniquement la seed de la clé de récupération, plus le descripteur. C’est ce que nous appelons « seedless »: les clés du chemin principal n’existent qu’à l’intérieur des appareils.

Ce que vous gagnez est une surface d'attaque physique coupée au strict minimum. Il n'y a plus de plaque métallique à la maison qui donne à quiconque la lit l'accès aux fonds. Un cambrioleur qui s’éloigne avec vos appareils s’éloigne avec des boîtes protégées par un code PIN et, sur des modèles avec un élément sécurisé, sans moyen connu d’extraire la seed (rappel : ne stockez pas tous les appareils du chemin primaire au même endroit !).

Vous attendez, pendant ce temps, que le chemin de récupération s'ouvre, puis déplacez les fonds vers un nouveau portefeuille.

Ce que vous perdez est la possibilité de restaurer un appareil principal exactement comme il était : si un appareil se casse, si vous oubliez son code PIN, ou si une mise à jour l'efface, vous passez par le chemin de récupération, après avoir attendu la durée que vous avez choisie.

Ressources

• Télécharger Liana : lianawallet.com
• [...]