Signatures numériques et autorisation des transactions

Ce qu’autorise une signature

Une signature numérique est une valeur cryptographique créée sur un message spécifié à l’aide d’une clé privée et d’un algorithme de signature. D’autres participants peuvent vérifier la signature à partir du message et de la clé publique correspondante. Pour une transaction de blockchain, le message représente généralement une modification prévue conformément aux règles du réseau : transférer de la valeur, appeler un programme ou satisfaire à des conditions associées à une sortie existante. Les octets exacts inclus dans ce message déterminent ce qui est autorisé ou non. Une signature ne signifie pas « J’accepte tout » ; elle est vérifiée par rapport à un énoncé précisément défini, même si le logiciel présente cet énoncé au signataire sous la forme d’un bref résumé lisible par une personne.

La signature et la diffusion sont deux événements distincts. Un appareil ou une application peut construire une transaction, demander une signature, puis seulement transmettre les octets signés à un nœud du réseau. Une signature peut donc exister avant que la transaction soit visible dans un explorateur de blocs. Une fois soumise, le réseau vérifie encore sa validité et les autres règles, et son inclusion n’est pas automatique. Les apprenants doivent distinguer la préparation, la signature, la soumission, la validation et l’inclusion. Les mécanismes de consensus du module 2 régissent la manière dont les transactions acceptées sont intégrées à un historique partagé ; ils ne constituent pas en eux-mêmes l’acte cryptographique de signature.

Un message doit être sans ambiguïté

Sérialisation et champs signables

La sérialisation convertit des informations structurées en une représentation exacte en octets. Une application peut afficher un destinataire, un montant, des frais et le nom d’un réseau, mais la vérification de la signature porte sur des octets définis conformément aux règles d’encodage d’un protocole. Modifier un champ signé après la création d’une signature entraîne généralement l’échec de la vérification. Certains protocoles autorisent délibérément un sous-ensemble défini de champs au moyen de modes de signature qui modifient les éléments couverts. Par conséquent, un analyste ne doit pas supposer que chaque signature engage tous les éléments de contexte affichés. La question technique pertinente est la suivante : quels champs ce mode de signature particulier a-t-il réellement liés ?

Une transaction de type Bitcoin consomme des sorties de transaction antérieures non dépensées et propose de nouvelles sorties. Le hachage de signature applicable engage des informations de transaction conformément aux règles et aux indicateurs de type de hachage. Une transaction de type Ethereum comporte généralement des champs tels qu’une destination, une valeur, des données, un nonce et des paramètres de frais, et utilise un encodage de transaction approprié pour la signature. Une transaction Solana signe un message sérialisé contenant des instructions, des informations de compte et un hachage de bloc récent ou une solution de remplacement autorisée. Malgré leurs structures différentes, les trois reposent sur le même principe : les vérificateurs doivent contrôler le même message prévu que celui qui a été signé.

Autoriser une transaction n’est pas la même chose que l’exécuter

Une signature valide est nécessaire pour de nombreux types de transactions, mais elle ne suffit pas à garantir une modification d’état réussie. Une transaction proposée peut comporter un compteur de séquence invalide, un solde insuffisant, un hachage de bloc récent expiré, une condition de dépense non satisfaite ou une erreur d’exécution de contrat. Dans les systèmes fondés sur des comptes, la signature peut être valide même lorsque l’exécution échoue et que des frais de traitement sont facturés. Dans d’autres cas, la transaction peut ne jamais parvenir à la chaîne. Pour expliquer un transfert contesté, il faut donc au moins répondre à deux questions : le message a-t-il été dûment autorisé conformément aux règles du réseau, et quel résultat l’exécution ou le règlement sur le réseau a-t-il réellement produit ?

L’autorisation peut également impliquer plusieurs clés. Une règle de dépense peut exiger plusieurs signatures, imposer des conditions temporelles ou recourir à une logique de programme. Un compte de contrat intelligent peut valider des instructions conformément à son code plutôt que de s’appuyer sur un compte externe détenu par une seule personne. Il ne faut pas décrire ces systèmes comme dépourvus de signature simplement parce qu’aucune signature ordinaire de compte ne figure dans le même champ. La leçon générale est que les règles d’autorisation relèvent du protocole ou du programme et doivent être interprétées dans leur contexte. La gouvernance et les contrôles de conservation sont des sujets distincts qui seront abordés plus loin dans le cours.

Rejeu et liaison au contexte

Un rejeu se produit lorsque des données signées valides sont réutilisées dans un contexte où elles n’étaient pas destinées à autoriser une autre action. La conception des transactions peut réduire le risque de rejeu au moyen d’identifiants propres au réseau, de compteurs de séquence, de données d’expiration ou d’autres éléments de contexte signés. L’Ethereum Improvement Proposal (EIP) 155, Simple Replay Attack Protection, a introduit des données identifiant la chaîne dans la construction de signature pour les transactions Ethereum héritées concernées. Les formats de transaction modernes comportent également des règles de contexte de chaîne, mais leur mise en œuvre varie. Le principe général est simple : les vérificateurs doivent savoir non seulement si une signature est mathématiquement valide, mais aussi si elle est valide pour ce réseau, ce type de transaction et cet usage.

Demandes de signature et compréhension humaine

Une interface utilisateur peut afficher « Approuver » ou « Signer », alors que les actions sous-jacentes ont des conséquences techniques différentes. Dans les contrats de jetons Ethereum, par exemple, une approbation d’allocation peut permettre à un compte ou à un contrat distinct de déplacer ultérieurement des jetons dans les limites des règles du contrat, tandis qu’un simple transfert d’actif natif est une transaction directe. Une signature de message hors chaîne peut autoriser une action ultérieure si un service ou un contrat reconnaît ce message signé. Ni le mot « signature » ni l’absence de déplacement immédiat de jetons ne prouvent que la demande est sans danger. Dans un cours de base, les évaluateurs doivent apprendre à se demander quelle capacité précise est accordée et si sa portée est limitée dans le temps, limitée en montant ou révocable selon la conception concernée.

Algorithmes et éléments de preuve de signature

NIST FIPS 186-5, Digital Signature Standard, spécifie des techniques comprenant ECDSA et EdDSA. Bitcoin Improvement Proposal 340 spécifie un schéma de signature Schnorr sur secp256k1 pour l’environnement Taproot de Bitcoin. Les mises en œuvre du réseau déterminent précisément la manière dont ces algorithmes sont appliqués et encodés. Il ne suffit pas d’identifier une signature comme étant « ECDSA » sans vérifier le format réel du message, la courbe, les règles de vérification et la version du protocole. Les systèmes peuvent également utiliser des fonctions de hachage cryptographique avant ou pendant la signature ; hacher le message et le signer sont des opérations liées, mais distinctes.

Comment un évaluateur doit documenter une action signée

1. Consigner le réseau, le type de transaction et l’identifiant exact de la transaction ou les données sérialisées, si elles sont disponibles.
2. Identifier ce que représentent les champs affichés relatifs au signataire, à la destination, au contrat, au montant, aux frais et aux données.
3. Confirmer la portée de la signature ainsi que le contexte de séquence ou de protection contre le rejeu applicable.
4. Distinguer la validité de la signature de l’état de la transaction, du résultat de l’exécution et de l’autorisation organisationnelle.

Cette méthode évite deux erreurs opposées. La première consiste à considérer qu’une transaction réussie prouve qu’une personne nommément désignée l’a approuvée en connaissance de cause. La seconde consiste à considérer qu’une signature valide prouve que la transaction a nécessairement réussi. Les éléments techniques peuvent étayer une enquête, mais l’attribution et l’intention juridique reposent sur des faits qui ne sont généralement pas inscrits dans une blockchain. Lorsqu’un analyste ne dispose que de captures d’écran, la meilleure approche consiste à récupérer indépendamment les enregistrements correspondants sur la chaîne avant de consigner une conclusion. Le module suivant abordera les aspects pratiques du stockage des clés et de l’organisation de la conservation, et non les mécanismes mathématiques traités ici.

À retenir pour l’examen : Identifiez les cinq étapes d’une transaction signée type, expliquez pourquoi les octets exacts à signer et la protection contre le rejeu sont importants, et distinguez une signature valide d’une exécution réussie, d’une inclusion confirmée et d’une approbation organisationnelle. Sachez que, selon les règles du protocole, les signatures peuvent couvrir des portées différentes.