Qu'est-ce qu'une demande de signature de portefeuille ? Qu’est-ce que j’approuve réellement ?

Comprendre les demandes de signature de portefeuille

1. Une demande de signature de portefeuille est une invite cryptographique lancée par une dApp, un contrat intelligent ou un protocole pour vérifier l'intention de l'utilisateur avant d'exécuter une action en chaîne.

2. Il ne s'agit pas de transférer des fonds directement, mais de demander à l'utilisateur de signer cryptographiquement un message ou un hachage de transaction à l'aide de sa clé privée.

3. La signature prouve la propriété de l'adresse du portefeuille et confirme l'accord sur les conditions codées dans la charge utile, telles que la délégation d'allocations, la frappe NFT ou l'interaction contractuelle.

4. Contrairement aux connexions traditionnelles, aucune information d'identification n'est partagée ; seule une preuve cryptographique vérifiable est générée et diffusée sur le réseau blockchain.

5. Chaque demande de signature affiche des métadonnées, notamment le domaine de la dApp connectée, l'ID de chaîne et la fonction exacte invoquée, bien que les utilisateurs négligent souvent ces champs lors des flux d'approbation rapides.

Que se passe-t-il derrière la signature

1. Lorsqu'une dApp déclenche une demande de signature, elle construit une structure de données typée EIP-712 ou un simple message personal_sign en fonction du contexte et de la prise en charge de la chaîne.

2. Le client du portefeuille (par exemple, MetaMask, Phantom, Trust Wallet) rend cette structure sous une forme lisible par l'homme, en extrayant les paramètres critiques tels que l'adresse du dépensier, le montant du jeton, la date limite et le nombre occasionnel.

3. Le portefeuille applique ensuite la signature ECDSA à l'aide de la clé privée de l'utilisateur sur le hachage keccak256 de l'entrée structurée, produisant une chaîne de signature de 65 octets.

4. Cette signature est soumise hors chaîne au serveur dApp ou intégrée dans une charge utile de transaction destinée à une vérification en chaîne via la récupération de l'adresse du signataire .

5. Aucune clé privée ne quitte jamais l’appareil ; l'opération cryptographique se produit localement au sein de l'enclave sécurisée ou du bac à sable d'extension.

Risques de signature aveugle

1. Les utilisateurs qui approuvent les demandes de signature sans inspecter les détails de la charge utile s'exposent à des approbations de jetons non autorisées, à des interactions contractuelles basées sur le phishing ou à des signatures de permis malveillantes.

2. L' exploit BYBIT, d'une valeur de 1,4 milliard de dollars, impliquait des coffres-forts multi-signatures compromis dans lesquels les attaquants manipulaient la logique de signature pour drainer stETH et ETH via de faux appels de permis.

3. Les anciennes signatures Ethereum ne disposent pas d'une séparation de domaine intégrée, ce qui permet des attaques par rejeu sur plusieurs chaînes si des messages identiques sont signés sur différents réseaux sans liaison d'ID de chaîne appropriée.

4. Certains portefeuilles ne parviennent pas à restituer avec précision les structures EIP-712 complexes, affichant des valeurs tronquées ou trompeuses, en particulier lorsque les structures imbriquées contiennent des tableaux dynamiques ou des appels de contrat externes.

5. Les vulnérabilités de réutilisation des signatures ont conduit à une exécution anticipée des ordres à cours limité et à un accès non autorisé aux coffres lorsque les noms occasionnels ou les délais sont mal configurés dans la charge utile signée.

Sauvegardes au niveau du portefeuille

1. Les portefeuilles modernes mettent en œuvre des contrôles de liaison de domaine qui rejettent les signatures à moins que l'origine de la demande ne corresponde à un domaine dApp vérifié stocké dans leur liste autorisée.

2. Certains portefeuilles matériels nécessitent une confirmation explicite de chaque champ de paramètre avant de lancer l'opération de signature, empêchant ainsi l'autorisation accidentelle d'allocations cachées.

3. Les fournisseurs de portefeuilles intègrent de plus en plus de moteurs d'analyse de contrats en temps réel qui signalent les adresses malveillantes connues ou les sélecteurs de fonctions suspects avant le rendu de la signature.

4. Certaines solutions de conservation de niveau entreprise appliquent des règles de signature basées sur des politiques, par exemple en bloquant toutes les signatures de permis, sauf si elles proviennent de multisigs de gouvernance sur liste blanche.

5. Les extensions de navigateur affichent désormais des avertissements lors de la détection d'ID de chaîne incompatibles, de noms occasionnels en double ou de signatures de fonction non reconnues intégrées dans la requête.

Foire aux questions

Q : La signature d'un message permet-elle à une dApp de contrôler mon portefeuille ? La signature seule ne confère pas le contrôle. Le contrôle n'intervient que si la charge utile signée autorise un contrat intelligent à dépenser des actifs ou à exécuter des fonctions privilégiées, comme l'approbation d'un dépensier ERC-20 ou l'appel d'une méthode transferFrom.

Q : Pourquoi certaines demandes de signature affichent-elles « 0x… » au lieu d'un texte lisible ? Cela se produit lorsque le dApp envoie des données brutes codées en hexadécimal plutôt qu'une entrée EIP-712 structurée. Les portefeuilles ne peuvent pas analyser la signification de chaînes d'octets arbitraires, ils affichent donc uniquement la représentation de hachage.

Q : Puis-je révoquer une signature après l'avoir approuvée ? Non. Les signatures cryptographiques sont immuables et apatrides. La révocation nécessite des actions en chaîne, par exemple la réinitialisation d'une allocation ERC-20 à zéro ou l'annulation d'une commande en attente via sa fonction d'annulation désignée.

Q : Les demandes de signature sont-elles les mêmes dans toutes les blockchains ? Non. Ethereum utilise personal_sign et eth_signTypedData, Solana s'appuie sur la sérialisation TransactionMessage avec des versions récentes imposant la séparation des domaines, tandis que les chaînes Cosmos SDK utilisent des formats de documents de signature basés sur Amino ou Protobuf, chacun avec des hypothèses de sécurité et des comportements de rendu distincts.