Public key infrastructure
With public key infrastructure ( PKI , English public key infrastructure ) is known in cryptology a system that digital certificates can issue, distribute and check. The certificates issued within a PKI are used to secure computer-aided communication.
concept
With the help of an asymmetric cryptosystem , messages can be digitally signed and encrypted in a network . With a suitable choice of parameters (e.g. the key length), secure cryptosystems can not be broken in the foreseeable future, even if the method (cf. Kerckhoffs' principle ) is known, at least according to the current state of knowledge.
In asymmetric encryption systems, the transmitter for an encrypted transmission requires the public key (public key) of the receiver. This could e.g. B. sent by e-mail or downloaded from a web page. It must be ensured that it is actually the recipient's key and not a forgery by a fraudster.
Digital certificates are now used for this , which confirm the authenticity of a public key and its permitted scope of application and validity. The digital certificate is itself protected by a digital signature, the authenticity of which can be checked with the public key of the issuer of the certificate.
To check the authenticity of the issuer key, a digital certificate is again required. In this way, a chain of digital certificates can be set up, each of which confirms the authenticity of the public key with which the previous certificate can be checked. Such a chain of certificates is called a validation path or certification path. The communication partners must be able to rely on the authenticity of the last certificate (and the key certified by this) without another certificate.
Components of a PKI
- Digital certificates : Digitally signed electronic data that can be used to prove the authenticity of objects.
- CA (Certificate Authority, CA) : Organization that provides the CA certificate and accepts the signature certificate applications.
- Registration Authority (Registration Authority, RA) : Organization, may apply to the people, machines or subordinate CA certificates. This checks the correctness of the data in the desired certificate and approves the certificate request, which is then signed by the certification authority. In the case of a manual check, this is carried out by the Registration Authority Officer.
- CRL (Certificate Revocation List, CRL) : A list of certificates that were withdrawn before the expiry date. Reasons are the compromise of the key material, but also the 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 updated and generated again. Instead of the CRL, a positive list, the so-called white list, 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. In addition to the CRL (or the white list) 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 the timely checking of the certificate is important. B. with financial transfers etc.
- Directory service (Directory Service) : contains a searchable directory that issued certificates, usually a LDAP server, rarely a X.500 server.
- Validation service (Validation Authority, VA) : A service that enables the validation of certificates in real time as OCSP or SCVP .
- Documentation: A PKI keeps one or more documents in which the working principles of the PKI are described. The 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, the PKI describes its requirements for its own way of working. It is used by third parties to analyze the trustworthiness and thus for inclusion in the browser.
- CPS (Certification Practice Statement): The concrete implementation of the requirements in the PKI is described here. This document describes the implementation of the CP.
- PDS (Policy Disclosure Statement): This document is an excerpt from the CPS if the CPS is not to be published.
Further:
- Subscriber : The owner of a certificate. These can be services, persons, servers, routers or similar.
- Participant : users of the certificates (those who trust them).
There are standardized specifications for the content and scope of the documents CP and CPS, see RFC 3647 . (English).
Trust models in public key infrastructures
Certificates are essentially digital notifications. Thus, the trust between the examiner and the issuer of a certificate and the way in which this trust is established represent the essential basis for the use of digital certificates. Conversely, such trust models can usually be used only implement technically through certificates.
Strictly hierarchical PKI
Often certificates are used within a completely hierarchical PKI. This trust model requires the existence of a root certification authority (Root CA) requires: a topmost certification authority, rely on the all participating parties. In practice, however, there is no such authority at the global level. For example, different countries and multinational companies each operate their own hierarchical PKIs with their own master certification bodies . The reason for this lies less in a lack of trust in other PKIs or root certification authorities than in the desire for complete control of the rules within your own PKI.
The certificates of a tribe are certification instance as root certificates or root certificates referred to and represent the trust anchor of the PKI. Root certificates from major root CAs are often integrated into the processing software. The problem with this, however, is that statements about the requirements for issuing the certificates - and thus about their trustworthiness and permitted areas of application - can only be made via the respective PKI documentation (see above).
Since the root certificate and thus the entire certificate hierarchy can only be trusted as long as its private key (which is stored on the root CA) is known exclusively to the issuing party, protecting the root CA is of utmost importance. It is therefore usually both physically protected (by securing access and access only by authorized persons or groups of people in the four- or multiple-eyes principle) and operated exclusively "offline", i. H. without access via a network from outside. Keys of the next level are generated or signed in a so-called key ceremony according to a precisely defined protocol. Often the RootCA computer is also protected against physical manipulation from outside, e.g. B. the keys are often automatically deleted when opening or shaking. Since the loss of the private key (e.g. due to a hardware defect) would have to provide the entire hierarchical PKI with new certificates, it is also necessary to establish a secure procedure for restoring the root certificates. For this purpose, the keys are often split up and distributed to several people for safekeeping. If the root certificate is restored, the key parts must be provided by the appropriate persons and re-entered.
Due to the high level of protection required by the root CA, signature or encryption requests are automatically processed with sub-certificates that are signed with the root certificate and have a shorter validity (usually a few months to years) than the root certificate (which is usually several years or Decades). The validity of the sub-certificates is selected in such a way that it can be viewed as improbable that the private keys belonging to the certificate can be calculated within the selected validity period with the currently available computing capacity. In this way, a certificate chain is created, in which reference is made to the signing certificate as the issuing body. This chain is usually supplied as part of a certificate in order to enable a check with regard to trustworthiness, validity and, if necessary, existing certificate revocation along the entire certificate chain. SSL certificate chains, which are used to secure browser-server communication, can be checked using HTTP public key pinning and secured against man-in-the-middle attacks.
Cross certification
One way of enabling the use of certificates across the boundaries of different hierarchical PKIs is cross-certification. Two certification authorities (usually the root authorities) issue each other a (cross) certificate. In contrast to normal certificates in a hierarchical PKI, cross certificates express the trust of two parties with equal rights. H. the regulations of one parent instance are not binding for the PKI of the other parent instance, or only binding insofar as they do not contradict its own regulations. The interpretation of the trust relationship expressed by a cross certificate is therefore sometimes not easy and in many cases not even unambiguous.
Another problem with bilateral cross-certification is that the number of cross-certificates increases quadratically with the number of certification authorities. So z. For example, if there are 20 base instances, 380 cross certificates are required between these base instances (20 * 19 = 380). One solution would be the cross-certification of all ordinary instances with a neutral Bridge-CA . This exchanges cross-certificates with all the main entities involved, so that the certificates of each PKI can be traced back to the certificates of every other PKI involved via the cross-certificates of the bridge CA. The Bridge-CA thus represents the center of the trust relationships of the base 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, he creates a certificate by signing this public key. On the basis of this certificate, other users can decide whether they too want to trust that the key belongs to the specified user or not. The more certificates are 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 certification authority. Since a certification authority almost always specifies the rules for issuing and using the certificates, in this case the Web of Trust changes to a partially hierarchical trust model.
Implementation of a PKI and card management
Building a PKI can be worthwhile for a larger company or agency. Smaller organizations, on the other hand, often forego such a measure and obtain their certificates from special PKI service providers. The focus of a PKI structure is always software for operating the certification authority (CA).
Certificates for employees are mostly saved on chip cards, which then become company IDs and can be used for various login processes. You thus become the basis for a single sign-on system.
The integrated options for managing the issued chip cards are often not sufficient in organizations with medium-sized and large networks, for example when issuing replacement cards or revoking cards and certificates . Commercial card management systems are therefore offered to simplify the management of such an infrastructure (so-called managed private key infrastructure, or mPKI or MPKI for short ).
Security aspects
The protection of the certification authority itself against external hacker attacks is critical . At the beginning of September 2011, for example, it became known that attackers at the Dutch company DigiNotar BV had issued unauthorized certificates for various domains (including google.com). These were demonstrably used for eavesdropping attacks (using man-in-the-middle attacks ) on Iranian citizens. The CAs concerned were then removed from their systems by the most important browser and operating system manufacturers. As a result, legitimate DigiNotar certificates are no longer recognized as valid, which has serious consequences for the IT infrastructure, since DigiNotar certificates are also used for the state public key infrastructure in the Netherlands .
Another attack vector is the use of hash collisions on certificates issued by the PKI. The signature of a certificate represents a hash value of the content, which is then encrypted with the CA's private key and thus confirms the authenticity of the certificate. It follows from this: if you had a certificate that has the same hash value as one that has already been signed by a CA, the signature can be copied and thus certifies a second certificate. Since hash functions are always limited to a certain output length, it also follows that collisions can inevitably occur with any input. Depending on the CA algorithm used , these can be brought about in a more or less targeted manner.
literature
- Norbert Pohlmann : Cyber security: The textbook for concepts, principles, mechanisms, architectures and properties of cyber security systems in digitization. Springer Vieweg, September 2019, ISBN 3658253975 (pages 115-149)
- Klaus Schmeh : Cryptography. Procedures, protocols, infrastructures. dpunkt, Heidelberg 2007, ISBN 978-3-89864-435-8 .
- Brian Komar: Microsoft Windows Server 2008 PKI and Certificate Security. Microsoft Press Germany, 2008, ISBN 978-3-86645-648-8 .
- Patrick Huber: Structure and function of public key infrastructures. GRIN Verlag, Munich 2018, ISBN 978-3-668-80088-5 .
Web links
Individual evidence
- ↑ Sönke Maseberg: Fail-Safe Concept for PKIs. (PDF) (No longer available online.) February 1, 2003, archived from the original on March 4, 2016 ; accessed on October 24, 2015 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ^ IANA Root KSK Ceremonies. Retrieved October 24, 2015 .
- ↑ DNSSEC KSK Ceremony 22. Accessed October 24, 2015 .
- ↑ Certification guideline for the T-Systems Trust Center Public Key Infrastructures. March 30, 2015, accessed October 24, 2015 .
- ^ L. Aaron Kaplan, Otmar Lendl: Interim report DigiNotar Certificate Authority Hack and relevance for Austria. (PDF, 120kb) CERT.at, September 8, 2011, p. 5 , accessed on September 28, 2011 .
- ↑ New SSL disaster: Wrong Google certificate went undetected for five weeks. heise.de, August 30, 2011, accessed on September 28, 2011 .
- ↑ Gmail.com SSL MITM ATTACK BY Iranian Government. pastebin.com, August 27, 2011, accessed September 28, 2011 .
- ↑ Dutch government takes control of DigiNotar. heise.de, September 5, 2011, accessed on September 28, 2011 .
