TrustMee: Self-Verifying Remote Attestation Evidence

1. Enunciazione del Problema

L'attestazione remota è fondamentale per stabilire la fiducia nelle Macchine Virtuali Confidenziali (cVM) e negli Ambienti di Esecuzione Fidati (TEE). Tuttavia, i meccanismi di verifica attuali soffrono di limitazioni significative:

• Complessità specifica della piattaforma: I verificatori devono implementare logica crittografica e librerie di parsing specifiche per l'hardware per ogni TEE supportato (ad esempio, Intel SGX, Intel TDX, AMD SEV-SNP).
• Aumento della Base di Calcolo Fidata (TCB): I verificatori si affidano a plugin nativi o driver scritti in linguaggi non sicuri per la memoria (come C/C++ con OpenSSL) per analizzare certificati ed evidenze. Questo introduce bug e vulnerabilità (ad esempio, esecuzione di codice remoto) nel verificatore stesso.
• Manutenzione e scalabilità: Aggiungere il supporto per un nuovo TEE richiede l'aggiornamento del codice del verificatore, la ricompilazione e la ridistribuzione. Ciò crea un problema "chicken-and-egg" in cui i verificatori sono incentivati a supportare meno piattaforme per minimizzare i rischi di sicurezza e i costi di manutenzione.
• Fragilità: Un bug in un plugin di un verificatore per un TEE può compromettere l'intero servizio di verifica, permettendo potenzialmente a un attaccante di impersonare altre piattaforme.

2. Metodologia: Architettura TrustMee

Gli autori propongono TrustMee, un verificatore di attestazione agnostico rispetto alla piattaforma che sposta l'onere della logica di verifica specifica della piattaforma dal verificatore all'attestatore.

Concetto Chiave: Evidenza Auto-Verificante

Invece di codificare la logica di verifica, il TEE che attesta include la propria logica di verifica specifica come componente WebAssembly (Wasm) insieme all'evidenza di attestazione.

• L'Attestatore: Genera l'evidenza di attestazione standard e un corrispondente componente Wasm che implementa la logica per analizzare e validare quel formato specifico di evidenze.
• Il Verificatore (TrustMee):
  1. Riceve l'evidenza e il componente Wasm.
  2. Misura il componente Wasm (verificando il suo hash/firma contro un archivio di fiducia).
  3. Esegue il componente all'interno di un runtime WebAssembly in sandbox (Wasmtime).
  4. Il componente analizza l'evidenza, verifica le endorsement ed elabora un set standardizzato di affermazioni.
  5. L'host TrustMee (codice agnostico rispetto alla piattaforma) applica la politica di valutazione a queste affermazioni e firma il risultato nel formato standard Entity Attestation Token (EAT).

Componenti Tecnici Chiave

• Modello Componenti WebAssembly: Utilizza il Wasm Interface Type (WIT) per definire un'interfaccia rigorosa e agnostica rispetto al linguaggio tra l'host e il componente. Ciò garantisce che, indipendentemente dal TEE, il verificatore interagisca con il componente tramite un'API uniforme (funzione evaluate).
• Sandboxing: Il componente Wasm viene eseguito in una sandbox con accesso limitato (ad esempio, cicli CPU limitati tramite "fuel metering", accesso di rete controllato e filesystem isolato). Ciò impedisce a un componente malintenzionato o difettoso di bloccare il verificatore o di accedere a dati sensibili dell'host.
• Modello di Fiducia:
  • Il verificatore si fida del runtime Wasm e del motore di policy.
  • La logica specifica della piattaforma è non fidata ma isolata.
  • Il verificatore controlla il firmatario del componente Wasm (solitamente il vendor del TEE) e l'hash del componente rispetto ai valori di riferimento.
  • Se un componente non è firmato o proviene da un firmatario sconosciuto, viene eseguito sotto policy predefinite severe (nessuna rete, CPU limitata).

3. Contributi Chiave

1. Architettura TrustMee: Un design innovativo per l'attestazione remota auto-verificante in cui l'attestatore fornisce il codice di verifica. Ciò elimina la necessità per i verificatori di mantenere driver specifici per la piattaforma.
2. Implementazione: Un prototipo funzionante integrato nel framework Trustee (parte del progetto Confidential Containers). Include componenti di verifica Wasm per AMD SEV-SNP, Intel TDX e Intel SGX.
3. Standardizzazione: Il sistema produce risultati nel formato standard EAT Attestation Result (EAR), garantendo compatibilità con le parti affidabili esistenti.
4. Analisi di Sicurezza: Dimostra che isolare la logica di parsing specifica della piattaforma in Wasm riduce significativamente la TCB del verificatore e mitiga i rischi associati a librerie non sicure per la memoria.
5. Valutazione delle Prestazioni: Quantifica l'overhead dell'approccio Wasm rispetto ai driver nativi.

4. Risultati e Valutazione

Gli autori hanno valutato TrustMee rispetto ai driver nativi Trustee per AMD SNP, Intel TDX e Intel SGX.

• Compatibilità: Ha verificato con successo evidenze provenienti da tre diverse architetture TEE utilizzando un singolo host verificatore non modificato. Aggiungere un nuovo TEE richiede ora solo la distribuzione di un nuovo componente Wasm, non l'aggiornamento del verificatore.
• Sicurezza:
  • La sandbox Wasm isola con successo le operazioni di parsing e crittografiche.
  • I componenti malintenzionati non possono compromettere il verificatore o impersonare altre piattaforme senza essere rilevati dal motore di policy (tramite controlli di firmatario/hash).
  • Gli attacchi di Denial-of-Service (DoS) sono mitigati tramite fuel metering e restrizioni di rete.
• Prestazioni (Latenza):
  • Avvio a freddo: La verifica iniziale (incluso il download e la compilazione del componente) presenta una latenza più elevata a causa dell'overhead di rete e di compilazione.
  • Avvio a caldo: Una volta memorizzato nella cache il componente, l'overhead è gestibile.
    • AMD SNP: La verifica Wasm nativa è stata circa 3,67 volte più lenta rispetto ai driver nativi C/Rust, principalmente a causa della mancanza di crittografia accelerata dall'hardware nei runtime Wasm attuali. Tuttavia, l'uso della crittografia basata sull'host (chiamando funzioni crittografiche native da Wasm) ha ridotto questo overhead a circa 1,47 volte.
    • Intel TDX/SGX: Il verificatore basato su Wasm che utilizza una libreria puramente Rust (dcap-qvl) è stato effettivamente più veloce del driver nativo Trustee che utilizza la libreria proprietaria DCAP di Intel. Confrontato con un driver nativo che utilizza anch'esso dcap-qvl, l'overhead Wasm è stato di circa 3,17 volte, ma la latenza assoluta è rimasta bassa (sotto i 50 ms nella maggior parte dei casi).
  • Dimensione della richiesta: Le richieste TrustMee sono spesso più piccole (riduzione fino al 37%) rispetto alle richieste native perché utilizzano la codifica CBOR invece di JSON codificato in base64, compensando la dimensione dell'identificatore del componente.

5. Significato e Impatto Futuro

• Disaccoppiamento della verifica dall'hardware: TrustMee rompe il forte accoppiamento tra il verificatore e il vendor del TEE. Ciò consente ai provider cloud e ai verificatori di supportare nuovi TEE istantaneamente senza modifiche al codice.
• Riduzione della superficie di attacco: Spostando il parsing soggetto a errori e la logica crittografica in una sandbox, la TCB del verificatore si riduce alla logica di base e al runtime Wasm, abbassando significativamente il rischio di vulnerabilità di esecuzione di codice remoto.
• Scalabilità: Il modello sposta l'onere della manutenzione sui vendor dei TEE (che già mantengono librerie di verifica) piuttosto che sugli operatori del verificatore.
• Estendibilità: L'architettura supporta l'attestazione composita (verifica dei livelli applicativi sopra i livelli hardware) e può essere adattata ad altri framework come Veraison.

Conclusione: TrustMee dimostra che l'attestazione remota può essere resa agnostica rispetto alla piattaforma senza sacrificare sicurezza o prestazioni. Sfruttando WebAssembly per associare la logica di verifica all'evidenza, risolve i colli di bottiglia di integrazione e manutenzione degli attuali ecosistemi eterogenei di TEE.