Hardware Security Modules (HSMs) are generally viewed as expensive and painful to maintain. It’s not surprising that a lot of HSM users are looking for a cloud-based solution that would allow them to hand over maintenance to a third party and move to an opex instead of capex model (i.e. rent the HSM instead of buying it).
At the same time, companies looking to migrate their more complex business-critical applications are finding that Cloud Service Provider (CSP) key management APIs (e.g. AWS KMS, GCP KMS, and Azure keyvault as covered in an earlier post) often don’t offer the cryptographic flexibility they need to migrate securely and in compliance.
Responding to these market forces, a new wave of cloud-hosted HSMs is arriving. Equipped with standard APIs like PKCS#11, they offer the promise of flexible crypto services while keeping keys secure from cloud application compromise.
AWS were already offering a Safenet HSM in the cloud way back in 2014, though the pricing model with a fixed up-front cost seems to have inhibited uptake. The new wave of cloud-based HSMs typically offer pure rental-based models: AWS have one (made by a new manufacturer), Utimaco offer a CSP-agnostic one, and word on the street is that Google will announce one today.
Other CSPs and HSM vendors will surely follow. So what can they do, and are they really secure?
The first thing to check out with any of these solutions is the potential to be locked-in. Most of our large financial services users have identified lock-in to a single CSP as a systemic risk they can’t afford to take. This means the cloud HSM has to support standard APIs, or the re-architecting and rewriting required to switch becomes a blocking point. PKCS#11, for all its shortcomings, is essentially the only show in town here.
However, PKCS#11 is a vast standard and not all implementations are the same. You need to know what commands and cryptographic mechanisms are supported, as well as what facilities are available for fine-tuning access to the API to prevent a whole host of known vulnerabilities. Finally, PKCS#11 is a difficult standard to implement correctly and new implementations often contain bugs that can compromise security. A FIPS or Common Criteria certification doesn’t test the crypto API, so offers no assurance against this kind of issue.
She’s Lost Control
Moving from an on-premise HSM to a cloud-hosted one means handing over control of firmware updates and driver updates to the cloud HSM host. This has some advantages, since organising firmware updates every 6 months across hundreds of HSMs is a major headache for big firms. But it also adds new risks, since like the rest of the public cloud, the updates typically happen at any time, usually without a chance for customers to test them before they are applied. They might introduce new security bugs, or just a subtle change in error codes that stops the application from working.
Cryptosense Analyzer software can test a PKCS#11 implementation and report on its compliance and vulnerability. It can be scheduled to make regular automated tests of a cloud HSM and alert on changes. It can also trace the way applications use the cryptography in the HSM to find vulnerabilities.