TrustMee: Self-Verifying Remote Attestation Evidence

1. Problem Statement

Remote attestation is critical for establishing trust in Confidential Virtual Machines (cVMs) and Trusted Execution Environments (TEEs). However, current verification mechanisms suffer from significant limitations:

• Platform-Specific Complexity: Verifiers must implement hardware-specific cryptographic logic and parsing libraries for every supported TEE (e.g., Intel SGX, Intel TDX, AMD SEV-SNP).
• Increased Trusted Computing Base (TCB): Verifiers rely on native plugins or drivers written in memory-unsafe languages (like C/C++ with OpenSSL) to parse certificates and evidence. This introduces bugs and vulnerabilities (e.g., remote code execution) into the verifier itself.
• Maintenance and Scalability: Adding support for a new TEE requires updating the verifier's codebase, recompiling, and redeploying. This creates a "chicken-and-egg" problem where verifiers are incentivized to support fewer platforms to minimize security risks and maintenance costs.
• Fragility: A bug in a verifier plugin for one TEE can compromise the entire verification service, potentially allowing an attacker to impersonate other platforms.

2. Methodology: TrustMee Architecture

The authors propose TrustMee, a platform-agnostic attestation verifier that shifts the burden of platform-specific verification logic from the verifier to the attester.

Core Concept: Self-Verifying Evidence

Instead of hardcoding verification logic, the attesting TEE bundles its specific verification logic as a WebAssembly (Wasm) component alongside the attestation evidence.

• The Attester: Generates the standard attestation evidence and a corresponding Wasm component that implements the logic to parse and validate that specific evidence format.
• The Verifier (TrustMee):
  1. Receives the evidence and the Wasm component.
  2. Measures the Wasm component (checking its hash/signature against a trust store).
  3. Executes the component inside a sandboxed WebAssembly runtime (Wasmtime).
  4. The component parses the evidence, checks endorsements, and outputs a standardized set of claims.
  5. The TrustMee host (platform-agnostic code) applies the appraisal policy to these claims and signs the result in the standard Entity Attestation Token (EAT) format.

Key Technical Components

• WebAssembly Component Model: Uses the Wasm Interface Type (WIT) to define a strict, language-agnostic interface between the host and the component. This ensures that regardless of the TEE, the verifier interacts with the component via a uniform API (evaluate function).
• Sandboxing: The Wasm component runs in a sandbox with restricted access (e.g., limited CPU cycles via "fuel metering," controlled network access, and isolated filesystem). This prevents a malicious or buggy component from crashing the verifier or accessing sensitive host data.
• Trust Model:
  • The verifier trusts the Wasm runtime and the policy engine.
  • Platform-specific logic is untrusted but isolated.
  • The verifier checks the signer of the Wasm component (usually the TEE vendor) and the component's hash against reference values.
  • If a component is unsigned or from an unknown signer, it runs under strict default policies (no network, limited CPU).

3. Key Contributions

1. TrustMee Architecture: A novel design for self-verifying remote attestation where the attester supplies the verification code. This eliminates the need for verifiers to maintain platform-specific drivers.
2. Implementation: A working prototype integrated into the Trustee framework (part of the Confidential Containers project). It includes Wasm verification components for AMD SEV-SNP, Intel TDX, and Intel SGX.
3. Standardization: The system produces results in the standard EAT Attestation Result (EAR) format, ensuring compatibility with existing relying parties.
4. Security Analysis: Demonstrates that isolating platform-specific parsing logic in Wasm significantly reduces the verifier's TCB and mitigates risks associated with memory-unsafe libraries.
5. Performance Evaluation: Quantifies the overhead of the Wasm approach compared to native drivers.

4. Results and Evaluation

The authors evaluated TrustMee against the native Trustee drivers for AMD SNP, Intel TDX, and Intel SGX.

• Compatibility: Successfully verified evidence from three distinct TEE architectures using a single, unmodified verifier host. Adding a new TEE now only requires distributing a new Wasm component, not updating the verifier.
• Security:
  • The Wasm sandbox successfully isolates parsing and cryptographic operations.
  • Malicious components cannot compromise the verifier or impersonate other platforms without being detected by the policy engine (via signer/hash checks).
  • Denial-of-Service (DoS) attacks are mitigated via fuel metering and network restrictions.
• Performance (Latency):
  • Cold Start: Initial verification (including component download and compilation) has higher latency due to network and compilation overhead.
  • Warm Start: Once the component is cached, the overhead is manageable.
    • AMD SNP: Native Wasm verification was ~3.67x slower than native C/Rust drivers, primarily due to the lack of hardware-accelerated crypto in current Wasm runtimes. However, using host-based cryptography (calling native crypto functions from Wasm) reduced this overhead to ~1.47x.
    • Intel TDX/SGX: The Wasm-based verifier using a pure-Rust library (dcap-qvl) was actually faster than the native Trustee driver using Intel's proprietary DCAP library. When compared to a native driver also using dcap-qvl, the Wasm overhead was ~3.17x, but the absolute latency remained low (under 50ms in most cases).
  • Request Size: TrustMee requests are often smaller (up to 37% reduction) than native requests because they use CBOR encoding instead of base64-encoded JSON, offsetting the size of the component identifier.

5. Significance and Future Impact

• Decoupling Verification from Hardware: TrustMee breaks the tight coupling between the verifier and the TEE vendor. This allows cloud providers and verifiers to support new TEEs instantly without code changes.
• Reduced Attack Surface: By moving error-prone parsing and crypto logic into a sandbox, the verifier's TCB is reduced to the core logic and the Wasm runtime, significantly lowering the risk of remote code execution vulnerabilities.
• Scalability: The model shifts the maintenance burden to TEE vendors (who already maintain verification libraries) rather than the verifier operators.
• Extensibility: The architecture supports composite attestation (verifying application layers on top of hardware layers) and can be adapted to other frameworks like Veraison.

Conclusion: TrustMee demonstrates that remote attestation can be made platform-agnostic without sacrificing security or performance. By leveraging WebAssembly to bundle verification logic with evidence, it solves the integration and maintenance bottlenecks of current heterogeneous TEE ecosystems.