In November 2019, Google announced the External Key Manager (EKM) service at the Google Cloud Next UK conference. Google Cloud’s External Key Manager is a next-level control for encryption keys, with a wide and growing range of over 20 Google services running in the Google Cloud Platform (GCP).

EKM allows encrypting data in Big Query and Google Compute Engine (GCE), with an external Key management service deployed outside Google’s infrastructure but controlled entirely by the User from a single point of management.

Companies can leverage cloud computing and analytics power when they maintain separation between data-at-rest and encryption keys.

Many cloud service providers have a provision where companies can bring their own Keys (BYOK); however, Google Cloud Platform is the first public cloud provider that enables companies to bring their own Key management system (BYOKMS).

The Fortanix DSM supports Google EKM integration. With this capability, Fortanix customers can migrate new classes of sensitive financial services, healthcare, and other applications requiring the highest data privacy compliance levels to the public Cloud.

Google EKM extends the envelope encryption scheme to allow the Key Encryption Key (KEK) to be encrypted using an externally managed Key Encryption Key (EKEK).

First, the data is encrypted using a local Data Encryption Key (DEK) stored with the data. DEK is then encrypted using a Key Encryption Key (KEK) stored separately in Cloud Key Management System (KMS) or Cloud Hardware Security Module (HSM).

Services running on GCP, such as Big Query and GCE, currently can use an encryption Key hosted by Google Cloud KMS or Cloud HSM to secure their data at rest.

Key provenance records Key creation processes. It includes information on who created the Key, when, the cryptographic model used, Key authorization, and the need for its creation.

Key provenance is applied throughout the Key lifecycle and provides details on how Keys are stored, accessed, used, and destroyed.

Organizations can track Key origins, location, backup history, and other characteristics. Provenance helps organizations validate Key encryption and other qualitative metrics.

Key centralization results in fewer Key distribution cycles and reduces the risks of keys being compromised.

It helps organizations focus on auditing and managing a single control unit instead of governing policies fragmented over different systems.

Centralized Key Management enables Key creation, Key rotation, and Key deletion in any number of cloud platforms. This setup allows flexibility in multi-cloud and hybrid architectures.

With Google EKM, organizations can fully own the encryption keys and store them on-premises under self-administrative control.

This setup will allow them to revoke Google’s access to the data if required for security purposes or to limit Google’s exposure to sensitive customer data.

Organizations can authorize and validate the use of Key and maintain a complete provenance of the root key.

Key Access Justifications (KAJ) feature of the EKM allows organizations to deny Google direct access to decrypt data even in incidents that are out of control or requested by a third-party authority.

KAJ provides a detailed justification for every request to decrypt data. Organizations can explicitly approve or deny cryptographic requests based on an access reason policy.

For example, organizations can allow Google to initiate access to the Key Encryption Keys (KEK) but reject access to third parties or when no justification is provided.

Organizations can use an audit log entry for each cryptographic operation, including the access reason.

• High Availability – External Key Manager (EKM) must be available as the GCP KMS service with which it integrates.
• Disaster Recovery - Google does not store keys on its servers and cannot access protected disks unless the organization provides it with the Key to Cloud EKM. If the Key is lost, there is no way for Google to recover the Key or any data encrypted with the lost Key.
• Performance - Latency and throughput should be within acceptable limits.
• Role-based access control - Access to the EKM Keys must be based on the roles of authorized users.
• Auditability - Operations performed outside the Cloud on the EKM must be logged with a high level of granularity.

The following services support Cloud EKM keys:

• Compute Engine/Persistent Disk
  Compute Engine encrypts customer data at rest by default. By using cloud EKM, organizations can control and manage default encryption and Data Encryption Keys (DEK) used to protect the Persistent Disks.
• BigQuery
  Organizations can encrypt data stored in BigQuery. They need to provide additional approval to access keys for revoking data from BigQuery cache.
• Google Kubernetes Engine (GKE)
  In GKE, Cloud EKM keys can be used to protect data on Virtual Machine disks (node boot disks and attached disks) and Application-layer Secrets.
• Cloud EKM keys can be used to encrypt Cloud SQLs and their backups with the same Key

Fortanix DSM supports the following customer-managed encryption keys (CMEK) integration services on the Google cloud:

• Artifact Registry
• BigQuery
• Compute Engine
• Cloud Logging: Log Router
• Cloud Spanner
• Cloud SQL
• Cloud Storage
• Dataflow Appliance and Dataflow shuffle
• Dataproc
• Google Kubernetes Engine: Data on VM disks or Application-layer Secrets
• Pub/Sub
• Secret Manager

The Fortanix DSM integration is available immediately as an on-premises solution and SaaS offering with a FIPS 140-2 Level 3 certified™

TM: A Certification Mark of NIST, which does not imply product endorsement by NIST, the US or Canadian Governments

• In a Google EKM integration for any Google services, the Google service reaches out to Fortanix DSM service to access the CMEK (Customer Managed Encryption Key). 
• For any on-premises cluster, you need to expose the Fortanix DSM service to GCP service with proper network access restrictions and considerations. 

Fortanix BV (Netherlands office) is a separate European entity. We have datacenters in Europe.

Any European entity would not be allowed by contract to transfer information to the USA, and this entity's ownership doesn't allow an American court to request the encryption keys through the Cloud Act.