A public key infrastructure (PKI) is the framework needed to manage public-key encryption. PKI protects communications between companies and users to exchange information and money safely and securely.
A PKI consists of:
An individual wishing to send an encrypted message requests a digital certificate from a Certificate Authority (CA). A registration authority (RA) is an authority in a network that verifies user request and tells the certificate authority (CA) to issue it. The CA then generates and distributes digital certificates, securely stores these certificates in a central repository and revokes them if needed.
PKI works by assigning a user a pair of keys that are generated against a user’s certificate by running a mathematical process.
PKI uses an asymmetrical and symmetrical process combination. For instance, the SSL certificate of a server contains an asymmetrical public and private key pair. The session key created during the SSL Handshake by the server and the browser is symmetrical.
Anyone can encrypt messages using the public key in asymmetric encryption, but only the holder of the paired private key can decrypt.
Suppose a user needs a file to be encrypted. The user’s private key is used to encrypt the file. An unpredictable number is used to start a pair of keys that can be used with an asymmetric key algorithm.
Depending on the assurance level of the identity, the CA can bind and distribute signed digital certificates either automatically, or under human supervision.
The Simple Certificate Enrollment Protocol (SCEP) allows you to securely issue certificates to a large number of network devices using an automatic registration process. The network devices must be pre – registered with the CA domain in order to successfully request the certificates.
The PKI services can be configured to automatically respond to requests for SCEP certificates or to send requests for SCEP certificates to the PKI administrator for approval or refusal. If automatic registration is enabled, certificate requests can be approved automatically and executed synchronously based on the knowledge of a predetermined secret passphrase.
Heavy procedures are used by serious certifying authorities. At the root, the CA key is stored in a HSM, but that’s only part of it. The CA itself needs to be physically protected, including proactive and retrospective measures.
Proactive measures are to prevent physical attacks or tampering from succeeding. For example, the CA with steel doors and guards is stored in a vault. The physical hardware is locked with several padlocks, and no one has more than one padlock key. Physical safety is crucial; HSM is the deepest layer of protection.
Retrospective measures concerns recovery after an incident. The HSM keeps a log of all signatures. The machine is under 24/7 video surveillance and remotely monitored. These measures are about knowing what happened if a breach happens. For example, if unauthorized certificates are somehow issued, the complete list of such certificates can be reconstructed, making recovery is as simple as withdrawing the offending certificates.
For extra recovery, the CA is often split into a long-lived root CA which is kept offline, and a short-lived intermediate CA. Both machines are in the cage and bunker; the root CA is never connected to a network. The root CA is physically accessed with dual control requiring at least two people and video recording to create the intermediate CA,certificate. This allows the intermediate CA to be revoked if hacked to the point that its private key was stolen, or if the fraudulent certificates cannot be recovered.
This is only the basics of PKI. For a simple breakdown of digital certificates read “Best Practice: Securing the Root CA of a PKI with a Utimaco HSM”: