Don't Trust, Verify: Building End-to-End Confidential Applications on Google Cloud

Source: Google Developers Blog

In today’s data‑driven world, many valuable insights rely on sensitive data categories—whether processing personally identifiable information (PII) for personalized services, collaborating on confidential datasets with partners, or analyzing sensitive financial information. Protecting data not only at rest or in transit but also during processing has become a critical business requirement.

While encryption for data at‑rest (on disk) and in‑transit (over the network) are well‑understood problems, the “data‑in‑use” challenge is often overlooked. Confidential Computing provides hardware‑level protection for data even while it’s being processed.

This post demonstrates how, with Google Cloud’s Confidential Space, organizations can build an end‑to‑end confidential service. We show how an end user can gain cryptographic assurance that their sensitive data is processed only by verified code running inside a secure, hardware‑isolated environment—even when the service is deployed using a scalable, load‑balanced architecture.

The Challenge of Trust and Confidentiality at Scale

Running a confidential service in a modern, scalable cloud environment introduces two challenges:

• Trust and Transparency: Customers need a way to verify the privacy properties of the code that processes their data. Open‑sourcing the entire application is often infeasible for businesses that must protect intellectual property, proprietary algorithms, or sensitive AI models. This creates a fundamental tension: how can an operator prove their service is confidential without revealing the very source code that makes it valuable?
• Scalability: Modern cloud applications are built for resilience and scale, typically running multiple service instances behind a load balancer. Terminating TLS at the load balancer simplifies key management but exposes plaintext data in the load balancer for inspection and routing, breaking end‑to‑end confidentiality and expanding the trusted computing base (TCB). Terminating TLS in each backend server would require securely distributing and managing TLS private keys across all instances, making those keys part of the workload’s attack surface.

Anchoring Trust with Google Cloud Confidential Space & Oak Functions

The solution starts with a strong, hardware‑enforced foundation: Google Cloud Confidential Space. It is a hardened Trusted Execution Environment (TEE) built on state‑of‑the‑art confidential computing hardware. It creates a hardware‑isolated memory enclave where code and data are protected from the host OS, other tenants, the cloud provider, or even the cloud project owner. The key primitive it provides is attestation—a signed report from the platform that proves the environment’s integrity and the identity of any Open Container Initiative (OCI) container running inside.

When full source‑code transparency is not possible, we run the application logic inside a containerized, verifiably private sandbox: Oak Functions. The sandbox prevents the business‑logic code from logging, storing data to disk, creating network connections, or interacting with the untrusted host except through explicitly allowed, controlled interfaces. This keeps a user’s sensitive data private.

The user’s trust is anchored in the well‑defined sandbox (which is open source and reproducibly buildable by anyone) and the sandbox developer’s endorsement, not the specific logic it executes. This simplifies the trust story: the user only needs to verify the small, transparent, open‑source Oak Functions container image rather than auditing a complex custom application.

Establishing Trust with Attested End‑to‑End Encryption with Oak Session

To enable a trusted connection over a load‑balanced path, we layer application‑level encryption on top of standard network‑level TLS using Oak Session, an open‑source library that implements an end‑to‑end encrypted session protocol. Oak Session builds a secure channel directly with the application logic inside the enclave, even when routed through untrusted intermediaries like a load balancer.

Nested End‑to‑End Encryption Channel

An encrypted channel is opened inside the outer TLS connection, directly with the confidential workload. Even if the outer TLS connection is terminated by the load balancer, the inner data remains protected. While TLS could be used for this nested channel, Oak Functions opts for the Noise framework instead.

Noise provides a flexible, lightweight framework for secure channel protocols based on Diffie‑Hellman key exchange. Its simplicity—about 2.5 K lines of code for our implementation versus 1.2 M LOC for BoringSSL—yields a smaller, more auditable cryptographic footprint.

Attestation

The confidential execution platform supplies a signed report confirming its integrity and the identity of the workload running within its hardware‑isolated enclave. Oak Session uses this attestation as part of a composable framework that allows assertions to be exchanged and verified. In Confidential Space, the attestation consists of:

• A binding verification key (public key).
• A signature of a session token derived from the nested encryption handshake, verifiable with the binding verification key.
• An attestation JSON Web Token (JWT) signed by the Google Cloud Attestation service. The JWT contains, among many other claims, the fingerprint of the verification key in the eat_nonce field.

The JWT establishes the platform’s identity, platform parameters (system image, environment configuration, etc.), and the workload’s identity. However, the JWT alone is insufficient: it could be exfiltrated and replayed by a malicious operator. The binding key and session token prevent this replay, completing the trust picture.

Session Binding

This critical step connects the secure channel to the attestation JWT. During the handshake, both parties… (content truncated).