Clés publiques, clés privées, signatures

La question de départ

Vous envoyez 5 000 FCFA par monnaie mobile. L'opérateur vous demande votre code PIN. Il vérifie que le code est le bon : pour cela, il doit connaître le secret (ou en détenir de quoi le contrôler). Si quelqu'un de l'opérateur est malhonnête, votre secret est en danger.

Sur un réseau ouvert, il n'y a pas d'opérateur de confiance. Il faut un moyen de prouver « c'est bien moi » sans jamais donner le secret à celui qui vérifie. C'est le but d'une paire de clés.

Le concept

Une paire de clés se compose de deux nombres liés :

• la clé privée : un nombre secret, tiré au hasard. Elle fait 32 octets (256 bits) pour les courbes elliptiques courantes comme P-256 ou Ed25519 ;
• la clé publique : calculée à partir de la clé privée par une opération à sens unique. On peut la publier.

« À sens unique » signifie : aller de la clé privée à la clé publique est rapide ; revenir en arrière est, d'après l'état actuel des connaissances, infaisable pour des clés bien choisies. Ce n'est pas une preuve mathématique absolue : c'est une hypothèse de difficulté (le logarithme discret sur courbe elliptique) que tous les experts testent depuis des décennies. Un ordinateur quantique assez grand casserait cette hypothèse ; on n'en dispose pas aujourd'hui, mais c'est une limite connue.

Combien de clés privées possibles ?

Une clé privée de 256 bits peut prendre environ 2^256 ≈ 1,16 × 10^77 valeurs. Deux personnes qui tirent au hasard ne tomberont pas sur la même, à condition que le hasard soit de qualité cryptographique. Un générateur faible (par exemple la fonction Math.random d'un navigateur) rend la clé devinable. Votre navigateur utilise pour cela le générateur du système, pas Math.random.

Deux familles d'algorithmes dans cet atelier

Le catalogue du cours cite ed25519 pour le laboratoire local ; l'outil du navigateur, lui, utilise ECDSA sur la courbe P-256 parce que c'est ce que l'API de chiffrement du navigateur (WebCrypto) offre partout. Les idées sont les mêmes : une clé privée signe, une clé publique vérifie. Bitcoin utilise une autre courbe (secp256k1) ; Ethereum aussi. Les concepts transfèrent, les octets non.

À vous

Ouvrez l'outil ci-dessous et générez une paire de clés. Notez que la clé privée n'est jamais affichée : elle reste dans la mémoire de votre navigateur. Exportez la clé publique : c'est du texte en base64 que vous pourriez envoyer à n'importe qui.

Ce que cela ne garantit pas

Avoir une paire de clés ne dit rien de qui vous êtes. N'importe qui peut en générer mille en une seconde. Une clé publique n'est qu'un nombre ; l'associer à une personne ou une entreprise demande autre chose (voir la leçon suivante).

En bref

• La clé privée est un grand nombre aléatoire secret ; la clé publique s'en déduit à sens unique.
• Ce sens unique est une hypothèse de difficulté, pas une preuve absolue.
• Une paire de clés ne prouve aucune identité par elle-même.

La question de départ

Aminata reçoit un message : « Payer 5 000 FCFA à Didier ». Une signature est jointe. Que sait-elle exactement, si la vérification réussit ?

Le concept

Il existe deux opérations :

• signer(clé_privée, message) → une signature (64 octets en forme brute pour ECDSA P-256 ou Ed25519) ;
• vérifier(clé_publique, message, signature) → vrai ou faux, rien d'autre.

En pratique, la signature porte sur l'empreinte du message (voir l'atelier 104) : ECDSA signe une empreinte du message (l'outil de la page utilise SHA-256 ; ECDSA lui-même ne l'impose pas), Ed25519 intègre son propre hachage. C'est pourquoi on peut signer un fichier de 1 Go aussi vite qu'un SMS.

Exemple détaillé avec l'outil

Signez dans l'outil le texte Payer 5000 FCFA a Didier, puis faites cinq vérifications :

La dernière ligne est la plus instructive. Voyons ce que l'on peut conclure.

Ce que la signature prouve (sous hypothèses)

Si la vérification réussit, et si la clé privée n'a pas fuité et si le schéma est sûr :

1. Authenticité de la clé : le message a été signé par quelqu'un qui détient la clé privée correspondant à cette clé publique.
2. Intégrité : le message n'a pas été modifié d'un seul bit depuis la signature.

Ce que la signature ne prouve pas

• Pas l'identité d'une personne. Elle prouve l'usage d'une clé. Qui détient cette clé ? Pour un site web, une autorité de certification signe un document liant un nom de domaine à une clé publique ; sur une blockchain, on suit simplement la clé comme un pseudonyme.
• Pas la vérité du contenu. On peut signer un mensonge très proprement.
• Pas la fraîcheur. Une signature ne porte pas la date. Le rejeu (cinquième ligne) reste valide : c'est pourquoi les transactions des chaînes à comptes (Ethereum, et notre réseau d'entraînement) signent aussi un nonce (compteur propre au compte) et un identifiant de chaîne, comme dans l'exercice bac-practice|chain=…|nonce=… ci-dessous. Bitcoin, lui, n'a ni nonce de compte ni identifiant de chaîne dans ses transactions : la signature porte sur la sortie précise qui est dépensée, et une sortie déjà dépensée ne peut plus l'être, ce qui joue un rôle comparable contre le rejeu.
• Pas l'intention. Une clé a signé ; un humain a-t-il voulu signer ? Un logiciel malveillant qui utilise la clé produit des signatures parfaitement valides.
• Pas la confidentialité. Le message reste lisible par tous.

Une différence avec le HMAC

Dans l'atelier 104 vous avez vu qu'un HMAC authentifie un message avec un secret partagé. Le destinataire, qui connaît ce secret, pourrait donc fabriquer lui-même un HMAC valide. Avec une signature, le vérificateur n'a que la clé publique : il peut vérifier, il ne peut pas signer. C'est ce qui permet à un tiers de trancher un désaccord.

En bref

• vérifier répond vrai ou faux pour trois objets : message, signature, clé publique.
• Vrai = « cette clé a signé ces octets », sous hypothèse que la clé est restée secrète.
• Ni identité, ni vérité, ni fraîcheur, ni intention.

La question de départ

On entend souvent : « signer, c'est chiffrer avec sa clé privée ». C'est faux pour les schémas de cet atelier, et cette phrase cause de vraies erreurs. Voyons pourquoi.

Deux buts différents

Dans une signature, le sens est donc inverse de celui du chiffrement : le secret sert à produire, le public sert à contrôler.

Pourquoi la formule « chiffrer avec la clé privée » est trompeuse

• ECDSA et Ed25519 ne sont pas des algorithmes de chiffrement. Ils ne savent faire que signer et vérifier : on ne peut pas « déchiffrer » une signature pour en tirer le message.
• Même pour RSA, où l'image existe historiquement, les implémentations sûres ajoutent un remplissage spécifique à la signature, différent de celui du chiffrement. Utiliser une primitive pour l'autre mène à des failles.
• Bonne pratique : une clé pour un seul usage. Ne réutilisez pas une clé de signature pour chiffrer, ni l'inverse.

Exemple détaillé : ce qu'un observateur voit

Aminata envoie à Didier, sur un réseau public :

1. Message signé, non chiffré : l'observateur lit « Payer 5000 FCFA à Didier » ; il ne peut pas le modifier sans casser la signature ; il peut le copier et le rejouer (leçon précédente).
2. Message chiffré, non signé : l'observateur ne lit rien ; mais n'importe qui connaît la clé publique de Didier et a donc pu écrire ce message. Didier ne sait pas qui l'a envoyé.
3. Les deux : on obtient confidentialité et authenticité, avec deux opérations et, de préférence, deux paires de clés.

Dans une blockchain publique, les transactions sont signées mais non chiffrées : tout le monde doit pouvoir les vérifier. Le chiffrement n'y est pas le mécanisme de base.

À vous

Dans l'outil HMAC, calculez le HMAC d'un message avec la clé secret1, puis vérifiez que quiconque connaît secret1 peut produire la même valeur. Comparez avec l'outil de signature : ici, la vérification n'exige pas de connaître le secret de signature.

Ce que cela ne garantit pas

Signer ne cache rien. Chiffrer ne prouve pas qui a écrit. Ni l'un ni l'autre ne protège de la perte de la clé privée.

En bref

• Chiffrer = confidentialité ; signer = authenticité et intégrité.
• ECDSA et Ed25519 ne chiffrent pas.
• Un message signé reste lisible.

La question de départ

Un employé colle sa clé privée dans un groupe de discussion, puis supprime le message trente secondes plus tard. A-t-il réglé le problème ?

Non. Pour comprendre pourquoi, il faut voir ce que le réseau peut, et ne peut pas, distinguer.

Pourquoi c'est irréversible

La vérification ne teste qu'une chose : « cette signature correspond-elle à cette clé publique ? ». Elle n'a aucun moyen de savoir qui tient la clé privée. Après une fuite :

1. Le voleur produit des signatures valides, indiscernables des vôtres.
2. Sur une blockchain, il peut vider le compte d'un seul message. Les transactions confirmées ne s'annulent pas.
3. Il n'y a, en règle générale, pas d'autorité à qui demander de « révoquer » une clé : c'est le principe même du système. Votre seule défense est de déplacer les fonds vers une nouvelle clé avant le voleur, et c'est une course.
4. Les signatures déjà faites restent valides. Sans horodatage fiable, il devient difficile de dire si un vieux document a été signé avant ou après la fuite.

Supprimer le message n'efface pas les copies : un robot a pu l'avoir lu en une seconde. Une clé qui a été visible est à considérer comme compromise pour toujours.

Une autre façon de perdre la clé : un nonce raté

ECDSA utilise, à chaque signature, un nombre secret à usage unique k (un « nonce » au sens ECDSA, à ne pas confondre avec le nonce de compte). Si deux signatures utilisent le même k, la clé privée d se calcule à partir des deux. Voici le principe, sur un modèle jouet : un petit nombre premier n = 23. Dans le vrai ECDSA, n est d'environ 2^256 et r vient d'un calcul sur courbe ; ici r est simplement donné, car seule l'algèbre compte.

La signature est : s = k⁻¹ · (z + r·d) mod n, où z est l'empreinte du message, r est identique pour les deux signatures (même k) et d est la clé privée.

Exemple : d = 9 (secret), k = 5 (réutilisé), r = 7.

• Message 1 : z₁ = 10, donc s₁ = 5⁻¹ · (10 + 7·9) = 14 · 73 mod 23 = 10 (car 5⁻¹ = 14 mod 23, et 73 mod 23 = 4, 14·4 = 56 = 10 mod 23).
• Message 2 : z₂ = 3, donc s₂ = 14 · (3 + 63) = 14 · 66 mod 23 ; 66 mod 23 = 20 ; 14·20 = 280 mod 23 = 4. Donc s₂ = 4.

L'observateur ne voit que (r, s₁, z₁), (r, s₂, z₂). Il calcule :

• k = (z₁ − z₂) · (s₁ − s₂)⁻¹ = 7 · 6⁻¹ mod 23 = 7 · 4 = 28 = 5 ✔
• d = (s₁·k − z₁) · r⁻¹ = (50 − 10) · 7⁻¹ = 40 · 10 mod 23 = 400 mod 23 = 9 ✔

Deux signatures, une clé privée. Ce défaut a été exploité dans de vrais produits à cause de générateurs aléatoires défaillants ; Ed25519 le prévient en dérivant k de façon déterministe de la clé et du message (c'est une propriété de conception de ce schéma) ; l'ECDSA déterministe de la RFC 6979 fait de même. Dans notre outil de navigateur, le générateur d'aléa du système fait ce travail : sa qualité compte.

Ce que cela ne garantit pas

Une sauvegarde de la clé (une phrase de récupération, par exemple) protège contre la perte, mais augmente le risque de fuite : chaque copie est une cible. Il faut arbitrer, pas cocher une case.

En bref

• Le réseau ne distingue pas le propriétaire du voleur : il ne voit que des signatures valides.
• Une clé exposée est compromise pour toujours ; on déplace les fonds, on ne « révoque » pas.
• Un nonce ECDSA réutilisé révèle la clé privée.