Lier le chiffré à son contexte

Au chapitre précédent, tu as vu que le nonce doit être unique pour que les garanties de l’AEAD tiennent. Mais il existe un autre vecteur d’attaque, plus subtil : un chiffré peut être parfaitement authentique, avec un tag valide et un nonce unique, et pourtant servir d’arme entre les mains d’un adversaire qui le rejoue dans le mauvais contexte. Le problème n’est plus l’algorithme. C’est l’absence de lien entre le chiffré et la situation dans laquelle il doit être utilisé.

Imagine un système de mise à jour logicielle. Un paquet de mise à jour est chiffré et authentifié pour un composant A, version 2. Un adversaire intercepte ce paquet et le rejoue comme mise à jour du composant B. Le tag est valide. Le nonce est unique. Personne n’a touché un seul bit. Pourtant, un code prévu pour un composant s’exécute dans un autre.

À la fin de ce chapitre, tu sauras définir les données associées et leur rôle dans la liaison d’un chiffré à son contexte, expliquer la séparation de domaines et pourquoi un même chiffré ne doit pas traverser plusieurs rôles, comprendre pourquoi un en-tête transmis en clair doit être couvert par le tag, et décrire comment un format versionné permet la migration cryptographique sans casser les données existantes.

Les données associées (AAD)

La notation complète d’un seal AEAD est $C = \mathrm{Enc}_k(N, A, P)$, où $A$ désigne les données associées Données associées (AAD) Données authentifiées par un algorithme AEAD mais non chiffrées, typiquement des métadonnées comme un en-tête, un identifiant ou un contexte d'utilisation. Elles lient le chiffré à son contexte : toute discordance entre les données associées attendues et celles fournies au déchiffrement invalide le tag et fait échouer l'opération. (Associated Data, parfois abrégées AAD). Ce paramètre est mentionné dans le module 1 ; ce chapitre l’examine en détail.

Les données associées sont des informations qui voyagent en clair avec le message chiffré mais qui sont liées au chiffré par le tag d’authentification. Elles ne font pas partie du chiffré : quiconque observe la transmission peut les lire. En revanche, elles font partie du calcul du tag : si les données associées diffèrent entre le seal et le open, la vérification échoue. L’open retourne une erreur, sans déchiffrement, sans information supplémentaire.

L’intuition centrale : l’AAD lie un chiffré à son contexte d’usage.

L’AAD peut contenir un identifiant d’utilisateur, un identifiant de session, un numéro de version, un identifiant de destination, un horodatage de création, ou toute combinaison de ces éléments. La contrainte est la suivante : la valeur utilisée lors du seal doit être identique à la valeur présentée lors du open. Toute divergence invalide le tag.

Reprenons l’exemple du paquet de mise à jour. Si le seal inclut en AAD l’identifiant du composant cible et la version attendue, le open échoue dès que le paquet est présenté à un autre composant ou pour une autre version. Le chiffré ne peut pas être rejoué hors de son contexte déclaré, même par quelqu’un qui ne connaît pas la clé.

Séparation de domaines

La séparation de domaines Séparation de domaines Technique consistant à dériver des clés ou des contextes distincts pour chaque rôle ou usage, de sorte qu'un chiffré valide dans un domaine ne puisse pas être rejoué dans un autre. Elle s'implémente typiquement via des données associées spécifiques au rôle, des préfixes de dérivation de clé ou des octets de version. Elle est essentielle pour prévenir les attaques par confusion de contexte. (domain separation) est le principe selon lequel une clé, ou une valeur cryptographique, ne doit servir qu’à un seul usage bien défini. Deux opérations différentes dans un même système ne doivent pas partager la même clé, même si elles utilisent le même algorithme.

Pourquoi ? Parce qu’un chiffré produit pour un usage peut être rejoué dans un autre si rien ne distingue les deux contextes cryptographiquement. Voici deux cas représentatifs.

Tokens de session et tokens d’API. Un service génère des tokens chiffrés avec AES-GCM. Si la même clé sert à chiffrer les tokens de session et les tokens d’API longue durée, un adversaire qui obtient un token d’API peut essayer de le présenter comme token de session. Le tag est valide, le nonce est unique. Sans séparation de domaines, le système n’a aucun moyen de distinguer les deux.

Chiffrement pour l’émetteur et pour le destinataire. Dans un protocole de messagerie, les messages chiffrés par Alice vers Bob et par Bob vers Alice ne doivent pas partager la même clé directionnelle. Sinon, un message d’Alice vers Bob peut être rejoué comme s’il venait de Bob vers Alice.

La séparation s’implémente de deux façons, souvent combinées.

• Clé par usage : dériver une clé distincte pour chaque rôle depuis une clé maîtresse, avec une étiquette explicite (par exemple une fonction de dérivation de clé avec un contexte “session-token” pour l’une et “api-token” pour l’autre).
• Contexte dans l’AAD : inclure systématiquement dans les données associées un identifiant de domaine (une chaîne comme "purpose=session" ou "direction=client-to-server"). Deux chiffrés produits dans des domaines différents auront des AAD différentes, donc des tags différents, même avec la même clé.

Les deux approches se renforcent mutuellement. La clé par usage interdit le replay au niveau des matériaux cryptographiques. Le contexte dans l’AAD interdit le replay même si deux usages partagent accidentellement une clé.

Le principe à retenir : un objet chiffré doit déclarer explicitement son domaine d’usage, et le système doit rendre impossible sa présentation dans un autre domaine.

En-têtes en clair, mais authentifiés

Dans de nombreux protocoles, un en-tête voyage en clair avant le chiffré. Cet en-tête peut contenir un identifiant de version, un identifiant d’algorithme, un identifiant de destinataire, une longueur de message, ou une combinaison de ces champs. Il doit être lisible avant le déchiffrement, notamment pour aiguiller la requête vers la bonne clé ou le bon algorithme.

Le problème est le suivant : si cet en-tête n’est pas couvert par le tag, il est malléable Malléabilité Propriété d'un schéma de chiffrement où une modification du chiffré produit un changement prédicible et exploitable du clair correspondant. Les modes de chiffrement sans authentification (flux, CTR, CBC sans MAC) sont malléables. L'utilisation d'un algorithme AEAD supprime cette propriété en faisant échouer tout déchiffrement d'un chiffré altéré. . Un adversaire peut le modifier sans invalider l’authentification. Les conséquences sont concrètes.

• Redirection de destinataire. Si l’identifiant de destinataire dans l’en-tête n’est pas authentifié, un adversaire peut remplacer l’identifiant de Bob par celui d’Alice. Le message est déchiffré par Alice, qui reçoit un contenu prévu pour Bob. Le tag est valide, car il ne couvre pas l’en-tête.
• Rétrogradation d’algorithme. Si l’identifiant d’algorithme dans l’en-tête n’est pas authentifié, un adversaire peut le remplacer par un algorithme plus faible. Le destinataire tente de déchiffrer avec cet algorithme, en croyant que c’est ce que l’émetteur a choisi.
• Confusion de version. Si le numéro de version n’est pas couvert par le tag, un adversaire peut faire passer un message d’une version pour une autre, en espérant que le parseur de l’autre version traite les octets différemment.

La solution est directe : placer l’en-tête entier dans l’AAD. L’en-tête reste lisible en clair (l’AAD n’est pas chiffrée), mais toute modification invalide le tag. L’émetteur inclut l’en-tête dans le seal. Le destinataire reconstruit l’en-tête depuis les octets reçus et le passe dans le open. Si un seul champ a été modifié en transit, le open échoue.

C’est le même mécanisme que dans le module 1 : le tag d’authentification couvre tout ce qui doit être protégé contre la modification, qu’il soit chiffré ou non.

Formats versionnés et agilité cryptographique

Un système déployé en production ne peut pas changer d’algorithme en un seul redémarrage. Des données existent, chiffrées avec l’algorithme actuel. Des clients anciens doivent continuer à fonctionner. La migration doit être progressive.

La agilité cryptographique Crypto-agilité Capacité d'un format ou d'un protocole à migrer vers de nouveaux primitifs cryptographiques sans casser les données existantes. Elle s'implémente typiquement par un octet de version en tête du chiffré, permettant de décoder les anciens enregistrements et de chiffrer les nouveaux avec l'algorithme courant. Elle est essentielle pour préparer une migration post-quantique. est la capacité d’un système à migrer d’un algorithme à un autre sans réécriture de l’ensemble du code et sans invalider les données existantes. Elle repose sur un format de message versionné.

Le principe est simple : le premier octet (ou les premiers octets) du message encodé indiquent quelle primitive a été utilisée pour le chiffrer. Le déchiffreur lit ce champ en premier, choisit le chemin de déchiffrement approprié, puis procède.

[version : 1 octet | nonce : N octets | chiffré + tag : M octets]

Une version 1 signifie AES-256-GCM. Une version 2 signifie XChaCha20-Poly1305. Une version 3 pourrait, demain, signifier un algorithme résistant aux ordinateurs quantiques. Aucun des deux formats n’est incompatible avec l’autre : les données chiffrées en version 1 restent déchiffrables tant que la clé de version 1 est conservée.

Ce mécanisme est déjà présent dans des protocoles courants. TLS encode l’identifiant de suite de chiffrement dans le handshake. Les formats de clé GPG incluent un octet d’algorithme. Les formats JWT incluent un champ alg dans l’en-tête.

Mais il introduit une contrainte critique : l’octet de version doit lui-même être couvert par le tag. Sinon, un adversaire peut modifier la version pour forcer le déchiffreur à utiliser un algorithme plus faible ou une clé différente. L’octet de version est en clair (pour que le déchiffreur sache quoi faire), mais il doit figurer dans l’AAD du seal et du open.

Structure d’un message authentifié

La structure ci-dessus illustre le principe général. L’en-tête est lisible sans clé, ce qui permet au destinataire de sélectionner la bonne clé et le bon algorithme avant de tenter le déchiffrement. Mais l’en-tête est cryptographiquement lié au chiffré via le tag : il est impossible de modifier la version, le nonce ou l’identifiant de destinataire sans invalider l’authentification.

Le principe de liaison

Tout ce qui précède converge vers un seul principe :

Un chiffré authentique mais hors de son contexte reste une faille. Le contexte fait partie du message.

Ce principe a des conséquences pratiques immédiates.

• Chaque chiffré doit déclarer explicitement pour qui il est, pour quel usage, dans quel domaine, avec quelle version.
• Ces métadonnées ne doivent pas seulement accompagner le chiffré : elles doivent être liées à lui par le tag, de sorte qu’un replay dans le mauvais contexte soit détecté cryptographiquement, pas seulement par une vérification applicative.
• La vérification applicative (vérifier l’identifiant dans la base de données, valider l’expiration d’un token) reste nécessaire, mais elle ne remplace pas la liaison cryptographique. Les deux couches sont complémentaires.

Quiz

Quiz

1. 1. Qu'est-ce que les données associées (AAD) dans un schéma AEAD ?

   • Des données chiffrées en parallèle du texte clair, pour une protection renforcée.
   • Des données transmises en clair, liées au chiffré par le tag, dont la modification invalide le open.
   • Une clé secondaire permettant de vérifier l'identité de l'émetteur.
   • Un sel aléatoire ajouté au texte clair avant le chiffrement.
   Vérifier

2. 2. Un service chiffre des tokens de session et des tokens d'API avec la même clé AES-GCM, sans séparation de domaines. Quel risque cela crée-t-il ?

   • Les deux types de tokens peuvent être déchiffrés par n'importe qui connaissant l'un des deux.
   • Un token d'API valide peut être rejoué comme token de session, car le tag est valide dans les deux contextes.
   • La même clé pour deux usages expose la clé via une attaque d'anniversaire.
   • Les tags produits pour les deux types deviennent identiques, ce qui permet la forge.
   Vérifier

3. 3. Un en-tête contenant l'identifiant de destinataire voyage en clair avant le chiffré, mais n'est pas inclus dans l'AAD. Que peut faire un adversaire ?

   • Rien : le tag couvre le chiffré, donc l'en-tête ne peut pas être exploité.
   • Modifier l'identifiant de destinataire sans invalider le tag, redirigeant le message vers un autre destinataire.
   • Déchiffrer le message en connaissant seulement l'identifiant de destinataire.
   • Forger un tag valide pour un message de son choix.
   Vérifier

4. 4. Pourquoi l'octet de version dans un format de message versionné doit-il être inclus dans l'AAD ?

   • Pour que le destinataire puisse trouver la bonne clé en consultant un registre externe.
   • Pour que la version figure dans le chiffré et soit invisible aux observateurs.
   • Pour que toute modification de la version invalide le tag, empêchant une rétrogradation forcée vers un algorithme plus faible.
   • Parce que le schéma AEAD exige que toutes les métadonnées soient dans l'AAD.
   Vérifier

Ce qu’il faut retenir

• Les données associées Données associées (AAD) Données authentifiées par un algorithme AEAD mais non chiffrées, typiquement des métadonnées comme un en-tête, un identifiant ou un contexte d'utilisation. Elles lient le chiffré à son contexte : toute discordance entre les données associées attendues et celles fournies au déchiffrement invalide le tag et fait échouer l'opération. sont transmises en clair mais couvertes par le tag d’authentification. Leur modification invalide le open. Elles lient le chiffré à son contexte d’usage.
• Une AAD vide est cryptographiquement valide, mais signifie que le chiffré n’est lié à aucun contexte et peut être rejoué librement.
• La séparation de domaines Séparation de domaines Technique consistant à dériver des clés ou des contextes distincts pour chaque rôle ou usage, de sorte qu'un chiffré valide dans un domaine ne puisse pas être rejoué dans un autre. Elle s'implémente typiquement via des données associées spécifiques au rôle, des préfixes de dérivation de clé ou des octets de version. Elle est essentielle pour prévenir les attaques par confusion de contexte. consiste à dériver des clés distinctes par usage ou à inclure un identifiant de domaine dans l’AAD, pour qu’un chiffré produit dans un domaine ne soit pas valide dans un autre.
• Tout champ d’en-tête transmis en clair doit figurer dans l’AAD : version, algorithme, identifiant de destinataire, direction du message. Sans cela, l’en-tête est malléable Malléabilité Propriété d'un schéma de chiffrement où une modification du chiffré produit un changement prédicible et exploitable du clair correspondant. Les modes de chiffrement sans authentification (flux, CTR, CBC sans MAC) sont malléables. L'utilisation d'un algorithme AEAD supprime cette propriété en faisant échouer tout déchiffrement d'un chiffré altéré. sans détection.
• Un format versionné permet la migration de primitives Crypto-agilité Capacité d'un format ou d'un protocole à migrer vers de nouveaux primitifs cryptographiques sans casser les données existantes. Elle s'implémente typiquement par un octet de version en tête du chiffré, permettant de décoder les anciens enregistrements et de chiffrer les nouveaux avec l'algorithme courant. Elle est essentielle pour préparer une migration post-quantique. sans invalider les données existantes. L’octet de version doit lui-même être couvert par le tag.
• Un chiffré authentique mais hors de son contexte reste une faille. Le contexte fait partie du message.