Aller au contenu
TortueTech
RubriquesGlossaire

Clé privée

Gestion des clés

Moitié secrète d'une paire de clés asymétriques : selon l'algorithme, elle signe, déchiffre ou établit un secret partagé, et toute la sécurité du dispositif repose sur le fait que personne d'autre ne la détient.

Deux séquences l'une sous l'autre. Pour signer, l'émetteur signe d'abord le message avec sa clé privée. Il envoie ensuite le message et la signature au destinataire, qui vérifie la signature avec la clé publique de l'émetteur : si la signature est valide, le message est authentique. Pour chiffrer, l'expéditeur chiffre le message avec la clé publique du destinataire et lui envoie le message chiffré. Le destinataire le déchiffre ensuite avec sa propre clé privée.

Rôle : Elle signe. Selon l'algorithme, elle déchiffre aussi ce qui a été chiffré avec la clé publique associée (RSA) ou calcule le secret partagé d'un échange de clés (Diffie-Hellman, X25519) ; une clé Ed25519, elle, ne déchiffre rien du tout, elle ne sait que signer. Retrouver la clé privée à partir de la clé publique demande un calcul hors de portée : factorisation de grands entiers pour RSA, logarithme discret sur courbe elliptique pour ECDSA ou Ed25519.

Stockage : Fichier protégé par une phrase de passe, carte à puce, HSM, enclave matérielle qui refuse de l'exporter : tout l'art consiste à lui offrir un endroit d'où elle ne sortira pas. La clé commitée « juste pour tester » fait exception, elle sort toujours, et elle survit au projet, l'historique Git ayant une mémoire que le commit de suppression n'efface pas.

Compromission : Si elle fuit, tout ce qu'elle a signé devient douteux et tout ce qu'elle protège devient lisible. On la révoque (CRL ou OCSP pour un certificat), puis on en génère une nouvelle : aucune remédiation ne la rend secrète à nouveau.

Formats : On la croise surtout en PEM (le bloc « BEGIN PRIVATE KEY »), en PKCS#8 ou au format OpenSSH. Le format ne change rien au secret : un fichier .pem lisible par tout le serveur reste une clé publiée.

Voir aussi :Clé publiqueCryptographie asymétriqueSignature numériqueHSMPKI

Ce qui arrive si on s'en passe

Une clé privée qui n'est plus détenue par une seule partie ne prouve plus rien. Toute personne qui en obtient une copie peut produire des signatures que les vérificateurs acceptent comme authentiques et se faire passer pour le détenteur légitime (serveur, utilisateur, éditeur de logiciel). Elle peut aussi déchiffrer les messages chiffrés avec la clé publique correspondante. Si le protocole n'assure pas la confidentialité persistante, les échanges enregistrés auparavant deviennent lisibles eux aussi. La fuite ne laisse aucune trace dans les signatures : celle d'un attaquant est mathématiquement identique à une signature légitime, ce qui supprime la traçabilité et la non-répudiation. La seule reprise possible consiste à révoquer la paire, à en générer une nouvelle et à redistribuer la clé publique à tous ceux qui s'y fiaient. Tant que les vérificateurs ignorent la révocation, ils continuent d'accepter la clé compromise.

Explication de la marmotte

Imagine une boîte aux lettres avec une fente : n'importe qui peut glisser un message dedans, mais seule la personne qui a la clé peut l'ouvrir et le lire. La clé privée, c'est cette clé-là. Elle va avec une autre clé, distribuée à tout le monde, qui sert seulement à fermer. La clé privée sert aussi à poser une sorte de tampon personnel sur un message : les autres peuvent vérifier que c'est bien toi qui l'as tamponné, sans pouvoir imiter le tampon. Toute la sécurité tient à une règle : ne jamais la montrer, ne jamais la prêter. Si quelqu'un la récupère, il peut lire ton courrier et signer à ta place.

Où ce terme est utilisé

← Tout le glossaire