This content was last updated in November 2023 and represents the status quo asof the time that it was written. Google's security policies and systems maychange going forward, as we continually improve protection for our customers.
To help you meet corporate and compliance regulations, Cloud HSM letsyou generate your encryption keys and perform cryptographic operations in FIPS140-2 Level 3 certified hardware security modules (HSM).
This paper describes Cloud HSM architecture, including how the hardwareis managed and keys are attested and created.
Overview
Cryptographic operations include encrypting data at rest, protecting theprivate keys forCertificate Authority Service,and protecting data encryption keys so that they can be stored together with theencrypted data. Cloud HSM uses Marvell LiquidSecurity HSMs (modelsCNL3560-NFBE-2.0-G and CNL3560-NFBE-3.0-G) with the firmware versions 3.4 build09. For more information about our certification, seeCertificate #4399.
Cloud HSM is fully managed so that you can protect your workloadswithout the operational overhead of managing an HSM cluster. The serviceprovides the following advantages:
- Global availability
- A consistent and unified API
- Automatic scaling based on your use
- Centralized management and regulatory compliance
Cloud HSM is available in every Google Cloud region around the globe,including multi-regions that span larger geographies. When you enableCloud HSM, you can create and use HSM-backed keys to protect your data,including data that you store in other Google Cloud services, such asBigQuery, Cloud Storage, andPersistent Disk.
Because Cloud HSM and the HSM hardware are managed by Google, you don'tneed to manage the HSM-backed keys in production. When you useCloud HSM, your data is strictly isolated from other tenants andservices in Google Cloud. The Cloud HSM data plane API, which is partof theCloud Key Management Service API, lets you manage HSM-backed keys programmatically.
Cloud HSM supports HSM-backedcustomer-managed encryption keys (CMEK) wherever CMEK keys are supported across Google Cloud. For example, you canencrypt data in Cloud Storage buckets or Cloud SQL tables using aCloud HSM key that you manage.
Cloud HSM management
Within Cloud HSM, clusters of HSMs are maintained by Googlesite reliability engineers (SREs) and technicians who work in each Google Clouddata center location. Google handles physical security, logical security,infrastructure, capacity planning, geo-expansion, and data centerdisaster-recovery planning.
Abstraction of HSM hardware
Typically, applications communicate directly with HSMs using both PKCS#11 and acluster management API. This communication requires that you maintainspecialized code for workloads that use or manage HSM-backed keys.
Cloud HSM abstracts communication away from the HSM by proxyingrequests for HSM-backed keys through the Cloud Key Management Service API. The abstraction reducesthe need for HSM-specific code. Cloud HSM inherits tight integrationwith Cloud KMS.
Tight integration with Cloud KMS provides substantial securitybenefits. The Cloud Key Management Service API significantly reduces the breadth of the HSM interfaceavailable, reducing risk in the case of a customer security breach. For example,an attacker would be unable to wipe entire HSMs. By default, attempts to destroyindividual keys are mitigated through a default 24-hour safety period. You can set theconstraints/cloudkms.minimumDestroyScheduledDuration organization policy toenforce a minimum length for the scheduled for destruction duration for newkeys and the constraints/cloudkms.disableBeforeDestroy organization policy todelete key versions only when they are disabled. For more information, seeControl key version destruction.
You can control access to HSM resources usingIdentity and Access Management (IAM). IAM configuration is less likely to suffer frommisconfigurations and bugs than a custom HSM solution.
Strict geographic separation, by design
In Cloud HSM, you can choose to make keys globally available or toenforce strict geographic restrictions on keys that require restrictions.
Often, HSMs are divided into partitions, so that a single physical device canoperate as multiple logical devices. You might use partitions to reducedeployment costs in cases where you need to separate HSM administration andkeys.
Each Cloud HSM regional location is associated with a separate wrappingkey. The wrapping key is cloned onto a partition in each HSM in the location,but never leaves the HSM in the location. Cloning lets HSMs in the same regionto serve the same set of customer keys, and ensures that HSMs outside the regioncannot serve those keys.
Cloud HSM also creates multi-regions using wrapping keys. All customerkeys for a multi-region are wrapped using a wrapping key present on a partitionin all locations that constitute the multi-region. The service uses thesame hardware for multi-regions, but provides the same strong isolation betweenregions and multi-regions that exists between different regions.
The regionalization scheme requires that wrapping keys are only replicated toappropriate partitions. Each configuration change must be approved by multiplemembers of the Cloud HSM team before it becomes active. Data centertechnicians can't access an HSM configuration, runtime, or storage in the field.
Centralized management
In a traditional data center that hosts HSMs, management of the HSMs and theirresources is entirely separate from management of other cryptographic resources.Cloud HSM is tightly integrated into Google Cloud, allowing you toseamlessly manage your Cloud HSM resources. For example, you can managethe following:
- You manage your HSM-backed resources alongside your other keys inCloud KMS and externally managed keys inCloud External Key Manager (Cloud EKM).
- You manage access to HSM-backed resources within IAM.
- Cost reporting for cryptographic operations using HSM-backed keys arereported in Cloud Billing.
- You can use HSM-backed keys transparently in all Google Cloud services thatsupport encrypting resources using CMEK.CMEK integrations require the CMEK key and the data it encrypts to belocated in compatible geographic locations. Because of the strict geographicrestriction of the Cloud HSM keys, all encryption and decryption ofthe CMEK data are also geographically restricted.
- Administrative operations on HSM-backed resources are always logged atthe API layer in Cloud Audit Logs. You can choose to enable data-accesslogging as well. For more information, seeCloud KMS audit logging information.
- Google partners directly with the HSM manufacturer to keep the hardware andsoftware on each HSM updated, and to find and fix issues in real time. Inthe event of a zero-day exploit on the HSM, Google can selectively disableaffected code paths on affected HSM clusters until the exploit is fixed.
Developer and user experience
Because Google is responsible for HSM management, Cloud HSM offerssignificant benefits to developers and end users.
HSMs at Google scale
When you rely on hardware that exists on-premises or in data centers, thehardware can create a performance bottleneck or become a single point offailure. Cloud HSM is designed to be extremely resilient tounpredictable workloads and hardware failures. The Cloud HSM backenduses a pool of HSMs in each region to ensure high availability and scalability. This pool of HSMs letsCloud HSM also provide high throughput. For more information, seeMonitor and adjust Cloud KMS quotas.
All customer keys are stored wrapped with a regional wrapping key in theCloud KMS database and can only be unwrapped by an HSM in the region aspart of a cryptographic operation. This wrapping has the following benefits:
- A key's durability is not tied to a specific HSM or subset of HSMs in aregion.
- Each Cloud HSM customer experiences the full scale and availabilityof the Cloud HSM clusters that serve their keys.
- Cloud HSM can handle a much larger set of keys that can be storedon an HSM.
- Adding or replacing an HSM is rapid and secure.
Unified API design
Cloud HSM and Cloud KMS share a common management and dataplane API. The internal details of communicating with an HSM are abstracted fromthe caller.
Consequently, no code changes are required to update an existing applicationthat uses software keys in Cloud KMS to support HSM-backed keys.Instead, you update the resource name of the key to use.
PKCS#11 support
You can use Cloud Key Management Service API to connect your existing applications to Cloud HSMto manage cryptographic keys. ThePKCS#11 library lets you use HSM-backed keys to sign your binaries and serve TLS web sessions.
Security and regulatory compliance
Cloud HSM has obtained compliance with numerous regulations, includingFedRAMP High,C5:2020, andOSPAR. In addition,Cloud HSM helps you enforce regulatory compliance for your workloads inthe cloud.
Cryptographic key attestation
Each time you generate or import a Cloud HSM key, the HSM generates anattestation statement that is signed with a signing key that is associated with the partition. Thestatement contains information about your key's attributes. The signing key isbacked by certificate chains rooted in both Google and the HSM manufacturer. Youcan download the attestation statement and certificates to verify thestatement's authenticity and validate properties of the key and the HSM thatgenerated or imported it.
The certificate chain lets you check the following:
- The HSM hardware and firmware are genuine.
- The HSM partition and HSM are managed by Google.
- The HSM is in the FIPS mode of operation.
The content of the attestation statement lets you check the following:
- The key is not extractable.
- The key was generated for your CryptoKeyVersion.
- The public key in an asymmetric key pair corresponds to an HSM-backedprivate key.
- The key material of an imported symmetric key matches the value you wrapped.
Secure key import directly into HSMs
You can securely import existing keys into Cloud HSM to maintain a backupof your key material outside of Google Cloud, or to simplify migrating certainworkloads to Google Cloud. The key-import process does not allow Google anydirect access to the unwrapped key material. Cloud HSM provides you with anattestation statement for the HSM-generated wrapping key to validate that noaccess occurred.
Because key import potentially creates security and compliance risk by allowingusers to bring keys from unknown sources, separate IAM rolesallow fine-grained control over who can import keys into a project. Importedkeys can be distinguished by the attestation statement that the HSM generates onimport.
For more information, seeImporting a key into Cloud Key Management Service.
Strict security procedures safeguard HSM hardware
As mandated by FIPS 140-2 level 3, HSM devices have built-in mechanisms to helpprotect against, and provide evidence of, physical tampering.
In addition to the assurances provided by the HSM hardware itself, theinfrastructure for Cloud HSM is managed according toGoogle infrastructure security design overview.
Documented, auditable procedures protect the integrity of each HSM duringprovisioning, deployment, and in production:
- All HSM configurations must be verified by multiple Cloud HSM SREsbefore the HSM can be deployed into a data center.
- After an HSM is put into service, configuration change can only beinitiated and verified by multiple Cloud HSM SREs.
- An HSM can only receive firmware that is signed by the HSM manufacturer.
- HSM hardware is not directly exposed to any network.
- Servers that host HSM hardware are prevented from running unauthorizedprocesses.
The duties for system operators are defined in standard operating procedures.System operators are prevented from accessing, using, or extracting customer keymaterial while performing their duties.
Service and tenant isolation
The Cloud HSM architecture ensures that HSMs are protected frommalicious or inadvertent interference from other services or tenants.
An HSM that is part of this architecture accepts requests only fromCloud HSM, and the Cloud HSM service accepts requests onlyfrom Cloud KMS. Cloud KMS enforces that callers haveappropriate IAM permissions on the keys that they attempt to use.Unauthorized requests don't reach HSMs.
HSM-backed keys are also subject toquotas for cryptographic operations. These quotas protect your ability to run yourworkloads by helping to prevent inadvertent or malicious attempts to overloadthe service. The default quotas, 3,000 QPM for asymmetric cryptographicoperations and 30,000 QPM for symmetric cryptographic operations, are based onobserved usage patterns. The quotas are significantly below the service capacityand can be increased upon request.
Request flows
This section demonstrates how the architectural highlights above apply inpractice by showing the steps for different types of requests. These flowsemphasize the Cloud HSM portions. For more information about stepscommon to all keys, see theCloud Key Management Service deep dive.
Creating keys
When you create an HSM-backed key, the Cloud Key Management Service API doesn't create the keymaterial, but requests that the HSM create it.
An HSM can only create keys in locations that it supports. Each partition on anHSM contains a wrapping key corresponding to a Cloud KMS location. Thewrapping key is shared among all partitions that support the Cloud KMSlocation. The key-creation process looks like the following:
- The Google Front End Service(GFE) routes the key creation request to aCloud KMS server in the location that corresponds to the request.
- The Cloud Key Management Service API verifies the caller's identity, the caller'spermission to create keys in the project, and that the caller hassufficient write request quota.
- The Cloud Key Management Service API forwards the request to Cloud HSM.
- Cloud HSM directly interfaces with the HSM. The HSM:
- Creates the key and wraps it with the location-specific wrapping key.
- Creates the attestation statement for the key and signs it withthe partition signing key.
- After Cloud HSM returns the wrapped key and attestation toCloud KMS, the Cloud Key Management Service API wraps the HSM-wrapped key according tothe Cloud KMS key hierarchy, then writes it to the project.
This design ensures that the key can't be unwrapped or used outside of an HSM,can't be extracted from the HSM, and exists in its unwrapped state only withinspecified locations.
The following diagram shows the differences when creating Cloud HSMkeys and software keys in Cloud KMS.
Cryptographic operations
When you perform a cryptographic operation in Cloud KMS, you don't needto know whether you are using an HSM-backed or software key. When theCloud Key Management Service API detects that an operation involves a HSM-backed key, it forwards therequest to an HSM in the same location. The following are the steps for acryptographic operation:
- The GFE routes the request to a Cloud KMSserver in the appropriate location. TheCloud Key Management Service API verifies the caller's identity, the caller's permission toaccess the key and perform the operation, and the project's quota forcryptographic operations.
- The Cloud Key Management Service API retrieves the wrapped key from the datastore and decryptsone level of encryption using the Cloud KMS master key. The key isstill wrapped with the HSM wrapping key for the KMS location.
- The Cloud Key Management Service API detects that the protection level is HSM and sendsthe partially unwrapped key, along with the inputs to the cryptographicoperation, to Cloud HSM.
- Cloud HSM directly interfaces with the HSM. The HSM completes thefollowing operations:
- Checks that the wrapped key and its attributes have not been modified.
- Unwraps the key and loads it into the HSM storage.
- Performs the cryptographic operation and returns the result.
- The Cloud Key Management Service API passes the result back to the caller.
Cryptographic operations using HSM-backed keys are performed entirely within anHSM in the configured location, and only the result is visible to the caller.
This diagram shows the difference between creating Cloud HSM keys andsoftware keys in Cloud KMS.
CMEK integrations
CMEK and Cloud HSM together allow you toprotect your data in select Google Cloud services with HSM keys. Configuring aCMEK-enabled service to use Cloud HSM keys is as simple as choosing a key with an HSMprotection level when following the service-specific instructions.
When a caller reads or writes data to a CMEK-enabled service, the caller doesn'tneed direct permission to use the key, and the caller doesn't need to knowwhether the key is stored in an HSM.
The flow for a CMEK operation is very similar to that for a normal cryptographicoperation with the following exceptions:
- The request from the CMEK-enabled service is initiated within Google'snetwork, and doesn't need to traverse the GFE.
- The Cloud Key Management Service API verifies that the service account for the CMEK-enabledservice has proper permissions to use the key. The Cloud Key Management Service API doesn'tvalidate permissions on the end user of the CMEK-enabled service.
Cloud HSM is Google Cloud's hardware key management service. It offersa numberof distinct advantages to users looking to protect their data at rest with HSMkeys. The service was designed with the principles of locked-down API access tothe HSMs, effortless scale, and tight regionalization of the keys.
Cloud HSM offers CMEK- support for the most important services andpresence ofCloud HSM in every Google Cloud region (including multi-regions andglobal). Theservice is designed to make it easy for you to protect your sensitive data,wherever it may be, with a key that's protected by FIPS 140-2 Level 3 devices.
What's next
To learn more, explore the following resources:
- Cloud HSM documentation
- Cloud KMS documentation
- Cloud Key Management Service deep dive
- Google infrastructure security design overview
- Trusting your data with Google Cloud
- Data encryption at rest
