Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Ce papier présente DCEA, un mécanisme qui génère une preuve cryptographique garantissant l'exécution des machines virtuelles confidentielles au sein d'un centre de données spécifique en liant les attestations TEE aux preuves matérielles de la plateforme, comblant ainsi la faille de sécurité actuelle qui permet des attaques par relais et mix-and-match.

L'essentiel

🌩️ Le Problème : "Le Mystère de l'Usine Secrète"

Imaginez que vous envoyez un secret très précieux (vos données bancaires, votre génome, ou une recette de cuisine secrète) à un grand fournisseur de nuage (comme Google ou AWS) pour qu'il le traite.

Pour vous protéger, le fournisseur utilise une boîte forte numérique appelée "Confidential VM" (Machine Virtuelle Confidentielle). C'est comme une chambre blindée à l'intérieur de l'ordinateur du fournisseur. Personne, pas même le propriétaire de l'ordinateur, ne peut voir ce qui se passe à l'intérieur de cette chambre.

Mais il y a un piège :
Quand la chambre vous envoie un certificat de sécurité, elle dit : "Je suis bien une chambre blindée, et je fonctionne correctement."
Cependant, elle ne dit pas où elle se trouve.

C'est comme si un voleur vous disait : "Je suis un honnête banquier, voici mon badge." Mais il vous a menti sur son adresse. Au lieu d'être dans une banque sécurisée, il est dans un garage sombre qu'il a lui-même construit. Il a le badge, mais le lieu n'est pas sûr.

Dans le monde du cloud, un fournisseur malhonnête pourrait prendre une machine certifiée, la déplacer dans un endroit non sécurisé (ou la simuler sur un serveur piraté), et vous dire : "C'est toujours la même machine sécurisée." Vous n'avez aucun moyen de le savoir. C'est ce qu'on appelle l'attaque par "proxy" ou "relais".

💡 La Solution : "La Preuve du Nuage" (Proof of Cloud)

Les auteurs de cet article (Filip, Moe, Andrew, et leur équipe) ont inventé une nouvelle méthode appelée DCEA (Data Center Execution Assurance). Leur but ? Créer une "Preuve du Nuage".

Ils veulent prouver non seulement que la chambre blindée est réelle, mais aussi qu'elle se trouve bien dans le bâtiment sécurisé du fournisseur, et pas dans un garage clandestin.

L'Analogie du Double-Sceau

Pour comprendre comment ils font, imaginez un scénario avec deux gardes :

1. Le Gardien de la Chambre (Le TEE) : C'est la technologie qui protège vos données à l'intérieur de la machine. Il a un tampon officiel qui dit : "Je suis une vraie chambre blindée."
2. Le Gardien du Bâtiment (Le TPM) : C'est une puce de sécurité physique située dans l'ordinateur lui-même (le serveur). Elle a un tampon qui dit : "Je suis bien dans le bâtiment de Google, au 3ème étage."

Le problème actuel : Le Gardien de la Chambre peut envoyer son tampon, mais il ne vérifie pas celui du Gardien du Bâtiment. Un voleur pourrait prendre le tampon du Gardien de la Chambre et le coller sur une fausse machine dans un garage.

La solution DCEA (Le "Double-Sceau") :
Le système oblige les deux gardes à se serrer la main à l'intérieur de la machine, avant de vous envoyer la preuve.

• La machine dit : "Voici mon tampon de sécurité (Gardien de la Chambre) ET voici le tampon du bâtiment (Gardien du Bâtiment)."
• Mais le plus important : Les deux tampons doivent correspondre.
• Si le Gardien de la Chambre dit "Je suis dans le nuage" mais que le Gardien du Bâtiment (la puce physique) dit "Je suis dans un garage", les deux tampons ne s'aligneront pas. La preuve sera rejetée.

C'est comme si vous deviez signer un document avec deux stylos différents en même temps : si l'encre ne correspond pas exactement, le document est faux.

🛡️ Comment ça marche concrètement ?

L'article décrit deux façons de mettre cela en place :

1. Le Cas Classique (Cloud Géré) : Vous louez une machine virtuelle. Le fournisseur gère tout. Ici, on fait confiance au fournisseur pour ne pas tricher, mais on vérifie quand même que la machine virtuelle et le serveur physique parlent le même langage.
2. Le Cas "Nu" (Bare-Metal) : Vous avez votre propre serveur physique dans le datacenter. C'est plus sécurisé car vous contrôlez le système d'exploitation, mais le fournisseur possède toujours le bâtiment. Ici, le système vérifie que le serveur physique n'a pas été modifié par un pirate logiciel.

🚫 Pourquoi c'est révolutionnaire ?

Avant, si un hacker contrôlait le logiciel du serveur (le système d'exploitation), il pouvait tromper le système de sécurité en lui faisant croire qu'il était dans un endroit sûr, alors qu'il n'y était pas.

Avec DCEA, même si le hacker contrôle tout le logiciel, il ne peut pas tromper la puce physique (le TPM).

• Imaginez un voleur qui essaie de voler une voiture de luxe. Il peut changer la peinture, le moteur, et même le GPS. Mais il ne peut pas changer le numéro de série gravé dans le châssis de la voiture par le constructeur.
• DCEA force la "chambre blindée" à montrer son numéro de série physique. Si le numéro ne correspond pas à celui du datacenter, vous savez immédiatement que c'est une arnaque.

🎯 En résumé

Cette recherche propose un nouveau standard de confiance pour le cloud computing :

• Avant : "Je vous assure que mes données sont chiffrées." (Mais où ?)
• Maintenant (avec DCEA) : "Je vous assure que mes données sont chiffrées ET que je suis bien dans le bâtiment sécurisé de Google, avec la preuve physique que personne ne peut falsifier."

C'est comme passer d'une simple promesse verbale à un contrat notarié avec une empreinte digitale vérifiée. Cela permet aux entreprises, aux banques et même aux systèmes financiers décentralisés (DeFi) d'avoir confiance dans le lieu où leurs secrets sont traités, même si elles ne font pas confiance à l'opérateur du serveur.

Résumé technique

Voici un résumé technique détaillé de l'article "Proof of Cloud: Data Center Execution Assurance for Confidential VMs", rédigé en français.

1. Problématique : Le Vide de la Preuve de Localisation

Les Machines Virtuelles Confidentielles (CVM) utilisent des Environnements d'Exécution de Confiance (TEE) matériels (comme Intel TDX ou AMD SEV-SNP) pour protéger les données en cours d'utilisation. Cependant, les mécanismes d'attestation actuels souffrent d'une lacune critique : ils certifient ce qui s'exécute (le code, l'état du logiciel), mais pas où cela s'exécute.

• Le risque : Un opérateur malveillant (ou un fournisseur de cloud compromis) peut exécuter une charge de travail certifiée sur du matériel non contrôlé ou dans un environnement physique non sécurisé, tout en fournissant une attestation valide.
• L'attaque "Proxy" (Relais) : Un attaquant peut intercepter les demandes d'attestation d'une machine fiable et les relayer vers une machine non fiable, ou combiner des preuves provenant de différentes machines (attaque "mix-and-match") pour falsifier la preuve d'exécution dans un centre de données de confiance.
• Conséquence : Pour des applications sensibles (DeFi, génomique, banques), l'utilisateur final ne peut pas cryptographiquement vérifier si ses données sont traitées dans le centre de données sécurisé promis par le fournisseur, ni détecter les attaques par canal latéral nécessitant un accès physique.

2. Méthodologie : Data Center Execution Assurance (DCEA)

Les auteurs proposent DCEA, un protocole conçu pour générer une "Preuve de Cloud" (Proof of Cloud). L'objectif est de lier cryptographiquement l'attestation de la CVM à la preuve d'origine de la plateforme matérielle (le châssis physique).

Principes Fondamentaux

DCEA combine deux racines de confiance indépendantes :

1. Le Fabricant du TEE (ex: Intel) : Fournit la preuve de l'intégrité du code et de l'environnement d'exécution isolé (via les rapports TDX/SEV).
2. Le Fournisseur d'Infrastructure (Cloud) : Fournit la preuve de l'environnement physique via un module TPM (Trusted Platform Module) ou vTPM (virtuel).

Architecture et Flux de Confiance

Le protocole fonctionne en deux scénarios principaux :

• Scénario I (CVM managée) : Le fournisseur gère l'hyperviseur et le vTPM. La confiance repose sur l'intégrité opérationnelle du fournisseur.
• Scénario II (Bare-Metal) : Le locataire a un contrôle total sur l'OS hôte et l'hyperviseur, mais le châssis physique reste dans le centre de données sécurisé. C'est le scénario le plus robuste.

Mécanisme de Liaison (Binding) :

1. Mesures Croisées : Le protocole lie les registres de mesure d'exécution du TEE (RTMR dans Intel TDX) aux registres de configuration de la plateforme (PCR dans le TPM).
2. Clés Scellées (Sealing) : La clé d'attestation du vTPM (AK) est "scellée" (cryptographiquement liée) à l'état de démarrage mesuré de l'hôte (via Intel TXT et les PCR 17-18). Cela signifie que la clé ne peut signer une attestation valide que si le logiciel hôte (hyperviseur, OS) correspond exactement à l'état mesuré.
3. Vérification In-Guest : La CVM récupère le rapport d'attestation du TEE et le devis (quote) du vTPM. Elle vérifie que les mesures du TEE correspondent aux mesures du TPM et que la clé utilisée pour signer le devis TPM est bien celle scellée à l'état actuel de la machine.
4. Preuve de Co-localisation : Si un attaquant tente de relayer une attestation d'une autre machine, les mesures (PCR/RTMR) ne correspondront pas, ou la clé scellée ne pourra pas être utilisée, échouant ainsi l'attestation.

3. Contributions Clés

1. Formalisation de la Preuve d'Environnement : Les auteurs définissent formellement le concept de "provenance de l'environnement" comme un objectif de sécurité de premier ordre, comblant le fossé entre la confiance dans le code et la confiance dans le lieu d'exécution.
2. Conception et Implémentation de DCEA : Ils proposent un protocole qui lie les rapports TEE aux devises TPM via un mécanisme de liaison interne à la machine virtuelle (in-guest binding), ancrant la charge de travail sur un châssis physique spécifique.
3. Preuve de Sécurité Formelle : En utilisant le modèle AGATE dans le cadre de la Composition Universelle (UC), ils prouvent que DCEA émule un TEE idéal sensible à la localisation, même en présence d'une pile logicielle hôte malveillante. Cela démontre la résistance aux attaques de relais avancées, y compris l'attaque "mix-and-match".
4. Implémentation et Évaluation : Une preuve de concept a été réalisée sur des instances Intel TDX en mode "bare-metal" sur Google Cloud, utilisant Intel TXT et des TPM discrets. Les résultats montrent des surcoûts de performance minimes, rendant le déploiement pratique.

4. Résultats et Évaluation

• Résistance aux Attaques : Le protocole neutralise six vecteurs d'attaque logiciels (A1-A6), notamment :
  • A1 (Relais/Proxy) : Empêché par le scellage de la clé sur l'état de démarrage spécifique de la machine.
  • A2 (Falsification de devis) : Impossible sans la clé scellée.
  • A3-A6 (Incohérences, interception, substitution) : Détectés par la vérification croisée des mesures (PCR vs RTMR) et la validation des chaînes de certificats.
• Performance : L'implémentation sur Google Cloud montre que l'ajout de DCEA n'introduit qu'un faible surcoût par rapport au flux d'attestation TEE standard, ce qui le rend viable pour des charges de travail réelles.
• Flexibilité : Bien que l'implémentation cible Intel TDX, le protocole est conçu pour être généralisable à d'autres architectures (AMD SEV-SNP, ARM CCA) dès lors qu'elles disposent de primitives d'attestation similaires.

5. Signification et Impact

L'article DCEA représente une avancée majeure pour le calcul confidentiel (Confidential Computing) :

• Changement de Modèle de Menace : Il élève le niveau de sécurité en traitant l'opérateur de l'hôte comme potentiellement malveillant, tout en faisant confiance à l'infrastructure physique du centre de données (le fournisseur de cloud) comme tiers de confiance économique.
• Garantie de Localisation Vérifiable : Pour la première fois, un client distant peut obtenir une preuve cryptographique qu'une charge de travail s'exécute bien sur le matériel d'un fournisseur de cloud spécifique et non sur un serveur local ou un matériel compromis.
• Applications Critiques : Cela ouvre la voie à des déploiements de confiance dans des environnements sans confiance mutuelle, tels que la Finance Décentralisée (DeFi), le traitement de données médicales sensibles, ou les systèmes multi-locataires où l'identité des participants est instable.
• Complémentarité : DCEA ne remplace pas les attestations existantes mais les complète, ajoutant une couche de "Preuve de Cloud" indispensable pour les scénarios où la localisation physique est aussi critique que l'intégrité du code.

En résumé, DCEA transforme la localisation d'exécution d'une hypothèse implicite en une propriété de sécurité vérifiable, renforçant considérablement la confiance dans les infrastructures cloud pour les données sensibles.