Public-key infrastructure

Using Public Key Infrastructure (PKI, English public key infrastructure ) is called in cryptology a system that can issue digital certificates, distribute and investigate it. The exhibited within a PKI certificates are used to secure computer communications.

Concept

With the help of an asymmetric crypto system messages can be digitally signed and encrypted in a network. Secure encryption systems can not be broken in the foreseeable future with a suitable choice of the parameters ( eg key length ) even if advised of the proceedings (see Kerckhoffs ' principle).

In asymmetric cryptosystems, the transmitter needs for encrypted transmission of the public key (public key ) of the recipient. This could be sent, for example, by e -mail or downloaded from a web page. It must be ensured that it is in fact the key of the recipient and not a forgery of an impostor.

For this purpose, now serve digital certificates that confirm the authenticity of a public key and its permissible scope and coverage. The digital certificate is itself protected by a digital signature whose authenticity can be verified with the public key of the certificate issuer.

To check the authenticity of the key exhibitors, in turn, a digital certificate is required. In this way, a chain of digital certificates to establish each confirm the authenticity of the public key with which the previous certificate can be checked. Such a chain of certificates is called a certification path validation or path. On the authenticity of the last certificate ( and certified by this key ), the communication partners must be able, without another certificate leave.

Components of a PKI

• Digital certificates: Digitally signed electronic data that can be used to prove the authenticity of objects.
• CA Certificate Authority ( CA) is the organization that provides the CA certificate and accepts the signature of certificate applications.
• Registration Authority ( Registration Authority RA): organization, can apply for certificates at the people, machines, or even subordinate CAs. This verifies the accuracy of data in the desired certificate and approves the certificate request, which is then signed by the certification body. For a manual check this is performed by the Registration Authority Officer.
• CRL (Certificate Revocation List, CRL): A list of certificates that have been revoked for a period of validity. Reasons are the compromise of key material, but also invalidate the certificate data ( eg e -mail) or leaving the organization. A CRL has a defined duration, after which it is generated again updated. Instead of the CRL can also be a positive list, the so-called white list will be used are entered in the certificates valid only all at the current time. Basically, a PKI must always offer a certificate status check. Here, however, in addition to the CRL ( or White- List) as an offline status examination also known as online status checks as OCSP or SCVP are used (see validation service). Online status checks are usually used where the time-accurate examination of the certificate is important, for example in financial transfers etc.
• Directory Service ( Directory Service): a searchable directory that contains certificates issued, usually an LDAP server, more rarely, an X.500 server.
• Validation Service ( Validation Authority, VA ): A service that allows the validation of certificates in real time as OCSP or SCVP.
• Documentaries: A PKI leads one or more documents in which the working principles of PKI are described. Key points are the registration process, handling of the private key, centralized or decentralized key generation, technical protection of PKI systems as well as any legal warranties. In X.509 certificates, the CPS can be linked to the extensions of a certificate. The documents listed below are partly common. CP ( Certificate Policy ): This document describes the PKI their requirements to their own work. There is a third party to analyze the trustworthiness and thus for inclusion in the browser.
• CPS (Certification Practice Statement ): Here is the concrete implementation of the requirements described in the PKI. This document describes the implementation of the CP.
• PDS (Policy Disclosure Statement ): This document is an extract from the CPS, if the CPS will not be published.

More:

• Subscriber: The owner 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 infrastructures

Certificates are essentially digital credentials dar. Thus, the trust between the auditor and the issuer of a certificate as well as the way how trust works, the essential basis for the use of digital certificates dar. Conversely can such trust models usually technically implemented only by certificates.

Strictly hierarchical PKI

Often certificates are used within a completely hierarchical PKI. This trust model assumes the existence of a root Certification Authority (root -CA): a top certification authority that is trusted by all participating parties. In practice, however, there is at the global level such an instance is not. For example, different countries and multinational companies operate their own hierarchical PKIs with its own root certificate authorities. The reason for this lies less in a lack of trust in other PKIs or root certification authorities, rather than the desire for complete control of the rules within their own PKI.

The certificates of a root certification authority are called root certificates or root certificates, and set the trust anchor of the PKI root certificates dar. important root CAs are often used by the processing software integrated. A problem here, however, is that statements about the requirements for the issuance of the certificates - and thus about their trustworthiness and permissible applications - just about the respective PKI documentation can be made ( see above).

Cross - certification

One way to allow the use of certificates across borders of different hierarchical PKIs of time, is the cross-certification. Here there are two CAs issue (usually root instances) each other a (cross- ) certificate. In addition to ordinary certificates in a hierarchical PKI press cross certificates trust between two equal parties from, that is, the rules of a trusted root are not binding on the PKI of the other root authority, or only binding insofar as they their own regulations do not disagree. The interpretation of the expressed by a cross- certificate trust relationship is therefore not always easy and in many cases not even unique.

Another problem of bilateral cross-certification is that the number of cross certificates square increases with the number of certification bodies. So 380 cross certificates would be, for example, from 20 root root instances between these instances required ( 20 * 19 = 380). A solution to this would be the cross- certification of all root instances with a neutral bridge CA. These exchanges with all involved root instances of cross- certificates, so can the PKI certificates in any of the Cross - Bridge-CA certificates to the certificates at any other PKI involved traced. So the Bridge-CA provides a central point of trust relationships of the root instances dar. For this reason, this is called by a bridge - induced CA trust model in the English language as a hub and spoke.

Web of Trust

A completely contrarian to the certification hierarchy trust model is used by the encryption software PGP and the open source version 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). Does a user that a public key actually belongs to the person who posted it, so he created a certificate signed by that public key. Other users can decide on the basis of this certificate, whether they want to trust that the key belongs to the specified user or not. The more certificates hanging on a key, the more secure you can be that this key really belongs to the listed owner.

A certificate can also be generated in the web of trust from a Certification Authority. As a certification body almost always dictates the rules for the issuance and use of certificates, is in this case the web of trust over in a partially hierarchical trust model.

Implementation of a PKI

The structure of a PKI can be worthwhile for a larger company or a larger authority. Smaller organizations, however, often refrain from such action and obtain their certificates for special PKI service providers. At the heart of PKI structure is always a software for operating the certification authority ( CA).

Certificates for employees are usually stored spent on smart cards, which are thereby to the company's identity and can be used for various application processes. They are thus the basis for a single sign-on system.

Since the built-in ways to manage the issued smart cards, such as issuance of replacement cards, revocation of cards and certificates in larger organizations are not sufficient, commercial card management systems are used for this purpose.

Safety aspects

Critical to the protection of the certification body is itself against hacker attacks from the outside. So early September 2011 it was announced that attackers had exhibited at the Dutch company DigiNotar BV unauthorized certificates for various domains ( inter alia google.com). These have been proven to eavesdropping used (via man-in -the -middle attack ) on Iranian citizens. The affected CAs were then removed from the main browser and operating system manufacturers from their systems. This also legitimate certificates from DigiNotar will no longer be accepted as valid, which has serious consequences for the IT infrastructure, as DigiNotar certificates are used in the Netherlands for the State Public Key Infrastructure.