Qu'est-ce qu'une transaction de signature aveugle ?

Définition et mécanisme de base

1. Une transaction de signature aveugle fait référence à un processus cryptographique par lequel un utilisateur signe numériquement des données sans connaître l'intégralité de son contenu ou de son contexte.

2. Cela se produit lorsque le logiciel ou le matériel du portefeuille ne présente que des informations partielles, telles qu'une adresse ou un montant, tout en omettant des champs critiques tels que la logique du contrat de destination, les appels de fonction ou les paramètres intégrés.

3. La signature est mathématiquement valide mais détachée de la compréhension sémantique, ce qui rend impossible pour le signataire de vérifier l'intention ou les conséquences avant l'approbation.

4. La signature aveugle repose sur des primitives cryptographiques de bas niveau qui traitent les entrées comme des octets bruts, ignorant la signification structurelle codée dans Ethereum ABI, les opcodes EVM ou les normes de transfert de jetons.

Risques liés à la mise en œuvre de portefeuilles

1. De nombreux portefeuilles mobiles et basés sur navigateur affichent des aperçus de transactions tronqués, en particulier pour les interactions complexes de contrats intelligents impliquant des appels de délégués ou des mises à niveau de proxy.

2. Les utilisateurs approuvent régulièrement les transactions intitulées « Interaction contractuelle inconnue » ou « Données personnalisées », sans savoir que la charge utile peut déclencher des transferts de jetons, une renonciation à la propriété ou des séquences d'autodestruction.

3. Les portefeuilles matériels ne parviennent parfois pas à décoder les données d'appel imbriquées, affichant uniquement les 8 à 16 premiers octets d'un sélecteur de fonction tout en masquant les arguments suivants qui déterminent le comportement.

4. Les dApps malveillantes exploitent cela en intégrant des couches d'interface utilisateur trompeuses : affichant une action à l'écran tout en soumettant des données d'appel entièrement différentes à la blockchain.

Vulnérabilités spécifiques à Ethereum et EVM

1. Les approbations ERC-20 avec des allocations infinies semblent souvent inoffensives dans les interfaces de portefeuille, mais permettent une vidange silencieuse si le contrat approuvé contient des failles de réentrance ou des fonctions de propriétaire malveillantes.

2. Les charges utiles de transaction contenant les opcodes CALLCODE ou DELEGATECALL peuvent exécuter du code arbitraire dans le contexte de stockage de l'appelant, un fait rarement apparu dans les écrans de confirmation standard.

3. Les contrats de procuration obscurcissent l'emplacement logique ; la signature d'une transaction ciblant une adresse proxy ne garantit pas que l'implémentation sous-jacente corresponde aux attentes des utilisateurs.

4. Les mises à jour d'Oracle Chainlink, les propositions de gouvernance et les charges utiles d'exécution multisig nécessitent souvent une signature aveugle en raison de contraintes de taille ou du manque de prise en charge du décodage ABI.

Cas d'exploitation réels

1. Début 2023, une extension de portefeuille n'a pas réussi à analyser la longueur des données d'appel dynamiques lors d'une migration de pool Uniswap V3, ce qui a conduit les utilisateurs à signer des approbations autorisant la liquidation flash de prêts par rapport à leurs positions.

2. Un agrégateur DeFi populaire a présenté des boutons « Swap » simplifiés tout en regroupant les signatures permit2 et les instructions de dépôt dans le coffre-fort : les utilisateurs ont confirmé une seule action mais ont autorisé plusieurs opérations irréversibles.

3. Plusieurs campagnes de phishing ont distribué de faux outils de récupération de portefeuille invitant les utilisateurs à signer des « messages d'authentification », qui étaient en réalité des autorisations de retrait pré-signées pour des adresses contrôlées par les attaquants.

4. Les interfaces utilisateur des ponts inter-chaînes ont soumis des messages relayés avec de faux identifiants de chaîne source, comptant sur les utilisateurs pour signer aveuglément des charges utiles qu'ils ne pouvaient pas valider hors chaîne.

Foire aux questions

Q : Les portefeuilles matériels peuvent-ils empêcher la signature aveugle ? R : Pas intrinsèquement. Si le micrologiciel ne dispose pas d'une analyse ABI complète, d'une vérification du contrat ou d'une inspection du bytecode sur l'appareil, même les appareils isolés restent vulnérables aux données d'appel mal interprétées.

Q : La signature aveugle équivaut-elle à la signature d'un hachage de message ? R : Non. Le hachage des messages implique une entrée lisible par l'homme et vérifiée avant la signature. La signature aveugle s'applique aux charges utiles binaires opaques où ni le hachage ni le contenu ne sont affichés de manière significative.

Q : Toutes les chaînes compatibles EVM souffrent-elles de la même manière des risques de signature aveugle ? R : La gravité du risque varie. Les chaînes avec un codage de transaction standardisé (par exemple, Ethereum avec EIP-2718) offrent des opportunités de décodage plus cohérentes que celles utilisant une sérialisation personnalisée comme certains cumuls spécifiques à une application.

Q : Pourquoi les portefeuilles ne refusent-ils pas simplement les données d'appel non signées ? R : La compatibilité exige une prise en charge forcée des contrats existants, des proxys non vérifiés et des interfaces non standard. Refuser de telles charges utiles perturberait l’accès à de larges segments de l’infrastructure DeFi déployée.