Customer-Supplied Encryption Keys

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.

    Cloud Storage CSEK

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.

  • 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. Its permissions allow it to be used only by Google Compute Engine.
    • 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.

    Compute Engine CSEK

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

Was this page helpful? Let us know how we did:

Send feedback about...

Documentation