CC and TEE (Confidential Computing and Trusted Execution Environment)
Encrypted zone (EZ) is built upon the foundational hardware security guarantees provided by Confidential computing (CC) Trusted Execution Environments (TEEs). While traditional security perimeters protect data at rest and data in transit, TEEs (such as AMD SEV-SNP or Intel TDX) ensure the confidentiality and integrity of data in use. By running within a TEE, the entire EZ node—including the enforcer, the ratified isolates, and the opaque isolates—is protected by hardware-level memory encryption. This creates a hard security boundary that prevents the host operating system, hypervisor administrators, or the cloud infrastructure provider from inspecting or tampering with the memory space of the workloads.
Relationship between EZ and the TEE
It is critical to understand that a TEE alone only protects the workload from the host infrastructure. It does not govern how the workload behaves internally or what data it chooses to send over the network. Encrypted zone acts as the software-level policy enforcement framework inside the TEE.
While the TEE hardware guarantees that the cloud provider cannot steal user data, the EZ enforcer and manifest guarantee that the proprietary workload itself (the opaque isolate) cannot inadvertently or maliciously exfiltrate that data. Together, they form a complete, end-to-end verifiable privacy boundary.
Transparent endorsement log
To achieve true privacy and transparency, external auditors and clients must be able to verify that the software running inside the TEE is exactly what it claims to be, without relying on unconditional trust in the workload operator. Encrypted zone relies on a transparent endorsement log to provide this verifiable chain of provenance.
When a publisher releases a new version of the EZ enforcer or a ratified isolate, they must generate an endorsement. This endorsement is a signed in-toto statement that cryptographically binds the binary's hash (digest) to specific metadata, such as the publisher's identity, the workload name, and the associated data-flow policies.
This endorsement is submitted to the transparent endorsement log, which certifies that the endorsement was created by the authorized publisher and also publishes the endorsement to an append-only, tamper-proof ledger.
Why this is critical for EZ
- Public auditability: Anyone can inspect the ledger to verify the exact code (using reproducible builds) and policies endorsed by a publisher.
- Preventing targeted attacks: Because the ledger is public and append-only, a malicious actor (or a compromised internal publisher) cannot silently deploy a backdoored version of the enforcer or a ratified isolate to a specific subset of users without that malicious endorsement becoming permanently visible on the public ledger.
Transparent certificate authority
A transparent certificate authority (TCA) is a certificate authority (CA) that runs in a TEE with transparent auditable logging. Its primary role is to act as the ultimate root of trust for the entire transparency system. Because of its critical role, trust in the TCA must be established through open-sourcing its code, using reproducible builds, and recording its own TEE attestation evidence to a tamper-evident, non-repudiable log. The auditor may inspect this evidence to build trust in the TCA.
The model implemented in encrypted zone (EZ) uses standard X.509 certificates and TLS/mTLS to establish session-based security. To support scale and operational separation, the TCA can also bridge to an intermediate transparent CA that offloads the routine signing of leaf certificates for EZ workloads.
CSR validation framework
A TCA performs a rigorous set of validations. As part of a complete CSR validation, the following verifications are performed:
- Attestation evidence verification: Verifying the authenticity and integrity of the attestation token or evidence against platform-specific public keys.
- Hardware root of trust: Validating hardware-level evidence to ensure the request originates from a genuine TEE.
- Transparency log proof of inclusion: Verifying that endorsements are recorded in public logs (like Sigstore Rekor or PES) by approved publishers.
- Digest comparison: Comparing the software digests extracted from the hardware attestation evidence against the validated public endorsements.
- Cryptographic key binding: Ensuring the CSR is cryptographically bound to the attestation evidence by matching public keys or verifying signatures.
- Requester authentication: Authenticating the operator or service account making the request using OIDC and verifying its binding to the CSR (primarily used during the TCA-to-AVS delegation phase).
Only upon successful verification of the applicable elements does the issuing authority grant a certificate, establishing the node's identity (for example, a SPIFFE ID) and enabling it to participate in the secure network.
Ecosystem alignment
Project Oak
The encrypted zone is designed to work synergistically with Project Oak, Google's open-source initiative for verifiable, secure enclaves. While they share the goal of verifiable private computing, they serve complementary layers of the stack:
- Project Oak provides the foundational, low-level secure runtime environment, focusing on strict hardware attestation mechanisms and verifiable, reproducible OS builds. Oak containers provides a full OS suitable for hosting verifiable open source workloads in an attested TEE.
- Encrypted zone (EZ) operates at the orchestration and policy layer. EZ enables decoupling of the policy (open source) from service logic (closed source), and provides the container management and service mesh for private computing—managing data scopes, enforcing routing policies using the IPC bridge, and providing the ratified isolate framework.
EZ uses Project Oak's verification libraries for attestation validation. In the future, Oak containers can potentially serve as an underlying node OS for EZ nodes on platforms without existing trusted TEE OS layers.