Authentification multisignature 2-of-3 : configuration Trezor Suite avec autres hardware wallets Ledger/ColdCard

Une institution financière détient des actifs numériques importants et souhaite que trois approbations soient requises pour chaque retrait majeur. Un fonds de pension cherche à éliminer le risque qu’un seul administrateur puisse autoriser une transaction sans vérification. Un cabinet d’avocats gère les portefeuilles de clients en fiducie et a besoin de preuves cryptographiques que plusieurs parties ont explicitement approuvé chaque mouvement de fonds. Ces situations exigent une architecture multisignature où aucune seule clé ne suffit à valider une transaction. La configuration 2-of-3 signifie que deux approbations sur trois appareils distincts doivent intervenir pour que la transaction soit diffusée.

La complexité vient de l’intégration pratique de plusieurs constructeurs. Un portefeuille matériel Trezor, un Ledger et un ColdCard ne partagent pas la même architecture cryptographique ou la même interface utilisateur. Chacun gère les clés privées selon ses propres spécifications, signe les transactions via des mécanismes distincts et exige une vérification de l’intégrité du firmware avant chaque utilisation. L’application de gestion Trezor Suite, téléchargée depuis trezor.io avec vérification SHA256, peut coordonner cette signature conjointe sur les appareils Trezor, mais les autres constructeurs demandent leurs propres étapes de validation. La question fondamentale n’est pas simplement de savoir comment connecter trois appareils. Elle consiste à vérifier que chaque appareil contrôle effectivement ses clés privées, que les signatures sont bien exécutées en environnement isolé, et que l’architecte de la solution peut auditer chaque étape sans supposer que le processus fonctionne correctement.

Architecture multisignature : fondamentaux et modèles de seuil

La signature multisignature ne distribue pas une clé privée en plusieurs fragments. Elle crée plutôt plusieurs clés indépendantes, chacune contrôlée par un appareil distinct, et utilise la cryptographie pour exiger qu’un nombre minimum d’entre elles signent une transaction avant que celle-ci ne soit valide. Une configuration 2-of-3 signifie que deux clés quelconques parmi les trois peuvent autoriser une dépense, tandis qu’une seule clé ne peut pas. Cette organisation offre un équilibre : si un appareil est perdu, volé ou compromis, les deux autres peuvent toujours approuver les transactions. Si deux appareils sont détruits, le troisième seul ne peut pas agir, forçant une récupération planifiée à l’avance.

Le contraste avec une clé centralisée est net. Dans un modèle traditionnel, une seule clé privée, protégée sur un seul appareil, signe toutes les transactions. Un vol ou une compromission de cet appareil met en danger tous les fonds. Un modèle multisignature répartit cette responsabilité : un attaquant doit obtenir l’accès à deux appareils physiquement distincts, avec des chemins de stockage différents et potentiellement des contrôles d’accès indépendants, pour pouvoir voler les fonds. Pour les institutions et les utilisateurs avancés, cet ajout de complexité opérationnelle se justifie par la réduction drastique du risque d’une perte catastrophique causée par un seul point de défaillance.

Les seuils 2-of-2 (deux appareils, deux approbations requises) et 3-of-5 (cinq appareils, trois approbations requises) sont aussi courants. Le choix du seuil dépend du compromis accepté entre disponibilité et sécurité. Un seuil 2-of-3 est souvent choisi par les institutions car il permet une perte d’un appareil sans rendre les fonds inaccessibles, tout en maintenant l’exigence que deux entités ou deux emplacements doivent approuver une transaction. Chaque appareil d’une configuration multisignature génère sa propre clé maître, indépendamment des autres. Ces clés ne sont jamais fusionnées, jamais partagées, et jamais stockées en un seul endroit.

La sécurité crypto du multisignature repose sur le fait que chaque signature est mathématiquement indépendante. Même si un attaquant obtient une signature, il ne peut pas la modifier pour autoriser une transaction différente, et une signature seule ne peut pas être transformée en deux signatures. Les standards comme BIP32, BIP44 et BIP45 définissent comment dériver des clés enfant à partir d’une clé maître, comment les ordonner, et comment un portefeuille multisignature sait quelles clés utiliser pour chaque transaction. L’importance de ces standards est qu’ils permettent à des appareils de différents fabricants de reconnaître mutuellement leurs clés respectives et de construire ensemble une adresse de portefeuille valide.

Intégration des appareils Trezor dans une configuration multisignature

Les appareils Trezor (Model One, T, Safe 3, Safe 5) supportent nativement la signature multisignature. Lorsqu’un Trezor est ajouté à une configuration multisignature 2-of-3, l’appareil génère une clé maître sur son processeur sécurisé, affiche les clés publiques dérivées sur son écran pour vérification manuelle, et ne divulgue jamais la clé privée. Chaque fois qu’une transaction doit être signée, l’appareil reçoit une demande de signature contenant les détails de la transaction, les affiche sur son écran isolé, et seulement si l’utilisateur appuie sur le bouton physique de confirmation, l’appareil calcule la signature à l’aide de sa clé privée interne.

Trezor Suite, disponible en tant qu’application de bureau pour Windows 10+, macOS Monterey+, et Linux, ou via une version web sur navigateurs Chromium, facilite cette intégration. L’application détecte automatiquement les appareils Trezor connectés via USB et présente une interface pour ajouter l’appareil à un portefeuille multisignature. Pendant ce processus, Trezor Suite affiche les clés publiques que chaque appareil génère, permettant à l’administrateur de les enregistrer ou de les capturer pour la configuration des autres appareils. La vérification des clés publiques sur l’écran de chaque appareil est une étape critique : elle garantit que l’appareil a bien généré une nouvelle clé et que personne ne l’a substituée par une autre pendant la configuration initiale.

L’application Trezor Suite ne demande jamais la phrase de récupération (seed phrase) sur l’écran d’un ordinateur. C’est un contrôle de sécurité fondamental : la phrase de récupération ne quitte jamais l’appareil matériel. Si une application Trezor Suite était compromise, elle ne pourrait pas extraire cette donnée sensible. L’application obtient les clés publiques dérivées auprès de l’appareil, mais pas la clé maître, et elle n’a pas besoin de celle-ci pour construire les adresses du portefeuille multisignature ou pour demander à l’appareil de signer une transaction.

Le contrôle de l’intégrité du firmware est un élément clé. À chaque connexion d’un appareil Trezor via Trezor Suite, le logiciel vérifie que le firmware de l’appareil n’a pas été modifié par un malware. Le firmware est signé numériquement par SatoshiLabs, et Trezor Suite valide cette signature avant de procéder. Si la signature est invalide ou absente, l’application avertit l’utilisateur et l’invite à réinstaller le firmware depuis trezor.io avec vérification SHA256. Cette vérification élimine les risques de phishing et de malware qui pourraient substituer un firmware compromis porteur d’une porte dérobée.

Configuration de Ledger dans une multisignature 2-of-3

Ledger propose également une signature multisignature, mais via Ledger Live et, pour certains cas avancés, via des applications de tiers comme Specter ou Caravan. Un appareil Ledger (Ledger Nano S Plus, Nano X, ou Stax) génère une clé maître lors de l’initialisation et dérive des clés enfant selon le schéma BIP32/BIP44. Ledger Live détecte les appareils connectés et permet de créer un portefeuille multisignature, mais le processus diffère légèrement de celui de Trezor Suite.

Dans une configuration 2-of-3 mélangée (Trezor + Ledger + ColdCard), Ledger ne connaît pas nativement les clés publiques des autres appareils. L’administrateur doit exporter les clés publiques de chaque appareil, idéalement en les affichant sur l’écran de chaque appareil pour vérification manuelle, puis les importer dans Ledger Live. Cela exige une coordination manuelle : l’administrateur se connecte au Trezor via Trezor Suite, enregistre la clé publique, se connecte au Ledger via Ledger Live, importe cette clé, puis répète le processus pour le ColdCard.

Ledger Live affiche les clés publiques des appareils connectés, mais pour une vérification complète, l’utilisateur doit également vérifier les clés sur l’écran physique de chaque appareil Ledger. Cet écran de confirmation est essentiel : il garantit que le logiciel Ledger Live n’a pas remplacé les clés publiques par d’autres avant de construire l’adresse multisignature. Une fois les clés importées et l’adresse de portefeuille générée, Ledger Live affiche des transactions en attente de signature et demande à l’appareil Ledger de les signer. L’utilisateur approuve chaque signature via l’écran et les boutons physiques de l’appareil, sans jamais exposer la clé privée au logiciel de bureau.

Un risque spécifique à Ledger Live est que l’application est propriétaire et fermée. Les utilisateurs ne peuvent pas auditer directement le code qui construit les transactions multisignature ou qui valide les clés publées. Contrairement à Trezor Suite, dont le code est ouvert et auditable sur GitHub, Ledger Live exige que l’utilisateur fasse confiance à l’application sans pouvoir vérifier ses opérations internes. Pour les institutions, ce manque de transparence peut être un facteur de décision majeur.

Intégration de ColdCard dans une configuration hétérogène

ColdCard, fabriqué par Coinkite, est un appareil matériel spécialisé conçu pour fonctionner hors ligne. Contrairement aux appareils Trezor et Ledger qui communiquent souvent par USB avec une application de gestion, ColdCard utilise principalement un écran et des boutons pour confirmer les transactions, et il communique via microSD ou des codes QR. Cette architecture rend l’intégration multisignature de ColdCard dans une chaîne hétérogène plus manuelle.

Dans une configuration 2-of-3 avec Trezor, Ledger et ColdCard, l’administrateur doit utiliser une application tierce capable de gérer des portefeuilles multisignature à partir de clés publiques de plusieurs sources. Specter Desktop (open-source) ou Caravan (également open-source) sont deux options largement utilisées. L’administrateur exporte les clés publiques de chaque appareil, les importe dans Specter ou Caravan, définit le seuil 2-of-3, et l’application génère l’adresse du portefeuille multisignature.

Lorsqu’une transaction doit être signée, Specter crée un fichier de transaction PSBT (Partially Signed Bitcoin Transaction) qui contient tous les détails de la transaction mais aucune signature. Ce fichier est transféré à chaque appareil (via USB pour Trezor et Ledger, via microSD pour ColdCard) où il demande l’approbation. Chaque appareil affiche les détails de la transaction sur son écran et demande une confirmation physique. Une fois que deux appareils ont signé le PSBT, la transaction est considérée comme complète et peut être diffusée sur la blockchain.

L’avantage de cette architecture est que ColdCard ne se connecte jamais directement à Internet. L’appareil reste isolé, réduisant la surface d’attaque réseau. L’inconvénient est que la gestion est plus lente : chaque étape de signature exige un transfert manuel de fichiers ou de codes QR. Pour les institutions qui acceptent cette friction opérationnelle en échange d’une sécurité renforcée, ce compromis peut être acceptable. Pour les transactions fréquentes, l’absence d’automatisation peut devenir un obstacle.

Processus de signature et vérification cryptographique

Lorsqu’une transaction doit être signée dans une configuration 2-of-3, le processus suit un ordre précis. D’abord, l’application de portefeuille (Trezor Suite, Ledger Live, Specter ou autre) construit la transaction en spécifiant les entrées (fonds à dépenser), les sorties (destinations et montants) et les frais estimés. La transaction n’est pas encore signée; elle contient seulement la structure et les données publiques.

Deuxièmement, la transaction est présentée au premier appareil matériel pour signature. L’écran de l’appareil affiche les détails essentiels : l’adresse de destination, le montant envoyé, les frais, et l’adresse de monnaie. L’utilisateur vérifie ces informations et, s’il approuve, appuie sur le bouton de confirmation physique de l’appareil. L’appareil calcule alors la signature à l’aide de sa clé privée interne, sans jamais l’exposer, et retourne la signature à l’application.

Troisièmement, la transaction partiellement signée est présentée au deuxième appareil. Cet appareil effectue une vérification indépendante : il valide que la transaction est bien formée, que la signature du premier appareil est cryptographiquement valide, et affiche les mêmes détails pour confirmation. Une fois que le deuxième appareil a signé, la transaction contient deux signatures sur trois clés possibles, ce qui satisfait la condition 2-of-3.

La vérification cryptographique garantit qu’aucune signature n’a été modifiée en transit. Chaque signature est liée mathématiquement à la clé publique de l’appareil qui l’a produite et au contenu exact de la transaction. Si un attaquant modifie une seule valeur dans la transaction après qu’elle ait été signée, la signature devient invalide. Si un attaquant essaie de substituer une signature, elle n’appariera pas avec les clés publiques du portefeuille multisignature. Cette propriété cryptographique est indépendante de la qualité du logiciel ou du réseau : elle est garantie par les mathématiques de la cryptographie asymétrique.

Bonnes pratiques pour la sécurité physique et opérationnelle

La configuration multisignature 2-of-3 élimine le risque d’une seule clé compromise, mais elle introduit une complexité opérationnelle qui peut devenir une vulnérabilité si elle n’est pas gérée correctement. La première bonne pratique est la séparation physique. Les trois appareils doivent être stockés en trois emplacements distincts, de préférence contrôlés par des personnes ou des entités différentes. Si tous les trois appareils sont stockés dans le même coffre-fort, un voleur qui accède à ce coffre-fort peut immédiatement accéder aux deux appareils nécessaires pour voler les fonds.

La deuxième bonne pratique est la documentation du processus de signature. L’institution doit enregistrer par écrit ou enregistrer vidéo le processus exact de signature : qui initie la demande, qui accède à chaque appareil, comment les détails de la transaction sont vérifiés, et qui approuve finalement. Cette documentation sert à plusieurs fins. Elle forme les nouveaux administrateurs, elle crée un audit trail pour la conformité, et elle permet de détecter des écarts ou des anomalies. Si une signature approuvée par le premier appareil disparaît soudainement, la documentation révèle si cela s’est produit auparavant et sous quelles conditions.

La troisième bonne pratique est le test de récupération. Une fois la configuration 2-of-3 établie, l’institution doit simuler la perte d’un appareil et vérifier que les deux appareils restants peuvent toujours signer les transactions. Cette simulation doit être menée hors ligne, en utilisant des transactions de test avec de petits montants, et elle doit documenter précisément comment l’appareil perdu a été remplacé ou comment sa clé privée a été restaurée depuis la phrase de récupération. Attendre une véritable catastrophe pour découvrir que la récupération n’est pas possible est imprudent.

La quatrième bonne pratique est le choix prudent des applications tierces. Specter Desktop, Caravan et d’autres applications multisignature sont open-source et auditables, mais elles ne sont pas officiellement supportées par SatoshiLabs ou Ledger. L’institution doit vérifier que l’application qu’elle choisit est maintenue activement, qu’elle bénéficie d’audits de sécurité indépendants, et que sa communauté d’utilisateurs comprend d’autres institutions de même taille. Une application abandonnée ou peu audité peut contenir des bugs qui compromettent la signature multisignature.

Vérification du firmware et élimination des risques de compromission

Chaque appareil matériel exécute un firmware qui implémente les opérations cryptographiques et gère l’interface utilisateur. Un firmware compromis, même si la clé privée reste protégée matériellement, peut refuser de signer les transactions légitimes, afficher des adresses incorrectes, ou créer des failles qui permettent à un attaquant d’inférer des informations sur la clé privée. La vérification du firmware est donc une étape obligatoire avant toute utilisation d’un appareil dans une configuration multisignature.

Pour Trezor, la vérification est intégrée à Trezor Suite. Chaque fois qu’un appareil se connecte, l’application contrôle que le firmware est signé par SatoshiLabs en utilisant une clé publique stockée dans le code de Trezor Suite. Si le firmware n’a pas la bonne signature, ou s’il s’agit d’une version antérieure à celle attendue, Trezor Suite avertit l’utilisateur et lui propose de réinstaller le firmware. Cette réinstallation doit être effectuée depuis trezor.io avec vérification SHA256. Un administrateur ne doit jamais télécharger le firmware depuis une autre source ou en faire confiance à une version hébergée sur un site tiers.

Pour Ledger, la vérification du firmware dépend de Ledger Live. Avant d’utiliser un appareil Ledger, l’utilisateur doit s’assurer que Ledger Live reconnaît le firmware comme authentique et à jour. Ledger propose également un processus de réinstallation du firmware si celui-ci semble compromis. Cependant, comme Ledger Live est propriétaire, l’utilisateur ne peut pas auditer indépendamment les détails cryptographiques de la vérification. L’institution doit faire confiance au processus de Ledger, ou chercher une application tierce capable de vérifier les signatures du firmware Ledger (ce qui n’existe pas largement disponible).

Pour ColdCard, la vérification du firmware peut être faite via des outils open-source comme coldcard-cli ou des applications de tiers. ColdCard publie des sommes de contrôle SHA256 et des signatures PGP de ses versions de firmware, permettant à un utilisateur avancé de vérifier indépendamment que le firmware téléchargé est authentique. Cette transparence diffère nettement de celle de Ledger Live et offre aux institutions une opportunité d’audit plus profond. Cependant, cette vérification exige de la compétence technique et une certaine familiarité avec les outils cryptographiques en ligne de commande.

L’absence de vérification du firmware avant d’utiliser un appareil dans une configuration 2-of-3 est une faiblesse critique. Si un attaquant a remplacé le firmware d’un seul appareil, cet appareil compromis peut refuser les transactions légitimes ou les rediriger vers une autre adresse. Puisqu’une configuration 2-of-3 exige deux signatures, un seul appareil compromis ne peut pas à lui seul autoriser une fausse transaction, mais il peut bloquer les transactions légitimes jusqu’à ce qu’un administrateur détermine quel appareil est défaillant et le remplace.

Vérification de l’intégrité du code et audit technique

Pour les institutions qui souhaitent pousser la vérification au-delà de la simple utilisation, l’accès au code source est essentiel. Trezor Suite est open-source et disponible sur GitHub. Cela signifie qu’une institution peut télécharger le code, le compiler elle-même, et vérifier que le binaire qu’elle exécute correspond bien au code publié. Cet exercice, appelé reproductible build, exige une infrastructure informatique mature, mais il offre une garantie cryptographique que personne n’a inséré de code malveillant dans l’application pendant sa compilation.

Ledger Live est propriétaire et ne permet pas cet audit approfondi. Les utilisateurs et les institutions ne peuvent vérifier que Ledger Live exécute exactement ce qu’il prétend en lisant le code. Une institution de taille significative peut négocier un audit de sécurité indépendant de Ledger Live, mais ce luxe n’est pas disponible aux utilisateurs ordinaires.

ColdCard et ses outils associés offrent un niveau intermédiaire. Le firmware de ColdCard est open-source, permettant aux utilisateurs techniques de compiler et de vérifier le firmware qu’ils installent. Les applications tierces comme Specter et Caravan sont également open-source. Cela signifie qu’une institution peut auditer chaque composant de sa chaîne multisignature, du firmware sur les appareils matériels aux applications de gestion du portefeuille sur le bureau.

Un utilisateur qui souhaite configurer une multisignature 2-of-3 professionnelle doit décider du niveau d’audit qu’il peut se permettre. Pour une institution avec une importante exposition aux actifs numériques, un audit technique complet par une sociétés spécialisée en sécurité cryptographique (comme une agence de conseils en cybersécurité qualifiée) est une dépense justifiée. Pour un utilisateur particulier avancé, la relecture du code open-source et la vérification des signatures numériques peut suffire. Le point clé est que plus l’audit est profond, plus la confiance dans l’intégrité de la configuration peut être fondée sur des preuves techniques plutôt que sur des allégations du fabricant.

Configuration pratique : étapes et checklist

Avant de commencer une configuration 2-of-3 avec Trezor, Ledger et ColdCard, un administrateur doit préparer l’environnement et documenter chaque étape. Voici une checklist détaillée. D’abord, acquérir les trois appareils matériels auprès des fournisseurs officiels (trezor.io pour Trezor, ledger.com pour Ledger, coldcard.com pour ColdCard) et vérifier les emballages pour des signes de manipulation. Ensuite, initialiser chaque appareil séparément dans un environnement contrôlé. Pour Trezor, créer une nouvelle phrase de récupération et la stocker de manière sécurisée (par exemple, sur papier dans un coffre-fort). Pour Ledger, faire de même. Pour ColdCard, initialiser aussi sur l’appareil lui-même.

Deuxièmement, vérifier le firmware de chaque appareil. Télécharger Trezor Suite depuis trezor.io, vérifier le SHA256 du fichier téléchargé, installer l’application et connecter le Trezor. Vérifier que Trezor Suite affiche que le firmware est à jour et signé. Faire de même pour Ledger Live et pour ColdCard (en utilisant les outils de ligne de commande appropriés). Documenter les versions de firmware vérifiées pour chaque appareil.

Troisièmement, exporter les clés publiques de chaque appareil. Connecter le Trezor à Trezor Suite et afficher les clés publiques dérivées pour le schéma de portefeuille multisignature choisi (par exemple, BIP45 pour Trezor). Enregistrer ces clés publiques. Répéter pour Ledger et ColdCard, en utilisant des applications telles que Specter ou Ledger Live selon le cas.

Quatrièmement, importer les trois clés publiques dans une application multisignature compatible. Utiliser Specter Desktop ou Caravan, charger les trois clés publiques, définir le seuil à 2-of-3 et générer l’adresse du portefeuille multisignature. Afficher l’adresse sur chaque appareil matériel pour vérification visuelle. Vérifier que tous les trois affichent la même adresse.

Cinquièmement, documenter la configuration. Enregistrer les trois clés publiques, les versions de firmware vérifiées, l’adresse du portefeuille multisignature, et les chemins de dérivation utilisés. Conserver cette documentation hors ligne, dans un endroit sécurisé. Inclure aussi un processus écrit pour la récupération d’urgence : comment fonctionner si un appareil est perdu, comment régénérer un appareil à partir de sa phrase de récupération, et comment vérifier que le nouvel appareil fait bien partie du portefeuille multisignature.

Sixièmement, faire un test avec un petit montant. Envoyer une petite quantité de bitcoin (ou d’autres actifs) à l’adresse du portefeuille multisignature. Vérifier que chaque appareil reçoit une demande de signature, en affiche les détails, et permet l’approbation. Enregistrer les signatures générées et vérifier qu’une fois deux appareils ont signé, la transaction peut être diffusée avec succès. Ce test valide toute la chaîne avant d’engager des montants significatifs. Vous pouvez commencer aujourd’hui en téléchargeant Trezor Suite depuis la source officielle.