Parler le langage des clés, des messages et des attaquants
- Accueil
- Cryptographie
- Parler le langage des clés, des messages et des attaquants
Parcours « Débuter en cybersécurité » — étape 05/12
04Protéger une information en environnement hostile06Comprendre TLS : mécanismes, garanties et limites
Parler le langage des clés, des messages et des attaquants
Section intitulée « Parler le langage des clés, des messages et des attaquants »La cryptographie a un vocabulaire court mais exigeant : une douzaine de mots suffisent pour lire la plupart des documentations, à condition de ne pas les confondre. Un nonce n’est pas un IV, un sel n’est pas un secret, une clé publique n’est pas un mot de passe, et un tag valide ne dit rien de la session dans laquelle le message a été envoyé. Ce chapitre fixe ces mots, présente les figures d’attaquants que le reste du site convoque, décrit les modèles d’attaque classiques et montre comment passer du vocabulaire à un cahier des charges vérifiable.
Avant de jouer aux échecs, il faut savoir distinguer le fou de la tour, sinon chaque conseil devient incompréhensible. La cryptographie a elle aussi ses pièces et ses joueurs, dont certains trichent. Ce chapitre sert de lexique commun : une fois les mots bien rangés, le reste du site se lit sans quiproquo ni fausse évidence.
→ Lire l’explication complète de la marmotte
Les objets manipulés par une primitive
Section intitulée « Les objets manipulés par une primitive »Une primitive cryptographique (un chiffrement, une signature, un code d’authentification) prend des entrées et produit des sorties. Les nommer correctement, c’est déjà savoir lesquelles protéger.
Le message clair (plaintext) est la donnée à protéger ; le message chiffré (ciphertext) est ce qui circule ou se stocke. La clé est le seul élément secret par construction : selon le principe énoncé par Auguste Kerckhoffs en 1883, la sécurité doit reposer sur le secret de la clé et non sur celui de l’algorithme, qu’il faut supposer connu de l’adversaire.
Autour de ces trois objets gravitent des paramètres publics. Le nonce (number used once) est une valeur qui ne doit jamais être réutilisée avec la même clé ; elle peut être un compteur, une valeur aléatoire, ou une combinaison des deux, et elle n’a pas besoin d’être secrète. L’IV (Initialization Vector, vecteur d’initialisation) est la valeur de départ d’un mode de chiffrement ; selon le mode, ses exigences diffèrent. En mode CBC (Cipher Block Chaining), l’IV doit être imprévisible : TLS 1.0 utilisait comme IV le dernier bloc chiffré du message précédent, donc connu de l’attaquant, et l’attaque BEAST l’a exploité en 2011. En mode compteur ou en GCM (Galois/Counter Mode), l’exigence est l’unicité, pas l’imprévisibilité : un compteur incrémenté convient parfaitement. Employer IV et nonce comme synonymes universels conduit donc à appliquer la mauvaise règle au mauvais mode.
Le sel est une valeur publique, unique par entrée, ajoutée à un mot de passe avant hachage : il empêche les tables précalculées et rend les empreintes de deux mots de passe identiques différentes. Il est stocké en clair à côté de l’empreinte ; supposer qu’un sel doit rester secret mène à le cacher avec un soin qui serait mieux employé ailleurs. Le pepper est au contraire un secret commun à toute la base, conservé hors de celle-ci (fichier de configuration protégé, module matériel) : si la base fuit sans le pepper, les empreintes sont inexploitables hors ligne. La page Transformer mots de passe et secrets applicatifs en clés les met en œuvre.
Le tag est la courte valeur d’authentification produite par un MAC (Message Authentication Code) ou un chiffrement authentifié : 128 bits en AES-GCM. Il prouve que le message et les données associées n’ont pas été modifiés par qui ne possède pas la clé. Les données associées, ou AAD (Additional Authenticated Data), sont authentifiées mais non chiffrées : un en-tête, un identifiant de destinataire, un numéro de version.
Enfin, une primitive produit une erreur. Un déchiffrement authentifié qui échoue ne renvoie pas un texte « un peu abîmé » : il renvoie un refus, et ce refus doit interrompre le traitement. Ignorer l’erreur d’une bibliothèque, ou pire, utiliser quand même le texte partiellement déchiffré, annule toute la garantie d’intégrité.
Pourquoi un nonce n’est pas une clé. Une clé est secrète et peut servir des milliards de fois ; un nonce est public et ne sert qu’une fois par clé. En AES-GCM, réutiliser un nonce avec la même clé est catastrophique : le XOR (ou exclusif) des deux messages chiffrés révèle le XOR des deux messages clairs, et l’attaquant peut calculer de quoi forger des tags pour des messages de son choix. La page Chiffrement par flot : état, compteurs et réutilisation interdite détaille ce mécanisme. Un compteur de 96 bits incrémenté évite toute répétition tant que l’état est sauvegardé ; un nonce aléatoire de 96 bits ne devient risqué qu’après de l’ordre de 2³² messages sous une même clé, limite fixée par le NIST (National Institute of Standards and Technology) pour garder la probabilité de collision négligeable.
Le certificat, enfin, n’est pas une clé : c’est un document signé par une autorité qui lie une clé publique à une identité. La clé publique n’est pas un secret, et une clé privée n’est pas un mot de passe : la première est un nombre aléatoire de grande taille, le second une chaîne mémorisée par un humain, d’entropie faible, qu’il faut transformer avant d’en tirer une clé.
Atelier : annoter une API de chiffrement authentifié
Section intitulée « Atelier : annoter une API de chiffrement authentifié »Une API AEAD (Authenticated Encryption with Associated Data) concentre presque tout ce vocabulaire. Avec la bibliothèque Python cryptography :
import osfrom cryptography.hazmat.primitives.ciphers.aead import AESGCM
key = AESGCM.generate_key(bit_length=256) # clé : secrète, 32 octetsaead = AESGCM(key)nonce = os.urandom(12) # nonce : public, 96 bits, jamais réutilisé avec cette cléaad = b"commande:v2;client=42" # données associées : authentifiées, non chiffréesplaintext = b"virement 100 EUR vers compte 7" # message clair
ciphertext = aead.encrypt(nonce, plaintext, aad)# ciphertext = message chiffré suivi du tag de 16 octets
# Au déchiffrement, il faut le même nonce et les mêmes AAD.# En cas de modification, la bibliothèque lève InvalidTag :# l'exception doit stopper le traitement, pas être attrapée et ignorée.recovered = aead.decrypt(nonce, ciphertext, aad)Le nonce voyage en clair avec le message chiffré ; seule la clé reste secrète. Les AAD ne sont pas transmises dans le chiffré : le destinataire doit les reconstituer de son côté, et c’est précisément ce qui lie le message à son contexte. La page Chiffrer et authentifier en une seule construction approfondit ces constructions.
Les figures d’attaquants
Section intitulée « Les figures d’attaquants »La littérature met en scène des personnages : Alice et Bob communiquent, Eve (de l’anglais eavesdropper, l’oreille indiscrète) écoute, Mallory (de malicious) modifie, Trent (de trusted) joue le tiers de confiance. Derrière ces prénoms se cachent des capacités précises, et c’est elles qu’il faut retenir.
L’observateur réseau est un adversaire passif : il lit tout ce qui circule mais ne modifie rien. L’intermédiaire actif peut en outre bloquer, modifier, rejouer, réordonner et injecter des messages ; c’est l’adversaire de référence des protocoles, formalisé en 1983 par Dolev et Yao. Le serveur curieux (honest-but-curious) exécute fidèlement le protocole mais lit et retient tout ce qui passe par lui ; c’est l’adversaire du chiffrement de bout en bout. Le client compromis est un poste où l’attaquant a pris pied : il voit les messages en clair et peut utiliser les clés qui y résident. L’administrateur trop privilégié n’est pas forcément malveillant, mais il dispose d’accès qui dépassent sa fonction, et ces accès deviennent ceux de quiconque vole son compte.
Un protocole validé contre un observateur passif n’est pas validé contre un intermédiaire actif. Un chiffrement sans authentification peut résister parfaitement à Eve et se faire retourner par Mallory, qui modifie des bits du message chiffré pour modifier de façon prévisible le message clair.
Les modèles d’attaque
Section intitulée « Les modèles d’attaque »Le second axe décrit ce que l’attaquant peut obtenir du système.
| Modèle | Ce que l’attaquant possède | Exemple concret |
|---|---|---|
| Texte chiffré seul | Des messages chiffrés | Écoute d’un réseau Wi-Fi chiffré |
| Texte clair connu | Des paires clair et chiffré | En-têtes de fichiers ou formules de politesse prévisibles |
| Texte clair choisi | Il fait chiffrer les messages de son choix | Un script injecté dans une page fait envoyer des requêtes choisies sur une connexion chiffrée |
| Texte chiffré choisi | Il fait déchiffrer les messages de son choix et observe le résultat | Un serveur qui répond différemment selon la validité du remplissage |
Le dernier modèle n’a rien de théorique : c’est celui de l’attaque de Bleichenbacher et des oracles de remplissage. Les notions de sécurité modernes en découlent : IND-CPA (indistinguabilité sous attaque à clairs choisis) et IND-CCA2 (indistinguabilité sous attaque à chiffrés choisis adaptative). Un chiffrement moderne doit viser la seconde.
Deux attaques échappent à ce tableau parce qu’elles ne cassent aucune primitive. Le rejeu renvoie un message authentique déjà vu : son tag reste valide, et seul un compteur, un nonce vérifié ou un horodatage permet de le refuser. La confusion de contexte fait accepter un message authentique dans un autre contexte que celui prévu : un jeton émis pour le service A présenté au service B, une réponse destinée à Alice renvoyée à Bob. L’authenticité d’un message n’est pas l’identité d’une session : le tag prouve que le message vient de quelqu’un qui détient la clé, pas qu’il appartient à l’échange en cours. Les AAD servent précisément à lier le message à son contexte.
Du vocabulaire au cahier des charges
Section intitulée « Du vocabulaire au cahier des charges »Le vocabulaire sert à écrire un modèle de menace, c’est-à-dire un document qui dit ce qu’il faut protéger, contre qui, sous quelles hypothèses, et ce qui reste hors périmètre. Prenons un formulaire de connexion web.
Objectif mesurable : un attaquant qui observe ou modifie le trafic ne peut ni obtenir le mot de passe, ni ouvrir une session au nom de l’utilisateur ; un attaquant qui vole la base des comptes ne peut pas retrouver un mot de passe de 12 caractères aléatoires en moins de plusieurs années de calcul. « Le formulaire est sécurisé » n’est pas un objectif ; il ne peut ni être atteint, ni être démenti.
Hypothèses : le canal est protégé par TLS (Transport Layer Security) avec un certificat valide ; le serveur n’est pas compromis au moment de la saisie ; les empreintes sont calculées avec Argon2id, un sel par compte et un pepper hors base ; les tentatives sont limitées en fréquence.
Hors périmètre : le poste de l’utilisateur infecté par un enregistreur de frappe, la réutilisation du même mot de passe sur un autre site, l’hameçonnage qui imite le formulaire. Les déclarer hors périmètre ne les fait pas disparaître ; cela indique qu’ils relèvent d’autres mesures, comme l’authentification résistante à l’hameçonnage.
Données associées : le jeton de session émis après connexion est lié à l’identifiant de l’utilisateur, à sa date d’expiration et au domaine émetteur, pour qu’un jeton ne puisse pas être rejoué ailleurs.
Atelier : relire un protocole jouet
Section intitulée « Atelier : relire un protocole jouet »Soit le protocole suivant, conçu un vendredi après-midi : « Le client envoie au serveur AES-GCM(K, nonce, "ouvrir la porte"). Le serveur déchiffre et, si le tag est valide, ouvre la porte. »
Les hypothèses implicites sautent aux yeux une fois nommées. La clé K est partagée, mais rien ne dit comment, ni combien de clients la connaissent. Le nonce est-il unique ? Si chaque client choisit le sien aléatoirement avec la même clé, les collisions deviennent possibles à grande échelle. Surtout, un observateur passif qui enregistre le message peut le rejouer à volonté : le tag reste valide, la porte s’ouvre, et la cryptographie a fonctionné exactement comme prévu. Rien ne lie le message à une porte précise : le même message ouvre toutes les portes qui partagent la clé. La correction passe par un défi aléatoire envoyé par le serveur, l’identifiant de la porte dans les AAD, et une clé par client. Le protocole jouet n’était pas faux mathématiquement ; il répondait à une question que personne n’avait posée.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans vocabulaire partagé, les erreurs passent la relecture parce qu’elles ont l’air correctes : un nonce traité comme un simple IV aléatoire laisse les répétitions possibles, et un sel protégé comme un secret détourne les efforts de ce qui l’est vraiment, pendant qu’une clé publique prise pour un secret donne une confiance que rien ne justifie. Sans modèle de menace écrit, les hypothèses restent implicites : un protocole validé contre un observateur passif part en production face à un intermédiaire actif, et le rejeu n’est jamais testé puisque personne ne l’a nommé. L’audit perd enfin son critère d’arrêt : faute de périmètre déclaré, aucune conclusion ne peut dire ce qui a été vérifié, seulement ce qui n’a pas encore cassé.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Une opération de chiffrement prend un message lisible, appelé message clair, et une clé, c’est-à-dire un nombre secret, puis produit un message chiffré illisible sans cette clé. Certains paramètres n’ont pas besoin d’être secrets : un nonce est une valeur qui ne doit servir qu’une seule fois avec une même clé, et le vecteur d’initialisation joue un rôle voisin au démarrage du chiffrement. Le sel est une valeur publique et unique ajoutée à un mot de passe avant sa transformation, alors que le pepper est une valeur secrète commune, conservée ailleurs que la base. Le tag est une courte empreinte calculée avec la clé, qui permet de vérifier qu’un message n’a pas été modifié. Pour juger une protection, on décrit ensuite l’adversaire : un attaquant passif se contente d’observer le réseau, un attaquant actif modifie, bloque ou rejoue les messages, un serveur curieux lit ce qu’il reçoit, un administrateur trop privilégié accède à ce qu’il ne devrait pas voir. On précise aussi ce que l’attaquant peut obtenir : seulement des messages chiffrés, des paires de messages clairs et chiffrés, ou la possibilité de faire chiffrer ou déchiffrer les messages de son choix. Le modèle de menace rassemble ces éléments : ce qu’il faut protéger, contre qui, sous quelles hypothèses, et ce qui reste hors périmètre. Sans lui, une construction solide contre un observateur peut céder face à un intermédiaire actif.
À lire aussi
- Du chiffre manuel au chiffrement moderneUtiliser les systèmes classiques comme support pédagogique, puis montrer pourquoi les constructions modernes exigent modèles, clés, modes et authentification.
- Transformer un bloc en chiffrement de messageExpliquer les modes opératoires, leurs fuites et leurs exigences de paramètres, puis orienter vers les modes authentifiés pour les usages modernes.
- Protéger une information en environnement hostilePoser les quatre garanties cryptographiques de base, distinguer primitive et système, et délimiter ce que la cryptographie ne répare jamais.
- Lire une garantie sans la surinterpréterDonner les outils pour comprendre une preuve de sécurité, une hypothèse de dureté et un modèle d’attaque, tout en rappelant leurs limites pratiques.
Pages voisines
La citent
- Lire une garantie sans la surinterpréter
- Produire de l’aléa utilisable en cryptographie
- Héritage, politique et limites de la cryptographie
Parler le langage des clés, des messages et des attaquants
Elle cite
- Chiffrement par flot : état, compteurs et réutilisation interdite
- Chiffrer et authentifier en une seule construction
- Transformer mots de passe et secrets applicatifs en clés
- Chiffrement bout en bout pour collaboration multi-utilisateurs
- Comment bloquer un webhook forgé sans signature vérifiée
- L'attaque de Bleichenbacher : un oracle de padding contre RSA PKCS#1 v1.5
- Vérifier un protocole cryptographique avec Tamarin ou ProVerif
