This content was last updated in February 2025 and represents the status quo as of the time that it was written. Google's security policies and systems may change going forward, as we continually improve protection for our customers.
Customer-supplied encryption keys (CSEK) are a feature in Cloud Storage and Compute Engine. If you supply your own encryption keys, Google uses your key to protect the Google generated keys that encrypt and decrypt your data.
This document describes how CSEKs work and how they are protected in Google Cloud.
How CSEKs work with Cloud Storage
When you use CSEKs in Cloud Storage, the following keys are part of the wrapping process:
- Raw CSEK: You provide a raw CSEK as part of an API call. The raw CSEK key is transmitted from the Google Front End (GFE) to the storage system's memory. This key is the key encryption key (KEK) in Cloud Storage for your data.
- Wrapped chunk keys: The raw CSEK is used to wrap the wrapped chunk keys.
- Raw chunk keys: The wrapped chunk keys wrap the raw chunk keys in memory. The raw chunk keys are used to encrypt the data chunks that are stored in the storage systems. These keys are used as the data encryption keys (DEKs) in Cloud Storage for your data.
The following diagram shows the key wrapping process.
The following table describes the keys.
| Keys | Stored in | Purpose | Accessible until |
|---|---|---|---|
Raw CSEK |
Storage system memory |
Protects the wrapped chunk keys. |
Customer-requested operation (for example, |
Wrapped chunk keys |
Storage devices |
Protect raw chunk keys stored at rest. |
Storage object is deleted. |
Raw chunk keys |
Storage devices' memory |
Protect the data that you read or write to the disk. |
Customer-requested operation is complete |
How CSEKs work with Compute Engine
When you use CSEKs in Compute Engine, the following keys are part of the wrapping process:
- Raw CSEK: You provide a raw CSEK or an RSA-wrapped key as part of an API call. The CSEK is transmitted from the GFE to the internal cluster manager's front end. The cluster manager is a collection of processes running under a cluster manager identity in Google's production infrastructure that implements the logic for managing Compute Engine resources such as disks and VM instances.
- Google-owned asymmetric wrapping key: If an RSA-wrapped key is provided as the CSEK, then the key is unwrapped using a Google-owned asymmetric wrapping key.
CSEK-derived key: The raw CSEK is combined with a per-persistent disk cryptographic nonce to generate a CSEK-derived key. This key is used as the KEK in Compute Engine for your data. In the cluster manager front end, both the CSEK and the CSEK-derived key are kept only in the cluster manager memory. The CSEK-derived key is used in the cluster manager memory to unwrap the wrapped disk keys which are stored in the cluster manager instance metadata and instance manager metadata, when automatic restart is enabled (this metadata is not the same as the instance metadata).
Raw disk keys: The CSEK-derived key is used to wrap raw disk keys when creating a disk and to unwrap raw disk keys when accessing a disk. The following events occur:
- If automatic restart is enabled, the wrapped disk keys are stored persistently by the cluster manager for the lifespan of the VM so that the VM can be restarted in the event of a crash. The wrapped disk keys are wrapped with a Google-owned symmetric wrapping key. The permissions of the wrapping key allow it to be used only by Compute Engine. If automatic restart is turned off, the wrapped disk keys are deleted using the deletion process that is described in Data deletion on Google Cloud.
- If live migration is enabled, the raw disk key is passed from the old VM instance memory to the new VM instance memory without the instance manager or cluster manager being involved in the key copy.
The raw disk keys are passed to the memory of the cluster manager (CM), instance manager, and VM. These keys are used as the DEKs in Compute Engine for your data.
The following diagram shows how key wrapping works.
| Keys | Held by | Purpose | Accessible until |
|---|---|---|---|
Raw CSEK |
Cluster manager front end |
Derive the CSEK-derived key by adding a cryptographic nonce. |
Customer-requested operation (for example, |
Public-key wrapped CSEK (when RSA key wrapping is used) |
Cluster Manager front end |
Derive the CSEK-derived key by first unwrapping with a Google-owned asymmetric key. |
Customer-requested operation is complete. |
Google-owned asymmetric key (when RSA key wrapping is used) |
Keystore |
Unwrap the RSA-wrapped key. |
Indefinitely. |
CSEK-derived key |
Cluster manager front end |
Wraps the disk keys. |
Key wrapping or unwrapping operation is complete. |
Google-wrapped disk keys (when automatic restart is used) |
Cluster manager front end |
Protect disk keys stored at rest, for disks attached to running instances. Restart the instance in cases where the VM memory is lost (for example, a host crashes) |
VM is stopped or deleted. |
Raw disk keys |
Virtual machine monitor (VMM) memory, cluster manager memory |
Read or write data to the disk, live-migrate the VM, and perform in-place upgrades |
VM is stopped or deleted |
Google-wrapped CSEK-derived key |
Cluster manager database |
Restart the operation in case of failure |
Customer-requested operation is complete |
How CSEKs are protected
This section provides information on how CSEKs are protected on disk, as they move around the Google Cloud infrastructure, and in memory.
Raw CSEKs, CSEK-derived keys, and raw disk keys are never stored on disk unencrypted. Raw disk keys are stored wrapped with CSEK-derived keys and with Google keys when automatic restart is used. Google doesn't permanently store your keys on its servers.
Each service uses access management features provided by the infrastructure to specify exactly which other services can communicate with it. The service is configured with the allowlist of the allowed service account identities, and this access restriction is then automatically enforced by Google Cloud infrastructure. For more information, see service identity, integrity, and isolation.
The infrastructure also provides cryptographic privacy and integrity for RPC data on the network. Services can configure the level of cryptographic protection they want for each infrastructure RPC, and these are enabled for CSEKs. For more information, see Encryption of inter-workload communication.
Key material lives in various systems' memory, including cluster manager memory and VMM memory. Access to these systems' memory is by exception (for example, as part of an incident) and managed by access control lists. These systems have memory dumps disabled or automatically scan for key material in memory dumps. For information about protections to these jobs, see How Google protects its production services.