Read time: 5 mins

Encryption is a process that takes plaintext as input and transforms it into an output (ciphertext) that reveals no information about the plaintext. Encryption adds a layer of defense for protecting data and ensures that if the data accidentally falls into an attacker’s hands, they cannot access the data without having access to the encryption keys. Even if an attacker obtains the storage devices containing your data, they will not be able to understand or decrypt it.

Data Encryption Options

Cloud storage encrypts data on the server-side before it is written to disk, at no additional charge. Besides this standard, there are additional ways to encrypt the data while using Cloud Storage.

Below are the available encryption options for Google Cloud:

Server-side encryption

Google Cloud Storage performs server-side encryption by default on all uploaded objects. All data is broken into chunks which can be up to several GB in size. Using envelope encryption, each chunk of data is encrypted with a unique Data Encryption Key (DEK) that is also encrypted with a Key Encryption Key (KEK). The encrypted version of the DEK is then stored alongside the encrypted data, and the encrypted chunks of data are distributed across Google’s storage systems

Google Cloud Storage supports server-side encryption with two key options:
Customer-supplied encryption keys

With the customer-supplied encryption key (CSEK) option, users must generate their own AES 256
symmetric key and provide it to google cloud storage for encryption/decryption operations. The CSEK is only stored in storage system memory and never persisted on any Google Cloud device

Cloud storage does not permanently store user’s key on Google’s servers or otherwise manage user’s key. Instead, the user provide key for each cloud storage operation, and the key is purged from Google’s server after completion of the operation. The customer-supplied encryption key is hashed and then purged from the storage system. The cryptographic hash is used to validate (future requests) but cannot be used to decrypt data or to reconstruct a key When the customer supplies the encryption key, cloud storage uses the key while encrypting

  • the object data
  • the object’s checksum
  • the object’s hash

Cloud Storage uses standard server-side keys to encrypt the remaining metadata for the object, including the object’s name.Encryption and Decryption workflow mentioned below:

  1. The CSEK is provided to Google Cloud Storage along with the data upload
  2. Data is broken into sub-file chunks
  3. A Google Cloud Storage system calls a common cryptographic library that Google maintains, called CrunchyCrypt, to generate a unique, one-time key called DEK
  4. Each data chunk is encrypted using a DEK
  5. The storage system then uses the CSEK as the KEK and encrypts the DEK
  6. The encrypted DEK is stored alongside the ciphertext chunk it encrypted in Google Cloud Storage while the plaintext version of the DEK is deleted from memory
  7. The customer-supplied encryption key is hashed and then purged from the storage system. The cryptographic hash is used to validate future requests but cannot be used to decrypt data or reconstruct the key
  8. The client or application requests data from Google Cloud Storage while supplying the CSEK
  9. Google Cloud Storage identifies the chunks in which the data is stored and where the chunks reside and retrieves the chunks
  10. For each data chunk, the storage system retrieves the encrypted DEK and decrypts it using the CSEK
  11. Once the decryption is done using DEK, the storage system discards the DEK and sends the decrypted data to the client or application that requested the data
Customer-managed encryption keys:

Customer-managed encryption keys are keys generated for users by Cloud Key Management Service (KMS), that the user manages themselves. These keys act as an additional encryption layer on top of the standard Cloud Storage encryption.The encryption and decryption workflow:

  1. Data is broken into sub-file chunks after being uploaded to Google Cloud
  2. A Google Cloud Storage system calls a common cryptographic library that Google maintains, called CrunchyCrypt, to generate a unique one-time use DEK
  3. Each data chunk is encrypted using a DEK
  4. The storage system then sends the DEK to Google’s Key Management Service (KMS) to be encrypted using that storage system’s associated Key Encryption Key (KEK)
  5. The encrypted DEK is stored alongside the ciphertext chunk it encrypted in Google Cloud Storage while the plaintext version of the DEK is deleted from memory
  6. When data is requested, Google Cloud Storage identifies the chunks in which the data is stored and where the chunks reside and retrieves the chunks
  7. For each data chunk, the storage system retrieves the encrypted DEK and sends it to Google’s KMS for decryption
  8. KMS sends the decrypted DEK to the storage system where it is used to decrypt the data
  9. The storage system discards the DEK and sends the decrypted data to the client that requested the data

Client-side encryption:

With this option, Users create and manages its own encryption keys. Users must encrypt the data before sending it to cloud storage. The encrypted data on the client side arrives at cloud storage in an encrypted state. When cloud storage receives the data, one more time the data will be encrypted. This second encryption is called server-side encryption, which Cloud Storage manages. While retrieving the data, cloud storage removes the server-side layer of encryption, but user must decrypt the client-side layer by themselves.

Benefits

Customer-managed keys provide the following benefits:

  • More Control over Data Access:
    • Customer-managed keys provide an extra level of security for customers with sensitive data.
    • When the customer decides to disable access, data can no longer be decrypted
  • Stop Data Breaches:
    • In this case, disabling customer-managed keys will allows customers to stop ongoing exfiltration of their data
  • More Control over Data Lifecycle:
    • Using customer-managed keys, sensitive data is encrypted with the customer’s key. Without customer’s/users consent no one can decrypt the data
    • The customer has full control over the data’s lifecycle
  • Secure
    • Compute assets are encrypted using the industry-leading AES-256 standard, and Google never retains users’ keys, meaning Google cannot decrypt user’s data at rest.
  • Comprehensive
    • Customer-Supplied Encryption Keys cover all forms of data at rest for Compute Engine, including boot and data persistent disks.
  • Fast
    • Google Compute Engine is already encrypting user’s data at rest, and Customer-Supplied Encryption Keys gives user greater control, without additional overhead.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Cyber security experts conference 2022

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

  • Master Key Types: Google Cloud Platform (GCP) offers 2048, 3072, and 4096 bit RSA asymmetric master keys.  It is also one of the only Cloud Service Providers (CSPs) to offer 256 bit symmetric master keys.
  • Encryption Modes: GCP offers symmetric AES GCM and asymmetric RSA OAEP encryption methods.
  • Plaintext Size Limits: Google Cloud Platform offers a plaintext size limit of 64KB.
  • Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Google Cloud Platform takes an AES-256 key that is wrapped by RSA 3072. 
  • Signature Modes: To ensure the integrity of data-in-transit, signatures are used. GCP offers RSA-PSS, RSA PKCS#1V1.5, ECDSA with P-256, and ECDSA with P-384 signature methods.
  • Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. All HSM keys on Google Cloud Platform are FIPS 140-2 level 3 compliant.
  • Google Cloud KMS Features: Google Cloud KMS can store keys in either an HSM or a software application. This key storage can be accessed by both the customer and the CSP. Google Cloud KMS is FIPS 140-2 Level 3 compliant if an HSM is used, and FIPS 140-2 Level 1 compliant if software keys are used. Google Cloud KMS supports symmetric and asymmetric keys. It also supports 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata and RSA keys of sizes 2048, 3072 and 4096.Google Cloud KMS is capable of key management, storage, auditing, encryption, encryption for Kubernetes, and both HSM and software key management.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Cyber security experts conference 2022

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Online data security has always been important, but never more so than now. With more and more of our data being stored on the cloud, users need to look for the best security solutions to ensure their confidential information is secure. While all parts of online data security are necessary to secure data, arguably the most important portion is data encryption.

This is why more and more cloud services are using a type of encryption called Format-Preserving Encryption.

What is Format-Preserving Encryption?

If your company has multiple 16-digit credit card numbers stored in a database, but the encrypted ciphertext needs to be 16-digits as well after encryption, this is where Format-Preserving Encryption [FPE] comes in.FPE encrypts plaintext that is a certain length and produces a ciphertext that is the same length as the plaintext and uses the same set of values as the plaintext. Using the previous example of a 16-digit credit card number with a plaintext of 1483920193402918, the ciphertext created with FPE could produce an output of 1483666666662918.

By using FPE, you can see that the ciphertext and plaintext are the same length and only use numerical values for encryption. One cloud provider that lets users implement FPE in their encryption is Google Cloud.

Format-Preserving Encryption in Google Cloud

Google Cloud gives users access to a de-identification technique called pseudonymization. Pseudonymization is a technique that replaces sensitive data with cryptographically generated tokens. Google Cloud supports three different pseudonymization techniques:

  1. Deterministic encryption using AES-SIV
  2. Format-Preserving Encryption
  3. Cryptographic hashing

All three techniques use cryptographic keys for data transformation, but we will focus on the Format-Preserving Encryption.
Google Cloud uses a type of FPE called FPE-FFX. FFX focuses on two different FPE methods,FF1 and FF3, to encrypt data.At the time of writing this, FF1 is the only method currently supported for encryption. FF2 did not make it to publication at the time of FFX’s creation. FF2 and FF3 derivations are being resubmitted, but after a cryptanalytic attack in 2017, FF3 was considered to be too insecure.FFX uses multiple rounds of a Feistel function on the plaintext, along with the use of a key, to create the ciphertext. A Feistel function splits the plaintext into two parts and does a permutation each round on each half of the plaintext, and then swaps the left half of text to the right and vice versa. The FF1 method uses 10 rounds of the Feistel function, and FF3 uses 8 rounds of the Feistel function. FPE-FFX has several steps necessary to encrypt data.To begin encryption, the alphabet being used to de-identify the data must be specified in one of three ways:

  1. Using one of four values that represent the most common character sets/alphabets
  2. Using a radix value specifying the size of the alphabet. Specifying 2 gives an alphabet consisting of the numbers 0 and 1, while specifying 95 gives an alphabet with all numeric, upper-case alpha, lower-case alpha, and symbol characters
  3. By building an alphabet containing the exact characters to be used

When using FPE-FFX in Google Cloud, the data is encrypted as previously described, but can also be prepended with a surrogate annotation, resulting in a final token. The token takes the following form when a surrogate annotation is included: surrogate_infotype(surrogate_length): surrogate_value. The surrogate annotation is surrogate_infotype(surrogate_length). The infotype is defined by the user and the surrogate value is the resulting ciphertext. If no surrogate annotation is specified, then the final token is just the surrogate value. To re-identify unstructured data, the full token, including a surrogate annotation, is necessary, while structured data only needs the surrogate value.

Conclusion

Format preserving encryption is extremely important for users who wish to keep the ciphertext after encryption as the same length as the plaintext. Of the several different FPE-FFX methods used on Google Cloud, FF1 is the best practice method to use, due to the extra rounds of the Feistel function it goes through.

Structured data requires a surrogate annotation be prepended on the ciphertext to allow for re-identification of data. Google Cloud has a strong implementation of FPE in place for customer use. For those in need of same length plaintext and ciphertext, Google Cloud’s FPE-FFX is their best choice.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Cyber security experts conference 2022

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Let's talk