Aller au contenu

Clés publiques et privées

La cryptographie à clé publique permet à un portefeuille de signer des transactions blockchain avec une clé privée secrète, tandis que le réseau vérifie les signatures avec la clé publique correspondante. Découvrez les différences entre clés, adresses, phrases de récupération et les risques de signature.

Mis à jour

À des fins éducatives uniquement ; ne constitue pas un conseil en sécurité ou en investissement. Les transactions blockchain peuvent être irréversibles. Ne divulguez jamais une clé privée ou une phrase de récupération et vérifiez chaque transaction avant de signer.

Réponse directe

Une paire de clés publique et privée est une relation cryptographique asymétrique qui autorise et vérifie des actions sur une blockchain. La clé privée est une donnée secrète servant à créer des signatures numériques. La clé publique correspondante peut être partagée et permet de vérifier ces signatures sans connaître la clé privée.

Une adresse blockchain est généralement dérivée d’une clé publique, d’un script ou d’une règle de compte ; elle n’est pas toujours identique à la clé publique. La dérivation et le format dépendent du réseau. Une adresse désigne une destination ou un compte, tandis que le contrôle dépend normalement du respect des règles de dépense ou d’autorisation du réseau.

Détenir une clé privée ne place pas les jetons dans le portefeuille. Le registre consigne les actifs ou sorties dépensables, et la clé permet d’autoriser des changements d’état valides. Quiconque obtient la clé peut éventuellement signer comme son détenteur ; perdre la seule clé utilisable peut rendre des actifs auto-conservés définitivement inaccessibles.

Fonctionnement

Le processus de signature de base est le suivant :

  1. Le portefeuille génère une clé privée avec un aléa cryptographiquement sûr, ou la dérive d’une graine selon un schéma défini.
  2. Une opération mathématique à sens unique dérive la clé publique correspondante. Avec un algorithme et une implémentation sûrs, retrouver la clé privée depuis la clé publique doit être infaisable en pratique.
  3. Les règles du réseau dérivent ou associent une adresse, un script ou un compte à la clé publique. Les réseaux peuvent employer des courbes, hachages, encodages et modèles de compte différents.
  4. Le portefeuille signe une transaction ou un message précis avec la clé privée. La signature porte sur les données encodées exactes ; toute modification l’invalide.
  5. Les participants utilisent la clé publique et les règles du protocole pour vérifier la signature avant d’accepter l’action autorisée. La vérification ne révèle pas la clé privée.

Une phrase de récupération n’est pas une clé privée. Dans de nombreux portefeuilles déterministes hiérarchiques, elle représente l’entropie permettant de recréer une graine dont dérivent plusieurs clés et adresses. La connaître peut donc donner le contrôle de tous les comptes dérivés. Un mot de passe de portefeuille chiffre ou déverrouille généralement un fichier local ; il ne remplace pas les clés et ne peut les restaurer seul.

Le contrôle par paire de clés ne décrit pas non plus tous les comptes. Par exemple, un compte Ethereum détenu extérieurement est contrôlé par une paire de clés, tandis qu’un compte de contrat dépend de son code déployé et peut imposer multisignature, délai ou récupération.

Exemple

Alice donne une adresse de réception à Bob. Le portefeuille de Bob vérifie le réseau et le format, construit le paiement et lui demande de confirmer destinataire, montant et frais. Il signe localement cette transaction exacte avec la clé privée de Bob puis diffuse la transaction signée ; la clé privée n’est jamais envoyée à Alice ni au réseau.

Les nœuds vérifient la signature et les règles de dépense. Une signature valide indique que la clé requise a autorisé la transaction, mais ne prouve ni l’identité légale de Bob, ni la fiabilité d’Alice, ni la pertinence économique. Si Bob signe pour le mauvais réseau, destinataire ou appel de contrat, une cryptographie correcte peut tout de même autoriser le mauvais résultat.

Risques

  • Divulgation : Hameçonnage, logiciel malveillant, sauvegarde cloud, capture d’écran, extension ou faux support peuvent révéler clé privée ou phrase de récupération. Traitez chacune comme donnant le contrôle total.
  • Perte : Appareil détruit, phrase secrète oubliée, sauvegarde incomplète ou paramètres de dérivation incompatibles peuvent empêcher la récupération. Testez la procédure documentée sans exposer le secret.
  • Mauvais aléa ou logiciel : Génération prévisible, code de signature défectueux, chaîne logistique compromise ou portefeuille malveillant peuvent annuler une cryptographie solide. Utilisez des logiciels maintenus et des appareils de signature réputés.
  • Signature ambiguë : Une signature peut autoriser transfert, approbation de jeton, ordre, connexion ou autre message. Lisez l’intention compréhensible et vérifiez séparément détails encodés, réseau, adresse et montant.
  • Concentration opérationnelle : Une clé contrôlant tous les actifs crée un point de défaillance unique. Séparez soldes et rôles, réduisez l’exposition en ligne et envisagez signature matérielle, multisignature ou comptes à règles pour les montants élevés.

Si une clé privée ou phrase de récupération a pu être exposée, considérez-la compromise. Sur un appareil sain, créez un nouveau portefeuille généré indépendamment, vérifiez sa sauvegarde et transférez actifs restants et autorisations nécessaires lorsque cela est sûr. Ne saisissez pas l’ancien secret sur un site prétendant contrôler ou réparer le portefeuille.

Idées reçues

Idée reçue 1 : La clé privée n’est que le mot de passe du portefeuille

Un mot de passe peut protéger une application locale ou un magasin chiffré. La clé privée autorise les signatures ; réinitialiser le mot de passe ne recrée pas une clé ou phrase de récupération perdue.

Idée reçue 2 : L’adresse et la clé publique sont toujours identiques

La construction d’adresse dépend du protocole. Beaucoup encodent un hachage, script ou règle de compte plutôt que la clé publique brute, et certaines adresses de contrat n’ont aucune clé privée.

Idée reçue 3 : Partager la clé publique permet de calculer la clé privée

Les systèmes sûrs sont conçus pour partager clés publiques et signatures. Les menaces pratiques sont un mauvais aléa, une implémentation défectueuse, un secret exposé ou une future rupture cryptographique, pas la vérification normale.

Idée reçue 4 : Une signature valide prouve l’identité du signataire

Elle prouve que la clé requise a autorisé les données selon le protocole. Relier cette clé à une personne ou organisation réelle exige une preuve d’identité distincte.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...