GCP: About Encryption

Dhruv | Aug 9, 2022
This article is part of a series.
  • Part 1: This Article

Encryption at rest

Encryption by default

  • GCP encrypts customer data by default
  • Key creation and rotation are managed by GCP
  • Data is broken into subfile chunks
  • Each chunk is encrypted at storage level with its unique encryption key
  • No two chunks will ever have the same encryption key
  • Each updated chunk is encrypted with a new key
  • Key used for encryption is called data encryption key (DES)
  • DEKs are generated by storage system using Google’s cryptographic library, keyczar
  • AES-128 and AEAS-256 are used for encryption
  • Implemented using BoringSSL(fork of OpenSSL)
  • Backups are encrypted using a separate key

Encryption using KMS

  • DEKs are encrypted with a key encryption key(KEK)
  • This process is known as envelope encryption
  • KEKs are stored centrally in Cloud Key Management Service (Cloud KMS)

What is Cloud KMS?

  • A central repo for storing KEKs
  • Generate, use, rotate and destroy symmetric encryption keys
  • KEKs are not exportable from KMS
  • Encryption and decryption are done with keys in KMS
  • Helps provide misuse and provides an audit trail
  • KEKs are automatically rotated at regular intervals (standard is 90 days)
  • Managed by ACL for each key

Customer-Supplied Encryption Keys (CSEKs)

  • Keep encryption keys on premises where required and use them to encrypt services in GCP
  • COntrol access to and use of data at the finest level of granularity, ensuring data security and privacy
  • Manage encryption of cloud-hosted data the same way as current oon-premises data- or better.
  • HAve a provable and auditable root of trust over resources
  • Be able to further separate and segregate customer data, beyond the use of ACLs

Encryption in transit

  • Encryption in transit protects your data if communications are intercepted while data moves between toye site and the cloud provider or between 2 service
  • It reduces the potential attach surgace
  • Prevents attacker from accessing data if communications are intercepted

Google Front End (GFE)

Globally distributed system that GCP services accept requests from.

GFE features

  • Terminating traffic for incoming HTTP(S), TCP and TLS proxy traffic
  • DDOS attack prevention
  • Routing and load balancing traffic to GCP services
  • Google implements the following security strategy within GFE:
    • Authentication
    • Integrity
    • Encryption

Types of Routing Requests

  • User to GFE encryption
  • User to customer appllication hosted on GCP
  • VM to VM
  • VM to GCP service
  • GCP service to GCP service

Methods of Encryption

Virtual Network Encryption and Authentcation

  • Encryption is performed at the network layer (Layer 3)
  • AES-128
  • Session keys are established on hosts
    • Protected by ALTS
  • Security tokens used for authentication
    • Generated for every flow; consist of token key and host secret
  • Protects a compromised host from spoofing packets on the network

IPSec Tunnel

  • Layer 3 traffic
  • Traffic traveling between the two networks is encrypted by one VPN gateway and decrypted by the other VPN gateway
  • IKEv1 (AES-128), IKEv2 (AES-256)

Transport Layer Security (TLS)

  • Any data sent to GFE is encrypted in transit using TLS (default)
  • Also used in API interactions

Boring SSL

  • TLS in the GFE is implemented with BoringSSL
  • Fork of OpenSSL
  • Automatically negotiates the highest version of the protocol to ensure the best possible security

Google’s Certificate Authority

  • Identity verification achieved in TLS through the use of a certificate
  • Certificate holds DNS hostname of server and public key

Root key migration and key rotation

  • Google is responsible for the rotation of keys and certificates
  • TLS certificates - rotated every 2 weeks
    • Lifetime: 3 months
  • Keys - rotated daily
    • Lifetime: 3 days

Application Layer Transport Security (ALTS)

  • Layer 7 traffic
  • Mutual authentication and transport encryption system developed by Google
  • Used for securing Remote Procedure Call (RPC) communications within Google’s infrastructure
  • Identities are bound to entities (user, machine, or service) instead of to a specific server name or host
  • Relies on both the Handshake Protocol and the Record Protocol
  • Governs how sessions are established, authenticated,encrypted, and resumed
  • GFE to service / service to service

Cloud KMS


  • Cloud Key Management Service (KMS) is a service that lets you manage cryptographic keys for every service within the Google Cloud Platform
  • Generate, use, rotate, and destroy symmetric encryption keys
  • Automatic or at-will key rotation
  • Asymmetric and symmetric key support
  • Used to encrypt all data on Google Cloud (default)
  • Integrated with Cloud IAM and Cloud Audit Logs
  • Tracked every time it is used and authenticated and logged
  • Permissions are handled by Access Control Lists (ACLs) on a per-key basis
    • Per key policy
  • Used with Cloud HSM
  • DEKs are encrypted with a key encryption key (KEK).
  • Process known as envelope encryption - “Encrypting key with another key.”
  • A central repository for storing KEKs
  • KEKs not exportable from KMS
  • Automatically rotates KEKs at regular intervals
  • Standard rotation period is 90 days


  • Four types of locations:
    • Regional (e.g., Iowa)
      • Zones in a specific geographical place
    • Dual-regional (e.g., Iowa and South Carolina)
      • Zones in two specific geographical places
    • Multi-regional (e.g., United States)
      • Zones spread across a general geographical area
    • Global
      • KMS resources are available from zones spread around the world.
  • Users and services who are far away from the location will experience higher latency.
  • Read operations are served by a data center close to the requesting user or service.
  • Write operations must propagate to multiple data centers when performed on multi-region or global resources.
    • Will be slower as a result.

Object Hierarchy

  • Keys are stored in a hierarchical structure
    • Project
    • Location
    • Key ring
    • Key
    • Key version
  • Project
    • KMS belongs to a project
    • Best practice is to run in a separate project to be able to lockdown permissions with regards to having access to KMS and the keys themselves
  • Geographical Location
    • Where KMS keys are stored
    • Where KMS receives requests
  • Key Ring
    • Grouping of keys for organizational purposes
    • Keys inherit permissions from the key ring
  • Key
    • Cryptographic key
    • Symmetric or asymmetric
  • Key Version
    • The material that makes up the key (length, algorithm)
    • Numbered sequentially
    • States:
      • Pending generation
        • Being generated
        • Asymmetric keys only
      • Enabled
      • Disabled
        • Can be put back into the enabled state
      • Scheduled for destruction
        • Can be put back into the disabled state
      • Destroyed
      • Symmetric encryption
        • Primary key version to be enabled for encryption
      • Asymmetric encryption
        • Key version to be enabled for encryption or digital signing

Key Rotation

  • Symmetric key rotation
    • A new key version of a key is generated
    • New key marked as primary
    • Previous key not destroyed
    • Old key available for decryption
    • Automatic key rotation
  • Asymmetric key rotation
    • A new key version of a key is generated
    • Manual key rotation only

Separation of duties

  • Ensuring that one individual does not have all necessary permissions to be able to complete a malicious action.
  • Users normally should not have access to decryption keys.
  • Helps prevent security or privacy incidents and errors.
  • Best practice: Move KMS to its own project.

Secret Management

  • Cloud KMS does not directly store secrets.
  • Encrypts secrets that you store elsewhere.
  • Use the default encryption built into Cloud Storage buckets.
  • Use application-layer encryption using a key in Cloud KMS.