Introduction

Storing and encrypting data at Google's scale requires using a centralcryptographic key management service with multiple layers of keys for theencrypted data. An example of multiple layer of keys isenvelope encryption,which is the process of encrypting a key with another key.

You can encrypt data at both theapplication layer, which is responsible fordisplaying data to users, and thestorage layer, which provides the physicalstorage of data.

By default, at the storage layer, Google Cloudencryptscustomer content stored at rest using envelope encryption, with Google'sinternal key management service as the central keystore. If you're storing andencrypting data yourself, you can use Cloud Key Management Service as your centralkeystore at the application layer, which is the focus of this topic.

Cloud KMS stores keys in akey hierarchy designed for ease, withaccess to resources in the key hierarchy governed byIdentity and Access Management.The following shows the main levels of a Cloud KMS key hierarchy:

Find out more about the key hierarchy atobject hierarchy.

Data encryption keys

The key used to encrypt data itself is called adata encryption key (DEK).

Here are best practices for managing DEKs:

• Generate DEKs locally.
• When stored, always ensure DEKs are encrypted at rest.
• For easy access, store the DEK near the data that it encrypts.
• Generate a new DEK every time you write the data. This means you don't need torotate the DEKs.
• Do not use the same DEK to encrypt data from two different users.
• Use a strong algorithm such as 256-bit Advanced Encryption Standard (AES) inGalois Counter Mode (GCM).

Key encryption keys

The DEK is encrypted (also known aswrapped) by akey encryption key (KEK).The process of encrypting a key with another key is known asenvelopeencryption.

Here are best practices for managing KEKs:

• Store KEKs centrally.

• Set the granularity of the DEKs they encrypt based on their use case. Forexample, consider a workload that requires multiple DEKs to encrypt theworkload's data chunks. You could use a single KEK to wrap all DEKs thatare responsible for that workload's encryption.

• Rotate keys regularly, and also after a suspected incident. To learn more, seekey rotation.

Balancing DEKs and KEKs

Having a smaller number of KEKs than DEKs and using a central key managementservice makes storing and encrypting data at scale more manageable. A centralkey service also is a singular point to more easily audit and restrict dataaccess.

Depending on your situation, and the volume of data you are encrypting, you maychoose to use a similar model. A single KEK can be used to protect many DEKs;this model permits individual data objects to each have their own DEK withoutmassively increasing the volume of keys stored in a central key managementservice.

Cloud Key Management Service was designed to manage KEKs, and thus the maximum data inputsize forEncrypt andDecrypt functions is 64 KiB. However, for data that youknow will not approach that limit, you could use Cloud KMS toencrypt and decrypt data directly.

How to encrypt data using envelope encryption

The process of encrypting data is to generate a DEK locally, encrypt data withthe DEK, use a KEK to wrap the DEK, and then store the encrypted data and thewrapped DEK. The KEK never leaves Cloud KMS.

To encrypt data using envelope encryption:

1. Generate a DEK locally. You could do this with an open source library such asOpenSSL, specifying a cipher type and a password from which to generate thekey. You can also specify a salt and digest to use, if desired.

2. Use this DEK locally to encrypt your data.

   As an example, you could use OpenSSL as shown in theencrypting themessage example. For best practice, use 256-bit Advanced EncryptionStandard (AES-256) cipher in Galois Counter Mode (GCM).

3. Generate a new key in Cloud KMS, or use an existing key, whichwill act as the KEK. Use this key to encrypt (wrap) the DEK.

4. Store the encrypted data and the wrapped DEK.

1. Retrieve the encrypted data and the wrapped DEK.

2. Use the key stored in Cloud KMS to unwrap the encrypted DEK.

3. Use the plaintext DEK to decrypt the encrypted data. If using OpenSSL asearlier, see thedecrypting the message example.

For sample code that shows how to encrypt and decrypt with envelopeencryption, seeClient-side encryption with Tink and Cloud KMS.

Integration with Google Cloud services

Several Google Cloud products are integrated with Cloud KMSto support Customer-Managed Encryption Key (CMEK) functionality. CMEK withCloud KMS adds an extra layer of protection for your data, providesyou with control of your encryption keys, and leverages the key managementbenefits of Cloud KMS. SeeUsing Cloud KMS with otherservices to see a full list of products that support CMEK.

Other options for Google Cloud services

For data stored in Google Cloud products that do not support CMEK, youcan implement your own application-layer encryption. This requires implementingyour own envelope encryption as described above, so that you store dataencrypted locally in Google Cloud. This is also how you could useCloud KMS to encrypt data you store in other cloud serviceproviders or on premises.

In addition to supporting CMEK, the following products supportCustomer-Supplied Encryption Key (CSEK) functionality.

With CSEK, you supply your own AES-256 key to serve as the KEK, and your keyprotects the DEKs that protect your data. Your CSEK key is protected by anadditional layer of protection, using a Cloud KMS key.

Now that you canimport keys into Cloud KMS, you canimport your keys and use them with CMEK-enabled services instead of relying onCSEK.