- LastPass (2022) : les coffres clients étaient chiffrés, mais les métadonnées (URLs des sites, emails des clients, noms d\'utilisateur) n\'étaient pas chiffrées dans la même enveloppe — une erreur de design qui a permis à l\'attaquant d\'extraire des informations exploitables même sans déchiffrer le contenu des coffres.
- L\'erreur la plus fréquente : utiliser le chiffrement en transit (TLS) comme substitut au chiffrement au repos, en supposant que les données sont protégées une fois dans les systèmes internes. Ce n\'est pas le cas.
- L\'utilisation d\'algorithmes obsolètes (RC4, DES, 3DES, RSA avec clés 1024 bits, SHA-1) reste fréquente dans les systèmes legacy et dans les implémentations effectuées par des équipes sans expertise cryptographique.
- La gestion incorrecte des IV (Initialization Vectors) dans les modes CBC ou CTR invalide le chiffrement : IVs fixes, IVs prévisibles ou réutilisation d\'IVs permettent des attaques connues qui récupèrent le plaintext.
- Le padding oracle est une vulnérabilité d\'implémentation qui permet de déchiffrer des messages chiffrés en AES-CBC via des oracles de déchiffrement exposés — une erreur d\'implémentation encore rencontrée dans des systèmes en production.
- Le certificate pinning mal configuré crée des faux positifs (ruptures de service lors des renouvellements) ou des angles morts (si le pin est sur le certificat leaf et non sur la CA, l\'attaquant peut usurper via une CA compromise).
Le chiffrement est un domaine où les erreurs d\'implémentation sont fréquentes, subtiles et potentiellement catastrophiques. Contrairement à beaucoup de mesures de sécurité, une implémentation incorrecte du chiffrement peut produire un système qui semble sécurisé lors des audits de conformité mais qui est vulnérable aux attaques cryptographiques. Pire : elle peut donner aux équipes une confiance erronée dans la protection de leurs données, les conduisant à négliger d\'autres contrôles de sécurité qui auraient été maintenus en l\'absence de cette fausse assurance.
Les erreurs de déploiement du chiffrement se regroupent en plusieurs catégories : les erreurs de choix algorithmique (mauvais algorithme ou mauvais paramètres), les erreurs d\'implémentation (code incorrect qui invalide les propriétés cryptographiques), les erreurs architecturales (chiffrement bien implémenté mais dans le mauvais endroit), et les erreurs de gestion des clés (le maillon le plus faible de presque toutes les implémentations).
Les erreurs de choix algorithmique
L\'utilisation d\'algorithmes obsolètes est plus répandue qu\'on ne le pense dans les systèmes en production. AES-128 en mode ECB (Electronic Code Book) est une erreur classique — le mode ECB ne masque pas les patterns dans le plaintext, rendant le chiffrement faible même avec AES. AES en mode CBC sans MAC (Message Authentication Code) est vulnérable aux attaques de padding oracle. L\'utilisation de MD5 ou SHA-1 pour le hachage des mots de passe — des algorithmes rapides conçus pour l\'intégrité des fichiers, pas pour la protection des mots de passe — est encore rencontrée dans des systèmes qui n\'ont pas été audités ou mis à jour depuis plusieurs années.
La cryptographie asymétrique introduit ses propres erreurs : des clés RSA de 1024 bits sont maintenant factorisables par des adversaires disposant de ressources significatives, et l\'utilisation de courbes elliptiques non recommandées (NIST P-192) présente des faiblesses connues. Les recommandations actuelles — AES-256-GCM pour le chiffrement symétrique, RSA-2048 minimum ou ECC avec P-256/P-384 pour l\'asymétrique, Argon2id ou bcrypt pour les mots de passe — sont stables mais pas universellement appliquées.
La violation T-Mobile de 2021 (50 millions de clients via une API non sécurisée) a révélé que des données de clients étaient accessibles sans chiffrement au niveau de l\'API — la protection reposait uniquement sur les contrôles d\'accès à l\'endpoint. L\'investigation technique a identifié que l\'API exposait des données en clair une fois l\'authentification passée, sans validation d\'autorisation au niveau des ressources individuelles. Cette architecture — authentification de périmètre sans autorisation fine et sans chiffrement au niveau des données — est un anti-pattern fréquent dans les APIs développées rapidement : le développement se concentre sur les fonctionnalités, pas sur les garanties cryptographiques des données exposées.
Les erreurs d\'implémentation cryptographique
Les erreurs d\'implémentation les plus fréquentes dans les systèmes custom incluent : la réutilisation de nonces ou d\'IVs (catastrophique en mode GCM — deux messages chiffrés avec le même nonce et la même clé permettent de récupérer les deux plaintexts et la clé d\'authentification), la génération de nombres aléatoires non cryptographiquement sûrs (utilisation de Math.random() en JavaScript ou de rand() en C pour des valeurs cryptographiques), et la construction manuelle de primitives cryptographiques (implémenter soi-même AES au lieu d\'utiliser une bibliothèque éprouvée).
Le principe fondamental "don\'t roll your own crypto" reste violé dans beaucoup de systèmes — non pas par des implémentations complètes d\'algorithmes maison, mais par des constructions personnalisées à partir de primitives standard qui créent des vulnérabilités dans l\'assemblage. Les constructions authentifiées (authenticated encryption) sont particulièrement sujettes à ces erreurs : séparer le chiffrement de l\'authentification et les combiner incorrectement invalide les propriétés de sécurité de chacun.
Les erreurs architecturales de chiffrement
Les erreurs architecturales concernent la position du chiffrement dans l\'architecture plutôt que son implémentation intrinsèque. Chiffrer le transport (TLS) sans chiffrer les données au repos laisse les données vulnérables une fois dans les systèmes de stockage. Chiffrer les données au repos avec des clés stockées dans le même volume que les données ne protège pas contre un attaquant qui accède au volume. Chiffrer les backups avec les mêmes clés que les données de production signifie que la compromission des clés expose simultanément les données live et les archives.
L\'attaque sur Colonial Pipeline a mis en évidence des erreurs architecturales dans la séparation des réseaux IT et OT (Operational Technology). Les systèmes SCADA qui contrôlent le pipeline n\'utilisaient pas de chiffrement authentifié pour les communications de contrôle — une lacune fréquente dans les environnements industriels où les protocoles de contrôle (Modbus, DNP3) ont été conçus avant que la sécurité réseau ne soit une préoccupation. Sans chiffrement des communications de contrôle, un attaquant ayant accès au réseau IT peut potentiellement envoyer des commandes non authentifiées aux systèmes de contrôle industriel via le réseau — une architecture que Colonial Pipeline a ensuite corrigée en renforçant la segmentation et le chiffrement des communications OT.
L\'attaque NotPetya sur Maersk en 2017 a exploité une erreur architecturale dans la conception du contrôleur de domaine Active Directory : un seul contrôleur de domaine, situé en Ukraine, gérait l\'ensemble de l\'authentification du réseau mondial. Ce composant critique n\'était pas protégé par des mécanismes cryptographiques renforcés adaptés à son importance stratégique dans l\'architecture. La destruction de ce contrôleur a rendu impossible toute authentification Kerberos dans le réseau — illustrant comment une erreur architecturale dans la protection d\'un composant central d\'infrastructure peut compromettre l\'ensemble de la résilience cryptographique d\'une organisation.
L\'exposition de données de localisation de 2 millions de véhicules Toyota pendant dix ans résultait d\'une erreur architecturale de chiffrement : une base de données cloud configurée avec un accès public sans authentification. Les données de localisation — qui auraient dû être chiffrées et protégées par des contrôles d\'accès stricts en raison de leur sensibilité — étaient accessibles sans clé, sans token et sans authentification. Cette configuration permettait à n\'importe quel utilisateur disposant de l\'URL de la base de données d\'accéder aux historiques de localisation des véhicules. L\'erreur n\'était pas dans l\'algorithme de chiffrement mais dans son absence totale dans un système qui aurait dû l\'avoir par défaut.