Confidential computing : chiffrer la RAM des VM (SEV-SNP, TDX)

On chiffre le disque avec LUKS. On chiffre les flux avec TLS. Reste un trou béant que la plupart des architectures ignorent : la mémoire vive. Au repos et en transit, les données sont protégées. En traitement, elles sont en clair dans la RAM, et tout ce qui a la main sur l'hyperviseur les lit. L'administrateur du host, un hyperviseur compromis, un dump mémoire forcé : la donnée est nue. Sur une infra qu'on ne contrôle pas entièrement, c'est le maillon faible que personne n'adresse avec le chiffrement classique.

Le confidential computing s'attaque exactement à ce trou : chiffrer la mémoire d'une VM pour que même l'opérateur de la machine physique ne puisse pas la lire.

Le triptyque habituel couvre deux états sur trois. Donnée au repos : chiffrée sur disque. Donnée en transit : chiffrée sur le réseau. Donnée en cours de traitement, dans la RAM du serveur où le calcul a lieu : en clair. C'est une nécessité fonctionnelle, le CPU travaille sur des données déchiffrées. Le problème, c'est qui peut observer cette RAM.

Dans une VM classique, l'hyperviseur a un accès complet à la mémoire de ses invités. C'est son rôle : il l'alloue, la mappe, la déplace. Un opérateur cloud, un administrateur du host, ou un attaquant qui a pris l'hyperviseur, peut donc lire la RAM de n'importe quelle VM. Clés de chiffrement chargées en mémoire, secrets applicatifs, données métier en cours de calcul : tout est lisible. Le chiffrement du disque ne sert à rien quand la clé qui le déverrouille traîne en clair dans la RAM, accessible au niveau du dessous.

Le confidential computing renverse cette hypothèse. La définition du Confidential Computing Consortium est nette : protéger la donnée en cours d'utilisation en exécutant le calcul dans un environnement d'exécution de confiance matériel et attesté.

Un TEE (Trusted Execution Environment) est un environnement d'exécution qui garantit trois propriétés, selon la formulation du CCC : confidentialité des données (aucune entité non autorisée ne peut lire les données pendant leur traitement dans le TEE), intégrité des données (aucune entité non autorisée ne peut les modifier), intégrité du code (aucune entité non autorisée ne peut altérer le code qui s'exécute). Le mot clé, c'est matériel : la garantie vient du CPU, pas d'une couche logicielle qu'on pourrait contourner.

Concrètement, le CPU chiffre la mémoire de la VM protégée avec une clé qu'il génère et garde dans le silicium. L'hyperviseur continue d'ordonnancer la VM, de lui donner du temps CPU, de gérer ses I/O, mais il ne voit que du chiffré quand il regarde sa RAM. La clé ne sort jamais du processeur, l'opérateur n'y a pas accès. Deux implémentations dominent côté serveur.

AMD SEV-SNP

SEV (Secure Encrypted Virtualization) chiffre la mémoire par VM avec une clé éphémère propre à chaque invité. La génération SNP (Secure Nested Paging) ajoute ce qui manquait aux versions précédentes : la protection d'intégrité. Sans elle, un hyperviseur malveillant pouvait corrompre, rejouer ou remapper des pages chiffrées sans les lire mais en cassant l'exécution. SNP introduit une Reverse Map Table qui trace la propriété de chaque page mémoire et bloque ces attaques de remapping.

La clé de chiffrement est gérée par le PSP (Platform Security Processor), un coprocesseur de sécurité AMD. C'est aussi lui qui produit le rapport d'attestation, signé par une clé certifiée par AMD.

Intel TDX

TDX (Trust Domain Extensions) crée des VM matériellement isolées appelées Trust Domains, coupées du VMM, de l'hyperviseur et des autres VM par chiffrement et contrôle d'intégrité de la mémoire imposés par le CPU. TDX s'appuie sur MKTME (Multi-Key Total Memory Encryption) pour le chiffrement multi-clés, et sur un module logiciel attesté par le CPU pour la gestion. Chaque Trust Domain reçoit sa propre clé éphémère ; son espace d'adressage est scindé en zones privée et partagée via une Secure-EPT.

Les deux approches convergent sur le résultat : une VM dont la RAM est chiffrée par une clé matérielle inaccessible à l'opérateur. Elles diffèrent dans l'implémentation, et porter une charge d'une plateforme à l'autre n'est pas transparent.

C'est le point qui dérange et qui fait l'intérêt. Le modèle de menace du confidential computing inclut l'hyperviseur et l'opérateur de l'infrastructure dans la liste des entités dont on se protège. On part du principe que le host peut être compromis, ou simplement non fiable, et on veut que la charge reste confidentielle quand même.

Ça vise trois situations. Un hyperviseur compromis par un attaquant qui a pivoté jusque-là. Un administrateur du host curieux ou malveillant. Et le cas souverain, plus subtil : faire tourner une charge sensible sur une infra opérée par un tiers sans avoir à lui faire une confiance aveugle sur la confidentialité de la RAM. La garantie ne repose plus sur un contrat ou sur la bonne foi de l'opérateur, mais sur le matériel.

C'est un angle souveraineté concret. Le chiffrement au repos et en transit protège des fuites externes. Le confidential computing protège de la couche d'en dessous, celle qui opère la machine. Pour qui veut traiter de la donnée sensible sans que l'hébergeur puisse techniquement la lire, c'est la brique qui manquait, et elle complète le raisonnement du cloud souverain au-delà du seul drapeau du datacenter.

Chiffrer la RAM ne suffit pas. Encore faut-il être certain qu'on parle bien à une vraie enclave matérielle, et pas à un hyperviseur qui simule l'environnement pour récupérer le secret qu'on s'apprête à lui livrer. C'est le rôle de l'attestation distante.

Le mécanisme : le matériel (le PSP côté AMD, le module TDX côté Intel) produit un rapport signé cryptographiquement qui décrit l'état de l'enclave, l'empreinte du code chargé, la configuration. Une partie distante vérifie cette signature contre la chaîne de certificats du fabricant. Tant que l'attestation n'est pas validée, on ne livre rien. Une fois prouvé qu'on tourne dans une vraie enclave avec le bon code, on lui transmet les secrets : clés de déchiffrement, identifiants, certificats.

En pratique, ça s'enchaîne souvent avec un gestionnaire de secrets. L'enclave s'atteste, et seulement alors le coffre lui délivre les clés. Le couplage attestation puis libération de secret est exactement le motif qu'on automatise avec HashiCorp Vault pour la gestion centralisée des secrets, et la clé ainsi obtenue déverrouille typiquement un volume protégé par LUKS pour le chiffrement de disque. L'attestation se vérifie elle-même sur un canal authentifié, ce qui suppose une configuration TLS sérieuse côté vérificateur.

Le terme recouvre plusieurs modèles qu'il ne faut pas confondre.

La VM confidentielle, c'est ce qu'on vient de décrire : SEV-SNP ou TDX protègent une machine virtuelle entière, OS compris. La charge tourne sans modification, on hérite de la protection au niveau VM. C'est l'approche la plus directe à adopter, et elle se marie avec une plateforme de virtualisation sur Kubernetes comme KubeVirt pour faire tourner des VM dans un cluster.

Les Confidential Containers (projet CoCo, à base de Kata Containers) descendent au niveau du conteneur : chaque pod tourne dans une micro-VM confidentielle, ce qui apporte la garantie matérielle à une charge conteneurisée sans réécrire l'application.

Les enclaves applicatives (Intel SGX, AWS Nitro Enclaves) relèvent d'un modèle différent. On n'isole pas une VM mais une portion de code applicatif dans une enclave, ce qui impose d'adapter l'application et de découper ce qui tourne dans l'enclave de ce qui reste dehors. Plus fin, plus contraignant, réservé aux cas où on protège un secret très précis.

Le confidential computing n'efface pas tous les risques, et le vendre comme une solution miracle serait malhonnête.

Le surcoût de performance est réel mais modéré pour la plupart des charges. Les mesures empiriques publiées situent l'overhead autour de 2 à 5 % sur du calcul, 4 à 8 % sur la gestion mémoire, et jusqu'à 15 à 25 % sur de l'I/O non optimisé. Acceptable pour beaucoup de cas, à surveiller pour les charges très orientées entrées-sorties, où se concentre le vrai coût.

La complexité de l'attestation est le vrai coût caché. Mettre en place une chaîne d'attestation correcte, vérifier les bons certificats, gérer la révocation, intégrer ça à la livraison de secrets : ce n'est pas trivial, et une attestation mal vérifiée annule la garantie. Le point de fragilité se déplace vers le vérificateur.

Enfin, la garantie est celle du matériel, donc elle dépend de la solidité du matériel. Des travaux de recherche ont montré des attaques physiques visant le bus mémoire DDR5 qui, en accès physique au serveur, cassent la confidentialité des trois technologies en extrayant des clés ; la forge d'attestation, elle, a surtout été démontrée contre SGX et TDX, tandis que pour SEV-SNP la démonstration porte sur l'extraction de clés. Le confidential computing élève fortement la barre contre un opérateur logiciel ou un hyperviseur compromis, son modèle de menace principal. Il ne prétend pas résister à un attaquant qui démonte physiquement la machine avec l'outillage adéquat.

Le confidential computing répond à un vrai problème, longtemps ignoré : la RAM en clair, lisible par l'opérateur de la machine. Pour une charge sensible qui doit tourner sur une infra sans accorder à l'hébergeur une confiance aveugle sur la confidentialité mémoire, SEV-SNP et TDX changent la donne. La garantie passe du contrat au silicium.

Mais ce n'est ni gratuit ni automatique. Sans attestation correctement vérifiée, la VM chiffrée ne prouve rien et le bénéfice s'évapore. La vraie ingénierie n'est pas d'activer le chiffrement mémoire, c'est de construire et maintenir la chaîne d'attestation qui le rend digne de confiance. À adopter quand le modèle de menace inclut l'opérateur, à ne pas survendre comme une protection universelle.

• A Technical Analysis of Confidential Computing : Confidential Computing Consortium : définition de référence du TEE et du confidential computing, modèle de menace et attestation
• General overview of AMD SEV-SNP and Intel TDX : comparaison technique des deux architectures : clés éphémères, Reverse Map Table, Secure-EPT, attestation
• Confidential VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX : mesures empiriques des overheads de performance par type de charge
• ANSSI Technical Position Paper on Confidential Computing : position de l'agence française sur le périmètre de garantie et les limites du modèle
• TEE.Fail: Practical DDR5 Memory-Bus Attack : démonstration d'attaque physique sur le bus mémoire contre SGX, TDX et SEV-SNP