2025-11-18T12:28:13.304767

Proof of Cloud: Data Center Execution Assurance for Confidential VMs

Rezabek, Mahhouk, Miller et al.

Confidential Virtual Machines (CVMs) protect data in use by running workloads inside hardware-isolated environments. In doing so, they also inherit the limitations of the underlying hardware. Trusted Execution Environments (TEEs), which enforce this isolation, explicitly exclude adversaries with physical access from their threat model. Commercial TEEs, e.g., Intel TDX, thus assume infrastructure providers do not physically exploit hardware and serve as safeguards instead. This creates a tension: tenants must trust provider integrity at the hardware layer, yet existing remote attestation offers no way to verify that CVMs actually run on physically trusted platforms, leaving today's CVM deployments unable to demonstrate that their guarantees align with the TEE vendor's threat model. We bridge this confidence gap with Data Center Execution Assurance (DCEA), a design generating "Proofs of Cloud". DCEA binds a CVM to its underlying platform using vTPM-anchored measurements, ensuring CVM launch evidence and TPM quotes refer to the same physical chassis. This takes advantage of the fact that data centers are often identifiable via TPMs. Our approach applies to CVMs accessing vTPMs and running on top of software stacks fully controlled by the cloud provider, as well as single-tenant bare-metal deployments with discrete TPMs. We trust providers for integrity (certificate issuance), but not for the confidentiality of CVM-visible state. DCEA enables remote verification of a CVM's platform origin and integrity, mitigating attacks like replay and attestation proxying. We include a candidate implementation on Google Cloud and Intel TDX that leverages Intel TXT for trusted launch. Our design refines CVMs' threat model and provides a practical path for deploying high-assurance, confidential workloads in minimally trusted environments.

academic

Prova del Cloud: Garanzia di Esecuzione del Data Center per VM Confidenziali

Informazioni Fondamentali

ID Articolo: 2510.12469
Titolo: Proof of Cloud: Data Center Execution Assurance for Confidential VMs
Autori: Filip Rezabek, Moe Mahhouk, Andrew Miller, Stefan Genchev, Quintus Kilbourn, Georg Carle, Jonathan Passerat-Palmbach
Classificazione: cs.CR (Crittografia e Sicurezza), cs.DC (Calcolo Distribuito, Parallelo e in Cluster)
Data di Pubblicazione: 14 ottobre 2024 (preprint arXiv)
Link dell'Articolo: https://arxiv.org/abs/2510.12469

Riassunto

Le macchine virtuali confidenziali (CVM) proteggono i dati in uso eseguendo i carichi di lavoro in ambienti isolati a livello hardware. Tuttavia, ereditano anche i limiti dell'hardware sottostante. Gli ambienti di esecuzione attendibili (TEE) applicano questo isolamento, ma i loro modelli di minaccia escludono esplicitamente gli attaccanti con accesso fisico. I TEE commerciali (come Intel TDX) presuppongono che i fornitori di infrastrutture non sfruttino l'hardware a livello fisico. Ciò crea una contraddizione: i tenant devono fidarsi dell'integrità del fornitore a livello hardware, ma le attestazioni remote esistenti non possono verificare se una CVM sia effettivamente in esecuzione su una piattaforma fisicamente attendibile. Questo articolo propone il design della garanzia di esecuzione del data center (DCEA), che genera una "prova del cloud" legando la CVM alla sua piattaforma sottostante attraverso misurazioni ancorate a vTPM, garantendo che le prove di avvio della CVM e i riferimenti TPM puntino allo stesso chassis fisico.

Contesto di Ricerca e Motivazione

Definizione del Problema

Le attuali macchine virtuali confidenziali (CVM) affrontano un difetto di sicurezza critico: mentre i TEE possono provare "quale codice è in esecuzione", non possono provare "dove il codice è in esecuzione". Questo punto cieco "indipendente dalla posizione" consente agli operatori malintenzionati di eseguire carichi di lavoro apparentemente attendibili su hardware sotto il loro controllo, generando al contempo prove valide.

Importanza del Problema

Difetti del Modello di Minaccia: I modelli di minaccia dei TEE commerciali (Intel TDX, AMD SEV-SNP) presuppongono che gli attaccanti non abbiano accesso fisico ai server, ma non è possibile verificare questo presupposto
Casi di Attacco Reali: Recenti attacchi hanno sfruttato l'accesso fisico per estrarre le chiavi di attestazione di Intel SGX
Applicazioni ad Alto Rischio: Settori sensibili come la finanza decentralizzata (DeFi) dipendono sempre più dalla protezione TEE per asset di valore, ma i partecipanti si diffidano reciprocamente

Limitazioni degli Approcci Esistenti

Le attestazioni TEE standard verificano solo il modello della CPU, il microcod e lo stato di avvio, senza includere prove della posizione di installazione del processore
Non è possibile rilevare quando un operatore malintenzionato migra un carico di lavoro in un ambiente non controllato
Mancano meccanismi crittografici per verificare la posizione del TEE

Contributi Principali

Definizione del Modello di Minaccia DCEA: Per scenari CVM e bare-metal, coprendo varie capacità di attaccanti
Progettazione di un'Architettura DCEA Pratica: Legando l'attestazione TD alle misurazioni a livello di piattaforma tramite vTPM
Valutazione della Fattibilità e della Sicurezza del Metodo: Inclusa l'implementazione dettagliata del protocollo e le misure di mitigazione degli attacchi
Fornitura di un'Implementazione di Riferimento: Implementazione candidata su Google Cloud e Intel TDX, utilizzando Intel TXT per l'avvio attendibile

Spiegazione Dettagliata del Metodo

Definizione del Compito

DCEA mira a fornire prove crittografiche ai verificatori remoti, dimostrando che i carichi di lavoro confidenziali non solo vengono eseguiti su stati software e hardware verificati, ma anche in ambienti infrastrutturali noti.

Progettazione dell'Architettura Principale

Doppia Radice di Fiducia

DCEA stabilisce due radici di fiducia parallele:

Radice di Fiducia TEE: Dai produttori di TEE come Intel
Radice di Fiducia Infrastrutturale: Dal provider cloud, implementata tramite TPM/vTPM

Due Scenari di Distribuzione

Scenario Uno (S1): CVM Gestita

La CVM viene eseguita su un hypervisor gestito dal provider, dotato di vTPM
Il provider cloud gestisce il sistema operativo host e l'infrastruttura vTPM
L'associazione viene implementata attraverso verifiche di coerenza tra i riferimenti vTPM e TD

Scenario Due (S2): Distribuzione Bare-Metal

Server bare-metal single-tenant con accesso diretto a TPM discreti
Lo stack software host non è attendibile, affidandosi solo alle garanzie hardware
Sfrutta Intel TXT per stabilire una catena di fiducia dal TPM alla CVM

Dettagli di Implementazione Tecnica

Protocollo DCEA a Quattro Fasi

Stabilimento dell'Avvio Attendibile e della Radice di Piattaforma: Utilizzo di Intel TXT per l'avvio sicuro, misurando gli elementi di avvio iniziali nei PCR 17-18
Configurazione e Sigillamento delle Chiavi di Attestazione: Il TPM genera AK e sigilla il materiale della chiave privata secondo la politica dei PCR 17-18
Associazione delle Prove all'Interno del Guest: TD incorpora l'hash della chiave pubblica AK del vTPM nel suo rapporto di attestazione
Flusso di Lavoro delle Prove Composite del Verificatore: Il verificatore avvia una sfida basata su nonce, ottenendo il rapporto TD e il riferimento TPM

Innovazioni Tecniche Chiave

Verifica Incrociata PCR-RTMR: Rilevamento delle incoerenze confrontando i valori PCR del TPM e i valori RTMR del TD
Meccanismo di Sigillamento delle Chiavi: Sigillamento dell'AK del vTPM a valori PCR specifici, prevenendo l'uso in ambienti non corrispondenti
Associazione Transitiva: Creazione di un'associazione transitiva dalle prove TD alle misurazioni dello stack host attraverso l'hash AK

Analisi di Sicurezza

Modello di Minaccia

Capacità dell'Attaccante: Controllo del sistema operativo host, dell'hypervisor e dello stack di virtualizzazione; capacità di intercettare, ritardare, riprodurre o iniettare messaggi
Limitazioni dell'Attaccante: Impossibilità di effettuare manomissioni fisiche; i produttori di CPU e TPM sono attendibili; l'infrastruttura del provider cloud è attendibile

Vettori di Attacco e Mitigazione

Tipo di Attacco	Descrizione dell'Attacco	Meccanismo di Mitigazione
A1: Falsificazione di Riferimenti/Misurazioni	Falsificazione di riferimenti vTPM o iniezione di valori PCR/RTMR falsi	TD firmato da QE + riferimento AK sigillato
A2: Attacchi di Inoltro/Proxy	Inoltro di richieste di riferimento a una macchina remota onesta	Nonce + hash AK incorporato in TD + AK sigillato
A3: Incoerenza di Misurazione	Valori PCR non corrispondenti a TD-RTMR	Verificatore controlla TD RTMR rispetto a PCR 17-18
A4: Intercettazione/Manomissione del Canale	Attacco man-in-the-middle sul percorso TD a vTPM	Associazione degli endpoint tramite AK + verifiche di firma
A5: Sostituzione di Identità e Chiavi	Falsificazione del certificato TPM-EK o sostituzione dell'AK previsto	Fonte AK ancorata a EK + TD incorpora AKpub previsto
A6: Compromissione di Componenti Privilegiati	Esecuzione di binario vTPM malevolo modificato	Misurazione vTPM/host nei PCR 18

Configurazione Sperimentale e Risultati

Piattaforma di Implementazione

Piattaforma Target: Intel TDX su Google Cloud Platform
Stack Tecnologico: Intel TXT, TPM 2.0, hypervisor QEMU
Ambiente di Test: Host GCP e OVH nella regione canadese

Valutazione delle Prestazioni

Test delle prestazioni su 500 operazioni consecutive su TPM e vTPM:

Tipo di Operazione	TPM Hardware	vTPM
Generazione di Riferimenti	~0,55 secondi	~0,30 secondi
Operazioni di Firma	~0,40 secondi	~0,15 secondi

Risultati Chiave:

Il TPM hardware è circa un ordine di grandezza più lento del vTPM software
Le prestazioni del vTPM sono più stabili, il TPM hardware presenta maggiore variabilità
Per operazioni di attestazione una tantum, il sovraccarico di prestazioni è accettabile

Supporto della Piattaforma Cloud

Piattaforma	Supporto CVM	Supporto vTPM	Supporto Bare-Metal	TPM Hardware
GCP	✓	✓	✓	✓
Azure	✓	✓	×	×
AWS	×	✓	×	×

DCEA colma con successo il divario tra il modello di minaccia TEE e i requisiti di distribuzione effettivi
Attraverso la doppia radice di fiducia e la verifica incrociata PCR-RTMR, difende efficacemente da sei principali attacchi software
L'implementazione su piattaforme hardware esistenti dimostra la fattibilità della soluzione

Limitazioni

Dipendenza dal Flusso di Misurazione PCR: Le misurazioni PCR possono variare tra piattaforme diverse o stack di virtualizzazione
Sfide in Ambienti Multi-Tenant: Il riutilizzo di componenti vTPM può indebolire le garanzie di unicità dell'attestazione
Considerazioni sulla Privacy: La catena di certificati vTPM potrebbe divulgare dettagli di distribuzione

Direzioni Future

Estensione alle Piattaforme AMD: Richiede che AMD SEV-SNP fornisca funzionalità simili a RTMR
Registro Globale delle Chiavi: Stabilimento di una verifica di unicità AK basata su blockchain o trasparenza dei certificati
Integrazione di Prove a Conoscenza Zero: Implementazione di verifica della piattaforma che protegge la privacy

Valutazione Approfondita

Punti di Forza

Importanza del Problema: Affronta un punto cieco di sicurezza critico nella distribuzione di CVM
Innovazione del Metodo: Prima proposta sistematica di uno schema di attestazione vincolato alla posizione
Forte Praticità: Distribuibile su piattaforme commerciali esistenti
Analisi di Sicurezza Completa: Identifica e mitiga molteplici vettori di attacco
Implementazione Completa: Fornisce implementazione dettagliata del protocollo e valutazione delle prestazioni

Insufficienze

Dipendenza dalla Piattaforma: Attualmente limitato principalmente a Intel TDX, supporto AMD limitato
Assunzioni di Fiducia: Richiede ancora fiducia nella sicurezza fisica del provider cloud e nell'emissione di certificati
Sovraccarico di Prestazioni: Le operazioni TPM hardware sono relativamente lente
Complessità: L'implementazione del protocollo è complessa, aumentando la difficoltà di distribuzione

Impatto

Contributo Accademico: Fornisce una nuova dimensione di garanzia di sicurezza nel campo del calcolo confidenziale
Valore Pratico: Significativo per applicazioni ad alto rischio come DeFi
Potenziale di Standardizzazione: Potrebbe influenzare lo sviluppo futuro degli standard TEE

Scenari Applicabili

Applicazioni di finanza decentralizzata (DeFi)
Scenari di calcolo multiparty
Carichi di lavoro di calcolo cloud con requisiti di sicurezza elevati
Applicazioni di calcolo confidenziale che richiedono verifica della posizione

Bibliografia

L'articolo cita 55 lavori correlati, coprendo TEE, specifiche TPM, sicurezza del cloud computing, protocolli crittografici e altri campi importanti, fornendo una base teorica solida per la ricerca.