Cas pratiques cryptography

Contexte : Une application chiffre des données sensibles avant stockage. Cependant, un audit révèle que le chiffrement est mal implémenté. Le Problème : Le vecteur d'initialisation (IV) est fixe, ce qui compromet la sécurité. Implémentation actuelle : const iv = "0000000000000000"; const cipher = createCipheriv("aes-256-cbc", key, iv); L'utilisation d'un IV constant affaiblit le chiffrement. Contraintes : Vous devez conserver AES-256-CBC mais corriger l'utilisation du IV. La solution doit générer un IV unique pour chaque chiffrement et permettre le déchiffrement ultérieur. Livrable attendu : Corriger la logique afin d'utiliser un IV aléatoire sécurisé et expliquer comment le stocker avec les données chiffrées.

Contexte : Une application chiffre des données sensibles mais ne vérifie pas leur intégrité après déchiffrement. Le Problème : Le système utilise AES-CBC sans mécanisme d'authentification. Implémentation actuelle : const cipher = createCipheriv("aes-256-cbc", key, iv); Aucun HMAC ou mode authentifié n'est utilisé. Contraintes : Vous devez conserver AES mais ajouter une protection d'intégrité (HMAC ou AES-GCM). La solution doit empêcher toute modification silencieuse des données chiffrées. Livrable attendu : Implémenter un mécanisme d'authentification des données chiffrées garantissant confidentialité et intégrité.

Contexte : Une application hache les mots de passe utilisateurs avant stockage. Le Problème : Le hachage est effectué sans sel, rendant le système vulnérable aux attaques par rainbow tables. Implémentation actuelle : const hash = sha256(password); Aucun sel unique par utilisateur n'est utilisé. Contraintes : Vous devez ajouter un sel unique et aléatoire pour chaque utilisateur. Le sel doit être stocké avec le hash. L'algorithme de hachage peut rester identique. Livrable attendu : Modifier le mécanisme de hachage afin d'intégrer un sel sécurisé et permettre une vérification correcte du mot de passe.

Contexte : Une application génère une paire de clés RSA pour signer des messages. Cependant, la clé privée est stockée dans un fichier accessible publiquement. Le Problème : La configuration actuelle expose la clé privée dans un répertoire non protégé. Configuration actuelle : PrivateKeyPath: /public/keys/private.pem Cela représente un risque critique de sécurité. Contraintes : Vous devez sécuriser le stockage sans modifier l'algorithme utilisé. La clé privée doit être protégée par des permissions strictes ou un coffre sécurisé. Livrable attendu : Proposer et implémenter une méthode de stockage sécurisé de la clé privée empêchant tout accès non autorisé.

Contexte : Une API compare un hash fourni par un client avec un hash stocké pour valider une requête sécurisée. Le Problème : La comparaison est faite avec un opérateur classique. Implémentation actuelle : if(receivedHash === storedHash) { grantAccess(); } Cette comparaison peut être vulnérable aux attaques par timing. Contraintes : Vous devez implémenter une comparaison en temps constant. Aucune modification du format des hash n'est autorisée. Livrable attendu : Remplacer la comparaison naïve par une méthode de comparaison sécurisée en temps constant afin de limiter les risques de timing attack.

Contexte : Une équipe utilise un générateur pseudo-aléatoire standard pour créer des clés d'API temporaires. Le Problème : Le générateur utilisé n'est pas cryptographiquement sécurisé et pourrait produire des valeurs prévisibles. Contraintes : Utiliser un générateur aléatoire cryptographiquement sécurisé fourni par la plateforme. Les clés doivent avoir une longueur minimale de 32 octets. Aucun générateur basé sur Math.random ou équivalent n'est autorisé. Livrable attendu : Implémenter une fonction générant des clés aléatoires sécurisées adaptées à un usage cryptographique.

Contexte : Une application doit garantir l'intégrité des documents échangés entre deux services internes. Le Problème : Vous devez mettre en place un mécanisme simple permettant de signer un message avec une clé privée et de vérifier la signature avec la clé publique correspondante. Contraintes : Utiliser RSA ou ECDSA. La clé privée ne doit jamais être exposée. La signature doit permettre de détecter toute modification du message. L'implémentation doit rester simple et démonstrative. Livrable attendu : Implémenter une fonction de signature d'un message et une fonction de vérification garantissant l'intégrité et l'authenticité du message.

Contexte : Une application desktop doit stocker localement des données sensibles comme des tokens d'accès ou des informations confidentielles. Le Problème : Les données sont actuellement sauvegardées en clair dans un fichier local. Contraintes : Utiliser un algorithme de chiffrement symétrique reconnu comme AES. La clé ne doit pas être codée en dur. Le système doit permettre le chiffrement et le déchiffrement fiables des données. L'implémentation doit rester simple. Livrable attendu : Implémenter un module permettant de chiffrer les données avant stockage et de les déchiffrer à la lecture en utilisant une clé sécurisée fournie dynamiquement.

Contexte : Vous rejoignez une équipe qui développe une application interne de gestion des employés. Les mots de passe sont actuellement stockés en clair dans la base de données. Le Problème : Vous devez mettre en place un mécanisme simple de hachage afin de sécuriser le stockage des mots de passe lors de l'inscription et de l'authentification. Contraintes : Utiliser un algorithme de hachage cryptographique reconnu (ex: SHA-256 ou bcrypt). Aucun mot de passe ne doit être stocké en clair. Le système doit permettre la vérification d'un mot de passe sans jamais le révéler. La solution doit rester simple et pédagogique. Livrable attendu : Implémenter une fonction de hachage des mots de passe et une fonction de vérification permettant de comparer un mot de passe fourni avec son empreinte stockée.

Contexte : Deux services internes doivent établir un canal sécurisé sans partager de clé secrète au préalable. Le Problème : Vous devez implémenter un mécanisme simple d'échange de clé basé sur Diffie-Hellman afin de dériver un secret partagé. Contraintes : Utiliser un algorithme Diffie-Hellman standard. Le secret partagé ne doit jamais transiter en clair. L'implémentation doit rester pédagogique et démontrer le principe mathématique. Livrable attendu : Implémenter la génération des paramètres publics, l'échange des valeurs publiques et la dérivation d'un secret partagé identique des deux côtés.

Contexte : Une application doit dériver des clés cryptographiques à partir de mots de passe utilisateurs pour chiffrer des données sensibles. Le système actuel utilise directement un hash simple du mot de passe. Le Problème : L'utilisation directe d'un hash (ex: SHA-256) rend le système vulnérable aux attaques par force brute accélérées par GPU. Contraintes : Vous devez utiliser un algorithme de dérivation de clé comme PBKDF2 avec un sel unique et un nombre d'itérations configurable. Le sel doit être stocké avec la clé dérivée. Le système doit permettre la vérification ultérieure du mot de passe. Livrable attendu : Implémenter un module de dérivation sécurisé incluant génération du sel, paramétrage des itérations et fonction de vérification robuste.

Contexte : Une API interne utilise des JWT pour authentifier les requêtes entre services. Le Problème : Les tokens sont signés mais aucune stratégie claire de gestion des clés ni de validation stricte des claims n'est définie. Contraintes : Utiliser un algorithme asymétrique (RS256 ou ES256). Validation obligatoire des claims exp, iss, aud. Support de rotation des clés via un endpoint public. Aucun secret partagé entre services. Livrable attendu : Définir et implémenter un système de signature et de validation JWT robuste incluant gestion des clés publiques et vérification complète des claims.

Contexte : Une application legacy utilise MD5 pour vérifier l'intégrité de fichiers transférés entre serveurs. Le Problème : MD5 est vulnérable aux collisions et ne garantit plus une intégrité fiable. Implémentation actuelle : const checksum = md5(fileContent); Contraintes : Vous devez remplacer MD5 par un algorithme sécurisé (ex: SHA-256 ou SHA-3) tout en conservant la compatibilité avec les anciens fichiers le temps d'une transition. Livrable attendu : Mettre en place un mécanisme de transition vers un algorithme moderne avec vérification renforcée de l'intégrité des fichiers.

Contexte : Un système génère des tokens de réinitialisation de mot de passe à l'aide d'un générateur standard non sécurisé. Le Problème : Le code actuel utilise une fonction pseudo-aléatoire prédictible. Implémentation actuelle : const token = Math.random().toString(36).substring(2); Cela rend les tokens potentiellement prévisibles. Contraintes : Vous devez utiliser un générateur cryptographiquement sécurisé. Les tokens doivent avoir au minimum 128 bits d'entropie. Livrable attendu : Remplacer la génération actuelle par un mécanisme sécurisé garantissant une entropie suffisante et imprévisible.

Contexte : Une application chiffre des données sensibles avec RSA et les transmet à un service distant. Un audit révèle une vulnérabilité potentielle. Le Problème : Le système utilise RSA sans padding sécurisé. Implémentation actuelle : const encrypted = rsaEncrypt(data, publicKey); Aucun padding OAEP n'est explicitement défini. Contraintes : Vous devez conserver RSA mais corriger l'utilisation du padding afin d'éviter toute attaque de type padding oracle. La compatibilité avec les données existantes doit être maintenue. Livrable attendu : Modifier la configuration de chiffrement pour utiliser un padding sécurisé (ex: OAEP) et expliquer la mitigation de la vulnérabilité.

Contexte : Une application chiffre des documents sensibles avec une clé symétrique unique utilisée depuis plusieurs années. Le Problème : Aucune stratégie de rotation de clé n'est implémentée. Configuration actuelle : ActiveKey: key_v1 Toutes les données sont chiffrées avec la même clé. Contraintes : Vous devez mettre en place une stratégie de rotation sans rendre les anciennes données inaccessibles. Les nouvelles données doivent être chiffrées avec une nouvelle clé. Livrable attendu : Implémenter un mécanisme de gestion multi-clés permettant de chiffrer avec la clé active et de déchiffrer avec les anciennes clés si nécessaire.

Contexte : Une application cliente établit une connexion TLS vers un serveur interne. Le Problème : La validation actuelle accepte tout certificat signé sans vérifier correctement le nom d'hôte. Implémentation actuelle : if(validateCertificate(cert)) { connect(); } Aucune vérification du Common Name ou Subject Alternative Name n'est effectuée. Contraintes : Vous devez maintenir TLS mais ajouter une validation stricte du certificat incluant vérification du hostname et de la chaîne de confiance. Livrable attendu : Corriger la logique de validation afin de prévenir toute attaque de type Man-in-the-Middle.

Contexte : Une équipe chiffre actuellement des données avec AES-CBC et un HMAC séparé, ce qui complique la maintenance. Le Problème : Vous devez simplifier le mécanisme en utilisant un mode de chiffrement authentifié intégré garantissant confidentialité et intégrité. Contraintes : Utiliser AES-GCM. Chaque opération doit générer un nonce unique. Le tag d'authentification doit être stocké avec les données chiffrées. Aucune clé ne doit être codée en dur. Livrable attendu : Implémenter un module de chiffrement/déchiffrement utilisant AES-GCM avec gestion correcte du nonce et du tag d'authentification.

Contexte : Une application manipule plusieurs clés API et secrets sensibles stockés en clair dans des fichiers de configuration. Le Problème : Vous devez concevoir un mécanisme de stockage chiffré des secrets avec contrôle d'accès strict. Contraintes : Utiliser un chiffrement symétrique fort (AES-256). La clé maîtresse ne doit pas être stockée en clair dans le code. L'accès doit nécessiter une phrase secrète ou variable d'environnement sécurisée. Livrable attendu : Implémenter un module permettant de stocker, chiffrer et récupérer des secrets de manière sécurisée tout en limitant l'exposition des clés sensibles.

Contexte : Deux microservices doivent établir un canal sécurisé sans partager de secret préalable. Le Problème : Vous devez implémenter un échange de clé basé sur Elliptic Curve Diffie-Hellman pour dériver un secret partagé utilisé ensuite pour le chiffrement. Contraintes : Utiliser une courbe standard sécurisée (ex: P-256). Le secret partagé ne doit jamais être transmis. Une dérivation de clé via HKDF doit être appliquée avant usage. Livrable attendu : Implémenter la génération des clés publiques, l'échange sécurisé et la dérivation d'un secret partagé prêt à être utilisé pour un chiffrement symétrique.

Contexte : Une plateforme SaaS stocke des données sensibles nécessitant plusieurs niveaux d'accès (lecture simple, audit, administration). Le Problème : Vous devez concevoir un schéma de chiffrement permettant de limiter l'accès aux données selon le rôle tout en évitant la duplication inutile des clés. Contraintes : Utiliser une hiérarchie de clés (clé maître, clés intermédiaires, clés de données). Les clés doivent être isolées par rôle. Support de rotation obligatoire. Livrable attendu : Proposer une architecture de chiffrement hiérarchique détaillant la dérivation des clés, la séparation des privilèges et le processus de rotation sécurisé.

Contexte : Votre organisation souhaite sécuriser la gestion des clés privées utilisées pour signer des transactions critiques. Le Problème : Les clés sont actuellement stockées sur le serveur applicatif, exposant un risque majeur en cas de compromission. Contraintes : Simuler un module matériel de sécurité (HSM) logique isolant l'usage de la clé privée. La clé ne doit jamais être exportable. Seules des opérations de signature contrôlées sont autorisées. Livrable attendu : Concevoir et implémenter une abstraction permettant de déléguer les opérations cryptographiques à un module sécurisé sans exposer la clé privée au code applicatif.

Contexte : Votre entreprise souhaite internaliser la gestion des certificats pour ses services internes et API critiques. Actuellement, les certificats sont auto-signés sans gouvernance centralisée. Le Problème : Vous devez concevoir une infrastructure à clés publiques (PKI) incluant une Root CA, une Intermediate CA et un processus d'émission et de révocation des certificats. Contraintes : Séparation stricte entre Root et Intermediate CA. Support de CRL ou OCSP. Protection forte des clés privées de l'autorité. Politique de rotation et durée de validité définies. Livrable attendu : Proposer l'architecture complète de la PKI, le flux d'émission des certificats, la stratégie de révocation et les mécanismes de protection des clés sensibles.

Contexte : Une API accepte des JWT signés en RS256. Un audit révèle une vulnérabilité potentielle. Le Problème : La validation ne force pas explicitement l'algorithme attendu. Implémentation actuelle : if(validateSignature(token, key)) { allow(); } Un attaquant pourrait forcer l'utilisation d'un algorithme HMAC avec la clé publique comme secret. Contraintes : Vous devez empêcher toute confusion d'algorithme et forcer explicitement RS256. Livrable attendu : Implémenter une validation stricte de l'algorithme et corriger la logique pour empêcher toute exploitation par substitution d'algorithme.

Contexte : Une application signe des messages avec ECDSA pour garantir leur authenticité. Le Problème : Le nonce utilisé lors de la signature est généré de manière déterministe incorrecte ou réutilisé. Implémentation actuelle : const k = generateWeakRandom(); sign(message, privateKey, k); La réutilisation d'un nonce peut permettre de reconstruire la clé privée. Contraintes : Vous devez garantir un nonce unique et sécurisé pour chaque signature. Respect strict des standards ECDSA. Livrable attendu : Corriger la génération du nonce afin d'éliminer tout risque de fuite de clé privée et documenter la vulnérabilité associée.

Contexte : Une application legacy utilise RSA PKCS#1 v1.5 pour déchiffrer des messages entrants dans un service exposé publiquement. Le Problème : Le service retourne des messages d'erreur différents selon la nature du padding invalide. Implémentation actuelle : if(!validPadding(data)) { return "Padding Error"; } Cette distinction peut exposer le système à une attaque de type Bleichenbacher. Contraintes : Vous devez supprimer toute fuite d'information et migrer vers un padding sécurisé (OAEP). Aucun changement de protocole applicatif visible côté client. Livrable attendu : Corriger la logique pour empêcher toute fuite liée au padding et renforcer la sécurité du mécanisme de déchiffrement RSA.

Contexte : Une application valide des certificats X.509 pour autoriser des connexions entrantes. Le Problème : La validation actuelle vérifie uniquement la signature du certificat sans valider toute la chaîne jusqu'à une autorité de confiance. Implémentation actuelle : if(validateSignature(cert)) { allowConnection(); } Aucune vérification de la chaîne complète ni de la date d'expiration. Contraintes : Vous devez implémenter une validation complète incluant chaîne de confiance, date de validité, révocation et correspondance d'usage. Livrable attendu : Corriger la logique afin d'assurer une validation X.509 complète conforme aux bonnes pratiques de sécurité.

Contexte : Une application accepte plusieurs algorithmes de signature pour maintenir une compatibilité legacy. Le Problème : Le système accepte encore des signatures en SHA-1 lorsqu'un champ alg est fourni dans le token. Implémentation actuelle : if(token.alg == supportedAlg) { verify(token); } Un attaquant peut forcer l'utilisation d'un algorithme faible. Contraintes : Vous devez empêcher tout downgrade vers des algorithmes obsolètes tout en maintenant la compatibilité contrôlée. Livrable attendu : Mettre en place une validation stricte des algorithmes autorisés et supprimer toute possibilité de négociation vers des algorithmes faibles.

Contexte : Deux services critiques échangent des données sensibles et doivent s'authentifier mutuellement. Le Problème : Actuellement, seul le serveur présente un certificat TLS, laissant le client non authentifié. Contraintes : Mettre en place une authentification mutuelle TLS (mTLS). Vérification stricte de la chaîne de confiance et des certificats clients. Gestion de révocation obligatoire. Livrable attendu : Concevoir et configurer un système mTLS complet incluant génération des certificats clients, validation côté serveur et gestion des révocations.

Contexte : Un système distribué doit dériver plusieurs clés différentes (chiffrement, signature, authentification) à partir d'un secret maître partagé. Le Problème : L'utilisation directe du secret maître pour plusieurs usages crée un risque de compromission croisée. Contraintes : Utiliser HKDF avec un salt robuste et un info spécifique par usage. Chaque clé dérivée doit être indépendante cryptographiquement. Aucun secret maître ne doit être exposé directement. Livrable attendu : Implémenter une dérivation sécurisée produisant plusieurs clés isolées par contexte et documenter la séparation cryptographique obtenue.