2024-04-18
In the rapidly evolving landscape of digital security and regulations, selecting the right combination of public key infrastructure (PKI) software and hardware security module (HSM) is crucial. Learn more about The Role of HSMs in PKI and Signing Solutions by reading our recent blog.
This guide aims to provide insights into different HSM options and their implications for security and compliance, tailored explicitly for product development engineers and product owners using EJBCA PKI.
There are multiple types of HSMs that are designed for different use cases, with varying form factors, capacities, integration capabilities, and features.
Designed for integration into networked environments, accessible by multiple systems within the network, suitable for on-premises HSM-backed PKI deployments.
Consideration: Offers flexibility in managing cryptographic keys, root CAs, and HSMs, aligning security strategies with specific needs, compliance requirements, and digital sovereignty concerns. This type of HSM is highly versatile, but setup and management require domain-specific knowledge.
Integration: EJBCA integrates with multiple vendors in the market, typically via standard interfaces such as PKCS#11 and REST.
Vendor Examples: Thales, Utimaco, Entrust, Fortanix, and Securosys.
These are streamlined devices, typically in the USB or MicroSD form factor and they possess the HSM functionalities of safeguarding sensitive key material and executing cryptographic operations.
Considerations: Their cryptographic performance is constrained, and their support for algorithms and key lengths may be limited compared to conventional HSMs. These modules are occasionally employed to secure the root of trust, such as Root CA keys in a PKI setup. Their compact design offers effective potential for secure storage in a safe.
Integration: EJBCA integrates with a few vendors in this segment and typically does so using the standard PKCS#11 interface.
Vendor Examples: Yubico, NitroKey, Smartcard HSM
Cloud HSM, sometimes called HSM as a service, offers several variants, each with distinct advantages. EJBCA integrates with Cloud HSMs using either a standardized PKCS#11 interface or a service-specific REST API.
Two primary service variants are commonly evaluated:
A self-service model, allowing users to provision, manage, and integrate the HSM service with their PKI application directly within the cloud environment.
Considerations: Users need to assess trade-offs between customization and management intricacies to align with unique security objectives.
Vendor Examples: AWS KMS, AWS CloudHSM, and Azure Key Vault
Outsourcing HSM hosting and management to a service provider allows users to leverage HSM security benefits without administrative overhead.
Considerations: Reduces management complexities; organizations must weigh this against potential limitations in customization and direct control over cryptographic resources.
Vendor Examples: Thales DPoD, Fortanix and Securosys CloudHSM.
When it comes to who generates keys and who manages them, this goes beyond just service models, and the entrance of cloud HSMs has brought with it new ways of evaluating key ownership and management. For many organizations, these are crucial aspects to consider.
Some options on the market are the following:
Organizations generate cryptographic keys locally, typically on their own on-prem HSM strictly under their control, and import them into a cloud-based HSM, balancing key ownership with cloud advantages.
Considerations: Ensures organizations maintain control while benefiting from cloud infrastructure. Management of key backups is one aspect organizations must consider as the main drawback of such an approach is the fact that keys need to be generated in an exportable fashion, allowing them to be exported in a standardized format such as a PKCS#12 container.
Organizations own and operate their dedicated HSM, while deploying applications in a cloud service, offering control over keys and the HSMs with the flexibility of cloud deployment.
Considerations: Balances security with application deployment options. While reaping some cloud benefits, organizations must still maintain HSM skills in-house and match the required SLAs. Nevertheless, the main advantage compared to the BYOK approach is the fact that sensitive cryptographic keys can be generated as non-exportable data objects and as such, benefit from the full key protection spectrum that HSMs are designed to deliver.
When evaluating HSMs, certifications play a crucial role in ensuring the devices meet industry standards for security and compliance. Here are the key certifications to look for when assessing HSMs related to PKI use cases:
Issued by the National Institute of Standards and Technology (NIST), this certification ensures compliance with federal security standards in the United States and is also a de-facto standard in the rest of the world.
FIPS 140-2 Level 3 signifies a high level of physical and logical security, making it suitable for protecting sensitive information such as private keys. Please note that FIPS 140-2 is now in the process of being superseded by FIPS 140-3, which is the new standard HSMs are tested against.
Consider the specific regulatory and industry requirements applicable to your use case or deployment and ensure that the chosen HSM has the necessary certifications to meet those standards, for example, PCI-DSS for payment-specific HSMs.
Considerations related to scalability, high availability, vendor lock-in, and backup/restore functionality are crucial when selecting an HSM solution for your PKI, whether on-premises or cloud-based. It is also important to future-proof the HSM and PKI solution by planning ahead with regard to capacity, certifications (such as FIPS 140-3), and cryptographic agility (for example, post-quantum cryptography, PQC).
Ensure that the HSM solution can scale to meet the growing demands of your PKI, considering cryptographic operations per second for various cryptographic algorithms and respective key lengths.
Look for HSM solutions providing redundancy, failover capabilities, and load balancing for continuous availability, especially under high loads and demanding SLAs.
Ensure robust key backup mechanisms covering not only key material but also the entire HSM configuration for disaster recovery.
Last but not least, it is highly recommended to consider HSMs that support either a standardized API like PKCS#11 or a REST API. By doing so, you minimize the vendor lock-in aspect while ensuring out-of-the-box integration, not only to your PKI software platform, but rather any application utilizing HSMs for key generation and protection.
The primary functionality an HSM offers is the protection of private keys. The reputation of a vendor hinges on that it is hard or next to impossible for an outsider to extract sensitive keys safeguarded by an HSM. The exception is to make a secure backup, which should only be possible to restore on HSMs of the same brand under typical multifactor and multi-person control. There is no standard for backup formats of HSMs, meaning that every HSM vendor has its own format, meaning that it is not possible to restore a backup from one vendor onto another vendor's HSM. In practice, once you have generated keys in one HSM, they are locked to that HSM vendor by design and frequently by compliance requirements.
The best way to manage vendor transition in the HSM space is to build a PKI that has a crypto-agile architecture where it is possible to transition to new keys generated on a new HSM and eventually abandon the old keys. Even though this comes with a certain overhead, it is recommended from a security point of view as opposed to a BYOK approach, which inevitably implies that sensitive key material will at some point in time reside outside the secured hardware environment, as a standardized key container, probably protected only by a password.
Considerations: Designing with crypto-agility in mind also enables moving from different HSM vendors or from on-premises to the cloud.
Undoubtedly, the HSM stands out as a crucial component in ensuring overall trust and assurance when it comes to key management in PKI solutions. EJBCA has, from day one, been supporting HSMs and has also evolved its HSM support as the technology has evolved.
While it is strongly recommended to use an HSM for a PKI solution, for testing and prototyping it can be convenient to use EJBCA Soft Crypto Tokens, where the keys are stored in the database protected by a password.
Try EJBCA or SignServer for yourself:
Download EJBCA Download SignServer
PKCS#11 (Public-Key Cryptography Standard #11) is a widely used cryptographic interface standard that defines a platform-independent API for accessing cryptographic tokens such as HSMs.
P11NG, short for Next Generation PKCS#11, signifies advancements and expansions over the original PKCS#11 implementation in EJBCA that was using the built-in Java support for PKCS#11. The P11NG support in EJBCA Enterprise encompasses supplementary features like broader algorithm support and refined optimizations specifically implemented for each HSM, which sometimes use HSM-specific features that are outside of the PKCS#11 standard. These enhancements go beyond what was possible through the Java PKCS#11 integration. P11NG is supported in EJBCA Enterprise. Find out more about the differences between EJBCA Community and EJBCA Enterprise on this page.
In a PKI setup with an offline, often also referred to as air-gapped, root Certificate Authority (CA) and HSM, the offline root serves as the ultimate trust anchor for the infrastructure, safeguarding the highest-level cryptographic keys. It is strongly recommended to not only use dedicated HSMs for key generation and storage in the context of a Root CA but rather consider a layered HSM approach, making sure that also Issuing CA keys as well as OCSP signing keys are safeguarded by dedicated HSMs with respective performance capabilities, suitable for addressing each specific use case.
Example: EJBCA on-premises PKI deployment with high availability, load balancing, and HSMs.
Adding a layer of intermediate/policy CAs is sometimes applicable to enable further hierarchical delegation of trust and management, for example, if the PKI manages multiple use cases or devices that would benefit from being managed separately. The Web UI, protocol, and API interfaces, the Registration Authority, RA, handles user or device validation and certificate enrollment, while OCSP and CRL manage revocation status. Ensuring high availability (HA) and secure segmentation is crucial for preventing service disruptions and mitigating risks of compromise across components.
Carefully considering the factors outlined in this blog allows architects, product development engineers and product owners to select a PKI and HSM solution that meets current requirements while preparing for future challenges and opportunities in the dynamic digital security landscape.
Try EJBCA or SignServer for yourself:
Download EJBCA Download SignServer
To learn more about PKI and HSMs, see:
Director of Solutions Engineering EMEA
Principal Solution Engineer Nordics
