Site icon Ryadel

Public Key Infrastructure (PKI) - Definitions and use cases

IIS - How to setup the web.config file to send HTTP Security Headers with your web site (and score an A on securityheaders.io)

Torso of a manager is locking one virtual lock in a lineup of open padlocks. Business metaphor and technology concept for cyber security, critical data streaming, encryption and personal information.

A Public Key Infrastructure (often abbreviated as PKI) is a set of processes and technological means that allow trusted third parties to verify and / or guarantee the identity of a user, as well as to associate a public key to a user: These public keys typically take the form of digital certificates.

In this article we will try to provide a general overview of this type of infrastructure, starting with the definition and the main examples of use.

Definition

In recent years, the term PKI has been used to indicate both the Certification Authority (CA) and related agreements, and, more broadly, the use of public key cryptographic algorithms in electronic communications. However, the use of the term in the latter sense is incorrect, as a PKI does not necessarily require the use of public key algorithms.

Furthermore, the PKI structure does not only concern the CA but a plurality of subjects and services connected to them, namely:

  • Certification Authority (CA), a public or private trusted third party authorized to issue a digital certificate through a certification procedure compliant with current regulations;
  • Registration Authority (RA), which is the system for registering and authenticating users who request the certificate;
  • Validation Authority (VA), which is the system that certifies the correspondence between the certificate issued and the issuing entity.
  • Security policies that defines the general principles;
  • Certificate Practice Statement (CPS), a document that illustrates the procedure for issuing, registering, suspending and revoking the certificate;

A PKI infrastructure is hierarchically composed of several Certification Authorities at the top of which is a root CA that certifies all the others. The first step in building a PKI is therefore to create the root CA. At this point, however, a problem arises: if the root CA is the root of the tree, who signs its certificate?

The answer is very simple: the CA signs its own certificate, issuing the key pair itself. From this it is clear the importance that the root CA has a good / excellent reputation, as there is no guarantor authority over it.

Use cases

The main purpose of PKIs is to provide users' public keys and, at the same time, guarantee their identity. Public keys, once released, are usually used to perform the following functions:

  • Encryption and/or authentication in email messages (e.g. using OpenPGP or S/MIME).
  • Encryption and/or authentication in standard documents (such as XML Signature or XML Encryption).
  • User authentication for applications (e.g. when logging into a system via smart card or authenticating a client via SSL/TLS).
  • Bootstrap procedures in secure communication protocols, such as the main protocols used for VPN and SSL connections. In both, the initial setup of a secure channel is done through public keys, while actual communications use faster secret key systems (aka Symmetric Key Cryptography).

Asymmetric Key Cryptography

Unlike symmetric encryption which uses a single key to encrypt and decrypt, asymmetric or public key encryption uses a pair of keys: a public key and a private key, respectively used to encrypt and decrypt. In such scenario, CAs are required to guarantee the association between a public key and the person who owns the corresponding private key.

  • Alice and Bob want to exchange signed and encrypted messages; for this purpose they both create their own key pair and publish the public ones on a keyserver;
  • Alice writes a message for Bob, signs it with her private key and encrypts it with Bob's public key, then she sends the message;
  • in reception Bob decrypts the message with his own private key and verifies the signature with the public key headed to Alice.

At this point, Bob is able to determine two things:

  • the message was directed to him, as he managed to decrypt it with his own private key;
  • the message was encrypted with the private key that matches the public key he used to verify the signature.

Man in the Middle

If we look at the example we started earlier, we can easily see how Bob is unable to determine with certainty that the message really came from Alice; as a matter of fact, it's possible that a third party has managed to intercept the communication in which Bob obtains Alice's public key and has managed to replace it with his own, thus pretending to be Alice. If this happens, Bob has no way to discover the deception. This is a type of attack known as Man in the Middle, a term used to refer to all situations in which a third person stands between a communication between two subjects.

To solve situations of this type, CAs are born that take care of verifying and guaranteeing the correspondence between key and owner, verifying the user's identity when he requests a certificate and then signing a digital certificate that certifies the user's identity. . In this way, the Man in the Middle no longer has a way to pretend to be Alice, as he is unable to reproduce the CA's signature.

The Italian legislation, in implementation of the European Directive 1999/93 / EC, has identified in the CNIPA, now known as the Agency for Digital Italy, the public body that accredits the main certifying entities (eg Infocert, Aruba, Poste Italiane, etc.): in addition to accrediting the certifiers, AgID also controls their work and issues regulations in accordance with the current applicable legislation.

Conclusions

That's it for now: we hope this article will help those interested in understanding the structure and functioning of PKIs.

The contents shown in this article delve into some specific aspects of more general topics such as data encryption and cyber security. For more information on these topics, we recommend reading our article on in-transit and at-rest data encryption.

 

Exit mobile version