Quatre stratégies de sécurité à partir d'un vol de portefeuille

Les méthodes de conservation qui résistent à l'épreuve du temps sont souvent simples, intuitives et faciles à comprendre, avec le moins d'étapes et le minimum de besoin de confiance.

Rédigé par : Liu Jiaolian

Le portefeuille de connexion sociale de Keplr a rencontré des problèmes, avec des milliers de comptes dont les actifs ont été transférés. L'entreprise a attribué la cause à une vulnérabilité dans l'infrastructure de Web3Auth. La plupart des utilisateurs volés n'ont pas fait d'erreurs, ils ont simplement choisi la facilité en se connectant avec Google ou Apple pour créer ce portefeuille.

La cause exacte de l'incident n'a pas encore été divulguée en détail. Les entreprises se renvoient également la balle. Jiaolian a fait quelques recherches sur cette piste et a mis en parallèle les stratégies de sécurité utilisées par plusieurs portefeuilles typiques pour voir quels problèmes pourraient exister.

Prenons d'abord la stratégie traditionnelle d'auto-hébergement des cryptomonnaies comme référence, c'est-à-dire que l'utilisateur note sa phrase de récupération, l'écrit sur papier et la conserve soigneusement.

Cette stratégie est très simple, la clé est entre vos mains, personne ne le sait. Sa limite de sécurité, c'est vous-même : ne pas perdre le papier, ne pas le photographier, ne pas le dire à personne. Le désavantage est que la mémoire humaine n'est pas fiable, un incendie, un déménagement, une lessive, tout cela peut faire disparaître ce papier. Mais son avantage est que le risque est visible sur ce papier, vous pouvez le voir d'un coup d'œil, et vous savez très bien qu'il doit être pris très au sérieux, avec une vigilance maximale.

Avec cette référence, examinons maintenant les stratégies de gestion des clés privées de plusieurs applications de portefeuille populaires dans l'industrie. Notez que nous excluons les solutions de bourses centralisées qui détiennent directement tous les droits de contrôle, et discutons des solutions qui gèrent les phrases de récupération sans détenir le contrôle total des actifs.

Commençons par la méthode du portefeuille Uniswap : sa stratégie est assez simple, elle consiste à chiffrer la phrase de récupération et à la sauvegarder sur votre propre iCloud ou Google Drive.

Un ensemble de données chiffrées est stocké sur les serveurs d'Apple, et le mot de passe pour le déchiffrer est dans votre tête. Lors de la récupération, vous devez vous connecter à votre compte cloud et entrer le mot de passe que vous avez spécifiquement utilisé pour chiffrer la phrase de récupération, qui n'est pas le même que votre identifiant Apple. Le fournisseur de services cloud ne reçoit que des données chiffrées, théoriquement impossibles à déchiffrer. Le risque est donc transféré du côté du compte : un identifiant Apple volé, un code de vérification intercepté, un site de phishing qui vole votre mot de passe, chacun de ces scénarios pourrait permettre à quelqu'un d'autre d'accéder à la sauvegarde. Mais au moins, le risque reste dans un endroit que vous connaissez bien, le compte cloud et le mot de passe, ce sont des choses que vous utilisez tous les jours.

Le risque dans le cloud n'est qu'un seul : le service de stockage d'Apple ou de Google est piraté. Bien sûr, c'est aussi pourquoi ils ont choisi Apple et Google plutôt que d'autres fournisseurs de services cloud, car ils font davantage confiance à la sécurité de ces deux géants.

Ensuite, nous avons le portefeuille web3 classique MetaMask (communément appelé portefeuille renard). Sa méthode est beaucoup plus complexe : la phrase de récupération chiffrée est stockée sur les serveurs de MetaMask, et la clé de déchiffrement est divisée en plusieurs morceaux, répartis sur différents nœuds de serveur ; pour la récupération, vous avez besoin de deux éléments : d'une part, les identifiants de connexion de Google, Apple ou Telegram, et d'autre part, le mot de passe que vous avez défini. Les deux éléments doivent être réunis pour reconstituer la clé.

MetaMask précise que même si tous les serveurs sont compromis, l'attaquant ne peut obtenir que des morceaux, et il doit encore déchiffrer votre mot de passe. Cela est vrai, mais cela dépend de certaines conditions. En général, lors d'une récupération en ligne, les identifiants de connexion sont la première porte, la limitation de vitesse du serveur est la deuxième, et le mot de passe est seulement la troisième ; un mot de passe faible ne sera pas immédiatement compromis. Mais une fois que les nœuds de fragments sont compromis et que l'attaquant obtient des morceaux, il peut effectuer une attaque par force brute hors ligne sur sa propre machine, ce qui annule la limitation de vitesse, et à ce moment-là, la force du mot de passe devient la seule ligne de défense.

Enfin, examinons le système utilisé par Keplr, qui a rencontré des problèmes. La clé est divisée en trois morceaux, un morceau est sur l'appareil de l'utilisateur, un autre sur le serveur cloud, et un troisième comme sauvegarde de récupération, qui est reconstitué par le serveur après connexion. En théorie, deux des trois morceaux suffisent pour reconstituer la clé privée, mais tant que deux morceaux sont contrôlés par le même fournisseur de services, le seuil de sécurité des trois morceaux se réduit à un point de défaillance unique. Jiaolian a l'intuition que l'incident pourrait très bien provenir de ce point, mais la situation réelle devra attendre que l'entreprise divulgue plus de détails techniques spécifiques.

En comparant ces quatre méthodes, une règle contre-intuitive émerge.

De la première à la quatrième méthode, il semble que les verrous deviennent de plus en plus nombreux, les composants de plus en plus nombreux, le système de plus en plus complexe, prétendant ou promettant que des stratégies de chiffrement complexes peuvent améliorer la sécurité. Pourtant, les risques que l'utilisateur peut voir deviennent de moins en moins nombreux. La clé écrite sur papier, vous savez où elle se trouve ; le texte chiffré stocké dans iCloud, vous savez qu'il est chez Apple ; avec le système MetaMask, le texte chiffré est sur le serveur, les morceaux sont sur les nœuds, le mot de passe est dans votre tête, vous devez d'abord comprendre les quatre rôles pour pouvoir en parler ; avec Keplr, lorsque quelque chose se passe, l'utilisateur ne sait même pas à qui demander des comptes.

D'un autre côté, alors que la complexité du système augmente et que la compréhension de l'utilisateur diminue, la surface d'attaque exposée aux hackers augmente. Comment les hackers pourraient-ils ne pas se réjouir ? Le papier et le stylo n'ont qu'un seul risque, être volés ou brûlés ; la sauvegarde iCloud ajoute un compte cloud ; le système MetaMask ajoute un fournisseur de services de connexion, des nœuds fragmentés, la force du mot de passe ; le système Keplr ajoute toute l'infrastructure. Chaque couche supplémentaire disperse la dépendance à la confiance sur plus de niveaux et d'étapes, au lieu de réduire la confiance.

Cette diffusion de la dépendance à la confiance peut être fatale. Un calcul simple : une personne gère la clé, si elle fait une erreur, le système échoue ; si deux personnes sont impliquées, si l'une d'elles fait une erreur, le système échoue également. Évidemment, la probabilité qu'une des deux personnes fasse une erreur est supérieure à celle qu'une seule personne fasse une erreur. Les étapes en série ne feront qu'abaisser la fiabilité, pas l'augmenter.

Alors pourquoi concevoir cela de cette manière ? Parce que dans la première méthode, la probabilité qu'une personne fasse une erreur est tout simplement trop élevée. Écrire un mot par erreur, perdre le papier, se faire jeter le papier par un membre de la famille, ces choses se produisent tous les jours. La connexion sociale réduit considérablement le taux d'erreur des utilisateurs, au prix d'introduire un segment de risque lié au fournisseur de services. Sur le papier, cela peut sembler avantageux, mais le problème est que ces deux probabilités, l'utilisateur ne peut pas les voir et ne peut pas les vérifier.

Le plus ironique dans tout cela est qu'un système qui nécessite dix pages de documentation pour expliquer pourquoi il est sûr, a déjà fait perdre la capacité de jugement à l'utilisateur ordinaire. Il ne peut que choisir de croire, et croire n'est pas la sécurité, c'est parier.

Jiaolian ne peut s'empêcher de se rappeler cette phrase de Satoshi Nakamoto dans le livre blanc de Bitcoin : « Lorsque la possibilité de renversement existe, la demande de confiance se diffuse. » Bien que Satoshi parlait du paiement en ligne, cela peut être comparé à la récupération de la clé privée, qui est en soi un processus réversible, entraînant inévitablement une diffusion de la demande de confiance.

Et cette diffusion signifie en elle-même une augmentation de la surface d'attaque des hackers. Chaque étape nécessitant de la confiance est un point d'entrée potentiel pour les hackers.

Les méthodes de conservation qui résistent à l'épreuve du temps sont souvent simples, intuitives et faciles à comprendre, avec le moins d'étapes et le minimum de besoin de confiance. La simplicité n'est pas la rudesse, c'est laisser la complexité dans la mise en œuvre et laisser la capacité de jugement à l'utilisateur.

Si un portefeuille ne peut pas expliquer clairement où se trouve la clé, alors son auto-hébergement et sa sécurité ne sont qu'un slogan publicitaire. Pour vraiment posséder quelque chose, il faut pouvoir le désigner et dire : c'est à moi, j'en suis sûr à 100 % qu'il est là.

Ce contenu est fourni à titre informatif uniquement et ne constitue pas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, promotions en ligne ou informations mentionnées ici ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, trader ou effectuer toute autre opération sur des actifs crypto. Les actifs crypto sont très volatils et peuvent entraîner des pertes. La disponibilité des services, produits et événements liés à WEEX peut varier selon les régions. Veuillez vous assurer que votre participation respecte les lois et réglementations locales applicables.