Extending the Benefits of HSMs for Protecting Private Keys

A critical component of your machine identity management infrastructure often includes a hardware security module (HSM), a physical device that you connect to your network on which you manage secret keys. HSMs are the most secure way to physically and digitally secure your keys, including mission-critical keys like code signing keys. You may also use an HSM to perform additional tasks in your environment with those secure keys, such as encryption or creating digital signatures. An HSM can give you the ability to accelerate performance as hardware-based signing is faster than its software equivalent.
 

By design, an HSM provides two layers of security. First, the keys are physically protected because they are stored on a locked-down appliance in a secure location with tightly controlled access. Second, the keys are logically secure as they keep your secret keys, well, secret. The hardware and software are designed for the highest levels of security certification, and this separation of cryptographic functions from the programming and business logic functions protects against critical attack vectors.
 

Why is it critical that you use an HSM to protect your private keys? Achieving true randomness in software is currently not possible. All software based random number generators are pseudo-random number generators. Due to its nature, all software is deterministic, meaning it does not create true randomness. Why is this bad? Because if you know how a software function is programmed, and you know how it creates the seed data for the random function, then you can predict what future output can be.  When it comes to generating key pairs, if you know the random number used to create the key pair, you can derive the private key from the public key. So how is hardware able to achieve more statistical randomness? HSMs have dedicated hardware components for random number generation that do not require seed data. When HSMs are used for key generation, the end results are unpredictable key pairs that are less susceptible to attacks. In other words, you’ll have more secure keys.

Venafi takes private key security extremely seriously. By default, our key vault, called Secret Store, is encrypted. Its encryption key can either be stored in hardware or in software. This is an included feature of all products built on the Venafi Platform. Securely storing private keys and other sensitive assets in a centralized vault is only part of the battle, however. Whether you are dealing with SSH key orchestration for machine to machine access, rotating a single TLS certificate that is installed on multiple endpoints, signing critical software or firmware that goes out to millions of customers, or deploying authentication certificates to your employees, secure generation of private keys is critically important.
 

When it comes to working with certificates and SSH keys, there are many risks related to private key security. For many organizations, due to government regulations or internal security policies, there are additional questions that must be answered.

• How do I prevent private key theft or misuse?
• How do I make sure my private key generation methods contain sufficient entropy?

Orchestrating the installation of TLS certificates or the rotation of SSH keys in HSMs is challenging to do manually. Not only does it typically require the copying of multiple instances of private keys to non-secure locations, but the installation of the private key itself can be done incorrectly when done manually so that proper security settings are not applied. To mitigate these risks, you need to securely store private keys on HSMs, as they are considered the highest level of security for private keys. It’s the highest level because the private key material is created and remains within a hardware-protected secure enclave from which it never leaves. If you are not using the Venafi Platform, orchestrating HSM-backed key and certificate rotation can often be prohibitively expensive when done at scale.
 

Because of the expense to deploy HSMs across the enterprise for every application, some organizations see the most value from deploying HSMs only for high-value or mission-critical applications. That scenario may leave a majority of apps without access to the secure storage benefits of HSMs. In such cases, organizations may still wish to benefit from the higher entropy that an HSM affords to increase the level of security for keys—even if they are ultimately stored in software. This may also satisfy PCI DSS 3.6.1 requirements for “Generation of strong cryptographic keys”.
 

So, how can you leverage the security advantages of HSM, even when your keys are ultimately stored in software? Here’s how Venafi products help secure private keys in scenarios where they are stored in software:
 

Out of the box, Venafi products like TLS Protect, Endpoint Protect, and SSH Protect follow industry-standard permissions when private keys are deployed. In some cases, they grant even more controls to cover more complex scenarios.
 

TLS Protect, for example, includes the following features that provide additional control:

• The Venafi CAPI certificate installation driver supports installation to Microsoft Certificate Stores, which allows for control of Private Key Export. It can also set the Private Key Trustee for more granular permissions.
• The Venafi file and key store certificate installation drivers for PEM, JKS, IBM GSK, and PKCS#12 formats allow for granular owner and group permissions for private keys.

In SSH Protect you have extra control as well:

• When distributing private key files for various users to Linux/Unix systems, these files are written with a read & write (0600) permission to ensure that private keys are accessible only by the owner.
• When updating the authorized keys file on a Linux/Unix system, SSH Protect gives the default option of setting the file to a read & write (0600) permission so that users can still manage the authorized access for their account.  However, to improve security a simple policy can be applied so that authorized key files are written with read & write for root and read only for regular users (0644), so that all changes to access must be performed centrally through SSH Protect.

Endpoint Protect includes the following:

• When leveraging Venafi User Agent for Windows, certificates installed in the Microsoft Certificate Store are always installed as non-exportable in either the local machine store or the local user’s own store (depending upon the use case).

Everything mentioned above is included out of the box in these Venafi Machine Identity Management products, however, many of our customers have greater security demands for their private keys. For these extended use cases Venafi offers Advanced Key Protect.
 

Venafi Advanced Key Protect to the Rescue

To enhance your posture for machine identity management, Venafi created Venafi Advanced Key Protect, an optional add-on feature that strengthens the connection between an HSM and Venafi environment. Venafi Advanced Key Protect allows you to integrate an HSM with Venafi Platform (directly, or indirectly) for the best protection available for your machine identities.
 

There are several factors when considering TLS key generation:

• How are the private keys used? The way you’re using keys dictates which Venafi product you need, and different choices of private key protection are available for different products.
• Is the Venafi Platform connected directly to the HSM (central generation), or does it connect to the HSM through a remote system (remote generation)?
• Is the key generated in hardware (HSM) or in software (Venafi Platform)?
• Is the private key stored in the HSM, or is it being stored in Venafi Platform’s Secret Store?

Let’s look at the possible scenarios:

Hardware Remote Key Generation

With remote key generation, Venafi Platform interacts with an HSM only through a remote third-party system. For example, let’s say a CSR needs to be generated.

• First, Venafi Platform connects (via a supported integration driver) to the remote system (for example, Apache), and asks the remote system to initiate a CSR.
• The remote system connects to its HSM to generate the signed CSR, and exports the signed CSR to Venafi Platform, which can then submit to the certificate authority (CA).

In this scenario, Venafi Platform is not connected directly to the HSM. Venafi Platform is connected to the remote system, which integrates with the HSM to do a task (for example, sign a CSR), and the remote system returns the CSR to Venafi Platform.
 

Only Venafi TLS Protect uses hardware remote key generation because TLS Protect can leverage the knowledge of HSMs that is baked into our Apache, CAPI, and JKS drivers to communicate with HSMs.

Additionally, when working with Apache HTTP Server, TLS Protect with Advanced Key Protect can work with nCipher nShield HSMs to distribute the same certificate to 2 or more HSM-connected Apache servers. Advanced Key Protect does this by generating the key pair on one of the servers in the application group and distributes the key “stub” and application key token files to all other servers in the group.
 

Hardware Central Key Generation with Software Storage

With central key generation, Venafi Platform integrates directly with the HSM, with no remote system necessary. With central key generation while the key is always generated by the HSM, you have the option of exporting the key to the Venafi Secret Store.

Remember how earlier we talked about how HSMs provide higher security by creating the necessary entropy to create true randomness? Sometimes you need the entropy of an HSM-generated key, but your application doesn’t support connecting directly to an HSM. In this case, you need to store the key in software, not the HSM. Hardware central key generation makes it possible to generate keys in HSMs for applications that don’t support connection to an HSM.

How does this work? All Venafi products have access to this functionality with Advanced Key Protect. We leverage the wrap and export aspects of the PKCS#11 protocol to export a key that is generated by the HSM but never saved to the HSM.
 

Hardware Central Key Generation with Hardware Storage

Venafi’s CodeSign Protect can uniquely generate private keys on HSM and store them there. This provides leading-edge support for protecting mission-critical code signing keys. Industry standards require that timestamping certificates and extended validation code signing certificates be generated and stored in hardware.  Because of this we recommend pairing CodeSign Protect with Advanced Key Protect.

• The codesigning private key is generated by the HSM and is stored in the HSM. Venafi CodeSign Protect connects the HSM to the signing tool.
• We are also adding support for Time Stamping certificates. This will allow the private key to be generated and stored on the HSM for secure timestamping operations during the code signing process.
   

Resources for further reading...

• Supported Methods of Key Generation, Venafi Product Documentation (requires login).
• A Review of Hardware Security Modules: Fall 2010, Johan Ivarrsson, published on opendnssec.org.
• Understanding Hardware Security Modules (HSMs), Peter Smirnoff, published on cryptomathic.com, 13 September 2017.
• Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates, CAB Forum, August 13, 2019
• Keys In Hardware vs. Private Key Export, SafeNet Luna PCIe HSM 7.5 Product Documentation, December 13, 2019

Related posts

• Identity Wars Episode I: The Phantom Menace
• Identity Wars: Episode II – Attack of the Clones
• 3 Reasons You Need a Root of Trust When Orchestrating Machine Identities
• Why You Need Trust, Integrity and Control for Machine Identities in HSMs