Offline Root - or how to do PKI right

The private key is the most important part of the public key infrastructure. For the Root Certification Authority (CA) the private key is the "root anchor" of trust. If there is only one tier to a PKI hierarchy, everything depends on this private key being kept safe. The risk of having just one tier, is that the one private key needs to be available to sign the certificates used by the various endpoints verified by the PKI.

If a certificate is "self signed" or the private key of a single tier infrastructure, and the private key is ever compromised, all trust is lost. A new trusted certificate must be issued and all entities that depend on the compromised must must be updated to trust the new private key. This can be a very expensive and time consuming process.

Now what if we have a multi-tier PKI, where the root CA is offline and the intermediate and issuing CAs are online, and one of the online CAs is compromised?

Root tier. The physical server is stored in a secure location with enforced procedures to access it.
Intermediate tier (optional). One or more servers that have certificate-issuing-certificates signed by the root tier private key. These servers issue certificates to the issuing CA tiers. These servers assign policy for the next CA tier.
Issuing tier. This tier has certificate-issuing-certificates signed by (one or more of) the intermediate tier CAs. They issue certificates to endpoint entities such as user login, computers, web servers, and other network devices.

Each of the online tiers is configured to provide information on how to access a Certificate Revocation List (CRL), and this information is included in the certificates they issue. Entities regularly check the certificates presented to them against the CRL, and reject any certificate that is on the CRL. In the case of a CA, the certificate-issuing-certificate is invalidated, along with all the certificates under it. A new CA is created, its certificate signed, and the invalidated certificates are reissued.

When an endpoint encounters one of these new certificates the chain of trust is followed back to the still trusted root CA. The endpoint can present the new issuing CA certificate, which is then implicitly trusted by the endpoint.

Risks to the Root CA private key

The risks to the offline root CA private key can be divided into two categories:

Compromise of the private key data. In this case unauthorized access to the private key data is gained. This can happen a number of ways:
- The attacker gains physical access to the server and is able to access the key.
- The CA server is attached to the network and the attacker is able to gain access through a remote attack.
- The private key is stored on a removable media and is lost or stolen.
Compromise of the trust in the private key. This is most often the result of proper procedures not being followed:
- The physical server is accessed without the monitoring of the actions of the person accessing it.
- The server logs do not match the control logs for physical access.
- A backup copy of the CA data is not protected according to policy.
The loss of trust in the private key integrity is important to understand. With the speed at which attackers are capable of moving, even one minute of unauthorized access to the private key can result in the loss of trust in the key. If it is possible the key data was accessed, then the key must be considered compromised.

Was your current offline root CA configured by someone over RDP?
If someone connected your offline root CA to your internal network, would you be alerted?
Are there safeguards in place that require at least 2 people to be present to access your offline root CA?
Have you established an "Offline Root Access Ceremony" to define the process for accessing the offline root CA?