Public Key Infrastructures (PKI) basics

A public key infrastructure comprises all components (hardware, software, people and processes) required for the use of digital certificates. A PKI consists of one or more certification authorities (CA). The tasks of a PKI include:

• Ensuring the authenticity of keys, i.e. establishing a traceable link between a key and its origin to prevent misuse.
• Revocation of certificates, i.e., ensuring that decommissioned or compromised (e.g., stolen) keys can no longer be used.
• Guarantee of liability (non-repudiation), i.e., the owner of a key cannot deny that it belongs to him.
• Enforcement of policies, i.e. standardized procedures for the use of certificates.

To get started with this topic, please also read the article "Cryptography basics" take into account.

It is important to mention here that a certification authority usually only takes care of the management of the public keys, (with few exceptions) but not those of the private keys.

A certification authority usually consists of one or more computers with appropriately installed software, associated processes and documents. Certification authorities are components of a public key infrastructure (PKI). Their main tasks are to...

1. Verify the identity of applicants and ensure that certificates are issued only to authorized applicants.
2. issue certificates (i.e., sign them) and thus confirm the verified identity.
3. Manage and announce the revocation status of the issued certificates.

In corporate networks, it is common to establish a hierarchy of multiple certification authorities. This increases security on the one hand, and scalability on the other. The most common model is one with two levels: At the top of such a hierarchy is a single root CA, to which several intermediate CAs and issuing CAs are subordinate.

In this way, for example, the root CA can be effectively protected against attacks from the network by never being connected to a network (hence the term "offline root CA"). In rare cases, a three-level hierarchy is used, with another level of intermediate CAs between the root CA and the issuing CAs, which can be used, for example, to enforce organizational policies (Policy CA).

The most critical technical component of a certificate authority is its private key. If an attacker succeeds in to misappropriate or steal the private keythen the entire chain of trust downwards (i.e., including all certificates issued by it in the past and in the future) is compromised. For this reason, the private key of each individual certificate authority must be treated with particular sensitivity and protected by appropriate measures. Without special protective measures, it resides both on the hard disk and in the RAM of the certification authority computer while the certification authority software is running, and can potentially be stolen from there.

To counteract this problem, the following safety measures should be taken:

• Root CAs and policy CAs should never (i.e. actually at any time, not even during installation or maintenance) be connected to a network in order to prevent them from being attacked and compromised via it. Unlike all other certificates in a PKI, the root CA's certificate cannot be revoked in most cases because it is self-signed.
• A CA should only be run in a virtual environment (e.g., VMware, Xen, Hyper-V) using separate security measures, if at all. In addition to the risk of theft of sensitive data, there is a high risk of undetected manipulation due to the snapshot function present in most virtualization environments. The virtualization hosts should be separately secured against access by unauthorized persons, for example by an additional lockable server cabinet, extended access controls and the use of full hard disk encryption.
• The private key of a CA should be encrypted with a Hardware Security Module (HSM) can be secured. These are dedicated devices that keep the private key under lock and key (non-exportability) and can use a graduated rights model to ensure that only authorized persons and computers can use the private key. Cryptographic operations can only be performed via the HSM.

Using certificates with Microsoft Windows

Applications that work on the Microsoft Windows operating system basically have two options for using certificates:

1. Microsoft Windows includes the Microsoft CryptoAPIa programming interface that can perform cryptographic operations on behalf of the calling application. A key advantage here is that certificates can be shared between applications and managed centrally.
2. The application can implement its own cryptographic operations, thus bypassing the Microsoft CryptoAPI. A popular example of this is the Mozilla Firefox browser, which uses its own cryptography implementation.

In the following consideration, it is assumed that the applications used make use of the Microsoft CryptoAPI.

Certificate validation

Certificate validation can be divided into several interrelated processes, which are described in more detail below:

• Certificate discovery describes the process of identifying all certification authority certificates needed to verify a certificate.
• Certification path validation describes the process of establishing the chain of trust by validating all certificates within the chain until it ends at a certificate from a root CA that is deemed trustworthy. Both processes are described in the article "Basics: Finding certificates and validating the certification path" described.
• Revocation status checking describes the process of checking the revocation status for all certificates within a trust chain. It is described in the article "Basics: Checking the revocation status of certificates" described.
• Certificate validation describes the process of checking the content of all certificates in the chain for validity.

Verification of the validity of certificates

The trustworthiness of a digital certificate is measured by the following criteria, among others:

• If the certificate is located in a valid format (i.e. does its coding comply with the common standards and can be read by the recipient without errors)?
• Is the identity confirmed by the certificate (Subject Name or Subject Alternative Name) valid?
• Is the certificate chain complete?
• Does the certificate chain end at a root certification authority certificate that has been classified as trustworthy?
• Is the certificate within its validity period?
• Does the signed hash value of the certificate match its actual hash value (calculated during certificate verification)?
• If the certificate was issued by the Certification Authority revoked or is it stored in the untrusted certificate store?
• If the certificate has been released for the intended use ("Key Usage" and/or "Extended Key Usage" attributes)?
• Is the certificate subject to certain Constraints, e.g. on certain Domain names or Hierarchy levels?
• Are all extensions of the certificate marked as critical understood by the applications testing the certificate?

This process is performed for each certificate in a certificate chain to be verified. Only if all certificates within a chain have successfully gone through this process and are consequently recognized as trustworthy will the actual certificate to be verified ultimately also be recognized as trustworthy.

Related links:

• Cryptography basics
• Basics: key algorithms, signature algorithms and signature hash algorithms

External sources

• What's in a certificate chain and why? (Ryan Hurst)