Quelles sont les clés de chiffrement asymétriques?

Le chiffrement asymétrique, aussi connu sous le nom de cryptographie à clé publique, repose sur une paire de clés liées mathématiquement : une clé publique et une clé privée. La clé publique est partagée ouvertement – utilisée par quiconque pour chiffrer des messages ou vérifier des signatures numériques. La clé privée est gardée secrète par son propriétaire pour les opérations de décryptage ou de signature.

Les algorithmes asymétriques les plus utilisés aujourd'hui sont RSA (Rivest–Shamir–Adleman) et ECC (Elliptic Curve Cryptographie). RSA est basé sur la difficulté pratique d'affacturer les grands produits de base, tandis qu'ECC exploite la structure algébrique des courbes elliptiques sur des champs finis pour une sécurité équivalente avec des tailles clés beaucoup plus petites. Par exemple, une clé ECC 256 bits fournit une sécurité comparable à une clé RSA 3072 bits, rendant ECC plus efficace pour les environnements restreints tels que les appareils mobiles et les paramètres IoT.

Comprendre que le cryptage asymétrique n'est pas seulement une curiosité mathématique, mais aussi le fondement des communications sécurisées – tout ce qui va de HTTPS au cryptage par courriel (PGP) aux portefeuilles de blockchain – aide à comprendre pourquoi la gestion du cycle de vie des clés est critique pour la mission.

Le cycle de vie des clés de chiffrement

Le cycle de vie d'une paire de clés asymétriques de chiffrement s'étend de la génération initiale à la destruction finale sécurisée. Chaque phase introduit des risques spécifiques qui doivent être abordés de manière proactive.

1. Génération de clés

La génération de clés est le fondement de la sécurité cryptographique. Le processus doit utiliser un générateur de nombres aléatoires (CSPRNG) sécurisé cryptographiquement pour garantir une imprévisibilité. La faiblesse du hasard – qu'il s'agisse d'un algorithme défectueux, de valeurs de semences prévisibles ou de problèmes d'entropie matérielle – peut rendre la paire de clés dissoute même si le problème mathématique sous-jacent demeure difficile.

Pour la génération RSA, il faut sélectionner deux grands premiers indépendants (généralement 2048 bits ou plus), calculer le produit n, et en tirer les exposants publics et privés. Pour ECC, le générateur sélectionne un entier aléatoire dans l'ordre d'une courbe définie. Les normes NIST SP 800-56A et SP 800-133 précisent les algorithmes approuvés et les étapes de validation des paramètres.

Une clé destinée à la signature de code devrait avoir différents paramètres que celui utilisé pour l'authentification du serveur TLS. Le marquage des clés avec métadonnées (propriétaire, but, date de création, expiration) à partir du moment de la génération simplifie les opérations futures du cycle de vie.

2. Distribution des principales

Bien que la clé privée ne soit jamais distribuée, la clé publique doit être remise à toutes les parties qui en ont besoin. Le défi crucial ici est d'assurer l'authenticité de la clé publique : le récepteur doit être certain que la clé appartient vraiment à l'entité revendiquée. Sans cette vérification, un attaquant peut remplacer sa propre clé publique et intercepter ou imiter les communications.

La solution standard utilise l'infrastructure à clé publique (ICP) avec des certificats numériques délivrés par les autorités de certification (AC). Un certificat lie l'identité d'une entité (p. ex., un nom de domaine ou un nom d'organisation) à sa clé publique, signée par la clé privée de l'AC. Toutefois, la sécurité de l'ensemble de l'ICP dépend de la gestion du cycle de vie de l'AC, comme l'ont montré les compromis passés de l'AC (p. ex., DigiNotar, Comodo).

Les solutions de rechange à l'ICP pour la distribution des clés comprennent le modèle OpenPGP web of trust et l'approche de la confiance en première utilisation (TOFU) du protocole de Signal. Chacun a des compromis entre l'évolutivité et les hypothèses de sécurité.

3. Utilisation des clés

Pendant la phase d'utilisation, la paire de clés est activement utilisée : clé publique pour le chiffrement ou la vérification de signature, clé privée pour le décryptage ou la signature. La sécurité de cette phase dépend souvent de la façon dont la clé privée est protégée pendant son utilisation. Si un attaquant accède à la mémoire du système pendant que la clé privée est chargée, il peut la copier.

Pour le décryptage, la clé privée doit être disponible en ligne (par exemple, dans un serveur TLS qui termine HTTPS). Cela crée une fenêtre de vulnérabilité – si le serveur est compromis, la clé peut être exfiltrée. Les mesures d'atténuation comprennent l'utilisation de clés de ticket de session avec de courtes durées de vie et ne pas persister la clé privée à long terme au-delà de la poignée de main initiale, ou l'utilisation d'architectures TLS sans clé où la clé privée ne laisse jamais un appareil de signature dédié.

Pour les opérations de signature (signature de code, signature de document, autorisation de transaction), la clé privée devrait idéalement être stockée hors ligne et accessible uniquement par une interface sécurisée avec approbation physique ou multifactorielle. Le vol récent de certificats de signature de code utilisés dans l'attaque SolarWinds a montré les effets dévastateurs en cascade d'un compromis de clé de signature – les attaquants pourraient signer des mises à jour malveillantes comme légitimes.

4. Rotation et expiration des clés

La rotation clé est le processus de retrait d'une paire de clés existante et de production d'une nouvelle paire après une période ou un événement prédéterminé. Les avantages sont deux fois plus importants : elle limite la quantité de données chiffrées sous une seule clé (réduction de l'impact d'un futur compromis) et elle oblige le système à rétablir la confiance dans une nouvelle paire de clés.

Les dates d'expiration sont intégrées dans les certificats X.509 pour faire respecter la rotation. Lorsqu'un certificat expire, la paire de clés devient techniquement invalide aux fins de ce certificat, bien que les clés cryptographiques elles-mêmes puissent être toujours valides.

Pour la terminaison TLS, le nouveau certificat et la paire de clés doivent être déployés avant l'expiration de l'ancienne, la validité du chevauchement étant permise. Pour le chiffrement, les données chiffrées sous l'ancienne clé publique doivent être re-encryptées sous la nouvelle clé après une fenêtre de migration. Ceci est particulièrement difficile pour les environnements de données stockées de longue durée. Certains systèmes utilisent une approche hybride : une "clé clé de chiffrement" (KEK) qui chiffre les clés de chiffrement, permettant la rotation de la KEK sans re-encrypter toutes les données.

5. Révocation et destruction des principales

La révocation est le mécanisme d'urgence permettant d'invalider une paire de clés avant son expiration naturelle. La raison la plus courante est la suspicion ou la confirmation d'un compromis de clé privée. D'autres déclencheurs comprennent le départ des employés, l'algorithme déprécié comme dangereux (p. ex., le passage de SHA-1 à SHA-256 dans les certificats) ou les changements de politique organisationnelle. La révocation nécessite une diffusion rapide et fiable : dans l'ICP, les listes de révocation de certificats (LCR) et le protocole de statut de certificat en ligne (PSPC) prévoient cette fonction.

Les LCR peuvent être grandes et la bande passante-intense, et la gestion du navigateur des vérifications de révocation varie considérablement. De nombreux navigateurs utilisent aujourd'hui les bases de données de révocation CRLite ou agrégées pour des raisons de performance. L'omission de la révocation à atteindre toutes les parties en cause à temps a conduit à des incidents où les certificats compromis sont restés fiables pendant des jours ou des semaines.

La destruction sécurisée de la clé privée une fois qu'elle n'est plus nécessaire, que ce soit en raison de la rotation, de la révocation ou du déclassement, est l'étape finale. La suppression du fichier peut simplement laisser des restes récupérables sur le disque. La NIST SP 800-88 recommande une effacement cryptographique : écraser la clé avec des zéros ou utiliser des mécanismes de destruction de clé matérielle dans les HSM qui érodent physiquement le matériel clé à la commande.

Meilleures pratiques de gestion

La gestion efficace du cycle de vie exige des politiques systématiques et des contrôles techniques appliqués à toutes les phases. Voici les pratiques détaillées que les équipes de sécurité devraient mettre en œuvre.

Stockage sécurisé

Les clés privées ne doivent jamais être stockées dans un texte clair sur disque ou dans des fichiers de configuration d'application. La norme de l'industrie est un module de sécurité matérielle (HSM) – un dispositif physique résistant aux manipulations qui génère, stocke et utilise des clés privées sans jamais les exposer au système hôte. Les HSM vont des appareils connectés au réseau aux services gérés par le cloud (AWS CloudHSM, Azure Dediced HSM).

L'accès aux clés devrait être limité aux seuls processus et utilisateurs qui l'exigent absolument, en utilisant une authentification robuste (p. ex. accès basé sur le rôle, authentification multifacteur pour les opérations administratives). Pour les clés de grande valeur (clés de CA racine, clés de signature de code), envisager l'autorisation multipartite où deux administrateurs ou plus doivent approuver toute opération d'utilisation des clés.

Rotation régulière

Automatisez la rotation des clés autant que possible. Des outils comme Certbot (Encryptons) renouvellent automatiquement les certificats TLS tous les 60 à 90 jours. Pour l'ICP interne, utilisez Azure Key Vault ou HashiCorp Vault pour faire respecter les horaires de rotation et s'intégrer aux plateformes de gestion du cycle de vie des certificats. La rotation devrait également déclencher le réencryptage de toutes les données cryptées sous l'ancienne clé – c'est souvent la partie la plus difficile et doit être planifiée dès le début dans la conception du système.

Fréquences de rotation des documents par type de clé : clés TLS annuelles; clés de signature de code tous les 2-3 ans; clés racine CA tous les 5-10 ans (mais les clés subordonnées qu'ils signent peuvent tourner plus fréquemment).

Distribution de clés authentique

Pour les clés publiques, obtenir des certificats auprès d'AC de bonne réputation et utiliser la transparence du certificat pour détecter les erreurs de délivrance. Pour les clés internes, déployer une CA privée avec une clé racine bien gérée. Distribuer des certificats ou des clés publiques via un dépôt signé, une gestion sécurisée des paramètres (p. ex., les poussées MDM) ou des empreintes digitales vérifiées manuellement (pour les groupes de confiance plus petits).

Mettre en œuvre le piquage des certificats, le cas échéant, mais être conscient du risque opérationnel : le piquage peut causer des pannes, et le piquage ne protège pas contre le compromis du serveur épinglé. Une alternative est d'utiliser les en-têtes Expect-CT et Expect-Staple pour imposer des contrôles de révocation et la transparence des certificats sans piquage de codage dur.

Suivi et vérification

Centraliser les journaux pour tous les événements clés du cycle de vie : génération, distribution, utilisation, rotation, révocation et destruction. Utilisez un système de gestion des informations et des événements de sécurité (SIEM) pour corréler les événements clés avec d'autres télémétries de sécurité. Par exemple, une augmentation soudaine des tentatives de déchiffrement échoué peut indiquer une clé testée par un attaquant.

Vérifier régulièrement l'inventaire clé : quelles clés existent, qui les possède, quand elles ont été générées, quand elles expirent et si elles sont encore nécessaires.De nombreuses organisations souffrent de « l'étalement clé » – des centaines de certificats inutilisés encombrant des magasins de fiducie ou des serveurs, chacun présentant un risque potentiel.

Effectuer des tests de pénétration périodiques ciblant spécifiquement les faiblesses de gestion des clés : tester la capacité de lire les clés privées à partir des décharges de mémoire, vérifier que les certificats révoqués ne peuvent pas être rétablis, et confirmer que la destruction des clés rend la clé irrécupérable.

Planification de la réponse à l'incident pour le compromis clé

Quelle que soit la solidité de la gestion du cycle de vie, la possibilité de compromis clé reste. Chaque organisation devrait avoir un playbook qui répond : Comment décelons-nous un compromis clé ? (par exemple, certificats inattendus émis, connexions impossibles avec des signatures falsifiées). Comment le conservons-nous ? (Récupérer le certificat immédiatement, générer de nouvelles clés, avertir les parties touchées).

Étapes pratiques : pré-générer des listes de révocation hors ligne pour votre CA privée, tenir des listes de contact de toutes les parties en cause et tester le processus de révocation au moins une fois par année.

Conclusion

Chaque étape introduit des vulnérabilités qui, si elles sont ignorées, peuvent sous-cuter la cryptographie la plus forte. En adoptant des pratiques exemplaires telles que le stockage basé sur HSM, la rotation automatisée, la distribution authentifiée et l'audit approfondi, les organisations peuvent maintenir l'intégrité et la disponibilité de leurs systèmes cryptographiques. À mesure que le paysage de la menace évolue avec les progrès de l'informatique quantique et les vecteurs d'attaque plus sophistiqués, rester discipliné dans la gestion du cycle de vie clé n'est pas seulement une tâche de conformité, mais une posture de sécurité fondamentale.