This content was last updated in May 2024 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 data 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 content 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 own and 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.

Keys in Google Cloud

The following table describes the different properties of keysin Google Cloud.

¹ The owner of the key indicates who holds therights to the key. Keys that you own have tightly restricted access or no accessby Google.

² Management of keys includes the followingtasks:

• Create keys.
• Choose the protection level of the keys.
• Assign authority for management of the keys.
• Control access to keys.
• Control usage of keys.
• Set and modify the rotation period of keys, or trigger a rotation of keys.
• Change key status.
• Destroy key versions.

³ Control of keys means setting controls on thekind of keys and how the keys are used, detecting variance, and planningcorrective action if needed. You can control your keys, but delegate managementof the keys to a third party.

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 content is data that you generate yourself or provide to us, like datastored in Cloud Storage buckets, Persistent Disk volumes, and disk snapshots used by Compute Engine. This document focuses on default encryption at restfor this type of customer data.

Customer metadata is data about your customer content and includesauto-generated project numbers, timestamps, IP addresses, the byte size of anobject in Cloud Storage, or the machine type inCompute Engine. Customer metadata is protected to a degree that isreasonable for ongoing performance and operations. This document doesn’t focuson the protections for metadata.

Together, customer content and customer metadata make up customer data.

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 infrastructure layer

All of Google's storage systems use a similar encryption architecture, thoughimplementation details differ from system to system. Data is broken into logicalchunks 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.

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 logical 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.

A logical data chunk might contain the data of multiple customers. If you wantto achieve logical data separation through encryption, you must enableCloud Key Management Service.

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.

For Intel and AMD processors, the RNG is seeded fromRDRANDinstruction and the Linuxkernel's RNG. In turn, the Linux kernel's RNG is seeded from multipleindependent entropy sources, including RDRAND and entropic events from the datacenter environment (for example, fine-grained measurements of disk seeks andinter-packet arrival times). For Arm processors, the RNG is seeded from theLinux kernel's RNG.

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,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 thekeystore 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.) 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 theroot keystore masterkey, which is also AES-256 and is stored in a peer-to-peer infrastructure,which is called theroot 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.

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. Only a few 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.

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 co-designed the stateless hash-based digitalsignature scheme that is standardized asFIPS205. We are editors of theInternational Organization for Standardization (ISO) standard onpost-quantum cryptography hash-basedsignatures and contributed toguidance on statemanagementfor hash-based signatures at IETF.

• Enablement: Werolled out post-quantumcryptographyto our internal protocol for transport layer security. We enabled supportfor post-quantum cryptography inChrome.We added several post-quantum cryptography algorithms in ourTinkcryptographiclibrary.This code is experimental and is designed to help educate the communityabout each approach.

• Publications: We publishedTransitioning organizations to post-quantumcryptography inNature. This paper provides an overview of post-quantum cryptographymigration challenges. We also published a research paper on gettingpost-quantum cryptography inour securitykeys.

Note that symmetric encryption (using AES-128 or later) remains resistant to quantum attacks.

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.