La protection des données sensibles ne s’arrête pas aux limites du processeur ou d’un système sur une seule puce. Lorsque les instructions et les données sont transférées vers une mémoire externe telle que la DRAM, l’interface mémoire devient une partie de la surface d’attaque, en particulier dans les systèmes spatiaux et gouvernementaux susceptibles de fonctionner dans des environnements contestés et de rester en service pendant des décennies. Un article technique publié dans Semiconductor Engineering, rédigé par Vincent van der Leest et Ajay Kapoor de Rambus, propose une conception visant à protéger cette interface en allant au-delà du chiffrement du contenu pour vérifier qu’il n’a pas été modifié.
L’article a été publié sous la forme d’un Sponsored Blog le 3 septembre 2026. Il convient donc de considérer la présentation d’un produit Rambus comme un exemple commercial de l’approche proposée, et non comme une preuve indépendante de sa supériorité. Le principe technique fondamental est toutefois plus large que le produit lui-même : la mémoire externe a besoin de confidentialité, d’authentification et de résistance à l’altération, ainsi que d’une gestion du cycle de vie des clés.
Le chiffrement masque les données, mais ne prouve pas leur intégrité
La technologie Inline Memory Encryption, ou chiffrement intégré de la mémoire, chiffre les données avant leur écriture dans la mémoire connectée à l’extérieur du système sur puce, puis les déchiffre lorsqu’elles sont récupérées pour être utilisées. Cette opération est généralement réalisée par un moteur de chiffrement placé entre la logique de traitement et le contrôleur mémoire, ce qui permet une protection transparente pour les logiciels tout en préservant les exigences de performance et de temps de réponse.
La confidentialité des données n’est toutefois pas synonyme d’intégrité. Un attaquant n’a pas nécessairement besoin de lire du matériel cryptographique, des données de capteurs ou des instructions d’exécution s’il est capable de modifier une valeur associée à une commande, à des coordonnées ou à une table de recherche. Le même risque s’applique aux données médicales et financières, ainsi qu’aux entrées ou aux paramètres de modèles d’intelligence artificielle, dont la modification peut entraîner des décisions ou des résultats non fiables.
C’est pourquoi l’article propose d’effectuer l’authentification aussi près que possible de l’emplacement de stockage, avant de remettre les données au processeur, aux accélérateurs ou à la logique de contrôle. Réduire la distance parcourue par des données non authentifiées limite le risque de propagation de données corrompues à l’intérieur du système.
Le choix du mode AES dépend des exigences, et non du nom de l’algorithme
AES-XTS est largement utilisé pour le chiffrement des unités de stockage et des mémoires à haut débit. Ce mode repose sur une valeur associée à l’adresse des données, de sorte que le même contenu ne produise pas le même texte chiffré lorsqu’il est stocké à des adresses différentes, sans ajouter de taille aux données protégées. AES-XTS n’offre toutefois que la confidentialité et ne constitue pas un mode de chiffrement authentifié combinant confidentialité et vérification de l’intégrité.
À l’inverse, AES-GCM combine chiffrement et vérification de l’intégrité au moyen d’un tag d’authentification vérifié avant de rendre le texte original disponible. Cela permet de détecter une modification intentionnelle, mais nécessite le stockage et la gestion des tags d’authentification ainsi que des valeurs nonces ou des vecteurs d’initialisation. Cette exigence peut avoir des conséquences sur la capacité mémoire, la bande passante, la répartition des adresses, les mécanismes de mise en cache et la phase d’initialisation.
En pratique, la décision ne devrait pas se limiter à la puissance de l’algorithme. L’ingénieur doit mettre en balance le modèle de menace, le niveau d’assurance requis, l’augmentation de mémoire acceptable, les objectifs de performance et l’architecture globale du système. Dans les systèmes sensibles, la capacité à détecter une modification peut justifier le coût supplémentaire des métadonnées et la complexité accrue de la conception.
La résistance aux attaques par canaux auxiliaires fait partie de la conception
Même des algorithmes mathématiquement corrects ne suffisent pas si leur implémentation divulgue leurs clés par des fuites physiques. L’article indique que l’analyse de la consommation électrique, des rayonnements électromagnétiques ou du temps d’exécution peut aider un attaquant disposant d’un accès physique à l’équipement à déduire les clés, sans casser AES lui-même.
Les mesures de résistance aux attaques par canaux auxiliaires doivent donc être conçues à l’intérieur du moteur de chiffrement, et non ajoutées ultérieurement uniquement au niveau du système. Les éléments de garantie mentionnés dans l’article comprennent la manipulation sécurisée des clés, un comportement prévisible en cas d’erreur, la protection des chemins de contrôle et la capacité à tolérer les défaillances aléatoires. L’article estime également que le recours à une solution éprouvée sur le terrain et à une expérience pratique de la lutte contre l’altération peut réduire les risques d’implémentation et la charge liée à l’établissement de la confiance dans la conception, notamment pour les programmes spatiaux et gouvernementaux.
Quels éléments doivent être tranchés au niveau de la plateforme ?
L’article explique que l’ajout d’un moteur de chiffrement au chemin mémoire ne résout pas tous les problèmes de protection. Les équipes chargées de la conception du système et du moteur de chiffrement doivent traiter plusieurs questions interdépendantes, notamment :
- Actualité des données : vérifier la validité d’une valeur ancienne n’empêche pas sa réinjection. Cela peut nécessiter des compteurs protégés, des informations de version ou un état synchronisé, avec des répercussions sur les métadonnées, la persistance et la reprise.
- Initialisation de la mémoire : les zones protégées peuvent avoir besoin de métadonnées valides avant le démarrage normal, tandis que l’initialisation de grandes mémoires peut influer sur le temps de démarrage et la disponibilité du système.
- Intégration d’une racine de confiance : la fourniture des clés, les politiques de sécurité, la transition entre les étapes du cycle de vie, l’effacement des clés et les mécanismes de reprise doivent être cohérents avec une chaîne de confiance qui commence au démarrage sécurisé et s’étend à la protection de la mémoire pendant le fonctionnement.
Rambus indique que son produit IME-IP-340, conçu pour les applications FPGA, utilise AES-GCM pour chiffrer, déchiffrer et authentifier les transactions mémoire, avec la prise en charge de la gestion d’une mémoire configurable, de la mise en cache, de la gestion des clés et d’options de résistance aux attaques par analyse de la consommation électrique. Selon la présentation de l’entreprise, ces capacités visent à aider les concepteurs à trouver un équilibre entre sécurité et performance, coût des métadonnées et exigences d’intégration.
Lecture éditoriale : les limites sont plus importantes que le moteur de chiffrement
Le changement concret mis en avant par l’article consiste à faire passer la protection de la mémoire du concept de « masquer le contenu » à une notion plus large incluant la détection des modifications et la résistance aux méthodes d’extraction des clés. Cela est important pour les systèmes qui s’appuient sur des données externes pour prendre des décisions ou exécuter des commandes, car l’intégrité des données est aussi importante que leur confidentialité.
Néanmoins, la source ne démontre pas à elle seule les performances d’IME-IP-340 dans des environnements opérationnels déterminés et ne fournit pas de chiffres détaillés sur le temps de réponse, la taille des métadonnées ou les résultats de tests indépendants. De plus, le chiffrement authentifié n’élimine pas la nécessité de concevoir des mécanismes de prévention des rejeux, d’initialisation et de gestion du cycle de vie. Toute solution doit donc être évaluée dans le cadre de l’architecture complète de la plateforme et de son modèle de menace propre, et non considérée comme un composant isolé garantissant automatiquement la sécurité de la mémoire.