DEK

Envelope Encryption – KMS Data Key Encryption

~ Last updated on : ~ jayendrapatil

Envelope Encryption

  • AWS KMS and Google Cloud KMS use a method called envelope encryption to protect the data.
  • Envelope encryption is an optimized method for encrypting data that uses two (or more) different keys — a Key Encryption Key (KEK) and a Data Encryption Key (DEK).
  • Master key is also known as Key Encryption Key – KEK and Data key is also known as Data Encryption Key – DEK.
  • Envelope encryption reduces the network load for the application or the cloud service as only the request and fulfillment of the much smaller data key through KMS must go over the network.
  • The data key is used locally by the encrypting service, avoiding the need to send the entire block of data to KMS and suffer network latency.
  • KMS can encrypt at most 4 KB of data directly. Envelope encryption allows encrypting arbitrarily large payloads by using locally generated data keys.
  • Envelope encryption can reduce KMS-related costs by up to 99% by minimizing the number of KMS API calls — only the data key wrapping/unwrapping goes through KMS, while encryption/decryption of actual data happens locally.

Envelope encryption key hierarchy

Root Key

  • A root key is an encryption key that is used to encrypt other encryption keys, such as data keys and key encryption keys. Unlike data keys and key encryption keys, root keys must be kept in plaintext so they can be used to decrypt the keys that they encrypted.
  • Key Management Service (KMS) generates and protects the root keys within FIPS 140-2 (AWS) or FIPS 140-3 (latest) validated Hardware Security Modules (HSMs).
  • In AWS KMS, root keys are referred to as KMS keys (previously called Customer Master Keys or CMKs — the CMK term was deprecated in August 2021).

Key Encryption Key – KEK

  • A key encryption key is an encryption key that is used to encrypt a data key or another key encryption key.
  • Key encryption key is encrypted (wrapped) by using a root key.
  • In Google Cloud KMS, the KEK is the Cloud KMS key used to wrap (encrypt) the DEK. The KEK never leaves Cloud KMS.

Data Encryption Key – DEK

  • A data key or data encryption key is an encryption key that is used to protect data.
  • Data keys differ from root keys and key encryption keys, which are typically used to encrypt other encryption keys.
  • Best practice is to use a strong algorithm such as 256-bit Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) for DEKs.
  • A new DEK should be generated every time data is written — this eliminates the need to rotate DEKs separately.
  • DEKs should always be stored encrypted (wrapped by a KEK) and near the data they encrypt for easy access.

Envelope Encryption Process

  • Encryption
    • Create a KMS key (root/master key) in your KMS service.
    • Generate a data key using the KMS API (e.g., AWS KMS GenerateDataKey API).
    • KMS returns both the plaintext data key and the encrypted (ciphertext) data key.
    • Use the plaintext data key locally to encrypt the data.
    • Store the encrypted data key alongside the encrypted data.
    • Immediately discard the plaintext data key from memory.
  • Decryption
    • Retrieve the ciphertext data key and encrypted data from storage.
    • Call KMS Decrypt API to decrypt the ciphertext data key using the KMS key. The plaintext data key is returned.
    • Use the plaintext data key to decrypt the data locally.
    • Discard the plaintext data key from memory after use.
  • Encrypting the data key is more efficient than re-encrypting the data under the new key because it is quicker and produces a much smaller ciphertext.

Envelope Encryption Benefits

  • Protecting data keys
    • When you encrypt a data key, you don’t have to worry about storing the encrypted data key, because the data key is inherently protected by encryption. You can safely store the encrypted data key alongside the encrypted data.
  • Encrypting the same data under multiple keys
    • Encryption operations can be time-consuming, particularly when the data being encrypted are large objects.
    • Instead of re-encrypting raw data multiple times with different keys, you can re-encrypt only the data keys that protect the raw data.
  • Combining the strengths of multiple algorithms
    • In general, symmetric key algorithms are faster and produce smaller ciphertexts than public key algorithms.
    • But public key algorithms provide inherent separation of roles and easier key management.
    • Envelope encryption lets you combine the strengths of each strategy.
  • Performance and scalability
    • Only the small data key (typically 256 bits) needs to transit the network to KMS, not the large data payload.
    • Reduces latency since encryption/decryption of the actual data is performed locally.
    • Helps stay within KMS API request rate quotas for high-throughput workloads.
  • Overcoming the 4 KB KMS size limit
    • KMS keys can only directly encrypt data up to 4 KB. Envelope encryption removes this limitation by using locally generated data keys for the actual encryption.

AWS KMS Envelope Encryption APIs

  • GenerateDataKey — Returns a plaintext data key and a copy encrypted under the specified KMS key. Use this when you need to encrypt data immediately.
  • GenerateDataKeyWithoutPlaintext — Returns only the encrypted data key. Use this when you don’t need to encrypt data immediately but want to store a key for future use.
  • GenerateDataKeyPair — Returns an asymmetric data key pair (public key in plaintext, private key in plaintext and encrypted). Useful for client-side encryption where different parties encrypt/decrypt.
  • GenerateDataKeyPairWithoutPlaintext — Returns only the public key in plaintext and the private key encrypted.
  • Encrypt — Encrypts up to 4 KB of plaintext directly using a KMS key (not envelope encryption).
  • Decrypt — Decrypts a ciphertext that was encrypted by a KMS key, including encrypted data keys.

AWS Encryption SDK

  • The AWS Encryption SDK is a client-side encryption library that implements envelope encryption as a best-practice pattern.
  • It generates a unique symmetric data key for each encryption operation by default.
  • Supports multiple wrapping keys (KMS keys) — allowing the same data to be decryptable by multiple keys.
  • Includes key commitment — ensures the ciphertext can only be decrypted to a single plaintext (prevents ciphertext ambiguity attacks).
  • Data Key Caching — An optional feature that reuses data keys for multiple encryption operations to reduce KMS API calls and cost. Should be used cautiously with appropriate security thresholds (max age, max messages, max bytes).
  • Available for Java, Python, C, JavaScript, and .NET.

Key Rotation and Envelope Encryption

  • When a KMS key is rotated, only new data keys are encrypted with the new key material.
  • Previously encrypted data keys remain decryptable because AWS KMS retains all previous versions of the key material.
  • This means you do not need to re-encrypt all your data when rotating the KMS key — only the key wrapping changes for new operations.
  • AWS KMS Key Rotation Updates (April 2024):
    • Flexible automatic rotation periods — customizable between 90 days and 2,560 days (previously fixed at 365 days).
    • On-demand rotation — rotate key material immediately using RotateKeyOnDemand API, independent of the automatic rotation schedule.
    • Rotation visibility improvements — track rotation history and key material versions.
    • Cost capped at 2 rotations — $1/month is added for the first and second rotation; all subsequent rotations are free.
    • Imported key rotation (June 2025) — On-demand rotation is now supported for symmetric-encryption KMS keys with imported key material (EXTERNAL origin).

Post-Quantum Cryptography and Envelope Encryption

  • As quantum computing advances, organizations must prepare for potential threats to current cryptographic algorithms (store-now-harvest-later attacks).
  • AWS KMS Post-Quantum Support (2025):
    • ML-KEM (Module-Lattice Key Encapsulation Mechanism) — Post-quantum key exchange now supported in TLS connections to AWS KMS, ACM, and Secrets Manager (April 2025). Protects data in transit against future quantum threats.
    • ML-DSA (Module-Lattice Digital Signature Algorithm) — Post-quantum digital signatures supported in AWS KMS (June 2025). Enables quantum-resistant signing operations within FIPS 140-3 Level 3 certified HSMs.
  • Google Cloud KMS Post-Quantum Support (2025):
    • Announced support for quantum-safe Key Encapsulation Mechanisms (KEMs) in preview (June 2025).
    • Quantum-safe digital signatures available in Cloud KMS (February 2025).
  • While envelope encryption itself (symmetric AES-256-GCM for data) remains quantum-resistant, the key exchange and wrapping mechanisms need post-quantum upgrades.

KMS Key Storage Options

  • Standard KMS Key Store — Default option. Keys are stored and protected in multi-tenant FIPS-validated HSMs managed by AWS.
  • Custom Key Store (CloudHSM-backed) — Keys are stored in a dedicated AWS CloudHSM cluster you own and control. Provides single-tenant HSM with direct key control.
  • External Key Store (XKS) — Introduced November 2022. Keys are stored in an external key management system outside of AWS. Designed for regulated workloads requiring keys to remain outside AWS at all times. Key operations may have higher latency due to external dependencies.
  • Google Cloud EKM (External Key Manager) — Similar to AWS XKS, allows using keys managed by a supported external key manager with Google Cloud services.

Envelope Encryption in AWS Services

  • Amazon S3 — Uses envelope encryption for Server-Side Encryption with KMS (SSE-KMS). Each object is encrypted with a unique data key, which is wrapped by the KMS key.
  • Amazon EBS — Encrypts volumes using data keys wrapped by a KMS key. Supports default encryption for all new volumes.
  • Amazon RDS/Aurora — Uses envelope encryption for encryption at rest of databases, automated backups, snapshots, and read replicas.
  • Amazon DynamoDB — Encryption at rest uses envelope encryption with AWS managed or customer managed KMS keys.
  • AWS Secrets Manager — Encrypts secret values using envelope encryption with KMS keys.
  • Amazon EKS — Supports default envelope encryption for all Kubernetes API data (secrets). Uses KMS keys for encrypting data encryption keys at the Kubernetes layer.
  • Amazon MSK (Managed Streaming for Apache Kafka) — Supports envelope encryption with KMS for data at rest.

Google Cloud KMS Envelope Encryption

  • Google Cloud KMS uses a similar key hierarchy with DEKs and KEKs.
  • The Encrypt and Decrypt operations in Cloud KMS are limited to 64 KiB input size (vs 4 KB in AWS KMS).
  • For larger data, use envelope encryption with a local DEK wrapped by a Cloud KMS KEK.
  • Best practices for DEKs in Google Cloud:
    • Generate DEKs locally.
    • Always store DEKs encrypted at rest.
    • Store the DEK near the data it encrypts.
    • Generate a new DEK every time you write data.
    • Use AES-256-GCM cipher for data encryption.
  • Google Cloud offers client-side encryption with Tink library, which implements envelope encryption with Cloud KMS as the KEK provider.
  • Customer-Managed Encryption Keys (CMEK) — Allows control over encryption keys used by Google Cloud services, leveraging Cloud KMS for key management.
  • Customer-Supplied Encryption Keys (CSEK) — Available for Cloud Storage and Compute Engine; you supply your own AES-256 key as the KEK.

AWS Certification Exam Tips

  • Envelope encryption is a key topic for AWS Solutions Architect Associate (SAA-C03), AWS Security Specialty (SCS-C02), and AWS Developer Associate (DVA-C02) exams.
  • Understand the difference between direct KMS encryption (up to 4 KB) and envelope encryption (unlimited data size).
  • Know when to use GenerateDataKey vs Encrypt API — if data exceeds 4 KB, envelope encryption with GenerateDataKey is required.
  • Understand that the plaintext data key should be discarded from memory immediately after use.
  • Key rotation does not require re-encrypting existing data — old key material is retained for decryption.
  • Know the role of Encryption Context as additional authenticated data (AAD) that provides integrity and authenticity.

Practice Questions

  1. A company needs to encrypt files larger than 100 MB using AWS KMS. Which approach should they use?
    1. Use the KMS Encrypt API directly
    2. Split the file into 4 KB chunks and encrypt each with KMS
    3. Use envelope encryption with GenerateDataKey to create a data key, then encrypt the file locally
    4. Use AWS CloudHSM directly without KMS
    Show Answer

    Answer: c – KMS Encrypt can only handle up to 4 KB. Envelope encryption uses a locally generated data key for encrypting large files.

  2. In envelope encryption, what happens when the KMS key is rotated?
    1. All previously encrypted data must be re-encrypted
    2. All previously encrypted data keys must be re-wrapped
    3. Only new data keys are wrapped with the new key material; old data keys remain decryptable
    4. The rotation fails if there are existing encrypted data keys
    Show Answer

    Answer: c – AWS KMS retains all previous key material versions, so old data keys encrypted under older material can still be decrypted.

  3. Which AWS KMS API should be used to obtain a data key for envelope encryption when you need to encrypt data immediately?
    1. Encrypt
    2. GenerateDataKeyWithoutPlaintext
    3. GenerateDataKey
    4. CreateKey
    Show Answer

    Answer: c – GenerateDataKey returns both the plaintext and encrypted data key for immediate use. GenerateDataKeyWithoutPlaintext only returns the encrypted copy.

  4. What is the maximum data size that can be encrypted directly using the AWS KMS Encrypt API?
    1. 256 bytes
    2. 4 KB
    3. 64 KB
    4. 1 MB
    Show Answer

    Answer: b – The KMS Encrypt API can encrypt up to 4,096 bytes (4 KB) of plaintext directly.

  5. A developer wants to reduce AWS KMS API costs for an application that performs thousands of encryption operations per second. Which approach is recommended? (Select TWO)
    1. Use the AWS Encryption SDK with data key caching
    2. Call KMS Encrypt for each operation
    3. Implement envelope encryption to minimize KMS API calls
    4. Increase the KMS API request quota
    5. Use SSE-S3 instead of SSE-KMS
    Show Answer

    Answers: a, c – Data key caching reuses data keys to reduce KMS calls, and envelope encryption itself minimizes KMS interactions by using local encryption.

  6. Which statement about AWS KMS key rotation is correct as of 2024? (Select TWO)
    1. Automatic rotation can only occur every 365 days
    2. On-demand rotation is available via the RotateKeyOnDemand API
    3. Rotation periods can be customized between 90 and 2,560 days
    4. Key rotation requires re-encrypting all existing data
    5. Rotation is only supported for AWS managed keys
    Show Answer

    Answers: b, c – Since April 2024, AWS KMS supports flexible rotation periods (90-2,560 days) and on-demand rotation independent of automatic schedules.

References

Google Cloud KMS – Key Management & Encryption

~ Last updated on : ~ jayendrapatil

Google Cloud KMS Key Management Service

  • Google Cloud KMS – Key Management Service provides a centralized, scalable, fast cloud key management service to manage encryption keys
  • KMS helps apply hardware security modules (HSMs) effortlessly to the most sensitive data by just a toggle between software- and hardware-protected encryption keys with the press of a button.
  • KMS provides support for external keys using Cloud External Key Manager to protect the data in Google Cloud and separate the data from the key
  • Cloud KMS supports multiple protection levels:
    • SOFTWARE – keys protected by software
    • HSM – keys protected by Cloud HSM hardware security modules
    • EXTERNAL – keys managed in an external key manager via Cloud EKM over the internet
    • EXTERNAL_VPC – keys managed in an external key manager via Cloud EKM over a VPC network
  • Cloud KMS now supports post-quantum cryptography (PQC) algorithms to help protect against future quantum computing threats (see Post-Quantum Cryptography section below)

Cloud KMS Keys, Keys Versions, and Key Rings

  • A Cloud KMS key is a named object containing one or more key versions, along with metadata for the key.
  • A key exists on exactly one key ring tied to a specific location.
  • After creation, a key cannot be moved to another location or exported.
  • As of March 2026, keys and key versions can now be deleted (previously only key versions could be destroyed, not deleted). Deleted key names cannot be reused.

Google Cloud KMS Keys, Key Rings, and Key VersionsKey

  • A named object representing a cryptographic key that is used for a specific purpose. The key material – the actual bits used for cryptographic operations – can change over time as new key versions are created
  • Key is the most important object for understanding KMS usage.
  • Key purpose and other attributes of the key are connected with and managed using the key.
  • IAM permissions and roles can be used to allow and deny access to keys
  • Cloud KMS supports both asymmetric keys and symmetric keys.
    • Symmetric key
      • is used for symmetric encryption to protect some corpus of data for e.g., using AES-256 to encrypt a block of plaintext.
    • Asymmetric key
      • consists of a public and private key.
      • can be used for asymmetric encryption, or for creating digital signatures.
      • supports ECDSA on Curve25519 in PureEdDSA mode (added April 2024)
  • Cloud KMS also supports:
    • MAC signing keys – for creating and validating MAC digital signatures
    • Key Encapsulation Mechanism (KEM) keys – for post-quantum safe key encapsulation (Preview, Sept 2025)
  • Key’s type (symmetric or asymmetric) can’t be changed after key creation
  • Cloud KMS supports algorithms including AES-256, RSA 2048/3072/4096, EC P256, EC P384, Ed25519, and post-quantum algorithms (ML-DSA-65, SLH-DSA-SHA2-128S, ML-KEM-768, ML-KEM-1024, KEM-XWING)

Key Ring

  • A grouping of keys for organizational purposes.
  • Key ring belongs to Google Cloud project and resides in a specific location
  • Keys inherit IAM policies from the Key Ring that contains them.
  • Grouping keys with related permissions in a key ring allows you to grant, revoke, or modify permissions to those keys at the key ring level without needing to act on each key individually.
  • Key rings provide convenience and categorization
  • To prevent resource name collisions, a key ring cannot be deleted.
  • Key rings and keys do not have billable costs or quota limitations, so their continued existence does not affect costs or production limits.

Key Metadata

  • Includes resource names, properties of KMS resources such as IAM policies, key type, key size, key state, and any other derived data
  • Key metadata can be managed differently than the key material.

Key Version

  • Represents the key material associated with a key at some point in time.
  • Key version is the resource that contains the actual key material.
  • Granting access to a key also grants access to all of its enabled versions. Access to a key version cannot be managed.
  • A key version can be disabled or destroyed without affecting other versions
  • Disabling or destroying a key also disables or destroys each key version.
  • Versions are numbered sequentially, beginning with version 1.
  • When a key is rotated, a new key version is created with new key material.
  • The same logical key can have multiple versions over time, thus limiting the use of any single version.
  • Symmetric keys will always have a primary version. This version is used for encrypting by default, if no version is specified
  • Asymmetric keys do not have primary versions, and a version must be specified when using the key.
  • When Cloud KMS performs decryption using symmetric keys, it identifies automatically which key version is needed to perform the decryption.
  • Key versions can now be deleted (GA March 2026) in addition to being destroyed. Deleted key versions must meet specific deletion criteria.

Key States

  • A key version’s state is always one of the following:
    • Pending generation (PENDING_GENERATION)
      • Applies to asymmetric keys only
      • is still being generated and can’t be used, enabled, disabled, or destroyed yet.
      • KMS will automatically change the state to enabled as soon as the version is ready.
    • Pending import (PENDING_IMPORT)
      • Applies to imported keys
      • Key material is being imported and can’t be used yet.
      • KMS will automatically change the state to enabled once import completes.
    • Enabled (ENABLED)
      • is ready for use.
    • Disabled (DISABLED)
      • may not be used, but the key material is still available, and the version can be placed back into the enabled state.
    • Scheduled for destruction (DESTROY_SCHEDULED):
      • is scheduled for destruction, and will be destroyed soon.
      • can be placed back into the disabled state.
      • Default scheduled destruction duration is 30 days (changed from 24 hours as of June 2024). Custom durations can be configured between 24 hours and 120 days.
    • Destroyed (DESTROYED)
      • is destroyed, and the key material is no longer stored in Cloud KMS.
      • If the key version was used
        • for asymmetric or symmetric encryption, any ciphertext encrypted with this version is not recoverable.
        • for digital signing, new signatures cannot be created.
      • may not leave the destroyed state once entered, except when re-imported (supported since Sept 2021).
      • It takes 45 days from destruction time for key material to be deleted from all Google active and backup systems.
    • Import failed (IMPORT_FAILED)
      • Key import was attempted but failed.
      • The import can be retried.
  • A key version can only be used when it is enabled.
  • Organization policy constraints can require a key version to be disabled before it can be scheduled for destruction (constraints/cloudkms.disableBeforeDestroy)

Google Cloud KMS Key States

Key Rotation

  • For symmetric encryption, periodically and automatically rotating keys is a recommended security practice
  • Cloud KMS does not support automatic rotation of asymmetric keys and has to be done manually
  • With key rotation, data encrypted with previous key versions is not automatically re-encrypted with the new key version.
  • Rotating keys provides several benefits:
    • Limiting the number of messages encrypted with the same key version helps prevent brute-force attacks enabled by cryptanalysis.
    • In the event that a key is compromised, regular rotation limits the number of actual messages vulnerable to compromise.
    • If you suspect that a key version is compromised, disable it and revoke access to it as soon as possible.
    • Regular key rotation helps validate the key rotation procedures before a real-life security incident occurs.
    • Regular key rotation ensures that the system is resilient to manual rotation, whether due to a security breach or the need to migrate your application to a stronger cryptographic algorithm.

Key Hierarchy

Google Cloud KMS Key Hierarchy

  • Data Encryption Key (DEK)
    • A key used to encrypt data.
  • Key Encryption Key (KEK)
    • A key used to encrypt, or wrap, a DEK.
    • All Cloud KMS platform options (software, hardware, and external backends) allow you to control KEK.
  • KMS Master Key
    • The key used to encrypt the KEK.
    • This key is distributed in memory.
    • KMS Master Key is backed up on hardware devices.
  • Root KMS
    • Google’s internal key management service.

Cloud KMS Autokey

  • Cloud KMS Autokey (GA September 2024) simplifies creating and using customer-managed encryption keys (CMEKs) by automating provisioning and assignment.
  • With Autokey, key rings, keys, and service accounts don’t need to be planned and provisioned before they’re needed. Instead, Autokey generates keys on demand as resources are created.
  • Keys created by Autokey use HSM protection level by default and follow recommended practices for:
    • Separation of duties
    • Key rotation
    • Location matching
    • Key specificity
  • Supported services include Cloud Storage, Compute Engine, BigQuery, Secret Manager, Cloud SQL, and Spanner.
  • Autokey supports two key management models:
    • Centralized key management – keys are created in a dedicated key project for all resources in a folder
    • Delegated key management (Autokey for Projects) – keys are created in the same project as the resources they protect (Public Preview, Feb 2026)
  • Autokey has a free tier (since April 2025):
    • 100 free active key versions monthly
    • 10,000 free cryptographic operations monthly
  • Uses a KeyHandle resource model: creating a KeyHandle triggers Autokey to provision a CryptoKey automatically.

Post-Quantum Cryptography (PQC)

  • Cloud KMS supports post-quantum cryptography algorithms to protect against threats from future quantum computers (“harvest now, decrypt later” attacks).
  • PQC Digital Signatures (Public Preview, February 2025):
    • ML-DSA-65 (FIPS 204) – Module-lattice-based digital signature algorithm
    • SLH-DSA-SHA2-128S (FIPS 205) – Stateless hash-based digital signature algorithm
    • These are NIST-approved post-quantum safe algorithms
  • Key Encapsulation Mechanisms (KEMs) (Preview, September 2025):
    • ML-KEM-768 – NIST-standardized lattice-based KEM
    • ML-KEM-1024 – Higher-security variant of ML-KEM
    • KEM-XWING – Hybrid KEM combining classical and post-quantum algorithms
    • KEMs enable sharing secrets resistant to quantum attacks
    • Uses a new key purpose: KEY_ENCAPSULATION
  • Google Cloud network encryption already uses ML-KEM for cryptographic key exchange by default, protecting all customer workloads.

Single-tenant Cloud HSM

  • Single-tenant Cloud HSM (GA December 2025) provides dedicated single-tenant HSM instances for customers requiring the highest level of isolation.
  • Each instance is a cluster of partitions on HSMs in a single Cloud KMS region.
  • Google manages the physical HSMs, but customers have administrative control over their instance.
  • Available in: us-central1, us-east4, europe-west1, europe-west4
  • Creating and managing an instance requires quorum approval with two-factor authentication using keys created and secured outside of Google Cloud.
  • Single-tenant Cloud HSM incurs additional costs beyond standard Cloud HSM pricing.
  • This differs from standard (multi-tenant) Cloud HSM where Google manages shared HSM infrastructure.

Cloud KMS Locations

  • Within a project, Cloud KMS resources can be created in one of many locations.
  • A key’s location impacts the performance of applications using the key
  • Regional
    • data centers exist in a specific geographical place
  • Dual-regional
    • data centers exist in two specific geographical places.
  • Multi-regional
    • data centers are spread across a general geographical area
  • Global
    • special multi-region with its data centers spread throughout the world
  • Reading and writing resources or associated metadata in dual-regional or multi-regional locations, including the global location may be slower than reading or writing from a single region.
  • Cloud KMS is available in 35+ regions worldwide, including recent additions: asia-southeast3 (Jan 2026), europe-north2 (Mar 2025), northamerica-south1 (Nov 2024), and africa-south1 (Jan 2024)

Cloud External Key Manager (Cloud EKM)

  • Cloud EKM lets you use encryption keys managed within a supported external key management system to protect data within Google Cloud.
  • Supports two connectivity options:
    • Cloud EKM over the internet – communicates with external key manager over the internet
    • Cloud EKM over a VPC – communicates via a Virtual Private Cloud network (private endpoint)
  • Coordinated external keys (since March 2023) – allows creating and managing keys in a compatible external key management system directly from Cloud KMS over a VPC network
  • Partner-managed EKM – arrangement where your EKM is managed by a trusted partner
  • Supported EKM partners include Thales CipherTrust, Fortanix, and others
  • Integrates with Key Access Justifications – provides visibility into reasons for each key access request, enabling fine-grained access control based on justification codes

Encryption Metrics and Key Tracking

  • Encryption Metrics Dashboard (GA May 2026) provides visibility into key usage across CMEK integrations.
  • Shows summaries and details of keys used in CMEK integrations and the resources they protect.
  • Supports both centralized and delegated key management models.
  • Project-level key tracking allows viewing which resources are protected by which keys.
  • Available via Google Cloud Console under Security > Key Management.

Organization Policy Constraints

  • Cloud KMS supports several organization policy constraints for governance:
    • constraints/gcp.restrictNonCmekServices – requires CMEK protection for specified services
    • constraints/gcp.restrictCmekCryptoKeyProjects – limits which KMS keys can be used for CMEK
    • constraints/cloudkms.disableBeforeDestroy – requires key version to be disabled before destruction
    • constraints/cloudkms.allowedProtectionLevels – controls which protection levels can be used (e.g., only EXTERNAL or EXTERNAL_VPC)
  • Custom organization policy constraints (Oct 2024) provide more granular control over specific fields for Cloud KMS resources.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Question 1: Your organization requires that all encryption keys used to protect Cloud Storage data are automatically provisioned with HSM protection and follow best practices for key management. Which Cloud KMS feature should you use?

  1. Cloud EKM with VPC
  2. Cloud KMS Autokey
  3. Manual CMEK creation with HSM protection level
  4. Google-managed encryption keys (GMEK)
Show Answer

Answer: 2 – Cloud KMS Autokey automatically provisions CMEK keys with HSM protection level, following best practices for separation of duties, rotation, and key specificity.

Question 2: Your security team is concerned about “harvest now, decrypt later” attacks where encrypted data is captured today and decrypted by future quantum computers. Which Cloud KMS capability helps mitigate this threat?

  1. Symmetric AES-256 encryption
  2. Cloud HSM with FIPS 140-2 Level 3
  3. Post-quantum cryptography (PQC) digital signatures and KEMs
  4. Key rotation every 90 days
Show Answer

Answer: 3 – Cloud KMS supports post-quantum safe algorithms including ML-DSA-65, SLH-DSA-SHA2-128S for digital signatures, and ML-KEM-768/1024 and KEM-XWING for key encapsulation, designed to resist quantum computer attacks.

Question 3: What is the default scheduled destruction duration for Cloud KMS key versions?

  1. 24 hours
  2. 7 days
  3. 30 days
  4. 90 days
Show Answer

Answer: 3 – As of June 2024, the default scheduled destruction duration is 30 days (changed from the previous 24-hour default). Custom durations between 24 hours and 120 days can be configured.

Question 4: Your company needs dedicated HSM hardware with administrative control, where creating instances requires quorum approval with two-factor authentication. Which Cloud KMS offering meets this requirement?

  1. Multi-tenant Cloud HSM
  2. Single-tenant Cloud HSM
  3. Cloud EKM with VPC
  4. Bare Metal HSM
Show Answer

Answer: 2 – Single-tenant Cloud HSM (GA Dec 2025) provides dedicated single-tenant instances with customer administrative control, requiring quorum approval with 2FA for management operations.

Question 5: Which statements about Cloud KMS key deletion are correct? (Choose 2)

  1. Key rings can be deleted
  2. Keys and key versions can be deleted if they meet deletion criteria
  3. Names of deleted keys can be reused
  4. Keys must meet deletion criteria before they can be deleted
  5. Deleted keys are immediately removed from all systems
Show Answer

Answer: 2, 4 – As of March 2026, keys and key versions can be deleted (GA), but they must meet specific deletion criteria. Key rings cannot be deleted, and names of deleted keys cannot be reused.

See also: Google Cloud Security Services Cheat Sheet

References

Google Cloud Encryption – At Rest & In Transit

~ Last updated on : ~ jayendrapatil

Google Cloud Data 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
  • Encryption can be used to protect data in three states:
    • Encryption at Rest protects the data from a system compromise or data exfiltration by encrypting data while stored.
    • Encryption in Transit: protects the data if communications are intercepted while data moves between the site and the cloud provider or between two services.
    • Encryption in Use: protects the data when it is being used by servers to run computations, using hardware-based Trusted Execution Environments (TEEs) such as Confidential Computing.

Encryption at Rest

  • Google uses several layers of encryption to protect customer data at rest.
  • All customer content stored at rest is encrypted, without any action required from the customer, using one or more encryption mechanisms.
  • All data stored in Google Cloud is encrypted at the storage level using AES-256
  • Google encrypts data prior to it being written to disk.

Google Cloud Encryption At Rest Options

Google Cloud Default Encryption

  • Data for storage is split into chunks
  • Each chunk is encrypted with a unique Data Encryption Key (DEK)
  • Two chunks will not have the same encryption key, even if they are part of the same Cloud Storage object, owned by the same customer, or stored on the same machine
  • If a chunk of data is updated, it is encrypted with a new key, rather than by reusing the existing key
  • Data encryption keys are stored with the data because of the high volume of keys at Google, and the need for low latency and high availability
  • Backups are encrypted using a separate DEK
  • Data encryption keys are encrypted with (“wrapped” by) Key Encryption Keys (KEK) also referred to as Envelope Encryption
  • KEKs are stored centrally inside Google’s Key Management Service (KMS)
  • Having a smaller number of KEKs than DEKs and using a central KMS makes storing and encrypting data at Google scale manageable, and allows tracking and controlling data access from a central point.
  • KEKs are not exportable from Google’s KMS by design; all encryption and decryption with these keys must be done within KMS
  • KMS can automatically rotate KEKs at regular time intervals
  • KMS maintains an active key with a set of historical keys for decryption
  • Google uses a common cryptographic library, Tink, which incorporates the FIPS 140-2 validated module, BoringCrypto, to implement encryption consistently across almost all Google Cloud products.

Google Cloud Default Data Encryption

Google Cloud Default Decryption

  • Service makes a call to the storage system for the data it needs.
  • The storage system identifies the chunks in which that data is stored (the chunk IDs) and where they are stored.
  • For each chunk, the storage system pulls the wrapped DEK stored with that chunk and sends it to KMS for unwrapping.
  • 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
  • KMS verifies that the storage system is authorized both to use the KEK associated with the service and to unwrap that specific DEK.
  • KMS passes the unwrapped DEK back to the storage system, which decrypts the data chunk and passes it to the service.

Google Cloud Decryption

Cloud Key Management Service (Cloud KMS)

  • Cloud KMS helps centralize management of encryption keys
  • Google’s Key Management Service is redundant and globally distributed.
  • Cloud KMS allows the customer to manage the encryption keys (CMEK)
  • A CMEK or Customer Managed Encryption Key can be used in both server-side encryption (SSE) and client-side encryption (CSE).
  • CMEK key can be used with KMS encrypt/decrypt and also be attached to a bucket, GCE disk, etc.
  • CMEK supports importing your own key material, which is useful for migrations.
  • Cloud KMS supports multiple protection levels:
    • SOFTWARE – cryptographic operations performed in software (FIPS 140-3 Level 1 validated)
    • HSM (Multi-tenant) – keys stored in Google-owned FIPS 140-2 Level 3 validated Hardware Security Modules
    • HSM_SINGLE_TENANT – keys stored in dedicated HSM partitions exclusively for a single customer (introduced 2025)
    • EXTERNAL – keys generated and stored in an external key management system, accessed over the internet
    • EXTERNAL_VPC – keys in an external system accessed over a VPC network for better availability
  • Cloud KMS now supports permanent key deletion (GA, Feb 2026) – allows deleting CryptoKeys and CryptoKeyVersions permanently. Deleted key names cannot be reused.

Cloud KMS Autokey

  • Cloud KMS Autokey (GA, 2024) simplifies creating and using CMEKs by automating provisioning and assignment.
  • Autokey automatically creates key rings, keys, and service accounts on demand when resources are created.
  • Eliminates the need to pre-plan and provision keys before they are needed.
  • Incorporates recommended best practices for key management automatically, including key rotation, separation of duties, and appropriate key granularity.
  • Supported services include Cloud Storage, Compute Engine, BigQuery, Cloud Run, Secret Manager, and more.
  • Autokey reduces operational toil for teams managing CMEK at scale.

Post-Quantum Cryptography in Cloud KMS

  • Cloud KMS now supports quantum-safe digital signatures (Preview, Feb 2025) using NIST post-quantum standards:
    • ML-DSA-65 (FIPS 204) – Module-Lattice-Based Digital Signature Algorithm
    • SLH-DSA-SHA2-128s (FIPS 205) – Stateless Hash-Based Digital Signature Algorithm
  • Cloud KMS supports post-quantum Key Encapsulation Mechanisms (KEMs) (Preview, 2025):
    • ML-KEM-768 and ML-KEM-1024 – Module-Lattice-Based Key Encapsulation
    • KEM-XWING – hybrid key encapsulation combining X25519 and ML-KEM
  • These capabilities protect against “Harvest Now, Decrypt Later” attacks where adversaries capture encrypted data today intending to decrypt it with future quantum computers.
  • Google Cloud network encryption already uses ML-KEM by default for all internal cryptographic key exchanges, protecting customer workloads automatically.

Single-Tenant Cloud HSM

  • Single-Tenant Cloud HSM (introduced 2025) provides dedicated HSM partitions exclusively for a single customer.
  • Designed for workloads requiring FIPS 140-2 Level 3 validation with cryptographic isolation from other customers.
  • Each instance is a dedicated cluster of HSM partitions distributed across multiple zones within a region for high availability.
  • Instance administrators have administrative control over the instance.
  • Keys can be generated by Google or imported into the single-tenant instance.
  • Useful for highly regulated industries (financial services, healthcare, government) requiring exclusive hardware isolation.

Cloud External Key Manager (Cloud EKM)

  • Cloud EKM allows using encryption keys managed in a supported external key management partner service.
  • Two connectivity options:
    • EKM over the internet (EXTERNAL protection level) – keys accessed via the internet
    • EKM over VPC (EXTERNAL_VPC protection level) – keys accessed over a VPC network for better availability and security
  • Google Cloud never accesses external key material.
  • Supported by many CMEK-integrated services.
  • Organization policies can restrict key creation to only EXTERNAL or EXTERNAL_VPC types for compliance requirements.

Customer-Supplied Encryption Keys (CSEKs)

  • Customer-Supplied Encryption Keys (CSEK) allows you to supply your own encryption keys. Google uses the key to protect the Google-generated keys used to encrypt and decrypt your data.
  • CSEK is supported only by Cloud Storage and Compute Engine.
  • CSEK Encryption
    • User provides a raw CSEK as part of an API call.
    • The key is transmitted from the Google front end to the storage system’s memory
    • This key is used as the Key Encryption Key (KEK) in Google Cloud Storage for the data.
  • CSEK Decryption
    • Raw CSEK is used to unwrap wrapped chunk keys, to create raw chunk keys in memory.
    • These are used to decrypt data chunks stored in the storage systems.
    • These keys are used as the data encryption keys (DEK) in Google Cloud Storage for your data.
  • Raw CSEK, CSEK-derived keys, and raw chunk/disk keys are never stored on disk unencrypted.
  • Raw chunk/disk keys are stored wrapped with CSEK-derived keys, and with Google keys where automatic restart is used. Google does not permanently store your keys on its servers.

Google Cloud Encryption At Rest Decision Tree

Encryption in Transit

  • Google applies several security measures to help ensure the authenticity, integrity, and privacy of data in transit.
    • Authentication: data source verification, either a human or a process, and destination.
    • Integrity: ensures data sent arrives at its destination unaltered.
    • Encryption: ensures data is unintelligible to keep it private.
  • Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.
  • Data is encrypted and authenticated in transit at one or more network layers when it moves outside physical boundaries not controlled by Google or on behalf of Google.
  • Depending on the connection that is being made, Google applies default protections to data in transit for e.g., communications are secured between the user and the Google Front End (GFE) using TLS.
  • Google Cloud customers with additional requirements for encryption of data over WAN can choose to implement further protections for data as it moves from a user to an application or VM to VM. These protections include IPSec tunnels, Gmail S/MIME, managed SSL certificates, and service mesh mTLS.
  • Google uses Application Layer Transport Security (ALTS) for mutual authentication and transport encryption of RPC communications within Google’s infrastructure.
  • Google Cloud network encryption now uses post-quantum key exchange (ML-KEM) by default to protect data in transit between Google facilities.

Google Cloud Encryption In Transit

  • [Connection A] – User to Google Front End
    • Google accepts requests from around the world using a globally distributed system called the Google Front End (GFE)
    • GFE terminates traffic for incoming HTTP(S), TCP, and TLS proxy traffic, provides DDoS attack countermeasures, and routes and load balances traffic to the Google Cloud services themselves.
    • User requests to customer applications can be routed through a Google Cloud HTTP(S) or TCP/SSL Proxy Load Balancer external load balancer
    • Google automatically encrypts traffic between GFEs and the backends load balancers that reside within VPC networks
    • Certificate Manager provides automated provisioning and management of TLS certificates for load balancers, including Google-managed certificates with automatic renewal.
  • [Connection B] – User to customer application hosted on Google Cloud
    • Cloud VPN or Interconnect can help secure a direct connection to a VM using an external IP or network load balancer IP. As the connection does not go through GFE, it’s not encrypted by default.
  • [Connection C] – Virtual Machine to Virtual Machine
    • VM to VM connections are encrypted if they leave a physical boundary, and are authenticated within the physical boundary.
    • VM to VM traffic, using external IP addresses, is not encrypted by default, and its security is provided at the user’s discretion
  • [Connection D] – Virtual Machine to Google Cloud Service
    • Connectivity to Google APIs and services can be protected using Private Google Access or Private Service Connect
    • From the VM to the GFE, Google Cloud services support protecting these connections with TLS by default
  • [Connection E] – Google Cloud Service to Google Cloud Service
    • Routing from one Google service to another takes place on Google Cloud network backbone and may require routing traffic outside of physical boundaries controlled by or on behalf of Google
    • Connections between these services are encrypted if they leave a physical boundary, and authenticated within the physical boundary.

Encryption in Use – Confidential Computing

  • Confidential Computing protects data while it is being processed using hardware-based Trusted Execution Environments (TEEs).
  • Encrypts data in memory, ensuring even the cloud provider cannot access data during processing.
  • Confidential VMs encrypt the memory contents of virtual machines using:
    • AMD SEV (Secure Encrypted Virtualization) – N2D machine series
    • AMD SEV-SNP (Secure Nested Paging) – provides additional memory integrity protection
    • Intel TDX (Trust Domain Extensions) – GA on C3 machine series (Sept 2024), creates isolated trust domains
  • Confidential VMs with NVIDIA H100 GPUs (Preview, Oct 2024) – protects AI/ML workloads with GPU-level TEEs, ensuring data remains protected throughout the entire processing pipeline.
  • Confidential GKE Nodes – extends Confidential Computing to Kubernetes workloads.
  • Confidential Space – enables multi-party computation where multiple organizations can collaborate on data without exposing raw data to each other.
  • Supports remote attestation for verifying the integrity of the execution environment.
  • Enables encryption of data across its entire lifecycle: at rest, in transit, and in use.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your organization requires that encryption keys used in Google Cloud must never be accessible to Google. Which encryption option should you use?
    1. Google default encryption
    2. Customer-Managed Encryption Keys (CMEK)
    3. Customer-Supplied Encryption Keys (CSEK)
    4. Cloud External Key Manager (Cloud EKM)

    Answer: d. Cloud EKM keys are stored in an external key management system and Google Cloud never accesses the key material.

  2. A financial services company needs dedicated HSM hardware that is not shared with other customers. Which Cloud KMS protection level should they select?
    1. SOFTWARE
    2. HSM (Multi-tenant)
    3. HSM_SINGLE_TENANT
    4. EXTERNAL_VPC

    Answer: c. Single-Tenant Cloud HSM provides dedicated HSM partitions exclusively for a single customer with cryptographic isolation.

  3. Your security team is concerned about “Harvest Now, Decrypt Later” attacks from future quantum computers. Which Cloud KMS feature addresses this?
    1. AES-256 symmetric encryption
    2. Cloud HSM with FIPS 140-2 Level 3
    3. Post-quantum Key Encapsulation Mechanisms (KEMs)
    4. Customer-Supplied Encryption Keys

    Answer: c. Post-quantum KEMs (ML-KEM-768, ML-KEM-1024, KEM-XWING) are designed to protect against future quantum computing threats.

  4. Which of the following is true about Cloud KMS Autokey? (Select TWO)
    1. It creates key rings and keys on demand when resources are created
    2. It only works with Cloud Storage
    3. It requires manual provisioning of service accounts
    4. It incorporates recommended best practices for key management automatically
    5. It replaces Cloud EKM

    Answer: a, d. Autokey automates key provisioning on demand and follows recommended best practices automatically.

  5. Which Google Cloud technology protects data while it is being processed in memory?
    1. Cloud KMS with CMEK
    2. Confidential Computing with Confidential VMs
    3. Customer-Supplied Encryption Keys
    4. Cloud Armor

    Answer: b. Confidential VMs use hardware-based TEEs (AMD SEV, AMD SEV-SNP, Intel TDX) to encrypt data in memory during processing.

  6. Your organization wants to automate TLS certificate lifecycle management for load balancers. Which service should you use?
    1. Cloud KMS
    2. Certificate Manager
    3. Cloud Armor
    4. Secret Manager

    Answer: b. Certificate Manager provides automated provisioning, management, and renewal of TLS certificates for Google Cloud load balancers.

References