Attribués une fois après une réponse correcte.
Savoir ce qu’un hash ou une signature démontre
À connaître avant : Un registre partagé
Prendre ses repères · Étape 2 / 6
Le site dit « connexion ». Le wallet dit « autorisation ».
Vous voulez simplement lire un article. Un site fictif ouvre la demande ci-dessous dans votre wallet. Que faites-vous ?
- Réseau
- Ethereum
- Token
- EXAMPLE · ERC-20 fictif
- Contrat autorisé
- Contrat non vérifié
- Plafond autorisé
- 1 000 EXAMPLE
Une approbation ERC-20 donne à un contrat une permission dans la limite d’un plafond. Elle diffère de la signature d’un simple message de connexion. Cet écran ne se connecte jamais à un wallet.
Une empreinte, un secret et une signature
Une fonction de hachage transforme une donnée de taille quelconque en une empreinte de taille fixe. Elle est déterministe : la même entrée produit la même sortie. Une petite modification donne une empreinte très différente. Retrouver une entrée à partir d’un hash, ou trouver deux entrées avec la même empreinte, doit être irréalisable en pratique avec une fonction appropriée.
Ce que le wallet signe réellement
Hacher n’est pas chiffrer. Le chiffrement vise à rendre un message illisible sans une clé ; le hash sert notamment à vérifier l’intégrité. Une empreinte ne prouve pas à elle seule qu’un contenu est vrai, seulement qu’il correspond à une donnée déterminée.
Une signature valide ne garantit pas la sécurité
Une clé privée permet de produire une signature. La clé publique permet de vérifier cette signature sans révéler le secret. La signature autorise une opération sur un message précis ; elle ne cache pas le montant. Les adresses sont des identifiants dérivés selon les règles du réseau. Un wallet gère des clés ou des moyens de signature, pas des pièces numériques stockées physiquement dans l’appareil.
Le message compte autant que la clé
Une clé privée sert à produire des signatures ; la clé publique correspondante permet de les vérifier. La vérification lie une signature à un message précis. Ce message doit aussi indiquer son contexte, par exemple réseau et contrat, pour éviter qu’une autorisation soit acceptée ailleurs. La protection contre le rejouement repose sur les règles de l’application, souvent un nonce ; un affichage lisible ne suffit pas. Un wallet peut demander un transfert, un appel de contrat ou un message structuré. Lisez cette demande, pas seulement la description du site.
Récupération, secret et données prévisibles
Une phrase de récupération peut dériver de nombreuses clés. Ce n’est pas un mot de passe qu’un support client peut réinitialiser. Un hash n’est pas un chiffrement : aucune clé de déchiffrement ne restitue normalement son entrée. Un attaquant peut essayer des entrées prévisibles et comparer leurs empreintes. Hasher un numéro de téléphone ne le rend donc pas automatiquement anonyme. Une signature vérifiée ne dit pas non plus si la clé a été volée ou si son détenteur a compris la demande.
Suivre un message de la signature à la vérification
- 01Message + contexte
- 02Signature privée
- 03Vérification publique
- 04Autorisation, pas vérité
Ces repères représentent des notions liées, pas nécessairement des étapes successives.
Lire l’explication
Une clé privée sert à produire des signatures ; la clé publique correspondante permet de les vérifier. La vérification lie une signature à un message précis. Ce message doit aussi indiquer son contexte, par exemple réseau et contrat, pour éviter qu’une autorisation soit acceptée ailleurs. La protection contre le rejouement repose sur les règles de l’application, souvent un nonce ; un affichage lisible ne suffit pas. Un wallet peut demander un transfert, un appel de contrat ou un message structuré. Lisez cette demande, pas seulement la description du site.
Replacez le mécanisme dans son contexte
Dans ce transfert direct fictif, le message signé précise réseau, destinataire et montant : « envoyer 25 unités à Bob ». Après signature, quelqu’un remplace Bob par Chloé en conservant montant et signature. Comparez les deux messages avant de décider si la vérification peut réussir.
Appliquer dans l’atelier →Ce que ce mécanisme ne garantit pas
Une phrase de récupération peut dériver de nombreuses clés. Ce n’est pas un mot de passe qu’un support client peut réinitialiser. Un hash n’est pas un chiffrement : aucune clé de déchiffrement ne restitue normalement son entrée. Un attaquant peut essayer des entrées prévisibles et comparer leurs empreintes. Hasher un numéro de téléphone ne le rend donc pas automatiquement anonyme. Une signature vérifiée ne dit pas non plus si la clé a été volée ou si son détenteur a compris la demande.
La distinction qui change l’analyse
Deux empreintes identiques établissent une concordance avec une référence. Si cette référence vient de l’attaquant, la concordance ne prouve pas l’identité de l’éditeur. Il faut donc demander à la fois « est-ce identique ? » et « qui a authentifié la référence ? ».
À vous de l’expliquer
Reprenez le cas ci-dessus. Nommez ce qui est établi, ce qui reste à vérifier et la preuve qui permettrait de conclure. Une réponse solide traite les deux côtés du schéma.
Que se passe-t-il si le destinataire change ?
Dans ce transfert direct fictif, le message signé précise réseau, destinataire et montant : « envoyer 25 unités à Bob ». Après signature, quelqu’un remplace Bob par Chloé en conservant montant et signature. Comparez les deux messages avant de décider si la vérification peut réussir.
Non. Le destinataire faisait partie du message signé : sa modification change ce qui est vérifié. La signature initiale n’autorise pas ce nouveau message. Cela protège l’intégrité de la demande, mais pas une personne qui a approuvé dès le départ un mauvais destinataire.
Choisir le bon contrôle
Un fournisseur vous envoie un document. Pour savoir si ses octets ont changé, comparez son hash avec une référence obtenue par un canal fiable. Pour protéger sa confidentialité, utilisez un chiffrement et une gestion des clés adaptés. Pour vérifier une signature, contrôlez-la sur le document exact avec la clé publique attendue. Ce sont trois tâches différentes.
Une quatrième question demeure : à qui appartient la clé ? Une signature valide produite avec une clé inconnue n’identifie pas votre fournisseur. Le lien entre cette clé et le fournisseur doit provenir d’un processus fiable distinct. Un certificat, une clé déjà vérifiée ou un canal authentifié indépendamment peut contribuer à ce contrôle.
Pour une transaction de wallet, faites la même distinction. Contrôlez message et contexte, puis signature et règles de transaction. Le réseau ne juge ni la pertinence du paiement ni la compréhension de la personne derrière la clé.
Vérifier sa compréhension
La signature se vérifie pour ce message et cette clé. Identifier l’expéditeur exige un lien fiable entre la clé et l’identité annoncée.
Les termes de cette leçon
- Hash
- Une empreinte de taille fixe calculée à partir de données. Elle vérifie une correspondance, pas la véracité.
Préparer une note de correction
Décrivez le passage et la correction proposée. Vous pourrez copier cette note pour la partager ; rien n’est envoyé. N’incluez aucune donnée personnelle ou confidentielle.