Google Encryption
Encryption at rest in Google Cloud
Google uses several layers of encryption to protect customer data at rest in Google Cloud products.
Google Cloud encrypts all customer content stored at rest.
Data for storage is split into chunks.
Each chunk is encrypted with a unique data encryption key.
Encryption keys are stored with the data, encrypted with ("wrapped" by) key encryption keys
Using AES256, with the exception of a small number of Persistent
Disks created before 2015 that use AES128.
Note: The Advanced Encryption Standard (AES) is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001.
AES has been adopted by the U.S. government. It supersedes the Data Encryption Standard (DES), which was published in 1977.
The algorithm described by AES is a symmetric-key algorithm,
meaning the same key is used for both encrypting and
decrypting the data.
AES is based on a design principle known as a substitution–permutation network.
AES-256, which has a key length of 256 bits, supports the largest bit size and is practically unbreakable by brute force based on current computing power, making it the strongest encryption standard Encryption works by taking plain text and converting it into cipher text, which is made up of seemingly random characters.
Only those who have the special key can decrypt it. AES uses symmetric key encryption, which involves the use of only one secret key to cipher and decipher information.
Introduction
Traveling the internet, moving between data centers, or stored on servers.
Strategy is encryption in transit and at rest.
Data can be accessed only by the authorized roles and services with audited access to the encryption keys.
What is encryption?
Encryption is a process that takes legible data as input (often called plaintext), and transforms it into an output (often called ciphertext) that reveals little or no information about the plaintext.
The encryption algorithm used is public, such as the Advanced Encryption Standard (AES), but execution depends on a key, which is kept secret.
To decrypt the ciphertext back to its original form, you need to employ the key.
Why does encryption help secure customer data?
Encryption adds a layer of defense in depth for protecting data—encryption ensures that if the data accidentally falls into an attacker's hands, they cannot access the data without also having access to the encryption keys.
Even if an attacker obtains the storage devices containing your data, they won't be able to understand or decrypt it.
Encryption at rest reduces the surface of attack by effectively "cutting out" the lower layers of the hardware and software stack.
Acts as a "chokepoint"—centrally managed encryption keys create a single place where access to data is enforced and can be audited.
What do we consider customer data?
Content provided to Google by a Google Cloud customer , directly or indirectly, via Google Cloud services used by that customer's account.
Google's default encryption.
Google Cloud encrypts all customer content stored at rest, without any action from the customer, using one or more encryption mechanisms.
Layers of encryption
Google uses several layers of encryption to protect data.
Figure 1: Distributed file system encryption or database and file storage encryption is in place for almost all files; and storage device encryption is in place for almost all files.
Encryption at the storage system layer
Data is broken into subfile chunks for storage; each chunk can be up to several GB in size.
Each chunk is encrypted at the storage level with an individual encryption key: two chunks will not have the same encryption key.
Google encrypts data prior to it being written to disk.
Each data chunk has a unique identifier.
Access control lists (ACLs) ensure that each chunk can be decrypted only by Google services operating under authorized roles.
A malicious individual who wanted to access customer data would need to know and be able to access (1) all storage chunks corresponding to the data they want, and (2) the encryption keys corresponding to the chunks.
Figure 2: Data at Google is broken up into encrypted chunks for storage.
Advanced Encryption Standard (AES) algorithm to encrypt data at rest.
All data at the storage level is encrypted with AES256 by default.
Recommended by the National Institute of Standards and Technology (NIST) for long-term storage use.
Note: GCM - Mode of operation for symmetric-key cryptographic block ciphers which is widely adopted for its performance. GCM throughput rates for state-of-the-art, high-speed communication channels can be achieved with inexpensive hardware resources.
Cipher block chaining (CBC) is a mode of operation for a block cipher -- one in which a sequence of bits are encrypted as a single unit, or block, with a cipher key applied to the entire block.
HMAC is a specific type of message authentication code involving a cryptographic hash function and a secret cryptographic
Encryption at the storage device layer
Encrypted at the storage device level with AES256 for hard disks (HDD) and solid state drives (SSD), using a separate device-level key (which is different than the key used to encrypt the data at the storage level).
Encryption of backups
Data remains encrypted throughout the backup process.
Backup system further encrypts each backup file independently with its own data encryption key (DEK), derived from a key stored in Google's Key Management Service (KMS) plus a randomly generated per-file seed at backup time.
Key management
Data encryption keys, key encryption keys, and Google's Key Management Service
The key used to encrypt the data in a chunk is called a data encryption key (DEK).
The DEKs are encrypted with (or "wrapped" by) a key encryption key (KEK). One or more KEKs exist for each Google Cloud service. These KEKs are stored centrally in Google's KMS, a repository built specifically for storing keys.
Data chunks and encrypted 2 with keys separate from keys used for other customers. These DEKs are even separate from those that 3 protect other pieces of the same data owned by that same customer.
DEKs are generated by the storage system using Google's common cryptographic library.
They are then sent to KMS to wrap with that storage system's KEK, and the wrapped DEKs are passed back to the storage system to be kept with the data chunks.
Retrieves the wrapped DEK and passes it to KMS. KMS then verifies that this service is authorized to use the KEK, and if so, unwraps and returns the plaintext DEK to the service. The service then uses the DEK to decrypt the data chunk into plaintext and verify its integrity.
The use of KEKs is managed by access control lists (ACLs) in KMS for each key, with a per-key policy.
Only authorized Google services and users are allowed access to a key. When a Google Cloud service accesses an encrypted chunk of data, here's what happens:
1. The service makes a call to the storage system for the data 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 stored with that chunk (in some cases, this is done by the service), and sends it to KMS for unwrapping.
4. The storage system verifies that the identified job is allowed to access that data chunk based on a job identifier, and using the chunk ID; and KMS verifies that the storage system is authorized both to use the KEK associated with the service, and to unwrap that specific DEK.
5. KMS does one of the following:
○ Passes the unwrapped DEK back to the storage system, which decrypts the data chunk and passes it to the service. or
○ Passes the unwrapped DEK to the service; the storage system passes the encrypted data chunk to the service, which decrypts 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.
Figure 3: To decrypt a data chunk, the storage service calls Google's Key Management Service (KMS) to retrieve the unwrapped data encryption key (DEK) for that data chunk.
Encryption key hierarchy and root of trust
Google's KMS is protected by a root key called the KMS master key, which wraps all the KEKs in KMS. This KMS master key is AES256 and is itself stored in another key management service, called the Root 5 KMS.
To summarize:
● Data is chunked and encrypted with DEKs.
● DEKs are encrypted with KEKs.
● KEKs are stored in KMS.
● KMS is run on multiple machines in data centers globally. ○ KMS keys are wrapped with the KMS master key, which is stored in Root KMS.
● Root KMS is much smaller than KMS and runs only on dedicated machines in each data center. ○ Root KMS keys are wrapped with the root KMS master key, which is stored in the root KMS master key distributor.
● The root KMS master key distributor is a peer-to-peer infrastructure running concurrently in RAM globally on dedicated machines; each gets its key material from other running instances. ○ If all instances of the distributor were to go down (total shutdown), a master key is stored in (different) secure hardware in (physical) safes in limited Google locations. ○ The root KMS master key distributor is currently being phased in, to replace a system that operated in a similar manner but was not peer to peer.
No comments:
Post a Comment