AES-256-GCM : le standard de chiffrement authentifié qui sécurise vos fichiers iPhone

TL;DR

AES-256-GCM est un algorithme de chiffrement authentifié qui chiffre les données et vérifie leur intégrité en utilisant une seule clé et un nonce unique par message. Il est défini par les normes NIST, accéléré matériellement sur les iPhone modernes, et utilisé par TLS 1.3, WireGuard et Signal. AppVault applique AES-256-GCM avec un nonce de 96 bits unique par fichier, une clé dérivée par PBKDF2 enveloppée par le Secure Enclave, et aucun appel réseau.

AES-256-GCM n’est pas un algorithme unique. C’est la combinaison de deux normes : l’Advanced Encryption Standard (AES) avec une clé de 256 bits, et le mode Galois/Counter (GCM). Ensemble, ils forment un schéma de chiffrement authentifié qui assure à la fois la confidentialité et la vérification d’intégrité en une seule passe. C’est le chiffrement par défaut dans TLS 1.3, WireGuard, Signal et le chiffrement au niveau fichier d’iOS. Comprendre son fonctionnement est important car la plupart des défaillances de sécurité d’AES-256-GCM proviennent d’erreurs d’implémentation, pas d’un cassage du chiffrement.

Pour une introduction non technique au chiffrement par blocs sous-jacent — ce que signifie « clé de 256 bits », pourquoi l’espace des clés est incassable par force brute, comment AES a été sélectionné par le NIST en 2001 — lisez d’abord la présentation en langage clair Qu’est-ce que le chiffrement AES-256 ?. Cet article approfondit spécifiquement le mode GCM.

Le chiffrement par blocs : AES-256

AES est un chiffrement par blocs symétrique normalisé par le NIST dans FIPS 197. Il opère sur des blocs de 128 bits et prend en charge des tailles de clé de 128, 192 et 256 bits. AES-256 utilise une clé de 256 bits et effectue 14 tours d’opérations de substitution-permutation. Chaque tour applique quatre transformations : SubBytes (substitution non linéaire via la S-box), ShiftRows (transposition d’octets), MixColumns (multiplication matricielle dans GF(2^8)) et AddRoundKey (XOR avec la clé de tour dérivée de la clé maîtresse).

La marge de sécurité d’AES-256 est élevée. Les meilleures attaques cryptanalytiques connues ciblent des variantes à nombre de tours réduit (par exemple AES-128 7 tours) ou des modèles à clés liées qui ne s’appliquent pas à une utilisation réelle. Pour l’AES-256 complet à 14 tours, aucune attaque pratique ne réduit la taille effective de la clé en dessous de 256 bits. C’est pourquoi AES-256 est approuvé pour les données classifiées « Très secret » par la National Security Agency américaine.

AES-256 bénéficie d’une accélération matérielle sur pratiquement tous les processeurs modernes. Les processeurs Intel et AMD incluent des instructions AES-NI. Apple Silicon (puce M-series et A-series) intègre des extensions ARM Crypto qui accélèrent les opérations AES, SHA et GCM. Sur un iPhone, le chiffrement AES-256 d’un fichier de 10 Mo s’effectue en quelques millisecondes.

Le mode : Galois/Counter (GCM)

Un chiffrement par blocs ne chiffre qu’un seul bloc à la fois. Pour chiffrer des messages plus longs que 128 bits, vous avez besoin d’un mode de fonctionnement. GCM, spécifié dans NIST SP 800-38D, est un mode de chiffrement authentifié qui combine une variante du mode compteur pour le chiffrement avec une fonction de hachage universelle (GHASH) pour l’authentification. Cette même construction est enregistrée comme primitive AEAD dans IETF RFC 5116.

GCM fonctionne en deux phases. D’abord, le texte en clair est chiffré à l’aide d’AES en mode compteur : un compteur de 128 bits est incrémenté pour chaque bloc, chiffré avec AES, puis combiné par XOR avec le texte en clair pour produire le texte chiffré. La valeur initiale du compteur est dérivée du nonce (nombre à usage unique) et d’un compteur commençant à 1. Ensuite, le texte chiffré et les données associées (métadonnées qui doivent être authentifiées mais non chiffrées) sont transmis à GHASH, une évaluation polynomiale dans GF(2^128). La sortie de GHASH est ensuite chiffrée avec AES pour produire l’étiquette d’authentification.

Le résultat est une sortie unique : le texte chiffré plus une étiquette d’authentification de 128 bits (longueur par défaut, pouvant être tronquée). Le destinataire déchiffre en recalculant l’étiquette et en la comparant. Si l’étiquette correspond, les données sont authentiques. Sinon, le destinataire doit rejeter les données.

GCM est parallélisable. Le mode compteur permet de chiffrer plusieurs blocs simultanément, ce qui explique pourquoi l’accélération matérielle peut atteindre un débit élevé. Sur un iPhone avec ARM Crypto Extensions, AES-256-GCM peut chiffrer à plusieurs gigabits par seconde.

Discipline du nonce : le point de défaillance le plus fréquent

AES-256-GCM nécessite un nonce. La norme spécifie un nonce de 96 bits. Ce nonce doit être unique pour chaque chiffrement effectué avec la même clé. La réutilisation d’un nonce avec la même clé permet à un attaquant de retrouver la clé d’authentification GHASH (H) puis de forger des messages arbitraires.

Les mathématiques sont impitoyables : si deux textes chiffrés partagent le même nonce et la même clé, le XOR des deux sorties GHASH révèle le XOR des textes en clair. De là, un attaquant peut retrouver H et produire des étiquettes valides pour n’importe quel texte chiffré. Ce n’est pas une attaque théorique. Elle a été exploitée en pratique, notamment dans l’article de 2015 « Nonce-Disrespecting Adversaries » qui a révélé des vulnérabilités de réutilisation de nonce dans plusieurs implémentations TLS.

La bonne parade consiste à ne jamais réutiliser un nonce sous la même clé. En pratique, cela signifie soit générer un nonce aléatoire (96 bits donnent 2^96 possibilités, mais la limite de l’anniversaire impose de ne pas chiffrer plus de 2^32 messages avec des nonces aléatoires pour que la probabilité de collision reste négligeable), soit utiliser un compteur déterministe garanti unique par message.

AppVault utilise un nonce unique de 96 bits par fichier. Le nonce est généré à l’aide d’un générateur de nombres aléatoires cryptographiquement sûr (SecRandomCopyBytes sur iOS) et stocké à côté du texte chiffré. Comme chaque fichier a son propre nonce, et que la clé est dérivée par installation et enveloppée par le Secure Enclave, le risque de réutilisation du nonce est éliminé.

Accélération matérielle : pourquoi c’est important

AES-256-GCM est coûteux en calcul en logiciel. La multiplication GHASH dans GF(2^128) est particulièrement lourde sans support matériel. Les processeurs modernes intègrent des instructions dédiées qui réalisent les tours AES et les opérations GHASH en un cycle.

Sur un iPhone, les extensions ARM Crypto incluent :

• Instructions AES (AESE, AESD, AESMC, AESIMC) qui effectuent un tour de chiffrement ou de déchiffrement AES.
• Instructions GHASH (PMULL/PMULL2 pour la multiplication polynomiale) qui accélèrent le calcul GHASH.

Le Secure Enclave d’Apple Silicon possède un moteur AES dédié qui peut chiffrer des données sans exposer la clé au processeur principal. AppVault utilise le Secure Enclave pour envelopper la clé de chiffrement des fichiers, garantissant que même en cas de compromission du processeur principal, la clé reste protégée.

Sans accélération matérielle, AES-256-GCM serait trop lent pour des applications temps réel comme les négociations TLS ou le streaming vidéo. Avec elle, le surcoût est négligeable.

Où AES-256-GCM est utilisé

AES-256-GCM est la suite de chiffrement par défaut de TLS 1.3 (TLS_AES_256_GCM_SHA384). Chaque connexion HTTPS utilisant TLS 1.3 en dépend. WireGuard, le protocole VPN moderne, utilise AES-256-GCM (ou ChaCha20-Poly1305 sur les appareils sans AES matériel). Signal, l’application de messagerie chiffrée, utilise AES-256-GCM pour le chiffrement des fichiers multimédias. iOS utilise AES-256-GCM pour le chiffrement au niveau fichier de la protection des données.

L’ubiquité d’AES-256-GCM n’est pas un hasard. C’est une norme NIST, accélérée matériellement et bien comprise par la communauté cryptographique. C’est le choix sûr par défaut pour toute application nécessitant un chiffrement authentifié.

Comparaison avec d’autres modes de chiffrement authentifié

AES-256-GCM n’est pas le seul mode AEAD. ChaCha20-Poly1305 est une alternative populaire, surtout sur les appareils sans accélération AES matérielle. ChaCha20 est un chiffrement par flux, pas par blocs, et Poly1305 est un hachage polynomial similaire à GHASH. ChaCha20-Poly1305 est plus rapide en logiciel qu’AES-256-GCM en logiciel, mais sur du matériel avec AES-NI, AES-256-GCM est plus rapide.

AES-256-CCM (Counter with CBC-MAC) est un autre mode AEAD normalisé par le NIST, mais il n’est pas parallélisable et plus lent que GCM. CCM est utilisé dans certains protocoles IoT et sans fil, mais TLS et la plupart des applications modernes lui préfèrent GCM.

AES-256-GCM-SIV est une variante résistante à la réutilisation de nonce qui se dégrade gracieusement si un nonce est réutilisé (elle révèle seulement que deux messages sont égaux, pas leur texte en clair). Elle est plus lente que GCM standard et moins déployée.

Pour la plupart des applications, AES-256-GCM est le bon choix. Il est rapide, normalisé et sûr lorsqu’il est correctement implémenté.

Comment AppVault implémente AES-256-GCM

AppVault utilise AES-256-GCM pour chaque fichier stocké dans le coffre. L’implémentation suit ces étapes :

1. Dérivation de clé. Le verrouillage par motif de l’utilisateur est transformé en une clé maîtresse de 256 bits à l’aide de PBKDF2-SHA256 avec 600 000 itérations et un sel de 128 bits par installation. Cette clé n’est jamais utilisée directement pour le chiffrement.
2. Enveloppement par le Secure Enclave. La clé maîtresse est envoyée au Secure Enclave, qui génère une nouvelle clé (la « clé d’enveloppement ») qui ne quitte jamais la puce. L’Enclave chiffre la clé maîtresse avec la clé d’enveloppement et renvoie la clé enveloppée au processeur principal. La clé maîtresse en clair est ensuite effacée de la mémoire.
3. Chiffrement des fichiers. Pour chaque fichier, un nouveau nonce de 96 bits est généré via SecRandomCopyBytes. La clé enveloppée est déchiffrée à l’intérieur du Secure Enclave et utilisée pour chiffrer le fichier avec AES-256-GCM. Le texte chiffré et le nonce sont écrits dans le stockage. L’étiquette d’authentification est ajoutée à la fin du texte chiffré.
4. Chiffrement du catalogue. Même la liste des fichiers (noms, dates, tailles) est chiffrée avec AES-256-GCM sous une clé distincte dérivée de la même clé maîtresse. Cela signifie qu’un attaquant ayant un accès brut à l’appareil ne peut pas déterminer combien de fichiers existent.

Le résultat est qu’aucun fichier ne produit le même texte chiffré, même s’ils contiennent le même texte en clair. Le Secure Enclave garantit que la clé de chiffrement n’est jamais exposée au système d’exploitation principal. Et comme AppVault n’effectue aucun appel réseau, aucun serveur ne peut être compromis pour fuiter des clés ou des textes chiffrés.

Limites d’AES-256-GCM

AES-256-GCM ne protège pas contre tout. Il est vulnérable aux attaques par canaux auxiliaires si l’implémentation fuit des informations temporelles ou de consommation. Le calcul GHASH est particulièrement sensible aux attaques temporelles ; des implémentations en temps constant sont nécessaires. La bibliothèque CoreCrypto d’Apple fournit une implémentation en temps constant d’AES-256-GCM, et AppVault utilise cette bibliothèque.

AES-256-GCM n’offre pas de confidentialité persistante (forward secrecy). Si la clé est compromise, tous les textes chiffrés passés peuvent être déchiffrés. La confidentialité persistante est assurée au niveau du protocole (par exemple, TLS 1.3 utilise l’échange de clés Diffie-Hellman éphémère) et n’est pas une propriété du chiffrement lui-même. AppVault atténue ce risque en conservant la clé sur l’appareil et en ne la transmettant jamais.

AES-256-GCM n’est pas résistant au quantique. L’algorithme de Grover réduit la taille effective de la clé d’AES-256 de 256 bits à 128 bits. Un ordinateur quantique suffisamment grand pourrait le casser. Cependant, un tel ordinateur quantique n’existe pas et n’est pas attendu avant au moins une décennie. Pour les secrets à long terme, des chiffrements post-quantiques comme CRYSTALS-Kyber sont en cours de normalisation.

AES-256-GCM ne protège pas contre la cryptanalyse par matraque ou la saisie physique de l’appareil. Si un attaquant a un accès physique à votre iPhone et peut vous contraindre à le déverrouiller, aucun chiffrement ne peut protéger vos fichiers. Le modèle de menace d’AppVault suppose que l’appareil est sous votre contrôle.

Pourquoi AppVault a choisi AES-256-GCM

AppVault a choisi AES-256-GCM parce que c’est l’algorithme de chiffrement authentifié le plus largement déployé, avec une accélération matérielle sur tous les iPhone modernes. Il est normalisé, revu par les pairs et approuvé par les plus grands protocoles de sécurité mondiaux. Il permet à AppVault de chiffrer les fichiers rapidement sans épuiser la batterie, et sa vérification d’intégrité garantit que les fichiers stockés n’ont pas été altérés.

L’alternative, ChaCha20-Poly1305, est également sûre et est utilisée par AppVault pour certaines opérations où l’AES matériel n’est pas disponible (par exemple sur les appareils plus anciens). Mais pour le chiffrement des fichiers sur iOS, AES-256-GCM est le choix naturel.

Chaque fichier dans AppVault est chiffré avec AES-256-GCM, un nonce unique et une clé dérivée de votre verrouillage par motif et enveloppée par le Secure Enclave. La pile cryptographique complète est documentée sur la page Chiffrement AES-256-GCM, avec des références à NIST FIPS 197, NIST SP 800-38D et au Guide de sécurité de la plateforme Apple. La page Modèle de menace explique ce contre quoi cette architecture se défend et ce qu’elle ne fait pas. La page Architecture zéro connaissance explique pourquoi AppVault ne voit jamais vos données.