In cryptology, public key infrastructure (PKI) is a system that can issue, distribute, and verify digital certificates. The certificates issued within a PKI are used to secure computer-aided communication. With the help of an asymmetric cryptosystem, messages on a network can be digitally signed and encrypted. Secure cryptosystems cannot be broken in a reasonable period of time, at least according to the current state of knowledge, if the parameters (e.g. the key length) are chosen appropriately, even if the procedure is known (cf. Kerckhoffs’ principle).
In asymmetric cryptosystems, the sender needs the recipient’s public key for encrypted transmission. This could be sent by e-mail or downloaded from a web page, for example. It must be ensured that it is actually the recipient’s key and not a forgery of a fraudster.
Digital certificates are now used for this purpose, confirming the authenticity of a public key and its permissible scope of application and validity. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified with the public key of the issuer of the certificate.
---
In order to check the authenticity of the issuer’s key, a digital certificate is required. In this way, a chain of digital certificates can be established, each of which confirms the authenticity of the public key that can be used to verify the previous certificate. Such a chain of certificates is called a validation path or certification path. Communication partners must be able to rely on the authenticity of the last certificate (and the key certified by it) without the need for another certificate.
Components of Public Key Infrastructure (PKI)
- Digital certificates: Digitally signed electronic data that can be used to prove the authenticity of objects.
- Certificate Authority (CA): The organization that provides the CA certificate and signs certificate requests.
- Registration Authority (RA): An organization from which individuals, machines, or even subordinate certification authorities can apply for certificates. The latter checks the correctness of the data in the certificate application and, if necessary, approves it. In the case of a manual check, this is carried out by the Registration Authority Officer. The information from the approved application can then be signed by the CA, resulting in the desired certificate.
- Certificate Revocation List (CRL): A list of certificates that were revoked before the expiration date. Reasons include the compromise of the key material, but also invalidity of the certificate data (e.g. e-mail) or leaving the organization. A certificate revocation list has a defined runtime, after which it is created again updated. Instead of the CRL, a whitelist can also be used, in which only all certificates that are currently valid are entered. In principle, a PKI must always offer a certificate status check. However, in addition to the CRL (or whitelist) as an offline status check, so-called online status checks such as OCSP or SCVP can also be used (see Validation Service). Online status checks are usually used where it is important to check the certificate at the right time, e.g. for financial transfers, etc.
- Directory Service: a searchable directory containing issued certificates, usually an LDAP server, less often an X.500 server.
- Validation Authority (VA) service: A service that enables real-time verification of certificates, such as OCSP or SCVP.
- Documentation: A PKI keeps one or more documents that describe the working principles of PKI. Key points are the registration process, handling of the private key, central or decentralized key generation, technical protection of the PKI systems and any legal assurances. In X.509 certificates, the CPS can be linked in the extensions of a certificate. Some of the documents listed below are common.
- CP (Certificate Policy): In this document, PKI describes its requirements profile for its own way of working. It is used by third parties to analyze trustworthiness and thus to include it in the browser.
CPS (Certification Practice Statement): This describes the concrete implementation of the requirements for PKI. This document describes the implementation of the CP. - PDS (Policy Disclosure Statement): This document is an excerpt from the CPS in case the CPS is not to be published.
More: - Subscriber: The holder of a certificate. These can be services, people, servers, routers, or similar.
- Participant: Users of the certificates (those who trust them).
Trust Models in Public Key
Certificates are essentially digital certifications. Thus, the trust between the examiner and the issuer of a certificate, as well as the way in which this trust is established, is the essential basis for the use of digital certificates. Conversely, such trust models can usually only be technically implemented through certificates.
Strictly hierarchical PKI
Certificates are often used within a completely hierarchical PKI. This trust model assumes the existence of a root CA: a supreme CA that is trusted by all participating parties. In practice, however, there is no such entity at the global level. For example, different countries and multinational companies each operate their own hierarchical PKIs with their own root certification authorities. The reason for this is not so much a lack of trust in other PKIs or root certification authorities, but rather a desire for complete control of the rules within one’s own PKI.
The certificates of a rootCA are called root certificates and represent the root anchors of PKI. Root certificates from important root CAs are often integrated into the processing software. However, the problem here is that statements about the requirements for the issuance of the certificates – and thus about their trustworthiness and permissible areas of application – can only be made via the respective PKI documentation.
Displaying a Certificate Chain in Windows
Since the root certificate, and thus the entire certificate hierarchy, remains trustworthy only as long as its private key (which is stored on the root CA) is known only to the issuing party, the protection of the root CA is of paramount importance. As a rule, it is therefore both physically protected (by securing access and access only by authorised persons or groups of persons in the four-eyes or multi-eyes principle) and operated exclusively “offline”, i.e. without access via an external network. Keys of the next level are generated or signed as part of a so-called key ceremony according to a precisely defined protocol. Often, the root CA machine is also protected against physical manipulation from the outside, e.g. the keys are often automatically deleted when opened or shaken. Since the loss of the private keys (e.g. due to hardware failure) would require the entire hierarchical PKI to be provided with new certificates, it is also necessary to establish a secure procedure for restoring the root certificates. To do this, the keys are often divided and distributed to several people for safekeeping. The key parts must be provided and re-entered by the appropriate persons in the event of the restoration of the root certificate.
Due to the high level of protection required by the root CA, the automatic processing of signing or encryption requests is carried out with sub-certificates that have been signed with the root certificate and have a shorter validity (usually a few months to years) than the root certificate (which is usually valid for several years or decades). The validity of the sub-certificates is chosen in such a way that it can be considered unlikely that the private keys belonging to the certificate can be computed within the selected validity period with currently available computing capacity. In this way, a certificate chain is created, in which reference is made to the signing certificate as the issuing authority. This chain is usually supplied as part of a certificate to enable a check of trustworthiness, validity and, if necessary, certificate revocation along the entire certificate chain. SSL certificate chains, which are used to secure browser-server communication, can be checked by HTTP public key pinning and secured against man-in-the-middle attacks.
Cross-certification
One way to enable the application of certificates across the boundaries of different hierarchical PKIs is through cross-certification. In this case, two certification authorities (usually root instances) issue a (cross-)certificate to each other. In contrast to normal certificates in a hierarchical PKI, cross-certificates express the trust of two equal parties, i.e. the rules of one parent instance are not binding on the PKI of the other parent instance, or only to the extent that they do not contradict their own rules. The interpretation of the relationship of trust expressed by a cross-certificate is therefore sometimes not easy and in many cases not even clear.
Another problem with bilateral cross-certification is that the number of cross-certificates increases quadratically with the number of certification bodies. For example, if there are 20 root instances, 380 cross-certificates would be required between these root instances (20*19=380). One solution to this would be to cross-certify all root instances with a neutral bridge CA. It exchanges cross-certificates with all participating root instances, so that the certificates of each PKI can be traced back to the certificates of each other participating PKI via the cross-certificates of the bridge CA. In other words, the bridge CA is at the heart of the trust relationships between the root instances. For this reason, the trust model induced by a bridge CA is also referred to as hub and spoke in the English-speaking world.
Web of Trust
A trust model that is completely contrary to the certification hierarchy is used by the encryption software PGP and the open-source variant GNU Privacy Guard. Both are based on OpenPGP and are compatible with each other. A certificate can be generated by any user (Web of Trust member). If a user believes that a public key actually belongs to the person who publishes it, they create a certificate by signing that public key. Other users can use this certificate to decide whether or not they want to trust that the key belongs to the specified user. The more certificates attached to a key, the more certain you can be that this key actually belongs to the specified owner.
A certificate can also be generated in the Web of Trust by a certificate authority. Since a certificate authority almost always sets the rules for the issuance and use of the certificates, in this case the Web of Trust transitions into a partially hierarchical trust model.
