Créer, vérifier et utiliser les clés dès le départ

Créer, vérifier et utiliser les clés dès le départ

Les algorithmes modernes sont rarement cassés ; les clés, elles, sont mal générées, copiées dans un dépôt Git, réutilisées pour trois usages ou conservées dix ans de trop. La plupart des catastrophes cryptographiques documentées tiennent moins à la mathématique qu’à la gestion de ces quelques dizaines d’octets. Ce chapitre installe les réflexes de base avant que les chapitres suivants ne présentent les primitives qui consomment les clés : comment en créer une correctement, comment vérifier celle qu’on reçoit, pourquoi chacune n’a qu’un seul métier, et que faire le jour où elle fuit.

Explication de la marmotte

Une clé de maison se fabrique, se confie à certaines personnes, sert tous les jours, se remplace quand on l’a perdue et se jette quand on déménage. Les clés numériques vivent exactement la même vie. Ce chapitre installe les bonnes habitudes à chacune de ces étapes, avant même de parler des serrures qui les utilisent.

→ Lire l’explication complète de la marmotte

Une clé est un objet vivant

Une clé n’est pas un paramètre de configuration que l’on règle une fois pour toutes. Elle traverse des états successifs, que le NIST (National Institute of Standards and Technology) décrit dans sa publication SP 800-57 consacrée à la gestion des clés, et chaque état appelle des contrôles différents.

La création produit la clé à partir d’une source d’aléa de qualité, dans un environnement maîtrisé, idéalement à l’endroit même où elle servira, pour éviter un transport. La distribution la met à disposition de ceux qui en ont besoin : une clé publique se diffuse librement mais doit arriver intacte, une clé secrète ne doit voyager que chiffrée par une autre clé, dite clé de chiffrement de clés ou KEK (Key Encryption Key). L’usage couvre la période active, bornée par une période de validité décidée à l’avance. L’archivage conserve, après la fin de l’usage actif, ce qui permet encore de déchiffrer d’anciennes données ou de vérifier d’anciennes signatures. La révocation annonce publiquement qu’une clé ne doit plus être acceptée, avant son terme normal, typiquement après une compromission. La destruction enfin efface toutes les copies de la clé, y compris dans les sauvegardes, quand plus rien ne dépend d’elle.

L’ordre compte. Détruire une clé de chiffrement avant d’avoir rechiffré les archives qu’elle protège revient à détruire les archives. Oublier de révoquer une clé de signature compromise laisse l’attaquant signer en toute légitimité apparente. Chaque clé de production mérite donc une fiche écrite, dont un modèle figure dans les ateliers ci-dessous.

Génération et validation

Une clé symétrique est une suite d’octets uniformément aléatoires, rien d’autre. Sa qualité dépend entièrement du générateur : il faut un générateur cryptographique, alimenté par le système d’exploitation, et jamais rand(), Math.random() ou un horodatage. Les causes et les remèdes sont détaillés dans Produire de l’aléa utilisable en cryptographie.

openssl rand -hex 32                              # 256 bits, affichés en hexadécimal
head -c 32 /dev/urandom > cle.bin                 # même chose, en binaire
python3 -c "import secrets; print(secrets.token_hex(32))"

L’histoire offre un rappel durable de ce qui se passe quand l’aléa manque. Entre 2006 et 2008, un correctif malheureux dans le paquet OpenSSL de Debian (CVE-2008-0166) a réduit la graine du générateur à l’identifiant de processus : il n’existait plus que 32 768 clés possibles par type et par taille, que des chercheurs ont simplement toutes générées. Toutes les clés SSH et certificats produits sur ces systèmes pendant deux ans ont dû être remplacés.

Une paire asymétrique se génère avec une bibliothèque reconnue, jamais avec une implémentation maison :

openssl genpkey -algorithm ed25519 -out sign.pem                         # paire de signature
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa.pem
chmod 600 sign.pem rsa.pem

La génération d’une clé RSA repose sur la recherche de deux grands nombres premiers, testés par des algorithmes probabilistes comme Miller-Rabin. Les défauts y sont discrets et dévastateurs. En 2012, deux équipes indépendantes ont collecté des millions de clés RSA publiques sur Internet et trouvé qu’une fraction non négligeable partageait un facteur premier avec une autre clé : un simple calcul de PGCD (plus grand commun diviseur) suffisait à les factoriser, le plus souvent sur des équipements embarqués démarrés sans entropie. En 2017, la vulnérabilité ROCA (CVE-2017-15361) a révélé que les puces Infineon produisaient des premiers d’une structure particulière, rendant les clés factorisables, ce qui a conduit l’Estonie à suspendre puis renouveler les certificats de centaines de milliers de cartes d’identité.

Pour Diffie-Hellman sur corps finis, les paramètres publics (module premier et générateur) se choisissent dans des groupes normalisés, comme ceux du RFC 7919, plutôt que générés à la main : un groupe mal construit peut cacher une faiblesse invisible à l’utilisateur.

Valider une clé publique reçue signifie au minimum vérifier sa structure : le format se lit sans erreur, l’algorithme et la courbe sont ceux attendus, la taille est conforme à la politique, l’exposant public RSA est raisonnable, et un point de courbe elliptique appartient bien à la courbe et au bon sous-groupe, comme expliqué dans Courbes elliptiques : compacité, validation et pièges. Il faut ensuite vérifier qu’il s’agit de la bonne clé, et non d’une clé valide fournie par un intermédiaire. C’est le rôle de l’empreinte (fingerprint), un condensé de la clé publique comparé par un canal indépendant :

ssh-keygen -lf ~/.ssh/id_ed25519.pub
# 256 SHA256:Q2v8...kU4 utilisateur@poste (ED25519)
openssl pkey -pubin -in sign.pub -outform DER | sha256sum

Quand le premier contact SSH affiche « The authenticity of host can’t be established », c’est cette empreinte qu’il faut comparer à celle annoncée par l’administrateur, et non le moment de taper « yes » par réflexe.

Les formats de clé, PEM, DER, JWK et autres, ne changent rien à la clé elle-même mais beaucoup à la façon dont les outils l’interprètent ; ils sont traités dans Formats, bibliothèques et API.

Usage séparé

Une clé, un usage. Les grands usages sont distincts : le chiffrement protège la confidentialité, la signature prouve publiquement l’origine, le MAC (Message Authentication Code, code d’authentification de message) prouve l’origine entre parties qui partagent un secret, la dérivation fabrique d’autres clés, le transport chiffre des clés pour les acheminer et le stockage protège des données au repos.

Utiliser la même clé pour deux de ces rôles crée des interactions que l’analyse de sécurité de chaque primitive n’a pas prévues. L’exemple classique est RSA : une même paire utilisée pour déchiffrer avec le remplissage PKCS #1 v1.5 et pour signer permet à un attaquant disposant d’un oracle de déchiffrement, à la manière de l’attaque de Bleichenbacher, de faire produire des signatures. L’attaque DROWN (2016) a de même exploité des clés RSA partagées entre un serveur moderne et un vieux service SSLv2 : la faiblesse de l’un compromettait les sessions de l’autre.

Le bon réflexe, quand un système a besoin de plusieurs clés, est de partir d’un secret maître et d’en dériver des sous-clés indépendantes avec une KDF (Key Derivation Function, fonction de dérivation de clé) comme HKDF (RFC 5869), en donnant à chaque usage une étiquette distincte :

from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

def deriver(maitre: bytes, usage: bytes) -> bytes:
    return HKDF(algorithm=hashes.SHA256(), length=32,
                salt=None, info=usage).derive(maitre)

k_chiffrement = deriver(maitre, b"tortuetech/v1/chiffrement")
k_mac         = deriver(maitre, b"tortuetech/v1/mac")

Les deux clés obtenues sont sans relation exploitable entre elles, et la compromission de l’une ne livre pas l’autre. Les certificats X.509 expriment la même discipline par l’extension keyUsage, qui restreint une clé à la signature, au chiffrement de clés ou à l’accord de clés.

Reste le cas embarrassant des clés courtes pour rétrocompatibilité : un vieil automate qui n’accepte que RSA 1024, un équipement qui ne parle que 3DES. La seule réponse acceptable est le confinement : clé dédiée à ce seul équipement, réseau isolé, date de fin inscrite dans le registre, et jamais de réutilisation de cette clé, ni de ses données, ailleurs.

Protéger au repos et en mémoire

Au repos, une clé privée dans un fichier doit avoir des droits restreints (mode 600, propriétaire unique) et, si possible, être elle-même chiffrée par une phrase de passe ou, mieux, résider dans un module matériel qui ne la laisse jamais sortir : HSM (Hardware Security Module), TPM (Trusted Platform Module), carte à puce ou service de gestion de clés dans le nuage. Une sauvegarde de clé sans contrôle d’accès équivalent à l’original n’est pas une sauvegarde, c’est une deuxième porte.

En mémoire, la clé est exposée aux fichiers d’échange, aux vidages après plantage (core dumps), aux journaux de débogage et aux messages d’erreur trop bavards. Les bibliothèques sérieuses verrouillent les pages sensibles en mémoire et les effacent après usage ; les applications doivent au minimum désactiver les vidages en production et ne jamais journaliser les objets qui contiennent des secrets. Les mécanismes opérationnels, coffres à secrets et KMS (Key Management Service), sont détaillés dans Exploiter les clés : rotation, KMS et secrets.

Premiers incidents

Cinq incidents reviennent sans cesse. La clé faible est trop courte, mal générée ou issue d’un composant défectueux : on la détecte par inventaire et outils de contrôle, on la remplace. La clé dupliquée est la même clé installée sur plusieurs machines, souvent par une image système clonée, de sorte que la compromission d’une seule machine compromet toutes les autres et qu’on ne sait plus d’où vient une signature. La clé journalisée apparaît dans un journal applicatif, une trace de débogage ou un ticket de support, que des dizaines de personnes et de systèmes peuvent lire. La clé compromise est celle dont on sait, ou dont on ne peut exclure, qu’un tiers l’a copiée. Une clé poussée dans un dépôt public appartient à cette catégorie dans les minutes qui suivent : des robots parcourent en permanence les plateformes de code à la recherche de secrets.

La réponse commune est un plan de rotation préparé avant l’incident : comment générer la remplaçante, la déployer partout, révoquer l’ancienne, vérifier qu’elle n’est plus acceptée nulle part, et traiter les données qu’elle protégeait. Un plan qui n’a jamais été exécuté est une hypothèse, pas un plan.

Exemples et ateliers

Générer une clé symétrique et une paire de signature, puis consigner leurs empreintes :

openssl rand -out donnees.key 32 && chmod 600 donnees.key
openssl genpkey -algorithm ed25519 -out release.pem && chmod 600 release.pem
openssl pkey -in release.pem -pubout -out release.pub
openssl pkey -pubin -in release.pub -outform DER | sha256sum   # à publier

Écrire une fiche de cycle de vie pour une clé de production :

Rubrique	Exemple
Identifiant	factures-chiffrement-2026-01
Usage unique	chiffrement des PDF de factures au repos
Algorithme et taille	AES-256-GCM, 256 bits
Emplacement	KMS, région Europe, non exportable
Accès	service de facturation en lecture, deux administrateurs en gestion
Mise en service et fin d’usage	2026-01-15, 2027-01-15
Rotation	annuelle, nouvelles données sur la nouvelle version
Archivage	conservée en déchiffrement seul tant que des factures en dépendent
Destruction	après rechiffrement complet et fin de la durée légale de conservation
Procédure de compromission	lien vers le plan de rotation d’urgence

Simuler la révocation d’une clé exposée, par exemple une clé de déploiement SSH retrouvée dans un dépôt : générer la remplaçante, l’ajouter aux authorized_keys des cibles, basculer les pipelines, retirer l’ancienne de toutes les cibles, puis tenter une connexion avec l’ancienne pour vérifier le refus. Enfin, examiner les journaux d’authentification sur la période d’exposition, car révoquer ne dit rien de ce qui a déjà été fait avec la clé.

Pièges classiques

Réutiliser une clé pour plusieurs primitives, par économie ou par commodité, crée des attaques croisées. Sauvegarder une clé sans contrôle d’accès en multiplie les points de fuite. Ne pas vérifier une clé publique reçue laisse un intermédiaire substituer la sienne. Repousser la rotation jusqu’à l’incident garantit que la première rotation se fera dans l’urgence, avec des systèmes qui n’ont jamais été conçus pour changer de clé.

À ne pas confondre

Une clé est aléatoire et pleine d’entropie ; un mot de passe est choisi par un humain et doit d’abord être transformé par une fonction lente, voir Transformer mots de passe et secrets applicatifs en clés. La rotation introduit une nouvelle version d’une clé pour les nouvelles données ; la re-génération complète remplace toute la hiérarchie et impose de rechiffrer l’existant. La révocation retire la confiance accordée à une clé ; la destruction fait disparaître la clé elle-même. Une clé publique est une valeur nue ; un certificat est un document signé qui l’associe à une identité, voir Relier une clé à une identité.

🐝 Ce qui arrive si on s’en passe

Une clé sans cycle de vie écrit produit deux accidents opposés. Le premier survient à la compromission : personne ne sait quelles données elle a chiffrées ni quels documents elle a signés, si bien qu’il devient impossible de mesurer ce que l’attaquant peut lire ou falsifier, et encore moins de rechiffrer ou de resigner ce qui doit l’être. Le second survient au ménage : une clé détruite alors qu’elle aurait seulement dû être révoquée emporte avec elle toutes les archives qu’elle protégeait, devenues illisibles pour leur propriétaire légitime aussi. La ruche perd alors son miel sans qu’aucun frelon n’ait eu à se donner la peine.

🦫 Explication de la marmotte 🍫

Une clé est un grand nombre secret, produit par une source de hasard de bonne qualité : si le hasard est faible, deux clés peuvent se ressembler ou être devinées. Certaines clés vont par paire, une publique que l’on distribue et une privée que l’on garde ; leur fabrication repose parfois sur des nombres premiers et des paramètres publics qu’il faut contrôler. Quand on reçoit une clé publique, on vérifie sa structure et son empreinte, une courte valeur calculée à partir de la clé, qui permet de s’assurer qu’elle n’a pas été remplacée. Ensuite, chaque clé n’a qu’un seul usage : chiffrer, signer, vérifier l’intégrité d’un message ou fabriquer d’autres clés. Utiliser la même pour plusieurs rôles crée des interactions imprévues entre les procédés. Une clé suit un cycle complet : création, distribution, usage, archivage, révocation, qui annonce qu’elle ne doit plus être acceptée, puis destruction, qui la fait disparaître. Pendant tout ce temps, elle doit être protégée sur le disque et dans la mémoire de l’ordinateur. Les incidents typiques sont une clé trop faible, une clé copiée à plusieurs endroits, une clé écrite par erreur dans un journal d’activité, ou une clé volée. Dans chaque cas, la réponse est la même : remplacer la clé selon un plan préparé à l’avance, puis vérifier que l’ancienne n’est plus acceptée nulle part.

À lire aussi

• Évaluer la force d’une protectionExpliquer comment raisonner en bits de sécurité, en durée de confidentialité et en coût réel d’attaque, sans réduire la décision à la longueur d’une clé.
• Lire une garantie sans la surinterpréterDonner les outils pour comprendre une preuve de sécurité, une hypothèse de dureté et un modèle d’attaque, tout en rappelant leurs limites pratiques.
• RSA : trappe, padding et usages restreintsTraiter RSA comme une primitive encore rencontrée mais exigeante, où la sécurité dépend autant du padding, de la génération et de l’implémentation que du module.
• RNG matériel ou PRNG dans un HSMSécuriser la génération de nombres aléatoires dans un HSM, entre source matérielle, générateur pseudo-aléatoire, attaques et exploitation.

Pages voisines

La citent

• Chiffrer et authentifier en une seule construction
• Prouver qu’un message vient du bon secret

Créer, vérifier et utiliser les clés dès le départ

Elle cite

• ⇄Lien dans les deux sens :L'entropie au démarrage
• Produire de l’aléa utilisable en cryptographie
• Courbes elliptiques : compacité, validation et pièges
• Exploiter les clés : rotation, KMS et secrets
• Relier une clé à une identité: certificats et PKI
• Transformer mots de passe et secrets applicatifs en clés
• Formats, bibliothèques et API : rendre la crypto utilisable
• Les secrets dans les dépôts Git
• Protocole SSH, clés d'hôte, authentification et durcissement

⇄ : les deux pages se citent l’une l’autre.