In my last post, I discussed some of the key concepts of a PKI: the public key infrastructure itself; digital certificates; certificate authorities (CAs); and the crucial role of cryptography and key management. I also talked about how CAs manage the lifecycle of all digital credentials within a PKI and so are the root of trust for the entire system. In this post, I shall discuss best practice for protecting CAs and the threats and vulnerabilities to a PKI system.

PKIs rely on a hierarchical chain of trust that includes a “Root” CA and “Subordinate” CAs. The chain of trust up and down the hierarchy has its foundation in the Root CA that provides the anchor or highest level of trust in the system. The Root CA distributes its certificate issuance load across the subordinate CAs to improve capacity, manageability, and resiliency across the system.


Naturally, it is of crucial important that the Root CA along with its signing keys is protected with the utmost security. Compromise of the Root CA means an organization would have to re-issue all certificates which would be a very difficult, disruptive and expensive process to undertake. Very often the security of the Root CA is so important that it is quite literally taken off-line, stored in a safe, not connected to a network and only made operational for tightly choreographed signing ceremonies.

Best practices for generating and protecting the keys associated with Root CAs and subordinates is to use certified hardware security modules (HSMs). As Robin Wilton and Ian Glazer of Gartner have noted, “Key management and storage for the CA itself should be implemented using an HSM capable of protecting against logical and physical attacks on the key store. Such devices should be appropriately accredited to standards such as FIPS 140-2 or other national equivalent.”

HSMs are devices designed specifically to isolate keys and signing operations from the CA software, host platform, and operating system – all of which are vulnerable to tampering and other forms of attack. HSMs also help to automate otherwise manual key control processes and procedures, and provide powerful controls to ensure correct authorization for the use of the protected key material. Also, of vital importance is the secure backup of the key material for recovery if necessary. HSMs can therefore help stretch the life of keys as well as allow the use of larger keys without performance compromise relative to software.

When making a threat assessment of a PKI, organizations should first focus on the common IT security issues that affect the overall security posture of and critical system such as authentication mechanisms for privileged administrators, virus detection, open ports and connections, and firewalls to name a few.

In addition, PKIs are vulnerable to specific attacks that the organization must consider:

Malware can compromise CA software and generate fraudulent certificate requests or approvals for what would appear to be legitimate to core certificate issuing systems.

Malicious code or insiders can attempt to steal private signing keys that would enable the certificate approval process to be circumvented and allow bogus certificates to be issued that appear to be legitimate, on demand.

Instead of stealing or misusing keys, Signing keys can be substituted with rogue keys that are known to the attacker and therefore enabling information to be exposed further down the chain.

Any of the above scenarios can have a far-reaching impact on an organization, breaking trust in the entire system. A threat and vulnerability assessment by a qualified independent assessor can help identify weak points in a PKI.

Of course, protection against these threats depends not just upon protecting the CA signing keys while they are in use. It requires an appraisal of the entire key management lifecycle. Over the last decade a number of “standards of due care”’ have become widely established for key management. These will be covered in a later post.

Part 1: What is a PKI and why is it important?

Part 3: Is your organization’s PKI adequate?

Part 4: Building trust into a PKI: Part 4?