Customer-supplied encryption keys (CSEK) are a feature in Google Cloud Storage and Google Compute Engine. If you supply your own encryption keys, Google uses your key to protect the Google-generated keys used to encrypt and decrypt your data.
Terms used in this topic:
Data encryption key (DEK): A key used to encrypt data.
Key encryption key (KEK): A key used to encrypt, or "wrap", a data encryption key.
Cluster Manager: A collection of processes running under a Cluster Manager identity in Google's production infrastructure. Implements the logic for managing Compute Engine resources such as disks and VM instances. Stores metadata relating to these resources.
Instance Manager: A collection of processes running under an Instance Manager identity in Google's production infrastructure. Executes modifications to VM instances (processes) on the fleet such as VM start/stop or disk attach/detach. Cluster Manager specifies what the state of the VMs should be at any point in time, and Instance Manager works to execute on that.
How customer-supplied encryption keys work
The following provides information on how customer-supplied encryption keys work with Google Cloud Storage and Google Compute Engine.
Cloud Storage
When you use customer-supplied encryption keys in Cloud Storage:
You provide a raw CSEK as part of an API call. This key is transmitted from the Google front end to the storage system’s memory. This key is used as the key encryption key in Google Cloud Storage for your data.
The raw CSEK is used to unwrap wrapped chunk keys, to create raw chunk keys in memory. These are used to decrypt data chunks stored in the storage systems. These keys are used as the data encryption keys (DEK) in Google Cloud Storage for your data.
| Key(s) | Stored in | Purpose | Accessible until |
|---|---|---|---|
| Raw CSEK | Storage system memory | Provided by the customer. Key encryption key (KEK) for chunk keys. Wraps the chunk keys. |
Customer-requested operation (e.g., insertObject or
getObject) is complete |
| Wrapped chunk keys | Storage devices | Protect chunk keys stored at rest | Storage object is deleted |
| Raw chunk keys | Storage devices’ memory | Data encryption key (DEK) for the
data. Read/write data to the disk. |
Customer-requested operation is complete |
Compute Engine
When you use customer-supplied encryption keys in Compute Engine:
You provide a raw CSEK as part of an API call.
- Optionally, you can provide a public-key wrapped CSEK.
This key is transmitted from the Google front end to the Cluster Manager’s front end:
- If a wrapped CSEK was provided, then it is unwrapped using a Google-owned asymmetric wrapping 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 key encryption key in Google 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, where automatic restart is enabled (these are not the same as the instance metadata).
- 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.
- If automatic restart is enabled, the wrapped disk keys are persisted 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 Google 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, Instance Manager, and Virtual Machine. These keys are used as the data encryption keys in Google Compute Engine for your data.
| Key(s) | Held by | Purpose | Accessible until |
|---|---|---|---|
| Raw CSEK | Cluster Manager front end | Provided by the customer. Used to derive the CSEK-derived key by adding a cryptographic nonce. |
Customer-requested operation (e.g., instances.insert,
instances.attachDisk) is complete |
| Public-key wrapped CSEK (Optional - where RSA key wrapping is used) |
Cluster Manager front end | Optionally provided by the customer. Used to derive the CSEK-derived key by first unwrapping with a Google-owned asymmetric key. |
Customer-requested operation is complete |
| Asymmetric wrapping key (where RSA key wrapping is used) |
Google’s internal key management service | Used to unwrap an RSA-wrapped key provided by the customer | Indefinitely |
| CSEK-derived key | Cluster Manager front end | Key encryption key (KEK) for disk keys. Wraps the disk keys. |
Key wrapping or unwrapping operation is complete |
| Google-wrapped disk keys (Optional - where 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 (e.g., host crash) |
VM is stopped or deleted |
| Raw Disk keys | Virtual Machine Monitor (VMM) memory, Cluster Manager (CM) memory |
Data encryption key (DEK) for the data. Read/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 customer-supplied encryption keys are protected
The following provides information on how customer-supplied encryption keys are protected on disk, as they move around the Google Cloud Platform infrastructure, and in memory.
On disk
Raw CSEK, CSEK-derived keys, and raw chunk/disk keys are never stored on disk unencrypted. Raw chunk/disk keys are stored wrapped with CSEK-derived keys, and with Google keys where automatic restart is used. Google does not permanently store your keys on its servers.
As they move around the infrastructure
Each service uses access management features provided by the infrastructure to specify exactly which other services can communicate with it. That service is configured with the whitelist of the allowed service account identities, and this access restriction is then automatically enforced by the infrastructure. Learn more about service identity, integrity, and isolation.
Beyond the RPC authentication and authorization capabilities discussed in the previous sections, 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 customer-supplied encryption keys. Learn more about the encryption of inter-service communications.
In memory
Key material lives in various systems’ memory as detailed above, including Cluster Manager memory and virtual machine monitor memory. Access to these systems’ memory is by exception, e.g., as part of an incident, and managed by access control lists. These systems either have memory dumps disabled, or automatically scan for key material in memory dumps. Access to the jobs themselves are restricted to a small number of Site Reliability Engineers as needed as part of their role to maintain the service, and access to logs to a small number of Software Engineers working on these features for debugging.
Learn more
- Customer-supplied encryption keys in Google Cloud Storage
- Customer-supplied encryption keys in Google Compute Engine