Components of a PKI, Part 5: Hardware Security Modules

Preface: Components of a PKI

Public key infrastructure (PKI) is a core technology in the identity and security stack. This technology uses encryption to allow entities such as an individual or device to be uniquely identifiable and able to store or transmit information securely. All modern organizations use PKI in some form or another. The digital certificate on a website that protects customers’ privacy and data is an example of PKI in action.

Fortunately, the fundamentals haven’t changed significantly since PKI was formally introduced in the X.509 standard in 1988. In this five-part blog series, we cover a few of the most important PKI components:

1. Digital Certificates
2. Certificate Authorities and CA Hierarchies
3. Certificate Revocation
4. Active Directory Certificate Services
5. Hardware Security Modules

Part 5: Hardware Security Modules

Certificates can identify us and protect our information, but only when we can maintain secrecy of the private key for our certificates. Hardware Security Modules (HSMs) are dedicated computing devices designed to protect private keys and cryptographic operations. To understand HSMs and how they can protect your PKI, we need to understand a few additional concepts:

• Key protection is the methodology for private key storage. 
• Cryptographic provider is a software library used by the operating system for how to perform cryptographic operations. 
• Software key is a private key that is stored in a software format, such as a certificate generated in your local certificate store or saved in an encrypted P12 or PFX file.
• Hardware key is a private key that was generated and stored on separate physical hardware, such as the microprocessor and memory storage on a smart card.  

HSMs provide the highest form of key protection. We typically recommend implementing HSMs as a best practice to protect PKI investments; however, many organizations have implemented HSMs to comply with industry regulations, such as: 

• Federal Information Processing Standard (FIPS) 140-2 
• Common Criteria (CC) 
• Payment Card Industry Data Security Standard (PCI DSS) 

How does an HSM protect my data?

Software keys are easy to steal. By default, Windows generates a software key for a certificate and stores it as a permissions-protected file BLOB on your computer. You can decide if you want to “Mark the private key as exportable” on Windows to prevent the certificate from being exported; however, an attacker with administrative access or a server backup can easily extract the software key. 

HSMs protect your data by restricting the use of the plaintext key within the tamper-resistant memory and cryptographic processor of the HSM itself. It’s impossible for an attacker or rogue administrator to steal a plaintext key from a server if the plaintext key never existed on the server. Additionally, HSMs have role-based access control (RBAC) features that allow you to apply policies for individual key containers, such as requiring a quorum of PKI administrators to provide a smart card and PIN to unlock the offline root CA private key stored in the HSM. 

As Figure 1 shows, the Certificate Authority (CA) relies on the HSM to perform the certificate signing process: 

1. Client generates a certificate signing request (CSR) and submits it to the CA
2. CA successfully authenticates to the HSM to access the CA key container 
3. CA submits the cryptographic signing operation to the HSM
4. HSM uses the unwrapped plaintext key to perform the cryptographic signing operation on behalf of the CA 
5. HSM returns the signed material back to the CA 
6. CA issues the certificate and returns it to the client 

In every scenario that the CA needs to use the private key, Steps 2-5 must be repeated. 

Figure 2 shows an example of an attacker attempting to compromise a CA. If the HSM is offline or inaccessible, the CA can no longer access the private key and would cease operation. 

Unfortunately, HSMs can’t protect you from every threat vector. To support scenarios such as a document signing server or an issuing CA, the Windows server must be able to use the HSM-protected key non-interactively. This is referred to as module protection. If an attacker gains access to a server that is actively connected to the HSM using only module protection, the attacker would be able to use the private key locally on the server since the server would successfully authenticate to the HSM to perform Steps 2-5 above. In this scenario, the HSM would still protect the private key from being extracted, and all malicious activities would need to be performed on a server that is (hopefully) audit logging. 

Final Remarks

HSMs aren’t for everyone—but they provide the highest level of assurance that money can buy. Highly regulated authorities (e.g., governments, payment processors, globally trusted CAs, etc.) rely on HSMs to protect mission-critical private keys, and the costs associated with HSMs are negligible compared to the impact of a key compromise. Many organizations want better security for their PKI but are uncomfortable with the financial or operational commitments to manage an HSM. Comparable levels of assurance can be achieved by leveraging a reputable managed PKI solution that builds and maintains the HSM-protected CAs on behalf of an organization. If you need advice about the security posture for your organization’s PKI, Ravenswood Technology can help. Contact us today.