La 6G va permettre de nouveaux usages nécessitant des débits très élevés et des temps de réponse très faibles. Dans ce contexte, la protection des données ne doit pas devenir un facteur limitant : il faut pouvoir chiffrer et authentifier les données avec une latence et une consommation énergétique aussi faibles que possible.
C’est dans ce cadre que le 3GPP étudie l’utilisation d’une approche cryptographique appelée AEAD – Authenticated Encryption with Associated Data, que l’on peut traduire par chiffrement authentifié avec données associées.
Pour comprendre l’intérêt de cette évolution, commençons par regarder comment les données sont protégées aujourd’hui.
1. Les algorithmes de sécurité en 5G ?
Dans un réseau mobile, deux propriétés de sécurité doivent être assurées :
- la confidentialité : un utilisateur non autorisé qui intercepte les données ne doit pas pouvoir les comprendre ;
- l’intégrité : le récepteur doit pouvoir vérifier que les informations reçues n’ont pas été modifiées.
En 5G, ces deux fonctions reposent sur des mécanismes cryptographiques distincts.
Le 3GPP définit notamment :
- 128-NEA1, 128-NEA2 et 128-NEA3 pour le chiffrement ;
- 128-NIA1, 128-NIA2 et 128-NIA3 pour la protection de l’intégrité.
Dans la pile protocolaire radio, ces mécanismes sont notamment appliqués au niveau de la couche PDCP – Packet Data Convergence Protocol.
De manière très simplifiée :
Données PDCP
|
+----> chiffrement
|
+----> protection d'intégrité
Ces mécanismes sont déjà fortement optimisés. Le problème posé par la 6G n’est donc pas que la cryptographie 5G serait inefficace, mais que les nouvelles contraintes du réseau conduisent à étudier une autre manière d’organiser ces fonctions de sécurité.
2. Pourquoi AEAD pour la 6G ?
Une piste consiste à assurer le chiffrement et l’authentification au sein d’une même construction cryptographique.
Une opération AEAD peut être représentée simplement :
Message
+
Clé
+
Nonce
+
Données associées
|
v
AEAD
|
v
Message chiffré + Tag d'authentification
Le message est chiffré et le tag d’authentification permet au récepteur de vérifier qu’il n’a pas été modifié.
L’intérêt d’AEAD réside dans la conception d’une primitive assurant conjointement chiffrement et authentification. Selon l’algorithme et son implémentation, cette intégration peut permettre de mutualiser certains traitements.
Et les « Associated Data » ?
AEAD permet également d’authentifier des informations sans nécessairement les chiffrer.
Prenons un exemple volontairement simplifié :
En-tête
visible mais authentifié
+
Données utilisateur
chiffrées et authentifiées
Certaines informations peuvent ainsi rester accessibles pour permettre le traitement du paquet, tout en étant protégées contre une modification.
Dans un véritable réseau 6G, déterminer quelles informations pourraient jouer le rôle d’Associated Data sera une question d’architecture.
Avec le network slicing, différentes classes de service ou de nouvelles fonctions distribuées, certaines métadonnées peuvent devoir rester accessibles à certaines entités du réseau.
La question est alors : quelles informations le réseau doit-il pouvoir lire tout en étant certain qu’elles n’ont pas été modifiées ?
3. Comment AEAD pourrait-il s’intégrer dans la 6G ?
Introduire AEAD ne consiste pas seulement à choisir un algorithme. Il faut aussi déterminer comment le terminal et le réseau négocient son utilisation et comment la protection est activée.
En 5G, la mise en place de la sécurité repose notamment sur :
- le NAS Security Mode Command, entre l’AMF et l’UE ;
- l’AS Security Mode Command, entre le gNB et l’UE.
Le principe général est le suivant :
UE gNB
| |
|---- capacités de sécurité --->|
| |
|<---- Security Mode Command ---|
| |
|---- Security Mode Complete -->|
| |
| Sécurité activée |
Une piste pour la 6G consiste à faire évoluer ce principe plutôt qu’à reconstruire entièrement les procédures de sécurité.
Le futur aNB pourrait par exemple sélectionner un algorithme AEAD parmi ceux supportés par le terminal :
UE aNB
| |
|---- capacités AEAD supportées ------>|
| |
|<---- Security Mode Command ----------|
| algorithme AEAD sélectionné |
| |
|---- Security Mode Complete --------->|
| |
| Activation
| protection
L’algorithme négocié pourrait ensuite être utilisé au niveau où la protection est requise, notamment pour le trafic utilisateur au niveau PDCP selon l’architecture finalement retenue.
Il ne s’agit pas d’une architecture 6G déjà normalisée. Le 3GPP étudie encore plusieurs possibilités dans le cadre des travaux FS_AEAD, menés au sein du groupe SA3 chargé de la sécurité.
L’intérêt est surtout de constater qu’AEAD pourrait s’inscrire dans la continuité des mécanismes existants, plutôt que provoquer une rupture complète avec la 5G.
4. Rocca-S et SNOW-Axn : des algorithmes pour le très haut débit
En parallèle des travaux de normalisation 3GPP menés dans SA3 (FS_AEAD), plusieurs équipes académiques proposent des constructions AEAD alternatives adaptées aux très hauts débits. Deux d’entre elles retiennent particulièrement l’attention : Rocca-S et SNOW-Axn.
Ces propositions n’ont pas le statut d’algorithmes normalisés : il s’agit
de candidates académiques en phase de recherche et d’évaluation. Leur
intérêt réside dans les débits qu’elles peuvent théoriquement atteindre,
mais le choix final du 3GPP reste ouvert.
Rocca-S
Rocca-S s’appuie notamment sur certaines opérations cryptographiques utilisées dans AES. Celles-ci peuvent être accélérées directement par des instructions disponibles dans les processeurs modernes, ce qui permet d’atteindre des débits de traitement très élevés.
SNOW-Axn
La famille SNOW est particulièrement intéressante pour les télécommunications puisqu’elle est historiquement liée aux mécanismes cryptographiques des réseaux mobiles.
SNOW-Axn adapte cette approche au chiffrement authentifié et certaines variantes atteignent également plusieurs centaines de Gbit/s sur les plateformes testées.
Mesurées en C++ sur processeur Intel haute gamme (i5-1145G7,
single-thread) :
- SNOW-Ax4 atteint **421 Gbps** en mode chiffrement seul sur
messages de 256 KB, mais descend à **184 Gbps** sur messages
de 16 KB (taille plus réaliste en trafic 6G). - En mode AEAD complet (chiffrement + authentification), SNOW-Ax4 mesure 311 Gbps sur grands messages.
- Rocca-S atteint 197 Gbps en AEAD, soit une alternative compétitive mais moins ambitieuse en débit.
Important: Ces débits reflètent des conditions optimales (messages longs, cache warm, pas de contexte-switching). Le débit réel dépendra de la distribution des tailles de paquets et de la charge système.
Se référer à : https://cic.iacr.org/p/3/1/31/pdf
Ces chiffres doivent toutefois être interprétés correctement. Un débit cryptographique de 200 Gbit/s ne signifie pas qu’un smartphone pourra transmettre à 200 Gbit/s.
Ces benchmarks mesurent la vitesse de traitement de la primitive cryptographique sur une plateforme donnée. Ils ne représentent pas les performances de l’ensemble de la chaîne :
Le choix d’un futur algorithme devra donc également prendre en compte sa latence sur les petits paquets, sa consommation énergétique et son coût d’implémentation dans un équipement réel.
Rocca-S et SNOW-Axn illustrent les recherches actuelles mais, à ce jour, rien ne permet d’affirmer qu’ils seront retenus pour la 6G.
5. AEAD, mobilité et NTN : s’appuyer sur les mécanismes existants
La nécessité de disposer de paramètres cryptographiques variant avec les paquets n’est pas nouvelle dans les réseaux mobiles. En 5G, les algorithmes de chiffrement et d’intégrité utilisent déjà différents paramètres, notamment le COUNT, le bearer et la direction de transmission.
La pile protocolaire doit également maintenir correctement le contexte de sécurité lorsque le terminal change de cellule ou lorsque plusieurs chemins de transmission coexistent, par exemple avec le DAPS handover – Dual Active Protocol Stack ou la duplication PDCP.
L’introduction d’AEAD devra s’inscrire dans cette continuité. Un algorithme AEAD utilise notamment une clé et un nonce, dont les contraintes de réutilisation dépendent de la construction cryptographique retenue.
Une future intégration pourrait donc s’appuyer sur les informations déjà disponibles dans le contexte de sécurité et dans la pile protocolaire :
Contexte de sécurité
+
Paramètres liés au paquet
(ex. COUNT, bearer, direction en 5G)
↓
Paramètres nécessaires à AEAD
↓
AEAD
↓
Données chiffrées + tag
Ce schéma reste volontairement conceptuel : la manière dont le nonce et les autres paramètres d’un futur algorithme AEAD seraient construits et gérés en 6G n’est pas encore définie.
L’enjeu n’est donc pas de réinventer la gestion du contexte de sécurité, mais de déterminer comment AEAD pourra s’intégrer aux mécanismes déjà utilisés dans les réseaux mobiles.
Et avec les réseaux NTN ?
La même logique peut s’appliquer aux NTN – Non-Terrestrial Networks.
Les communications par satellite introduisent des scénarios de mobilité supplémentaires : changement de satellite, changement de cellule ou transition entre réseau terrestre et réseau non terrestre.
Ces situations ne modifient pas directement le fonctionnement cryptographique d’AEAD. Elles nécessitent en revanche de maintenir correctement le contexte de sécurité au cours de ces transitions.
L’enjeu pour la 6G sera donc de faire en sorte que l’utilisation d’AEAD reste compatible avec les mécanismes de mobilité terrestres et non terrestres, tout en respectant les propriétés de sécurité de l’algorithme finalement retenu.
6. Pourquoi des clés de 256 bits ?
La préparation des réseaux aux futures capacités des ordinateurs quantiques constitue un autre enjeu.
Il faut cependant distinguer deux problématiques.
- La cryptographie asymétrique, utilisée notamment pour l’authentification et l’établissement de secrets, pourrait être fortement affectée par un ordinateur quantique suffisamment puissant. C’est pourquoi de nouveaux algorithmes post-quantiques sont développés.
- Pour la cryptographie symétrique, comme AES, le problème est différent.
L’algorithme de Grover permet théoriquement d’accélérer la recherche exhaustive d’une clé. L’utilisation de clés symétriques de 256 bits permet alors de conserver une marge de sécurité importante.
Certaines constructions AEAD étudiées, comme Rocca-S ou SNOW-Axn, utilisent ou peuvent utiliser des clés de cette taille.
Il faut cependant éviter un raccourci : AEAD n’est pas synonyme de cryptographie post-quantique.
AEAD et la migration post-quantique répondent à des problématiques différentes, même si elles participent toutes deux à l’évolution de la sécurité des futurs réseaux.
Conclusion
L’évolution vers AEAD ne signifie pas que les mécanismes cryptographiques de la 5G seraient devenus inefficaces.
La question posée par la 6G est différente : peut-on concevoir une protection mieux intégrée, capable d’assurer conjointement confidentialité et authentification tout en répondant aux nouvelles contraintes de débit, de latence et de consommation ?
AEAD constitue une piste particulièrement intéressante pour répondre à cette question.
Des constructions comme Rocca-S et SNOW-Axn montrent que le chiffrement authentifié peut atteindre des débits très importants. Mais les performances brutes ne suffiront pas.
Il faudra également déterminer comment AEAD s’intégrera concrètement aux mécanismes du réseau mobile : négociation de l’algorithme, gestion des clés et des paramètres cryptographiques, mobilité, handovers, NTN et définition des données qui pourront rester visibles tout en étant authentifiées.
La 6G étant encore en cours de définition, le choix des algorithmes et leur intégration dans les protocoles restent ouverts.
C’est précisément ce qui rend les travaux actuels du 3GPP intéressants : il ne s’agit pas seulement de choisir un algorithme plus rapide, mais de déterminer comment faire évoluer l’architecture de sécurité des réseaux mobiles pour accompagner la 6G.
Pour aller plus loin
- 3GPP – travaux SA3 et étude FS_AEAD – TR 33.771
- 3GPP TS 33.501 – Security architecture and procedures for 5G System
- 3GPP TS 38.323 – Packet Data Convergence Protocol (PDCP) specification
- 3GPP TS 38.331 – Radio Resource Control (RRC)
- Travaux de recherche sur Rocca-S
- Travaux de recherche sur SNOW-Axn
- Travaux 3GPP sur les Non-Terrestrial Networks (NTN)
