Exercices corrigés de cryptographie type E7

a) Une valeur de 32 caractères hexadécimaux, calculée par md5() (ligne 2) : c'est MD5, sans sel. MD5 est cassé (collisions connues depuis 2004) et surtout extrêmement rapide : une carte graphique en calcule des dizaines de milliards par seconde, et les empreintes de mots de passe courants figurent dans des tables précalculées. Une base volée livre la plupart des mots de passe en quelques minutes. C'est une défaillance cryptographique (A02 de l'OWASP 2021).

b) Sans sel, deux mots de passe identiques donnent la même empreinte : les deux patients ont le même mot de passe. C'est d'ailleurs l'empreinte MD5 de password, présente dans toutes les tables. Un attaquant repère les doublons et les mots de passe les plus courants immédiatement.

c) On ne compare plus l'empreinte dans la requête : on lit l'empreinte stockée par l'adresse, puis on la vérifie avec password_verify(), qui gère le sel et le coût.

2. $mdp = $_POST['mdp'];
3. $req = $pdo->prepare('SELECT id, mdp FROM patient WHERE email = ?');
4. $req->execute([$email]);
5. $patient = $req->fetch();
6. if ($patient !== false && password_verify($mdp, $patient['mdp'])) {
7.     session_regenerate_id(true);
8.     $_SESSION['patient'] = $patient['id'];
9. }

À l'inscription, l'empreinte est calculée par password_hash($mdp, PASSWORD_ARGON2ID), dans une colonne VARCHAR(255). Les empreintes MD5 existantes sont migrées à la connexion (vérification de l'ancien format, puis password_hash et mise à jour), comme au chapitre 6.

a) Chiffré : le numéro doit être relu (il figure sur les comptes rendus et les échanges avec l'Assurance maladie), donc il faut une transformation réversible avec une clé. Un hachage ne permettrait pas de le réafficher, et, appliqué à un numéro de format connu, il ne protégerait même pas sa confidentialité (on peut hacher tous les numéros possibles).

b) Par exemple : « Un prestataire chargé de la maintenance de la base, qui dispose d'un accès en lecture aux tables, exporte les numéros de sécurité sociale et les revend pour des fraudes à l'identité. » Si la colonne est chiffrée avec une clé détenue par l'application seule, l'export ne contient que des données inexploitables.

c) Elle est inacceptable : helianthe est un mot devinable de 9 caractères, pas une clé de 256 bits générée aléatoirement, et elle est écrite en clair dans un fichier de configuration qui risque d'être versionné ou lu. Il faut générer une clé de 32 octets avec random_bytes(32), la stocker hors du dépôt (variable d'environnement définie sur le serveur, ou coffre de secrets), lisible par le seul service, et chiffrer en AES-256-GCM avec un IV aléatoire par valeur.

a) La réponse ne montre ni en-tête HSTS ni attribut Secure sur le cookie de session : rien ne garantit que le portail impose HTTPS (et s'il répond en HTTP, tout circule en clair). Sur un Wi-Fi public, un attaquant peut lire les identifiants envoyés par le formulaire et voler le cookie de session (PHPSESSID) pour usurper la session du patient : atteinte à la confidentialité de données de santé.

b) Obtenir un certificat (Let's Encrypt avec certbot), configurer nginx pour n'accepter que TLS 1.2 et 1.3, rediriger tout le trafic HTTP vers HTTPS (code 301), ajouter l'en-tête HSTS (Strict-Transport-Security: max-age=63072000; includeSubDomains), et marquer le cookie de session Secure, HttpOnly et SameSite=Lax (en PHP : session.cookie_secure = 1, session.cookie_httponly = 1, session.cookie_samesite = "Lax").

a) Pour le patient (et le médecin à qui il transmet le PDF) : l'intégrité (le résultat n'a pas été modifié depuis sa validation, par exemple par une falsification du fichier) et l'authenticité (il émane bien du laboratoire et du biologiste nommé). Pour le laboratoire : la non-répudiation et la preuve en cas de litige ; il peut démontrer le contenu exact du compte rendu validé, et un document falsifié ne porterait pas de signature valide.

b) Le logiciel calcule l'empreinte (SHA-256) du PDF, puis la signe avec la clé privée du biologiste, conservée sur un support personnel (carte, module matériel) ; la signature et le certificat du biologiste sont intégrés au PDF. Le lecteur PDF recalcule l'empreinte du document reçu, vérifie la signature avec la clé publique contenue dans le certificat, et vérifie la chaîne de ce certificat jusqu'à une autorité de confiance. Si un seul octet a changé, la vérification échoue.

a) Le jeton fixe dans l'URL authentifie la clinique mais ne protège pas l'intégrité du contenu ; même en HTTPS, il est enregistré dans les journaux et l'historique, et quiconque le récupère peut l'utiliser indéfiniment. La signature HMAC prouve à chaque requête que l'expéditeur connaît le secret (authenticité) et que le corps n'a pas été modifié (intégrité) ; le secret lui-même ne circule jamais. On y ajoute un horodatage signé pour empêcher le rejeu d'une ancienne requête.

b)

$corps = file_get_contents('php://input');
$attendue = hash_hmac('sha256', $corps, $secret);
$recue = $_SERVER['HTTP_X_SIGNATURE'] ?? '';
if (!hash_equals($attendue, $recue)) {
    http_response_code(401);
    exit('Signature invalide');
}

hash_equals() compare en temps constant, pour ne pas renseigner l'attaquant par la durée de la comparaison.

a) Telnet transmet tout en clair, identifiants d'administration compris ; SNMPv2c avec la communauté public transmet un « mot de passe » connu de tous, en clair, sans intégrité. Un attaquant qui écoute le réseau récupère les accès d'administration et les informations des équipements : la confidentialité et l'intégrité sont menacées.

b) Remplacer Telnet par SSH (transport input ssh, clés RSA 3 072 bits ou plus, SSH version 2), et SNMPv2c par SNMPv3 en mode authPriv. Le document 1 est en syntaxe Cisco IOS : snmp-server group SUPERVISION v3 priv puis snmp-server user supervision SUPERVISION v3 auth sha <mot de passe> priv aes 128 <mot de passe> (sur un commutateur Aruba, comme dans le sujet Blanca : snmpv3 user supervision auth sha <mdp> priv aes <mdp>) ; on supprime snmp-server community public RO (no snmp-server community public). auth sha active l'authentification par HMAC-SHA : chaque message est accompagné d'une empreinte calculée avec un secret, ce qui garantit qu'il vient d'un utilisateur autorisé et qu'il n'a pas été modifié (authenticité et intégrité). priv aes active le chiffrement AES du contenu des messages (confidentialité).

a) Un portable perdu ou volé expose les données de santé qu'il contient : c'est une violation de données à notifier à la CNIL dans les 72 heures si elle présente un risque (article 33), et, si le risque est élevé, à signaler aux patients (article 34). Si le disque avait été chiffré, l'information individuelle des patients n'aurait pas été nécessaire. L'article 32 impose des mesures appropriées : pour des portables contenant des données de santé, le chiffrement en fait clairement partie.

b) Activer BitLocker par stratégie de groupe : chiffrement XTS-AES 256 du disque système, protecteur TPM + code PIN de démarrage pour les portables, et sauvegarde obligatoire de la clé de récupération dans Active Directory avant le chiffrement (le poste ne chiffre pas tant que la clé n'est pas enregistrée). Vérifier régulièrement l'état (manage-bde -status, rapport de conformité) et la présence des clés dans l'annuaire.

a) Le certificat de l'intranet est auto-signé, ou émis par une autorité interne dont le certificat racine n'est pas installé dans le magasin « Autorités de certification racines de confiance » des postes. Le navigateur ne peut pas remonter la chaîne jusqu'à une racine connue : il ne peut pas vérifier l'identité du serveur.

b) L'utilisateur ne fait plus la différence entre cette alerte et celle qu'afficherait une attaque de l'homme du milieu : le jour où un attaquant présentera un faux certificat pour l'intranet, il cliquera aussi sur « Continuer » et lui livrera ses identifiants. On a appris aux utilisateurs à ignorer la seule protection qui les alertait.

c) Installer une autorité de certification interne (rôle AD CS, avec une racine hors ligne et une autorité intermédiaire), délivrer à l'intranet un certificat dont le champ SAN contient intranet.helianthe.lan, et déployer le certificat racine par stratégie de groupe sur tous les postes du domaine. Activer l'inscription automatique pour les certificats des serveurs, et sensibiliser les utilisateurs : une alerte de certificat doit désormais être signalée, jamais ignorée.

Chiffrer les sauvegardes avant leur départ du site, avec l'outil de sauvegarde (restic, BorgBackup, ou l'option de chiffrement du logiciel du marché) en AES-256 : le prestataire et quiconque accède à son stockage ne voient que des données chiffrées. La clé (ou la phrase de passe) est conservée hors du système sauvegardé et hors du stockage du prestataire, en au moins deux exemplaires (coffre de mots de passe de l'équipe, copie scellée au coffre). Pour l'intégrité, on calcule et on conserve à part l'empreinte SHA-256 de chaque sauvegarde (ou l'on s'appuie sur la vérification intégrée de l'outil, comme restic check), et l'on teste la restauration régulièrement, déchiffrement compris.

a) Le trafic entre les sites traverse Internet en clair : un attaquant placé sur le chemin (chez un opérateur, sur un équipement compromis) peut lire les fichiers échangés et les identifiants, et modifier les flux. SMB 2 sans chiffrement expose le contenu des fichiers à toute écoute, y compris sur le réseau local (atteinte à la confidentialité).

b) Relier chaque site au siège par un VPN site à site : IPsec IKEv2 avec authentification par certificats délivrés par l'autorité interne (ou WireGuard), chiffrement AES-GCM. Pour les partages, passer à SMB 3 et imposer le chiffrement (Set-SmbServerConfiguration -EncryptData $true, ou Set-SmbShare -EncryptData $true partage par partage), et désactiver SMB 1.

a) Sans phrase de passe, le voleur qui lit le disque (non chiffré) peut se connecter à tous les serveurs où la clé publique est autorisée. Avec une phrase de passe, il doit d'abord la deviner, hors ligne : une phrase longue lui résiste, une phrase faible tombera. Dans les deux cas, la clé doit être considérée comme compromise.

b) Retirer la clé publique correspondante du fichier ~/.ssh/authorized_keys de tous les serveurs (idéalement, la gestion centralisée des clés ou des certificats SSH permet de le faire en une fois), générer une nouvelle paire pour l'administrateur, contrôler les journaux d'authentification des serveurs (/var/log/auth.log, journalctl -u ssh) depuis le vol, et faire chiffrer les disques des portables d'administration pour l'avenir.

1. (b) la clé publique de Bob : seul Bob, avec sa clé privée, pourra déchiffrer.
2. (c) 64 caractères (256 bits / 4 bits par caractère).
3. (c) GCM, grâce à son étiquette d'authentification.
4. (b) : le sel n'est pas secret ; il rend chaque empreinte unique.
5. (b) : seule une clé privée personnelle permet de prouver l'auteur ; avec un HMAC, la clé est partagée.
6. (b) : la clé privée reste sur le serveur.
7. (a) : les secrets éphémères sont effacés après chaque connexion.
8. (b) : la règle de l'ANSSI fixe 2 048 bits minimum pour un usage jusqu'à fin 2030, et recommande 3 072 bits.
9. (b) : c'est une simple représentation des octets, sans clé.
10. (b) : c'est une mesure recommandée au service d'une obligation de sécurité.
11. (b) : il est encodé en Base64URL, et sa signature HMAC empêche de le modifier.
12. (c) Argon2id (ou bcrypt) : lente, salée, conçue pour cet usage.