Default encryption at rest  |  Documentation  |  Google Cloud (2024)

This content was last updated in September 2022 and represents the status quoas of the time that it was written. Google's security policies and systems maychange going forward, as we continually improve protection for our customers.

At Google, our comprehensive security strategy includes encryption at rest,which helps to protect customer content from attackers. We encrypt all Googlecustomer content at rest, without any action required by you, using one or moreencryption mechanisms. This document describes our approach to defaultencryption at rest for Google infrastructure and Google Cloud, and how we use itto keep customer information more secure.

This document is for security architects and security teams who are currentlyusing or considering Google. This document assumes a basic understanding ofencryption andcryptographic primitives.For more information on cryptography, seeIntroduction to Modern Cryptography.

Encryption at rest is encryption that is used to help protect data that isstored on a disk (including solid-state drives) or backup media. All data thatis stored by Google is encrypted at the storage layer using the AdvancedEncryption Standard (AES) algorithm, AES-256. We use a common cryptographiclibrary, Tink, which includes our FIPS 140-2 validated module (namedBoringCrypto)to implement encryption consistently across Google Cloud.

We manage the keys used in default encryption at rest. If you useGoogle Cloud, Cloud Key Management Service lets you create your own encryption keys thatyou can use to add envelope encryption to your data. Using Cloud KMS,you can create, rotate, track, and delete keys. For more information, seeCloud Key Management Service deep dive.

How encryption at rest helps to secure data

Encryption at rest is one piece of a broader security strategy. Encryption hasthe following benefits:

• Helps to ensure that if data falls into an attacker's hands, theattacker cannot read the data without also having access to the encryptionkeys. Even if attackers obtain the storage devices that contain customerdata, they won't be able to understand or decrypt it.
• Helps to reduce the surface of attack by cutting out the lower layers ofthe hardware and software stack.
• Acts as a chokepoint because centrally managed encryption keys create asingle place where access to data is enforced and can be audited.
• Helps to reduce the attack surface because instead of having to protectall data, businesses can focus their protection strategies on theencryption keys.
• Provides an important privacy mechanism for our customers. When data isencrypted at rest, it limits the access that systems and engineers have tothe data

What is customer data?

As defined in theGoogle Cloud terms of service,customer data is data that customers or end users provide to Google throughthe services under their account. Customer data includes customer content andmetadata.

Customer content is data that you generate yourself or provide to us, like datastored in Cloud Storage, disk snapshots used by Compute Engine, andIAM policies. This document focuses on default encryption at restfor customer content.

Customer metadata makes up the rest of your data. Customer metadata couldinclude auto-generated project numbers, timestamps, IP addresses, the byte sizeof an object in Cloud Storage, or the machine type inCompute Engine. Metadata is protected to a degree that is reasonable forongoing performance and operations.

Default encryption of data at rest

Google encrypts all customer content stored at rest, without any action fromyou, using one or more encryption mechanisms. The following sections describethe mechanisms that we use to encrypt customer content.

Layers of encryption

Google uses several layers of encryption to help protect data. Using multiplelayers of encryption adds redundant data protection and allows us to select theoptimal approach based on application requirements.

The following diagram shows the several layers of encryption that are generallyused to protect user data in Google production data centers. Either distributedfile system encryption or database and file storage encryption is in place for all userdata, and storage device encryption is in place for all data inGoogle production data centers.

Encryption at the hardware and infrastructure layer

All of Google's storage systems use a similar encryption architecture, thoughimplementation details differ from system to system. Data is broken into subfilechunks for storage; each chunk can be up to several gigabytes in size. Eachchunk is encrypted at the storage level with an individual data encryption key(DEK): two chunks won't have the same DEK, even if they are owned by the samecustomer or stored on the same machine. (A data chunk in Datastore,App Engine, and Pub/Sub may contain the data of multiple customers.

If a chunk of data is updated, it is encrypted with a new key, rather than byreusing the existing key. This partitioning of data, each using a different key,limits the risk of a potential data encryption key compromise to only that datachunk.

Google encrypts data before it is written to a database storage system orhardware disk. Encryption is inherent in all of our storage systems, rather thanadded afterward.

Each data chunk has a unique identifier. Access control lists (ACLs) help toensure that each chunk can be decrypted only by Google services that operatewith authorized roles, which are granted access only at that point in time. Thisaccess limitation helps to prevent access to the data without authorization,strengthening data security and privacy.

Each chunk is distributed across our storage systems and is replicated inencrypted form for backup and disaster recovery. An attacker who wants to accesscustomer data would need to know and be able to access two things: all of thestorage chunks that correspond to the data that they want and all of theencryption keys that correspond to the chunks.

The following diagram shows how data is uploaded to our infrastructure and thenbroken into encrypted chunks for storage.

We use the AES algorithm to encrypt data at rest. All data at the storage levelis encrypted by DEKs, which use AES-256 by default, with the exception of asmall number ofPersistent Disks that were created before 2015 that use AES-128. AES is widely used because bothAES-256 and AES-128 are recommended by theNational Institute of Standards and Technology (NIST) for long-term storage use, and AES is often included as part of customercompliance requirements.

Encryption at the storage device layer

In addition tostorage system level encryption,data is also encrypted at the storage device level with AES-256 for hard diskdrives (HDD) and solid-state drives (SSD), using a separate device-level key(which is different from the key used to encrypt the data at the storage level).A small number of legacy HDDs use AES-128. SSDs used by Google implement AES-256for user data exclusively.

Encryption of backups

Our backup system ensures that data remains encrypted throughout the backupprocess. This approach avoids unnecessarily exposing plaintext data.

In addition, the backup system further encrypts most backup files independentlywith their own DEK. The DEK is derived from a key that is stored in Keystore anda randomly generated per-file seed at backup time. Another DEK is used for allmetadata in backups, which is also stored in Keystore.

FIPS compliance for data at rest

Google uses aFIPS 140-2 validated encryption module(certificate 4407) in our production environment.

Key management

Because of the high volume of keys at Google, and the need for low latency andhigh availability, DEKs are stored near the data that they encrypt. DEKs areencrypted with (wrapped by) a key encryption key (KEK), using a technique knownasenvelope encryption.These KEKs are not specific to customers; instead, one or more KEKs exist foreach service.

These KEKs are stored centrally in Keystore, a repository built specifically forstoring keys. Having a smaller number of KEKs than DEKs and using a centralKeystore makes storing and encrypting data at our scale manageable, and lets ustrack and control data access from a central point.

In Google Cloud, each customer can have shared and non-shared resources.An example of a shared resource is a shared base image inCompute Engine. For shared resources, multiple customers refer to asingle copy, which is encrypted by a single DEK. Non-shared resources are splitinto data chunks and encrypted with keys that are separate from the keys usedfor other customers. These keys are even separate from those that protect otherpieces of the same data owned by that same customer. Exceptions are data storedin Datastore, App Engine, or Pub/Sub, wheremore than one customer's data may be encrypted with the same DEK.

Generating DEKs

The storage system generates DEKs using Google's common cryptographic library.In general, DEKS are then sent to Keystore to wrap with that storage system'sKEK, and the wrapped DEKs are passed back to the storage system to be kept withthe data chunks. When a storage system needs to retrieve encrypted data, itretrieves the wrapped DEK and passes it to Keystore. Keystore then verifies thatthis service is authorized to use the KEK and, if so, unwraps and returns theplaintext DEK to the service. The service then uses the DEK to decrypt the datachunk into plaintext and verify its integrity.

All Google Cloud storage systems adhere to this key management model, butmost systems also implement additional levels of storage-side KEKs to create ahierarchy of keys. This allows the systems to provide low latency while usingthe highest-level KEK (stored in Keystore) as their root of trust.

Generating KEKs

Most KEKs for encrypting data chunks are generated within Keystore, and therest are generated inside the storage services. For consistency, all KEKs aregenerated using Google's common cryptographic library, using a random numbergenerator (RNG) built by Google. This RNG is based on NIST 800-90Ar1 CTR-DRBGand generates an AES-256 KEK. (In the past, this was AES-128, and some of thesekeys remain active for decrypting data.)

The RNG is seeded fromIntel's RDRAND instruction and the Linux kernel's RNG. In turn, the Linux kernel's RNG is seeded frommultiple independent entropy sources, including RDRAND and entropic events fromthe data center environment (for example, fine-grained measurements of diskseeks and inter-packet arrival times).

DEKs are wrapped with KEKs using AES-256 or AES-128, depending on theGoogle Cloud service. We are currently working on upgrading all KEKs forGoogle Cloud services to AES-256.

KEK management

Keystore was built solely for the purpose of managing KEKs. By design, KEKsused by storage systems aren't exportable from Keystore; all encryption anddecryption with these keys must be done within Keystore. This helps to preventleaks and misuse, and it enables Keystore to create an audit trail when keys areused.

Keystore can automatically rotate KEKs at regular time intervals, usingGoogle's common cryptographic library to generate new keys. Though we oftenrefer to just a single key, we really mean that data is protected using a keyset: one key is active for encryption, and a set of historical keys is activefor decryption. The number of historical keys is determined by the key rotationschedule. KEKs are backed up for disaster recovery purposes, and they areindefinitely recoverable.

The use of KEKs is managed by ACLs in Keystore for each key, with a per-keypolicy. Only authorized Google services and users are allowed to access a key.The use of each key is tracked at the level of the individual operation thatrequires that key—so every time that a user uses a key, the user isauthenticated and logged. All data access by users is auditable as part ofGoogle's overall security and privacy policies.

Process for accessing encrypted chunks of data

When a Google service accesses an encrypted chunk of data, the followingoccurs:

1. The service makes a call to the storage system for the data that it needs.
2. The storage system identifies the chunks in which that data is stored(the chunk IDs) and where they are stored.
3. For each chunk, the storage system pulls the wrapped DEK that is storedwith that chunk (in some cases, this is done by the service) and sends itto Keystore for unwrapping.
4. The storage system verifies that the identified job is allowed to accessthat data chunk based on a job identifier and using the chunk ID. Keystoreverifies that the storage system is authorized to use the KEK that isassociated with the service and to unwrap that specific DEK.
5. Keystore does one of the following:
   • Passes the unwrapped DEK back to the storage system, whichdecrypts the data chunk and passes it to the service.
   • In some rare cases, passes the unwrapped DEK to the service. Thestorage system passes the encrypted data chunk to the service, whichdecrypts the data chunk and uses it.

This process is different in dedicated storage devices, such as local SSDs,where the device manages and protects the device-level DEK.

The following diagram shows this process. To decrypt a data chunk, the storageservice calls Keystore to retrieve the unwrapped DEK for that data chunk.

Encryption key hierarchy and root of trust

Keystore is protected by a root key called the keystore master key, whichwraps all of the KEKs in Keystore. This keystore master key is AES-256 and isitself stored in another key management service, called Root Keystore. (In thepast, the keystore master key was AES-128, and some of these keys remain activefor decrypting data.) Root Keystore stores a much smaller number ofkeys—approximately a dozen per region. For additional security, Root Keystoreisn't run on general production machines, but instead is run only on dedicatedmachines in each Google data center.

Root Keystore in turn has its own root key, called the root keystore masterkey, which is also AES-256 and is stored in a peer-to-peer infrastructure,which is called the root keystore master key distributor, and which replicatesthese keys globally. (In the past, the root keystore master key was AES-128, andsome of these keys remain active for decrypting data.) The root keystore masterkey distributor only holds the keys in RAM on the same dedicated machines asRoot Keystore, and it uses logging to verify proper use. One instance of theroot keystore master key distributor runs for every instance of Root Keystore.

When a new instance of the root keystore master key distributor is started, itis configured with a list of host names of already running distributorinstances. Distributor instances can then obtain the root keystore master keyfrom other running instances. Other than the disaster-recovery mechanismsdescribed inGlobal availability and replication,the root keystore master key exists only in RAM on a limited number of speciallysecured machines.

To address the scenario where all instances of the root keystore master keydistributor in a region restart simultaneously, the root keystore master key isalso backed up on secure hardware devices that are stored in physical safes inhighly secured areas in multiple geographically distributed locations. Thisbackup would be needed only if all distributor instances in a region were to godown at once. Fewer than 100 Google employees can access these safes.

The following diagram shows the encryption key hierarchy. The encryption keyhierarchy protects a chunk of data with a DEK, wrapped with a KEK in Keystore,which is in turn protected by Root Keystore and the root keystore master keydistributor.

Summary of key management

The following list summarizes key management at Google:

• Data is chunked and encrypted with DEKs.
• DEKs are encrypted with KEKs.
• KEKs are stored in Keystore.
• Keystore is run on multiple machines in data centers globally.
• Keystore keys are wrapped with the Keystore master key, which is storedin Root Keystore.
• Root Keystore is much smaller than Keystore and runs only on dedicatedmachines in each data center.
• Root Keystore keys are wrapped with the root keystore master key, whichis stored in the root keystore master key distributor.
• The Root Keystore master key distributor is a peer-to-peerinfrastructure that runs concurrently in RAM on dedicated machinesglobally. Each machine gets its key material from other running instancesin the region.
• In case all instances of the distributor in a region were to go down, amaster key is stored in different secure hardware in physical safes inlimited Google locations.

Global availability and replication

At every level, high availability, low latency, and global access to keys arecritical. These characteristics are needed for key management services to beused across Google.

For this reason, Keystore is highly scalable, and it is replicated thousands oftimes in our data centers globally. It is run on regular machines in ourproduction fleet, and instances of Keystore run globally to support Googleoperations. As a result, the latency of any single key operation is very low.

Root Keystore is run on several machines dedicated to security operations, ineach data center. The Root Keystore master key distributor is run on these samemachines, one-to-one with Root Keystore. The Root Keystore master keydistributor provides a distribution mechanism using agossiping protocol.At a fixed time interval, each instance of the distributor picks a random otherinstance to compare its keys with and reconciles any differences in keyversions. With this model, there is no central node that all of ourinfrastructure depends on. This distribution method lets us maintain and protectkey material with high availability.

Google's common cryptographic library

Google's common cryptographic library isTink,which incorporates our FIPS 140-2 validated module,BoringCrypto.Tink is available to all Google developers. Consistent use of a common librarymeans that only a small team of cryptographers needs to implement this tightlycontrolled and reviewed code, making it unnecessary for every team at Google toindependently develop their own cryptography. A special Google security team isresponsible for maintaining this common cryptographic library for allproducts.

The Tink encryption library supports a wide variety of encryption key types andmodes, and these are reviewed regularly to ensure that they are current with thelatest attacks.

Currently, we use the following encryption algorithms for encryption at restfor DEKs and KEKs. These are subject to change as we continue to improve ourcapabilities and security.

Other cryptographic protocols exist in the library and were historicallysupported, but this table covers the primary uses at Google.

Research and innovation in cryptography

To keep pace with the evolution of encryption, we have a team of world-classsecurity engineers tasked with following, developing, and improving encryptiontechnology. Our engineers take part in standardization processes and inmaintaining widely used encryption software.We regularly publish our research in the field of encryption so that everyone—including the general public—canbenefit from our knowledge.

For example, in post-quantum cryptography research, we are working in thefollowing areas:

• Standardization: We're contributing to ongoing standardizationefforts for post-quantum cryptography. We co-authored three cryptosystemproposals for consideration by NIST as part of thepost-quantum cryptography standardization competition.We are editors of the International Organization for Standardization (ISO)standard onpost-quantum cryptography hash-based signatures.We are co-editors of the Internet Engineering Task Force (IETF) draft onJSON encoding for post-quantum cryptography signatures.

• Enablement: We have recently enabled several post-quantumcryptography algorithms in ourTink cryptographic library.This is experimental code that is designed to help educate the communityabout the pros and cons of each approach.

• Publications: We recently publishedTransitioning organizations to post-quantum cryptography in Nature. This paper provides an overview of post-quantum cryptographymigration challenges.

What's next

• For information about using your own encryption keys inGoogle Cloud, seeCustomer-managed encryption keys (CMEK).

• For general information on Google Cloud security, see theSecurity section of the Google Cloud website.

• For information on Google Cloud compliance and compliancecertifications, see theCompliance section of the Google Cloud website,which includes Google'spublic SOC3 audit report.

• For information on Google Workspace encryption and key management, seeHow Google Workspace uses encryption to protect your data,which covers much of the same content included here, but focuses solely onGoogle Workspace. For all Google Workspace solutions, we strive to keepcustomer data protected, and to be as transparent as possible about how wesecure it.

• For information about general security and compliance, seeCompliance resource center.