Après l'incident de Coldcard, une question a été de nouveau soulevée : si les portefeuilles matériels peuvent aussi faire des erreurs, et même laisser des dangers cachés dès le moment où les clés sont générées, pourquoi devrions-nous encore garder nos propres actifs ?
Notre évaluation est la suivante : l'auto-garde reste importante. Elle permet aux utilisateurs d'avoir l'autorisation finale pour les opérations en chaîne et conserve la possibilité de migration indépendante en cas de défaillance des plateformes ou des services. Coldcard n'a pas changé cette valeur, mais cela nous a fait réexaminer « comment posséder le contrôle en toute sécurité ».
La sécurité ne peut pas être jugée par une seule étiquette
Selon l'annonce officielle de Coldcard et l'analyse technique de Block, une erreur d'intégration du firmware a fait que certains appareils n'ont pas utilisé les nombres aléatoires matériels comme prévu, mais ont plutôt utilisé un chemin de nombres aléatoires logiciels prévisible. Des phrases mnémoniques apparemment normales peuvent ne pas avoir atteint le niveau de sécurité attendu dès l'étape de génération des clés.
Dans de nombreux cas publics, les utilisateurs n'ont pas cliqué sur des liens de phishing ni divulgué leurs phrases mnémoniques ; ils ont simplement créé des portefeuilles en suivant le processus par défaut du produit. Le problème est survenu à la source de la génération des clés, et quelle que soit la prudence avec laquelle ils ont stocké les clés par la suite, l'écart n'a pas pu être comblé.
Cet incident a brisé un raccourci cognitif courant : le matériel, le hors ligne ou l'open source peuvent tous améliorer la sécurité, mais aucune étiquette unique ne peut à elle seule constituer une conclusion de sécurité. Les utilisateurs ordinaires ne peuvent pas auditer le firmware ligne par ligne. Rendre le chemin par défaut fiable est la responsabilité que les produits de sécurité devraient assumer.
Après l'incident, OKX a déclaré que la plateforme avait vu un afflux important de fonds. CZ a ensuite cité un ensemble de données historiques, suggérant que « statistiquement, garder les actifs sur les échanges est plus sûr que l'auto-garde ». Il n'est pas surprenant que cette déclaration ait été approuvée.
Les institutions de garde matures peuvent investir plus de ressources pour établir des systèmes de sécurité et de récupération professionnels. Pour ceux qui manquent d'expérience en gestion de clés, confier cette partie du travail à des institutions peut en effet réduire la difficulté et le risque de gestion individuelle des clés. Reconnaître cela n'affaiblit pas la valeur de l'auto-garde ; cela ramène plutôt la discussion à la situation réelle de l'utilisateur.
Mais les chiffres historiques de pertes sont difficiles à fournir directement pour répondre à la question d'aujourd'hui. La recherche de River citée par CZ montre également que les données de perte permanente de BTC sont difficiles à attribuer avec précision, la grande majorité se produisant avant 2020 ; les pertes des échanges sont également impossibles à comptabiliser entièrement, et certaines compensations n'ont pas été déduites. Ces chiffres cumulés n'ont pas été ajustés en fonction de la taille des actifs et de la durée de détention. Ils montrent que les deux méthodes ont subi des pertes énormes, mais ils sont insuffisants pour mesurer le risque réel d'aujourd'hui.
Plus important encore, de telles comparaisons ne comptent généralement que « si les actifs ont été perdus », mais répondent rarement à « si on peut les retirer quand on en a besoin » et « si on peut partir après un problème de plateforme ». La garde peut réduire la pression de la gestion personnelle des clés, mais elle rend également les utilisateurs dépendants de la continuité d'exploitation de l'institution, de l'exécution des obligations de remboursement et de la fourniture d'accès au compte.
L'auto-garde préserve une autre voie
L'auto-garde est essentiellement un arrangement de contrôle. Pour les comptes d'auto-garde courants, les utilisateurs détiennent les clés privées ou les conditions de clé nécessaires pour compléter les signatures, et les développeurs de portefeuilles et autres fournisseurs de services ne peuvent pas unilatéralement compléter une autorisation valide.
Tant que les utilisateurs détiennent toujours des clés ou des sauvegardes valides, même si le portefeuille d'origine cesse de fonctionner, ils peuvent généralement récupérer le compte via des outils compatibles ; lorsque les utilisateurs ont besoin de transférer des actifs ou d'utiliser des applications en chaîne, ils n'ont pas à attendre qu'une plateforme ouvre d'abord les retraits.
Cette voie indépendante est la valeur la plus importante de l'auto-garde.
Il a certainement des limites. Les règles du réseau et des contrats peuvent toujours affecter l'utilisation des actifs. Ce que la garde autonome préserve, c'est que l'autorisation finale pour les opérations sur la chaîne ne doit pas reposer entièrement sur une seule institution, et non un contrôle absolu sur toutes les conditions externes.
Cette valeur n'est pas évidente lorsque la plateforme fonctionne normalement. C'est un peu comme une sauvegarde : elle ne rend pas les opérations quotidiennes plus rapides, mais lorsque le chemin d'origine échoue, elle détermine si les utilisateurs ont encore des options.
Par conséquent, il n'y a pas de réponse unique entre la garde et la garde autonome. Pour ceux qui ne peuvent temporairement pas gérer leurs clés en toute sécurité, choisir un service de garde soigneusement évalué est raisonnable ; pour ceux qui veulent réduire leur dépendance à une seule institution, établir un chemin qui peut être indépendamment récupéré et migré est tout aussi important. La clé n'est pas de savoir de quel côté vous vous tenez, mais d'être clair sur les risques que vous avez confiés et les capacités que vous avez conservées.
Le contrôle ne devrait pas être un fardeau pour les utilisateurs seuls
Le fait que les utilisateurs contrôlent leurs clés privées ne signifie pas que les fournisseurs de produits peuvent assumer moins de responsabilités en matière de sécurité. Les utilisateurs ordinaires ne peuvent pas vérifier tout le processus, de la génération des clés à la construction du firmware d'un appareil. Les produits doivent vérifier les chemins critiques, exposer les anomalies en temps opportun et répondre de manière transparente après que des problèmes surviennent. La sécurité devrait provenir d'une conception par défaut fiable, et non reposer sur la découverte par les utilisateurs de risques techniques cachés.
Les utilisateurs doivent également confirmer que les sauvegardes peuvent effectivement être restaurées, comprendre ce qu'ils autorisent avant de signer, et savoir à l'avance comment migrer si les principaux outils échouent. Mais ces capacités peuvent être construites progressivement. La garde autonome ne devrait pas être un examen de qualification qui exige que tout le monde transfère immédiatement tous ses actifs, ni exiger que tout le monde devienne un expert en cryptographie.
Pour imToken, soutenir la garde autonome commence par rendre ce choix plus fiable. Les utilisateurs doivent pouvoir comprendre ce qu'ils autorisent, savoir comment récupérer, et pouvoir migrer vers des outils compatibles si nécessaire. Ce n'est qu'alors que le contrôle peut être plus qu'un simple slogan.
L'incident de Coldcard n'a pas rendu la garde autonome moins importante ; au contraire, il a rendu les responsabilités de sécurité plus concrètes. La prochaine phase du problème à résoudre est de savoir comment rendre la sécurité, la récupération et l'expérience utilisateur plus fiables tout en conservant le contrôle de l'utilisateur.
Les utilisateurs peuvent choisir la garde, et peuvent quitter la garde si nécessaire ; ils peuvent avoir le contrôle, et ne doivent pas supporter toute la complexité seuls. C'est la signification de rediscuter de la garde autonome après Coldcard.
