Mechanism for MPC-Based TEE Attestation
1. Decentralized Root Key Generation
The core change is replacing the hardware-embedded Attestation Key (AK) with a key generated and managed by an MPC network:
-
MPC Key Generation: A master Root Key ($K_{Root}$) is generated using a $\mathbf{t}$-out-of-$\mathbf{n}$ MPC scheme. The full $K_{Root}$ key never exists on a single machine; it is instantly split into key shares and distributed across $n$ independent MPC nodes.
-
Public Key Publication: The public key corresponding to the MPC-managed $K_{Root}$ is published to a transparent and immutable ledger, such as a smart contract on a blockchain. This is the new, decentralized root of trust that all verifiers will check against.
2. Attestation Report Signing
Instead of the TEE’s internal hardware signing the attestation report directly with a fixed key, it engages with the MPC network:
-
Report Generation: The TEE (e.g., an SGX enclave) generates its Attestation Report (Quote), which contains the crucial measurements of the running code (MRENCLAVE, MRSIGNER).
-
Request to MPC: The TEE or a designated TEE Key Management Service (KMS) sends a request to the MPC network to sign a derived key or the report itself.
-
Key Derivation: The MPC nodes collaboratively perform a Threshold Signature Scheme (TSS) or a Threshold Key Derivation Function (TKDF) using their shares of $K_{Root}$. This operation creates a unique Attestation Signing Key ($K_{Attest}$) tied to the specific TEE’s identity, or directly signs the report. The key derivation can be based on the TEE’s unique identifier and the code measurements, ensuring the derived key is only valid for that exact software/hardware combination.
-
Signature Output: The MPC network produces the digital signature (or the unique $K_{Attest}$ for the TEE) and securely sends it back to the TEE over an authenticated channel. The signature is then included with the attestation report.
3. Remote Verification
The party verifying the TEE’s integrity uses the new public root of trust:
-
Verifier Action: A remote client receives the TEE’s attestation report and its signature.
-
Decentralized Check: The client checks the signature’s validity by using the public key of the MPC-managed $K_{Root}$ that’s recorded on the public ledger (smart contract).
-
Trust Outcome: Since the $K_{Root}$ is secured by a distributed $t$-out-of-$n$ consensus (MPC), the verifier’s trust is placed not in a single hardware vendor, but in the cryptographic consensus of the MPC network.
Advantages of the Hybrid Approach
| Feature | MPC-Derived Attestation Key | Hardcoded/Vendor Attestation Key |
|---|---|---|
| Trust Reliance | Distributed trust across multiple parties. | Centralized trust in a single hardware vendor (e.g., Intel, AMD). |
| Single Point of Failure | Eliminated. An attacker needs to compromise $t$ of $n$ MPC nodes. | High. A security flaw in the single hardware root key or its infrastructure compromises all TEEs using it. |
| Key Management | Enables key rotation and decentralized governance (e.g., a smart contract can govern policy). | Key is permanent and cannot be rotated without a vendor update/revocation mechanism. |
| Vulnerability Mitigation | Allows for immediate blacklisting of compromised TEEs via smart contract/MPC consensus upon discovery of an exploit. | Requires the hardware vendor to issue slow, centralized revocation lists (CRL) to mitigate vulnerabilities. |
