- Capital One (2019) : la mauvaise configuration du rôle IAM AWS qui a permis l\'accès à 100 millions de dossiers clients illustre une défaillance de gestion des droits cryptographiques — les permissions de déchiffrement des données S3 n\'étaient pas scopées au service légitime qui en avait besoin.
- Les clés hardcodées dans le code source sont le vecteur le plus documenté de compromission cryptographique — des milliers de clés API, de clés de chiffrement et de credentials sont exposées chaque mois via des dépôts GitHub publics.
- La rotation des clés est souvent négligée après les délais initiaux — des clés de chiffrement qui n\'ont jamais été rotées depuis leur création sont un signal de gestion des clés défaillante, indépendamment de leur force algorithmique.
- Le partage des clés entre environnements (développement, staging, production) est une pratique courante qui élargit massivement la surface d\'attaque — une compromission en développement peut exposer les clés de production.
- Les HSM (Hardware Security Modules) protègent les clés contre l\'extraction logicielle, mais une mauvaise configuration des politiques d\'accès au HSM annule cette protection — le HSM est aussi sécurisé que la liste des identités autorisées à l\'utiliser.
- Le backup des clés dans un environnement moins sécurisé que le système de production est un vecteur d\'attaque fréquemment exploré par les attaquants — les backups des clés ont la même valeur que les clés elles-mêmes.
La gestion des clés cryptographiques (Key Management) est la discipline qui transforme le chiffrement théorique en protection réelle. La robustesse algorithmique de AES-256 ou RSA-4096 n\'a aucune valeur si les clés qui permettent le déchiffrement sont stockées de manière insuffisamment protégée, partagées entre des contextes de sécurité hétérogènes, ou gérées par des processus sans traçabilité.
Les attaques qui ciblent les clés plutôt que les algorithmes sont significativement plus efficaces et moins coûteuses. Extraire une clé d\'un fichier de configuration en clair ou d\'un dépôt Git est infiniment plus rapide que d\'attaquer AES par force brute. Cette asymétrie explique pourquoi les attaques réelles ciblent presque toujours la gestion des clés plutôt que la cryptographie elle-même.
Les patterns de défaillance de la gestion des clés
Le pattern le plus fréquent est le stockage des clés dans le même environnement que les données qu\'elles protègent. Une clé de chiffrement stockée dans le même fichier de configuration que la connexion à la base de données qu\'elle protège n\'est pas une protection — elle n\'est qu\'un obstacle mineur pour un attaquant qui a déjà accès au système de fichiers. La séparation des données et des clés dans des systèmes de sécurité distincts (KMS, HSM, Vault) est le principe fondamental d\'une gestion des clés efficace.
La génération de clés faibles est une deuxième catégorie de défaillance. Des clés générées depuis des sources d\'entropie insuffisantes, des clés dérivées de mots de passe sans fonction de dérivation adaptée (PBKDF2, Argon2id), ou des IVs générés de manière prévisible invalident les propriétés cryptographiques même d\'algorithmes correctement choisis. La génération cryptographiquement sûre requiert des CSPRNGs (Cryptographically Secure Pseudo-Random Number Generators) correctement initialisés.
La violation Yahoo de 2016 (3 milliards de comptes) a révélé une défaillance dans la gestion des clés de hachage des mots de passe. Certains comptes utilisaient MD5 sans salt — une configuration dans laquelle deux utilisateurs avec le même mot de passe ont le même hash, permettant des attaques de type rainbow table. D\'autres comptes utilisaient MD5 avec un salt fixe par utilisateur — légèrement plus robuste mais toujours vulnérable aux attaques GPU avec des dictionnaires. La migration vers des algorithmes de hachage adaptés aux mots de passe (bcrypt avec un facteur de coût élevé) n\'avait pas été complétée pour l\'ensemble de la base. La gestion des "clés" de hachage (les salts et les paramètres des fonctions de dérivation) était incohérente et insuffisamment documentée.
Les architectures de gestion des clés
Une architecture de gestion des clés mature utilise une hiérarchie de clés qui minimise l\'exposition : les Master Keys (ou Key Encryption Keys) ne chiffrent pas directement les données mais chiffrent les Data Encryption Keys (DEK). Les DEK chiffrent les données et sont stockées à côté d\'elles — chiffrées. Les Master Keys sont protégées dans des HSM ou des KMS avec des politiques d\'accès très restrictives. Cette architecture limite l\'impact d\'une compromission : l\'attaquant qui accède aux données chiffrées et aux DEK chiffrées n\'a pas encore accès aux données en clair sans les Master Keys.
Les services cloud de gestion des clés (AWS KMS, Azure Key Vault, GCP Cloud KMS) implémentent cette architecture avec des fonctionnalités supplémentaires : audit de chaque utilisation des clés, politiques d\'accès granulaires basées sur les identités IAM, rotation automatique des clés, et possibilité d\'utiliser des Customer-Managed Keys (CMK) pour les données les plus sensibles. L\'utilisation des CMK plutôt que des clés managées par le fournisseur cloud est la protection supplémentaire pertinente dans le threat model où le fournisseur cloud lui-même est considéré comme un adversaire potentiel.
La rotation des clés : un processus souvent négligé
La rotation des clés est le processus par lequel les anciennes clés sont remplacées périodiquement par de nouvelles clés, et les données précédemment chiffrées sont rechiffrées avec les nouvelles clés. Ce processus limite la fenêtre d\'exploitation d\'une clé compromise — même si une clé est exposée, son utilité est limitée dans le temps. Dans les organisations sans processus de rotation, des clés générées il y a dix ans peuvent encore protéger des données sensibles — une fenêtre d\'exploitation de dix ans pour un attaquant qui aurait obtenu la clé.
La violation LastPass de 2022 illustre les limites de la gestion des clés dans une architecture de coffre-fort de mots de passe. Les coffres clients étaient chiffrés avec des clés dérivées des mots de passe maîtres des utilisateurs via PBKDF2-SHA256. L\'attaquant a exfiltré les coffres chiffrés avec l\'intention de les attaquer offline. La solidité de la protection dépend directement de la solidité du mot de passe maître : pour les utilisateurs avec des mots de passe maîtres faibles, l\'attaquant peut dériver la clé par force brute. LastPass utilisait un facteur d\'itération PBKDF2 de 100 100 — un nombre qui était à la limite des recommandations de l\'époque et qui, avec des GPUs modernes, ne représente qu\'une protection modérée contre les mots de passe faibles.
La publication de données Thales par LockBit en 2022 a inclus des informations sur des projets internes potentiellement sensibles. Dans un groupe de défense et de sécurité comme Thales, la gestion des clés pour les données classifiées ou sensibles est soumise à des réglementations strictes. L\'incident a soulevé des questions sur la gestion des droits d\'accès aux dépôts de données internes pour les prestataires et sous-traitants. Une gestion des clés qui limite l\'accès par projet, par équipe et par durée contractuelle — plutôt que des accès larges accordés pour la durée du contrat sans révision — aurait limité le périmètre des données accessibles depuis l\'accès initialement compromis.
La violation Medibank de 2022 a été initiée via des credentials volés d\'un prestataire — un accès compromis qui avait des permissions d\'accès aux systèmes de données de santé de l\'assureur. La gestion des clés d\'accès pour les prestataires est une dimension critique de la gestion des clés au sens large : non pas seulement les clés cryptographiques mais les credentials d\'accès qui permettent de déchiffrer et d\'accéder aux données. Des credentials prestataires avec des permissions trop larges, des durées de validité trop longues et une rotation insuffisante sont une défaillance de gestion des droits d\'accès équivalente à une défaillance de gestion des clés cryptographiques.