Architecture AllEyes : le chiffrement CPU-blind
Le problème : le CPU dans le chemin cryptographique
Les architectures de chiffrement réseau traditionnelles, qu'il s'agisse d'IPsec ou de MACsec logiciel, confient au processeur central l'intégralité des opérations cryptographiques. Le CPU gère l'échange de clés, exécute les algorithmes de chiffrement et de déchiffrement, et stocke le matériel cryptographique en mémoire vive. Cette concentration crée une surface d'attaque considérable : les clés résident dans la RAM, accessibles à tout processus disposant de privilèges suffisants.
Les attaques par canal auxiliaire comme Spectre et Meltdown ont démontré que l'isolation logicielle entre processus est une illusion. Un attaquant exploitant une vulnérabilité micro-architecturale du CPU peut lire la mémoire d'un autre processus, y compris les clés cryptographiques. Les attaques par démarrage à froid (cold boot), les compromissions firmware et les escalades de privilèges noyau élargissent encore cette surface. Le problème fondamental n'est pas la robustesse de l'algorithme de chiffrement : c'est le fait que le CPU, composant généraliste exposé à des milliers de vecteurs d'attaque, détient simultanément les clés et les données.
L'approche CPU-blind
L'architecture AllEyes repose sur un principe radical : retirer entièrement le CPU du chemin cryptographique. Le terme « CPU-blind » désigne une réalité matérielle, pas une abstraction logicielle. Le processeur central ne voit jamais les clés cryptographiques en clair. Il ne peut ni les lire, ni y accéder, ni les extraire, même en cas de compromission totale du système d'exploitation.
Toutes les opérations cryptographiques sont exécutées exclusivement par le FPGA : génération de clés, échange de clés, encapsulation, chiffrement et déchiffrement du trafic réseau. Le CPU conserve un rôle strictement limité au plan de gestion : configuration, supervision, journalisation et distribution des politiques de sécurité. Aucune de ces fonctions ne nécessite un accès au matériel cryptographique. Cette séparation est imposée par le matériel lui-même. Aucune escalade de privilèges, aucun exploit noyau, aucune attaque firmware ne peut la contourner.
Architecture matérielle
Le trafic réseau entre dans le FPGA directement depuis l'interface réseau d'entrée. Le chiffrement ou le déchiffrement s'effectue à débit de ligne, sans que les données ne transitent par le CPU ni par la mémoire vive du système hôte. Le plan de données suit un chemin strictement matériel : interface réseau d'entrée, FPGA, interface réseau de sortie.
Le plan de gestion est physiquement séparé du plan de données. Le CPU communique avec le FPGA via une interface de commande unidirectionnelle, sans accès en lecture aux registres contenant les clés ou les états internes du moteur cryptographique. Les clés sont générées et stockées dans l'enclave sécurisée du FPGA, une région mémoire dédiée inaccessible depuis le bus système principal. L'isolation matérielle garantit que ni le CPU ni aucun périphérique DMA ne peuvent accéder aux zones mémoire du FPGA qui contiennent le matériel cryptographique.
Chiffrement de ligne vs chiffrement de paquet
L'architecture AllEyes implémente un chiffrement de ligne de couche 2, comparable au MACsec mais exécuté intégralement en FPGA. Contrairement au chiffrement de paquet IPsec, qui opère en couche 3 et introduit une surcharge d'en-têtes (ESP, IV, ICV) ainsi qu'une latence variable liée au traitement logiciel, le chiffrement de ligne traite chaque trame à débit nominal sans aucune surcharge protocolaire.
La latence ajoutée par le chiffrement est déterministe et inférieure à 1 μs, indépendamment de la taille des trames ou de la charge réseau. Cette propriété est critique pour les applications sensibles à la latence. En comparaison, une pile IPsec logicielle introduit typiquement entre 50 et 500 μs de latence supplémentaire, avec une variance significative sous charge. Le chiffrement de ligne offre également un overhead nul en bande passante : l'intégralité du débit de l'interface est disponible pour les données utiles, sans perte liée aux en-têtes de tunnel.
Post-quantique natif
L'architecture AllEyes intègre nativement la cryptographie post-quantique au niveau du FPGA. L'échange de clés utilise un KEM hybride combinant ML-KEM-1024 (FIPS 203, le standard post-quantique du NIST) et X25519 (courbe elliptique classique). Cette approche hybride garantit la sécurité même si l'un des deux algorithmes se révèle vulnérable : il suffit qu'un seul résiste pour que la confidentialité des échanges soit préservée.
Le plan de données utilise AES-256-GCM pour le chiffrement symétrique du trafic, avec accélération matérielle complète dans le FPGA. L'ensemble de la chaîne cryptographique, de l'encapsulation de clés au chiffrement des trames, est exécuté en matériel, sans intervention logicielle. Cette intégration native élimine les goulets d'étranglement que l'on observe dans les implémentations logicielles de ML-KEM, où la taille des clés publiques (1 568 octets) et des textes chiffrés (1 568 octets) pèse sur les performances du CPU.
Crypto-agilité et FPGA
La transition post-quantique n'est pas un événement ponctuel. Les algorithmes évoluent, de nouvelles attaques sont découvertes, et les standards se mettent à jour. Un chiffreur qui ne supporte qu'un jeu fixe d'algorithmes devient obsolète dès qu'un changement s'impose. Les ASIC (circuits intégrés spécifiques) offrent d'excellentes performances mais sont figés : un ASIC gravé pour un algorithme donné ne peut pas être mis à jour sans remplacement physique de la puce.
Le FPGA résout cette équation. Sa logique reconfigurable permet de mettre à jour les algorithmes cryptographiques par simple mise à jour firmware, sans remplacement matériel. Si demain un nouvel algorithme post-quantique est standardisé, ou si une vulnérabilité est découverte dans un algorithme existant, le FPGA peut être reprogramé sur le terrain. Cette crypto-agilité matérielle garantit que les chiffreurs déployés aujourd'hui resteront conformes aux standards de demain, protégeant l'investissement sur toute la durée de vie de l'équipement.
Cas d'usage haute performance
L'exécution intégrale du chiffrement en FPGA permet d'atteindre des débits de 800 Gbps à 6,4 Tbps en chiffrement de ligne, avec une latence déterministe sub-microseconde. Ces performances ouvrent des cas d'usage inaccessibles aux solutions de chiffrement logiciel.
L'interconnexion de datacenters exige un chiffrement transparent à débit de ligne entre sites distants, sans dégradation de performance. Les backbones télécoms nécessitent un chiffrement de couche 2 capable de traiter des agrégations de trafic massives sans introduire de goulot d'étranglement. Le trading financier haute fréquence impose une latence déterministe et minimale, où chaque microseconde compte. Les réseaux de défense exigent une séparation matérielle absolue entre les données classifiées et le plan de gestion, avec zéroisation instantanée en cas de menace. Dans chacun de ces scénarios, l'architecture AllEyes apporte une réponse matérielle à des exigences que le logiciel seul ne peut pas satisfaire.
Vous avez des questions ?
Audit cryptographique, preuve de concept ou plan de migration — nous sommes là pour en parler.
Parlons-en →Articles suggérés
La menace quantique : pourquoi agir maintenant
Les ordinateurs quantiques progressent rapidement. La migration vers la cryptographie post-quantique ne peut plus attendre.
NIS2 et DORA : ce que les opérateurs critiques doivent savoir
Les directives NIS2 et DORA imposent de nouvelles exigences cryptographiques aux opérateurs critiques européens.
ML-KEM : le standard post-quantique du NIST
FIPS 203, le mécanisme d'encapsulation de clés retenu par le NIST pour l'ère post-quantique.