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.
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:
In SSH Protect you have extra control as well:
Endpoint Protect includes the following:
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.
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:
Let’s look at the possible scenarios:
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.
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.
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.
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.
Related posts