Appendix: Google Cloud Workload Services Daemon

The key-management and attestation interfaces exposed to a node’s workload container.

Overview

A node exposes its key-management and attestation operations through the Workload Services Daemon. The daemon runs inside the confidential VM alongside the workload container and acts as its security proxy: private keys stay in the Key Protection Service VM, and the daemon gathers the attestation evidence, so the container obtains Titan TPM and TDX evidence only through the daemon. The container reaches the GPUs directly, through the device nodes it needs for model execution and GPU health polling. For everything else, the container interacts with the daemon over local Unix domain sockets, and the daemon bridges those requests to internal services:

Key-management interface: Manages key-encapsulation mechanism (KEM) key pairs and performs decapsulation for request termination. Private keys stay inside the dedicated Key Protection Service VM, which the daemon reaches over a gRPC bridge; within that VM, memfd_secret further isolates the key material from the VM’s other processes.
Attestation Service: Gathers Intel TDX quotes from the confidential VMs, host Titan TPM quotes from the Host Services Daemon, and NVIDIA GPU attestation reports from the NVIDIA driver, returning endorsements that bind keys to this evidence.

For the node’s key-protection architecture, attestation evidence binding, and verification procedures, see Google Cloud Node Attestation. Appendix: Google Cloud Attestation Bundle Contents gives the wire format of the attestation bundle.

Interacting with the daemon

The daemon listens on two Unix domain sockets mounted inside the workload container at /run/container_launcher/:

kmaserver.sock: The key-management interface.
teeserver.sock: The Attestation Service.

Both interfaces speak HTTP over Unix domain sockets. In the Google Cloud Research Environment, curl reaches these endpoints directly:

% curl --unix-socket /run/container_launcher/kmaserver.sock http://localhost/v1/capabilities

The underlying API schemas are defined as protobufs in the open source key-protection-module repository, and the endpoints exchange those messages in their JSON encoding.

Key-management interface

The key-management interface on kmaserver.sock manages the life cycle of KEM keys and performs decapsulation:

GET /v1/capabilities: Lists the supported KEM algorithms, such as KEM_ALGORITHM_DHKEM_X25519_HKDF_SHA256.
POST /v1/keys:generate_key: Requests a new KEM key pair. The request specifies the algorithm and an optional lifespan in seconds. The private key remains isolated within the Key Protection Service VM; the daemon returns a UUID key_handle, the public key, and the expiration timestamp.
GET /v1/keys: Lists active KEM keys, their handles, public keys, and expiration times.
POST /v1/keys:decap: Performs KEM decapsulation. The caller provides the key_handle and the base64-encoded encapsulated ciphertext. The Key Protection Service decapsulates the ciphertext within its own VM boundary, encrypts the resulting shared secret to the daemon’s binding key, and returns the encrypted secret over the gRPC bridge. The daemon decrypts the secret and returns the decrypted shared_secret.
POST /v1/keys:destroy: Destroys a key pair identified by key_handle before its lifespan expires.

Attestation Service

The Attestation Service on teeserver.sock gathers attestation evidence from across the node’s hardware and firmware roots:

POST /v1/keys:getEndorsement: Generates an attestation endorsement binding a specific KEM key to the node’s evidence. The caller provides a base64-encoded verifier challenge and the key_handle.
POST /v1/hostAttestation: Collects attestation evidence for the physical host. The daemon forwards the verifier challenge to the Host Services Daemon running on the host operating system, returning the host Titan TPM quote, Device Identifier Composition Engine (DICE) certificate chain, and boot and launch event logs.

The POST /v1/keys:getEndorsement response returns two endorsements, each covering a serialized KeyClaims message that sets one of two claim types:

protected_key_attestation: The Intel TDX quote and event logs (the firmware Confidential Computing Event Log (CCEL) and the launch Canonical Event Log (CEL)) for the Key Protection Service VM. This endorsement carries VmProtectionKeyClaims, in which the Key Protection Service attests that it holds the KEM private key and will encrypt every resulting shared secret to the binding key; the message gives the KEM public key, the binding public key, and the KEM key’s expiration time.
binding_key_attestation: The Intel TDX quote for the Workload VM, with the firmware CCEL and the launch CEL. The launch CEL carries the attached NVIDIA GPU attestation reports, so the workload quote’s RTMR[3] covers them. This endorsement carries VmProtectionBindingClaims, a single field naming the binding public key whose private half the Workload VM attests to controlling.