Principales erreurs d’utilisation de la cryptographie

Le mode du dictionnaire électronique (ECB) chiffre chaque bloc indépendamment avec la même clé. Des blocs de texte en clair identiques produisent des blocs de texte chiffré identiques. La démonstration classique est le « pingouin ECB » : chiffrer une image bitmap avec ECB préserve la structure de l’image au niveau des blocs, ce qui rend le contour du pingouin clairement visible dans le texte chiffré. Le mode ECB n’offre aucune sécurité sémantique et ne doit jamais être utilisé pour un chiffrement pratique.

Implémenter des primitives cryptographiques à partir de zéro est l’une des pratiques les plus dangereuses du développement logiciel. La cryptographie exige une exactitude parfaite dans des conditions adverses : une fuite temporelle subtile, une erreur de décalage d’une unité dans le remplissage ou une mauvaise compréhension des exigences de sécurité peut créer des vulnérabilités exploitables, indiscernables d’un comportement correct lors de vérifications normales. Même les cryptographes experts commettent des erreurs d’implémentation ; les développeurs d’applications doivent utiliser exclusivement des bibliothèques soigneusement auditées.

MD5 ne résiste plus aux collisions depuis 2004 ; créer deux fichiers ayant le même hachage MD5 est trivial sur le plan computationnel. Des attaques par collision contre SHA-1 ont été démontrées en pratique par l’attaque SHAttered de Google en 2017, qui a produit deux fichiers PDF ayant le même hachage SHA-1. Ni l’un ni l’autre ne doit être utilisé à des fins de sécurité : signatures numériques, intégrité du contenu, stockage des mots de passe ou HMAC. Utilisez SHA-256, SHA-3 ou BLAKE2 pour les déploiements modernes.

Utiliser time() ou d’autres valeurs prévisibles pour initialiser un générateur de nombres pseudoaléatoires constitue une vulnérabilité critique lorsque la sortie du PRNG est utilisée à des fins de sécurité. Un attaquant qui connaît approximativement le moment où une clé a été générée peut parcourir par force brute l’espace des graines (tous les horodatages possibles dans une courte fenêtre) afin de retrouver la clé. Exemple classique : les premières versions de Netscape initialisaient la génération des clés SSL avec l’heure et l’identifiant du processus, deux informations observables par un attaquant sur la même machine.

rand() en C, java.util.Random et le module random de Python utilisent des générateurs linéaires congruentiels déterministes ou le générateur Mersenne Twister, conçus pour la qualité statistique des simulations et non pour la sécurité. Un attaquant qui observe suffisamment de sorties de ces générateurs peut reconstruire leur état interne et prédire toutes les sorties futures. À des fins de sécurité, utilisez les CSPRNG fournis par l’OS : secrets.token_bytes() en Python, crypto.randomBytes() dans Node.js ou /dev/urandom sous Linux.

Le chiffrement sans authentification assure uniquement la confidentialité, pas l’intégrité. Un attaquant qui ne peut pas lire le texte en clair peut tout de même modifier le texte chiffré, ce qui peut provoquer des modifications prévisibles du texte en clair, en particulier en mode CTR ou CBC. Cette malléabilité permet des attaques : un attaquant qui intercepte une transaction bancaire chiffrée pourrait inverser des bits pour modifier le montant du virement ou le compte destinataire sans connaître le texte en clair. Utilisez toujours un chiffrement authentifié (AEAD).

Inscrire en dur des clés de chiffrement ou des vecteurs d’initialisation dans le code source constitue une vulnérabilité critique. Le code source est souvent enregistré dans des dépôts de contrôle de version, parfois publics. Même dans des dépôts privés, toute personne ayant accès au code dispose de la clé. Des clés codées en dur signifient que toutes les instances utilisent la même clé et que la rotation des clés exige un redéploiement. Les clés doivent être stockées dans des variables d’environnement, des systèmes de gestion des secrets (HashiCorp Vault, AWS Secrets Manager) ou des modules matériels de sécurité.

Utiliser le même vecteur d’initialisation pour plusieurs chiffrements avec la même clé crée de graves vulnérabilités. En mode CTR, réutiliser l’IV produit le même flux de clés, ce qui permet de retrouver le texte en clair par XOR. En mode CBC, réutiliser l’IV permet à un attaquant de détecter quand deux messages commencent par les mêmes blocs de texte en clair. En mode GCM, réutiliser un nonce (IV) est catastrophique (voir la leçon sur la réutilisation des nonces). Générez un IV aléatoire nouveau pour chaque opération de chiffrement ; ajoutez-le au début du texte chiffré afin de le stocker avec le contexte de déchiffrement.

Stocker des mots de passe hachés avec MD5, SHA-256 ou toute autre fonction de hachage cryptographique rapide est insuffisant. Les processeurs graphiques modernes peuvent calculer des milliards de hachages SHA-256 par seconde, ce qui rend triviales les attaques par force brute hors ligne contre des bases de hachages dérobées. Le hachage des mots de passe exige des fonctions lentes conçues à cet effet et exigeantes en mémoire : bcrypt, scrypt ou Argon2id. Elles sont conçues pour rendre la force brute coûteuse, même avec du matériel spécialisé, afin de rendre les attaques hors ligne irréalisables en pratique du point de vue du calcul.

Désactiver la validation des certificats SSL/TLS (en définissant ssl.CERT_NONE en Python, en transmettant -k à curl ou en définissant trustAllCerts=true dans Android) supprime la protection contre les attaques de l’homme du milieu. Un attaquant peut présenter n’importe quel certificat et intercepter toutes les communications. Cette pratique apparaît dans les environnements de développement pour contourner les erreurs liées aux certificats autosignés, mais elle persiste fréquemment en production. Utilisez toujours une validation correcte des certificats et corrigez correctement les problèmes sous-jacents liés aux certificats.

Les fonctions cryptographiques signalent leurs échecs par des valeurs de retour ou des exceptions. Ignorer ces signaux permet à l’exécution de se poursuivre dans un état invalide : un déchiffrement ayant produit des données incohérentes, une vérification ayant échoué ou une génération de clé ayant rencontré une erreur. Dans les API fondées sur C comme OpenSSL, ignorer les valeurs de retour est particulièrement dangereux, car le programme peut continuer avec une mémoire non initialisée. Vérifiez toujours chaque valeur de retour des fonctions cryptographiques et gérez les échecs de manière sûre.

Pourquoi le mode ECB (dictionnaire électronique) est-il considéré comme non sécurisé pour chiffrer des données ?

Principales mauvaises pratiques à éviter : n’utilisez jamais le mode ECB (fuite des motifs de blocs), n’implémentez jamais vous-même les primitives cryptographiques, n’utilisez pas MD5 ni SHA-1 à des fins de sécurité, initialisez les PRNG avec un CSPRNG et non avec time(), utilisez un CSPRNG pour toute valeur aléatoire utilisée pour la sécurité, authentifiez toujours les données chiffrées (AEAD), ne codez jamais les clés ni les IV en dur, générez un IV nouveau pour chaque chiffrement, utilisez Argon2id pour les mots de passe plutôt que des fonctions de hachage rapides, validez toujours les certificats TLS et vérifiez chaque valeur de retour cryptographique.