Chiffrer et authentifier en une seule construction

Chiffrer et authentifier en une seule construction

Le chiffrement authentifié avec données associées, ou AEAD (Authenticated Encryption with Associated Data), doit être le choix par défaut pour toute nouvelle donnée confidentielle qui circule ou repose hors d’un périmètre de confiance. Le compromis est simple : on gagne une garantie d’intégrité exploitable et un format cohérent, on paie une discipline stricte sur les nonces, les erreurs et les limites de volume. Ce prix est dérisoire face au coût d’un chiffrement malléable.

Explication de la marmotte

Un colis confidentiel doit cacher son contenu, mais aussi permettre de voir s’il a été ouvert, remplacé ou accompagné d’une mauvaise étiquette. Cette technique fabrique un colis fermé avec un sceau difficile à imiter. Elle évite qu’une personne malveillante puisse modifier discrètement ce qui est transporté.

→ Lire l’explication complète de la marmotte

Le chiffrement seul protège contre la lecture, pas contre la modification. Un attaquant actif peut altérer un texte chiffré sans connaître son contenu. Selon le mode utilisé, cela provoque des modifications prévisibles dans le texte déchiffré, révèle des informations via un oracle d’erreur, ou permet de substituer des métadonnées. Une primitive AEAD lie le contenu chiffré, un contexte non chiffré et une étiquette d’authentification. Toute altération doit faire échouer la vérification avant que l’application ne consomme le moindre octet.

Cette règle n’est pas négociable : après un échec d’authentification, ne jamais parser, journaliser, désérialiser ou traiter le texte en clair retourné par une API. Certaines bibliothèques peuvent fournir des octets avant de signaler l’échec. Ces octets sont hostiles, même s’ils ressemblent étrangement à du JSON valide.

Composition : préférer l’AEAD à l’assemblage maison

Les anciens schémas combinent chiffrement et code d’authentification de message, ou MAC (Message Authentication Code). Trois ordres existent : encrypt-and-MAC, MAC-then-encrypt et encrypt-then-MAC. Seul encrypt-then-MAC permet, en général, de vérifier l’intégrité avant de déchiffrer. C’est le principe retenu par de nombreux protocoles modernes, mais l’implémenter correctement suppose de définir sans ambiguïté les clés, les longueurs, les encodages et les erreurs.

Assembler soi-même un chiffrement et un MAC est rarement justifié. Il faut dériver deux clés distinctes, authentifier les longueurs et les métadonnées, vérifier le MAC en temps constant, rejeter avant déchiffrement et éviter les divergences de sérialisation. Une API AEAD standard transporte ces contraintes dans une construction étudiée et testée. Pour comprendre la frontière entre intégrité, signature et authentification d’origine, voir « prouver qu’un message est authentique » (page à venir).

Une AEAD reçoit quatre entrées :

• une clé secrète ;
• un nonce, nombre utilisé une seule fois avec cette clé ;
• le texte en clair à protéger ;
• des données associées, ou AAD (Additional Authenticated Data), visibles mais authentifiées.

Elle produit un texte chiffré et un tag, l’étiquette d’authentification. Le tag doit être transmis intact. Les AAD doivent contenir tout ce qui définit le contexte de sécurité sans devoir être secret : version de format, identifiant de locataire, type d’objet, algorithme attendu, sens du flux, numéro de séquence et date d’expiration si celle-ci participe à la décision.

Authentifier seulement le corps d’un jeton tout en laissant son tenant_id, son type ou sa version hors des AAD ouvre une confusion de contexte. Un message valide dans un protocole peut alors devenir valide dans un autre. La séparation par clé reste préférable quand les domaines sont durablement distincts, mais les AAD constituent la barrière minimale contre la substitution inter-format.

AES-GCM : rapide, excellent, impitoyable avec les nonces

AES-GCM combine AES (Advanced Encryption Standard), un chiffrement par blocs, avec GCM (Galois/Counter Mode). GCM chiffre en mode compteur et calcule l’authentification avec GHASH, une fonction de hachage dans un corps fini. Sur processeur disposant des instructions AES et de multiplication sans retenue, AES-GCM est très rapide. C’est le bon choix pour les services généralistes, les flux réseau et les plateformes où l’accélération matérielle est disponible.

Sa faiblesse est brutale : un nonce ne doit jamais être réutilisé avec la même clé. Réemployer un couple clé, nonce révèle des relations entre textes en clair et fragilise fortement l’authentification GHASH. Ce n’est pas un incident dégradable, c’est une rupture de sécurité. Générer des nonces aléatoires de 96 bits est acceptable sous des bornes d’invocations calculées, mais un compteur persistant est préférable lorsque le volume est connu et maîtrisé.

Un compteur local impose une contrainte d’architecture : il doit survivre aux redémarrages et rester unique entre réplicas. Un déploiement actif/actif ne peut pas utiliser un compteur local sans préfixe unique par émetteur, réservation de plages ou état partagé. Restaurer une sauvegarde qui contient à la fois une clé GCM et un compteur ancien recrée le risque de réutilisation. La sauvegarde doit donc préserver un compteur avancé, ou la restauration doit provoquer une rotation de clé.

GCM accepte théoriquement des nonces de tailles variées, mais 96 bits restent le format opérationnel à imposer. Les chemins non standards ajoutent des calculs et des risques de divergence entre bibliothèques. Les limites de taille et de volume ne sont pas décoratives : le plafond par message, les tentatives de vérification et le nombre total de blocs sous une clé déterminent l’avantage d’un attaquant contre GHASH. Les profils doivent fixer ces bornes avant la mise en production, pas après le premier téraoctet un peu pressé.

Choisir une construction selon la plateforme et le risque de mauvais usage

ChaCha20-Poly1305 associe le chiffrement de flot ChaCha20 et l’authentificateur Poly1305. Il est souvent préférable à AES-GCM sur machine sans accélération AES, en environnement mobile ou dans certains systèmes embarqués. Il exige lui aussi un nonce unique par clé. Changer d’algorithme ne transforme pas un nonce fragile en nonce robuste, malheureusement.

AES-GCM-SIV est à retenir lorsque l’unicité des nonces ne peut pas être garantie avec assez de confiance. Le suffixe SIV signifie Synthetic Initialization Vector. La construction résiste à la réutilisation accidentelle d’un nonce mieux que GCM, mais elle ne rend pas cette réutilisation gratuite : des messages identiques dans un même contexte peuvent devenir reconnaissables, et les limites de volume restent applicables. Le gain est une résistance au mauvais usage, pas une permission de négliger l’état distribué.

AES-SIV offre une protection analogue contre les nonces réutilisés, avec un coût de calcul et un comportement déterministe qui révèle l’égalité de certains messages. Il convient à des données à faible entropie uniquement si cette fuite d’égalité est acceptable. OCB (Offset Codebook Mode) reste performant, mais son historique de brevets et sa disponibilité inégale n’en font pas le choix par défaut d’un service portable.

Ascon-AEAD128, standardisé pour la cryptographie légère, cible les microcontrôleurs et plateformes où mémoire, énergie et instructions disponibles comptent davantage que le débit maximal. Il ne faut pas l’introduire dans un serveur disposant d’AES accéléré par goût de la nouveauté. Le bon algorithme est celui que la plateforme exécute correctement, que les bibliothèques maintiennent et dont les contraintes de nonce sont réellement respectées.

La décision pratique est nette :

• choisir AES-GCM avec nonces uniques et gestion d’état démontrable ;
• choisir ChaCha20-Poly1305 sans accélération AES ;
• choisir AES-GCM-SIV si les nonces risquent d’être réutilisés par restauration, concurrence ou absence d’état fiable ;
• choisir Ascon-AEAD128 sur cible contrainte validée, pas par défaut sur infrastructure classique.

Pour sélectionner les primitives et préparer leur évolution, consulter « choisir, combiner et migrer » (page à venir).

Format de message, tags et exemple d’implémentation

Le format transporté doit préciser la version, l’identifiant de clé, le nonce, le texte chiffré et le tag. L’identifiant de clé n’est pas secret, mais il doit être inclus dans les AAD si sa substitution peut sélectionner une mauvaise clé ou modifier le sens du message. Ne jamais laisser le déchiffreur essayer toutes les clés disponibles : cela crée un coût asymétrique exploitable et masque les défauts de rotation.

Avec la bibliothèque Python cryptography, AESGCM retourne le texte chiffré suivi du tag de 128 bits. L’API rejette par une exception unique toute erreur de nonce, de tag ou d’AAD. La version de bibliothèque doit être maintenue, et la clé doit provenir d’un générateur cryptographiquement sûr ou d’un gestionnaire de clés, jamais d’un mot de passe passé tel quel à l’API.

# Python, bibliothèque cryptography maintenue
from os import urandom
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.exceptions import InvalidTag

key = urandom(32)  # 256 bits, à stocker hors du processus si possible
nonce = urandom(12)  # 96 bits, unique sous cette clé
aad = b"v1|tenant=42|type=invoice|kid=2026-09"
plaintext = b'{"amount":1250,"currency":"EUR"}'

aead = AESGCM(key)
ciphertext_and_tag = aead.encrypt(nonce, plaintext, aad)

try:
    recovered = aead.decrypt(nonce, ciphertext_and_tag, aad)
except InvalidTag:
    # Rejeter le message sans réutiliser aucun octet déchiffré.
    recovered = None

Un tag complet de 128 bits doit rester la norme. Tronquer le tag réduit directement le coût d’une falsification : avec un tag de t bits, chaque tentative indépendante a une probabilité proche de 2^-t de réussir. Les services qui acceptent beaucoup de tentatives, notamment sur réseau, ne peuvent pas compenser un tag court par de l’optimisme. Si un protocole impose une troncature, il doit imposer une limite stricte et persistante de vérifications par clé.

Ce que l’AEAD ne garantit pas et comment l’exploiter

Une AEAD ne masque ni la taille des messages, ni leur heure d’émission, ni leur destinataire réseau. Elle n’empêche pas le rejeu : un paquet valide peut être renvoyé tel quel. Pour empêcher ce rejeu, inclure un numéro de séquence dans les AAD et maintenir côté récepteur une fenêtre anti-rejeu persistante ou suffisamment durable. Un horodatage seul est insuffisant sans contrôle de fraîcheur et sans horloge fiable.

Elle ne prouve pas non plus quelle personne a émis le message. Tous les détenteurs de la même clé peuvent produire un tag valide. Pour une preuve vérifiable par un tiers, il faut une signature numérique, traitée dans signer pour une preuve publique. L’AEAD protège le transport et le stockage, pas la mémoire d’un processus compromis, ni les données affichées à un utilisateur autorisé.

L’exploitation exige un inventaire des clés, des algorithmes, des identifiants de clé et des limites de volume. Chaque clé doit avoir un domaine précis : ne pas utiliser la même clé pour AES-GCM, GCM-SIV et un MAC séparé. La rotation doit produire une nouvelle clé, accepter temporairement les anciennes en lecture selon une fenêtre définie, puis les retirer. Les messages doivent embarquer un identifiant de clé authentifié afin de sélectionner une clé sans ambiguïté.

La supervision doit compter les échecs d’authentification, les nonces rejetés, les versions de format et la consommation de volume par clé. Un pic d’échecs peut révéler une corruption, un défaut de déploiement ou une attaque, mais les journaux ne doivent jamais contenir le texte en clair, la clé ou un tag complet associé à une donnée sensible. Les procédures de sauvegarde et reprise doivent tester explicitement le maintien de l’unicité des nonces. Une restauration qui remet un compteur en arrière n’est pas une reprise, c’est une machine à fabriquer des collisions.

FAQ

Faut-il chiffrer aussi les données associées ?

Non. Les données associées restent visibles, mais toute modification est détectée. Les placer dans les AAD est précisément utile pour les en-têtes, identifiants, versions et compteurs qui doivent être routables sans pouvoir être remplacés.

Un nonce doit-il rester secret ?

Non. Le nonce est généralement transmis avec le message. Son exigence est l’unicité sous une clé donnée, pas le secret. Le confondre avec une clé conduit souvent à des formats inutilement opaques et à des erreurs de rotation.

Peut-on réutiliser une clé après un échec de déchiffrement ?

Oui, si la clé et les nonces restent valides. Un échec de tag ne compromet pas automatiquement la clé. En revanche, un nonce GCM réutilisé impose de considérer la clé comme compromise pour ce domaine et de la remplacer.

🐝 Ce qui arrive si on s’en passe

Sans construction authentifiée, le déchiffrement devient une source d’information : le comportement de l’application face à un texte chiffré modifié (erreur de remplissage, message de parsing, écart de temps de réponse) répond à l’attaquant à sa place, comme le montre la brèche « la question qui rend le module bavard ». Une altération sur un stockage ou en transit passe alors pour une donnée légitime, et rien ne permet ensuite de distinguer une corruption de disque d’une falsification volontaire : l’analyse après incident perd son point d’ancrage, puisque aucun tag ne date ni ne délimite les objets restés intacts. La supervision perd également son signal le plus simple, le compteur d’échecs de vérification, et les métadonnées de routage laissées hors authentification deviennent modifiables sans trace exploitable.

🦫 Explication de la marmotte 🍫

Cette technique protège un message avec une clé secrète. Le programme prend le message, une valeur qui doit être différente à chaque utilisation de la clé, et des informations visibles qui décrivent le message. Ces informations peuvent indiquer sa version, son type, son destinataire ou son numéro dans une suite.

Le programme produit ensuite deux éléments : un contenu rendu illisible et une courte valeur de contrôle. Le destinataire possède la même clé. Il reprend les informations visibles, la valeur différente et le contenu reçu. Avant de donner le message déchiffré au reste du programme, il vérifie la valeur de contrôle. Si un seul élément a changé, y compris une information visible, la vérification échoue et le message doit être rejeté.

La valeur différente doit être gérée avec rigueur. Si elle est réutilisée avec certaines méthodes de protection, deux messages peuvent révéler des informations et un attaquant peut parfois fabriquer un faux message. Des compteurs conservés après redémarrage, ou des valeurs aléatoires assez longues avec des limites calculées, évitent ce problème.

Cette protection ne bloque pas la copie d’un message valide. Pour cela, le destinataire doit mémoriser les numéros déjà reçus ou refuser les messages trop anciens. Elle ne protège pas non plus une clé volée, un programme infecté ou les informations qu’une personne autorisée a déjà lues.

À lire aussi

• Choisir, combiner et migrer les algorithmes symétriquesRegrouper les décisions pratiques: choix d’algorithme, combinaison, surchiffrement, compatibilité matérielle et retrait des options faibles.
• 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.
• Chiffrement par flot : état, compteurs et réutilisation interditePrésenter les chiffrements par flot et les générateurs de suites comme une famille utile mais très sensible à la réutilisation de flux, d’état et de nonce.
• Parler le langage des clés, des messages et des attaquantsDonner un vocabulaire stable pour lire tout le reste du site et éviter les confusions récurrentes entre clé, nonce, sel, tag, certificat et secret.

Pages voisines

La citent

• Chiffrement par flot : état, compteurs et réutilisation interdite
• Chiffrer par blocs : de l’héritage DES à AES
• Transformer un bloc en chiffrement de message
• Du chiffre manuel au chiffrement moderne
• Exploiter les clés : rotation, KMS et secrets
• Parler le langage des clés, des messages et des attaquants
• Protéger une information en environnement hostile
• Prouver qu’un message vient du bon secret
• Formats, bibliothèques et API : rendre la crypto utilisable

Chiffrer et authentifier en une seule construction

Elle cite

• ⇄Lien dans les deux sens :Exploiter un padding oracle CBC avec PKCS#7
• Créer, vérifier et utiliser les clés dès le départ
• Signer numériquement : preuve publique, politiques de vérification

⇄ : les deux pages se citent l’une l’autre.