Chiffrement authentifié : AES-GCM et ChaCha20-Poly1305

Authenticated Encryption (AE) résout un problème fondamental : le chiffrement traditionnel assure uniquement la confidentialité — il garde les données secrètes —, mais ne vérifie pas si le texte chiffré a été modifié. Un attaquant pourrait inverser des bits du texte chiffré et le destinataire déchiffrerait des données incohérentes sans savoir qu'elles ont été modifiées. Authenticated Encryption with Associated Data (AEAD) ajoute simultanément une garantie d'intégrité et d'authenticité, en produisant à la fois un texte chiffré et une balise d'authentification qui détecte toute modification.

AES-GCM (Galois/Counter Mode) combine deux composants : AES-CTR (mode compteur) pour le chiffrement et GMAC (Galois Message Authentication Code) pour l'intégrité. AES-CTR génère un flux de clés en chiffrant une valeur de compteur et en l'opérant par XOR avec le texte en clair — le chiffrement peut ainsi être parallélisé, contrairement au mode CBC. GMAC calcule une balise d'authentification sur le texte chiffré et sur toute Data associée. La balise obtenue (128 bits) est transmise avec le texte chiffré ; la moindre modification d'un bit invalide la balise.

AES-GCM nécessite un nonce (nombre utilisé une seule fois), généralement de 96 bits (12 octets). Le nonce doit être unique pour chaque opération de chiffrement effectuée avec la même clé : il n'a pas besoin d'être secret, mais il ne doit jamais être réutilisé. La réutilisation d'un nonce avec AES-GCM est catastrophique : si deux messages sont chiffrés avec la même clé et le même nonce, un attaquant peut appliquer XOR aux textes chiffrés pour annuler le flot de clés et potentiellement récupérer les deux textes en clair. Cette vulnérabilité est parfois appelée « mauvaise utilisation du nonce » et a été à l'origine d'attaques bien réelles permettant de récupérer des clés.

Lorsque les nonces AES-GCM sont réutilisés, l'attaquant peut calculer C1 XOR C2 = P1 XOR P2 (le XOR des deux textes en clair), car le même flot de clés a été utilisé pour les deux. De plus, la réutilisation du nonce permet de récupérer la clé d'authentification H, ce qui signifie que l'attaquant peut falsifier des balises d'authentification valides pour des messages arbitraires, compromettant complètement la confidentialité et l'intégrité. Des systèmes comme la Sony PS3 ont subi exactement cette attaque. La protection consiste à utiliser des nonces aléatoires (générés avec un CSPRNG) ou un compteur déterministe qui ne se réinitialise jamais.

ChaCha20-Poly1305 est l'autre chiffrement AEAD imposé par TLS 1.3. ChaCha20 est un chiffrement par flot conçu par Daniel Bernstein, qui génère un flot de clés au moyen d'opérations additionner-effectuer une rotation-XOR (ARX) : aucune table de consultation, un temps d'exécution totalement constant et une très grande rapidité sur les CPU dépourvus d'accélération matérielle pour AES. Poly1305 est un MAC à usage unique (code d'authentification de message) qui calcule la balise d'authentification sur le texte chiffré. Ensemble, ils offrent une sécurité équivalente à celle d'AES-GCM, mais sont nettement plus rapides sur les appareils mobiles et les appareils IoT.

Les processeurs modernes x86 et ARM64 pour ordinateurs de bureau et serveurs incluent des instructions matérielles AES-NI qui rendent AES-GCM extrêmement rapide. Cependant, de nombreux processeurs mobiles et IoT ne disposent pas d'AES-NI, ce qui rend AES-GCM logiciel relativement lent. ChaCha20-Poly1305 a été conçu pour être rapide en logiciel grâce à des opérations arithmétiques simples, offrant ainsi aux appareils mobiles des performances comparables sans accélération matérielle. Google a ajouté ChaCha20-Poly1305 à TLS comme solution de remplacement précisément pour les appareils Android, et il constitue désormais une suite de chiffrement de premier ordre dans TLS 1.3.

Le « AD » de AEAD signifie Associated Data : des métadonnées en clair qui sont authentifiées, mais pas chiffrées. Cela permet d'authentifier des données qui doivent rester lisibles (comme les en-têtes de paquets ou les champs indiquant le type d'enregistrement), tout en les protégeant contre toute modification. Dans TLS 1.3, les octets de l'en-tête d'enregistrement sont inclus en tant que données associées dans le calcul AEAD. Si un attaquant modifie l'en-tête (par exemple en changeant la longueur de l'enregistrement), la vérification de la balise d'authentification échoue et la connexion est interrompue.

Avant qu'AEAD ne devienne la norme, les cryptographes recommandaient Encrypt-then-MAC (EtM) : chiffrer le texte en clair, puis calculer un MAC sur le texte chiffré. Cette méthode est sûre, mais elle nécessite deux opérations distinctes avec deux clés distinctes. Les schémas AEAD comme AES-GCM combinent les deux opérations avec une seule clé, ce qui réduit la complexité de l'implémentation et élimine toute une catégorie d'attaques par oracle de bourrage qui affectaient MAC-then-Encrypt (MtE), l'ordre utilisé dans les anciennes versions de TLS (CBC + HMAC). TLS 1.3, qui utilise AEAD, évite entièrement ces problèmes.

AES-128-GCM et AES-256-GCM sont tous deux approuvés par NIST et considérés comme sûrs contre les ordinateurs classiques. AES-128 offre une sécurité de 128 bits avec des performances légèrement supérieures ; AES-256 offre une sécurité de 256 bits, fournissant une marge plus importante contre la cryptanalyse future et les menaces quantiques. Pour la plupart des applications actuelles, AES-128-GCM suffit, mais les systèmes gouvernementaux traitant des informations classifiées (NSA Suite B) exigent AES-256. TLS 1.3 propose les deux, et les serveurs peuvent les privilégier selon leur politique de sécurité.

Lors du déchiffrement d'un texte chiffré AEAD, le destinataire doit vérifier la balise d'authentification avant de déchiffrer. Le processus est le suivant : recalculer la balise attendue à partir du texte chiffré reçu, de la clé et du nonce ; la comparer à la balise reçue à l'aide d'une fonction de comparaison à temps constant ; poursuivre le déchiffrement uniquement si elles correspondent. La comparaison à temps constant est essentielle : si la comparaison s'arrête dès le premier octet différent, un attaquant peut mener une attaque par canal auxiliaire temporel afin de falsifier des balises valides octet par octet. Toute bibliothèque AEAD qui utilise une comparaison avec sortie anticipée est vulnérable.

Les algorithmes AEAD sont omniprésents dans la sécurité moderne : TLS 1.3 utilise AES-GCM et ChaCha20-Poly1305 pour chiffrer tous les enregistrements ; le VPN WireGuard utilise exclusivement ChaCha20-Poly1305 ; le protocole Signal l'utilise pour le chiffrement des messages ; le protocole QUIC (à la base de HTTP/3) utilise AES-GCM. Lorsque vous voyez une suite de chiffrement telle que TLS_AES_256_GCM_SHA384, SHA384 désigne la fonction de hachage HKDF utilisée pour la dérivation de clés, et non le mécanisme d'intégrité : la balise GCM assure l'intégrité.

Testez votre compréhension des notions de CompTIA Security+ (SY0-701) abordées dans cette leçon.

Dans cette leçon, vous avez appris que les algorithmes AEAD assurent simultanément la confidentialité et l'intégrité grâce à une balise d'authentification qui détecte toute modification du texte chiffré ; que la réutilisation d'un nonce avec AES-GCM est catastrophique, car elle permet de récupérer le flot de clés et de falsifier la clé d'authentification : les nonces doivent donc être uniques pour chaque chiffrement ; et que ChaCha20-Poly1305 est une alternative performante à AES-GCM pour les appareils dépourvus d'accélération matérielle pour AES. Nous allons maintenant étudier les fonctions de dérivation de clés utilisées pour sécuriser les mots de passe.