software

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

Published: (January 5, 2026 at 09:56 PM EST)
9 min read
Source: Google Developers Blog

Source: Google Developers Blog

DEC. 9, 2025

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

While encryption for data‑at‑rest (on disk) and data‑in‑transit (over the network) are well‑understood problems, the “data‑in‑use” challenge is often overlooked. This is where Confidential Computing comes in, providing 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’ll 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 key challenges:

  1. Trust and Transparency
    Customers need a way to verify the privacy properties of the code that processes their data. Open‑sourcing the entire application would solve this, but it’s a non‑starter for businesses that must protect valuable intellectual property, proprietary algorithms, or sensitive AI models.
    How can an operator prove their service is confidential without revealing the very source code that makes it valuable?

  2. 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 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’s 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,
  • 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 workload transparency isn’t possible (e.g., proprietary code), we run the application logic inside a containerized, verifiably private sandbox: Oak Functions. The sandbox prevents the business‑logic code from:

  • logging or storing data outside the TEE,
  • creating arbitrary network connections,
  • interacting with the untrusted host except through explicitly allowed, controlled interfaces.

Result: The user’s trust is anchored in the well‑defined, open‑source sandbox (which anyone can reproducibly build) and the sandbox developer’s endorsement, not the specific logic it executes. This simplifies the trust story: users only need to verify the small, transparent Oak Functions container image instead of a complex custom application.

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

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

Key Features of Oak Session

  • 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 at the load balancer, the inner data remains protected.
  • Noise protocol framework – While TLS could be used for the nested channel, Oak Functions opts for the Noise framework, which offers flexibility and strong cryptographic guarantees.

How It Works (High‑Level Flow)

  1. Attestation – The Confidential Space instance produces an attestation document proving it is running the expected Oak Functions container.
  2. Verification – The client verifies the attestation (signature, measurements, etc.) to ensure it is communicating with a genuine, untampered enclave.
  3. Session Establishment – Using Oak Session (Noise), the client and enclave perform a mutual key exchange, establishing a symmetric encryption key that only the enclave and the client know.
  4. Data Transfer – All payloads are encrypted with this session key, providing confidentiality and integrity even if the outer TLS connection is terminated at the load balancer.

Putting It All Together

By combining:

  • Google Cloud Confidential Space for hardware‑rooted isolation and attestation,
  • Oak Functions for a minimal, open‑source, reproducible sandbox, and
  • Oak Session for nested, end‑to‑end encryption,

we achieve a scalable, confidential service that:

  • Preserves data privacy throughout its lifecycle (at rest, in transit, and in use).
  • Allows customers to verify the confidentiality guarantees without exposing proprietary code.
  • Supports load‑balanced deployments without expanding the TCB to the load balancer.

References

Secure Channel Protocols Based on Diffie‑Hellman

A key advantage of Noise is its simplicity compared to a full‑blown TLS stack. Our implementation of Noise handshakes and the resulting encrypted channel is about 2.5 K LOC, compared to BoringSSL’s 1.2 M LOC. This small code footprint provides a more auditable set of cryptographic primitives, making it easier to implement correctly and verify.

Attestation

The trusted execution platform environment provides a signed report confirming its integrity and the identity of the workload running within its hardware‑isolated memory enclave. Oak Session is a composable framework that allows assertions to be exchanged and verified. In the case of Confidential Space, the assertion consists of:

  • Binding verification key (public key).
  • Signature of a session token derived from the nested encryption handshake. This signature can be verified with the binding verification key (see Session Binding below).
  • 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 alone is the first step toward establishing the identity of the platform, its parameters (system image, environment configuration, etc.), and the workload itself. However, the JWT alone is not sufficient—a malicious operator could exfiltrate it and replay it in other workloads. The binding key and session token prevent this, completing the picture.

Session Binding

This critical step connects the secure channel to the attestation JWT.

  1. During the handshake, both parties derive a unique session token, bound to the cryptographic identity of the session.
  2. The enclave signs this token with a private binding key that is cryptographically tied to its attestation assertion (by including the fingerprint of the verification key).
  3. By verifying this signature, the client confirms that the entity it performed the handshake with is the exact same one that was attested to by the hardware, preventing MITM and replay attacks where an old or invalid attestation could be used to bootstrap a new, malicious session.

In our example we use the hash of the Noise handshake transcript.
For a TLS channel, the session token may be created based on the Exported Key Material (EKM).

While the session token could be placed directly in the JWT eat_nonce, that would require one attestation per connection, increasing latency and exhausting the default quota of 5 QPS per project (quota details). Introducing the binding key decouples JWT requests from the critical serving flows.

Establishing Trust

Below is an excerpt of a JWT token showing platform setup and workload identity. Note the inclusion of the OCI registry and image digest.

{
  "aud": "oak://session/attestation",
  "iss": "https://confidentialcomputing.googleapis.com",
  "sub": "https://www.googleapis.com/compute/v1/projects/oak-functions/zones/us-west1-b/instances/oak_functions",
  "eat_nonce": "d3ee341dbbf8986b11e14db61bece35c02a18943ac6bbcd3868cb00676210fa4",
  "submods": {
    "container": {
      "image_reference": "europe-west1-docker.pkg.dev/oak-examples/c0n741n3r-1m4635/echo_enclave_app:latest",
      "image_digest": "sha256:2f81b55712a288bc4cefe6d56d00501ca1c15b98d49cb0c404370cae5f61021a"
    }
  }
}

Verification Steps

  1. Validate the JWT – check its signature and expiration date.
  2. Match the binding verification key to the fingerprint in the eat_nonce field.
  3. Verify the session token signature using the binding verification key.
  4. Confirm the platform setup and parameters in the JWT match expected values.
  5. Validate the container field against an expected value.

After completing these steps, the client has established trust in the platform, its configuration, and the workload.

Managing Expected Container Identity

Oak Functions is reproducibly buildable, so a client could build the OCI image locally and compare its digest to the one in the JWT. However, because Oak Functions is released periodically, constantly rebuilding and verifying each image becomes impractical.

The classic software‑engineering solution is indirection:

  • Trust any OCI image that originates from a trusted OCI registry and repository to which only the Oak team can publish.
  • This approach constitutes an endorsement of the image source.

More advanced endorsement mechanisms (e.g., signed provenance statements) can be layered on top of this basic model, but the core idea remains: the client trusts the registry‑repository pair rather than a specific image digest, simplifying verification while maintaining security.

Cosign signatures and provenance statements – A well‑known example is Cosign, which is natively supported in Confidential Space.

Conclusion: Your Path to Trusted Confidential Computing and Beyond

Google Cloud’s confidential‑computing architecture and the technologies developed by Project Oak give organizations the best of both worlds: standard, scalable infrastructure and verifiable, end‑to‑end data confidentiality. The diagram below illustrates the main components and the sequence of interactions between them until the channel is opened.

Oak session diagram

Google Cloud, in collaboration with open‑source security tools from Project Oak, provides a complete solution to protect your most sensitive data‑in‑use within standard, scalable cloud architectures.

What’s Next: Powering Secure Generative AI and Agentic Experiences

The principles discussed enable you to unlock new business opportunities through secure data collaboration and to provide cryptographic, auditable proof of your security and privacy posture to customers and regulators—even when the provider’s workload must remain proprietary due to intellectual‑property concerns (e.g., AI, healthcare, genomic research).

As businesses increasingly adopt Generative AI, protecting proprietary models, sensitive prompts, and confidential data processed by AI agents becomes paramount. With the availability of GPUs in Confidential Space, Google Cloud extends hardware protections to demanding AI workloads.

Imagine an AI agent processing your confidential corporate data to provide insights.
By combining Confidential Space with GPUs running open‑source models (e.g., Gemma), Oak Functions, and Oak Session, you can secure prompts and responses, building agentic experiences that are powerful and verifiably secure and private. This framework supplies the trust needed to deploy GenAI in high‑stakes, enterprise environments.

Call to Action

Back to Blog

Related posts

Read more »