An Overview of Public Key Infrastructures (PKI)

In the previous chapter we looked at the concepts of symmetrical and public (asymmetrical) key encryption and learned about confidentiality, integrity, nonrepudiation and authentication. In this chapter we will look in detail at Public Key Infrastructures.

Contents

What is a Public Key Infrastructure?

So far in this book we have looked at both symmetric and asymmetric key encryption. Both approaches to encryption involve the exchanging of keys between the entities wishing to establish a communications through the use of cryptography. The one missing element from these encryption mechanisms involves trust and proof of identity. Suppose, for example, two parties wish to communicate using public key encryption. The sender uses the public key belonging to the recipient and uses it to encrypt the information. On receipt of the encrypted information, the recipient uses a private key to decrypt, and thereby access, the information. The weak point in this scenario is that the sender has no way to validate that the person who provide them with the public key is who they say they are. The sender has to take completely on trust the fact that they person they are sending the information to is who they say they are.

This is where the public key infrastructure (PKI) comes in. A PKI involves the participation of trusted third parties who verify the identity of the parties wishing to engage in a secure communication through the issuing of digital certificates. A real world analogy might involve customs and immigration. When a person arrives at an airport aboard an international flight they have to pass through customs. If an arriving passenger simply verbally claims to be John Smith there is no way for the customs officer to know if John Smith is who is says he is. It is entirely possible that he really is John Smith, but because the customs office doesn't know the person he has know way of knowing whether he is trustworthy. Instead, the customs officer relies on a trusted third party in the form of a government passport issuing office. The passport office goes through the process of confirming a persons identity before issuing a passport. The passenger then uses this passport to confirm to the customs officer that they are who they say they are. Because the person has a passport, and the customs officer trusts the passport office the person is permitted into the country. Public key infrastructures work in a very similar way. A trusted third party called a registration authority verifies the identity of a person or entity and instructs another body, the certificate authority to issue a digital certificate which also contains that entities public key. This certificate (and the public key contained therein) may subsequently be used to prove identity and enable secure transactions with other parties.

Now that we have a basic understand what a PKI is and what it does we can begin to look at the various components of a PKI.

Certificate Authorities (CA)

A certificate authority (CA) is the trusted third party responsible for validating the identity of a person or organization. Once the identity has been verified a certificate server generates a digital certificate containing the subject's public key. The digital certificate is then digitally signed with the CA's private key.

Certificate Authorities are real organizations consisting of people and technologies whose job it is to validate the identity of those seeking digital certificates. The process of a CA are outlined documents known as certification practices statements (CPS). This document outlines issues such as how identities are confirmed and how digital certificates are maintained and transmitted. Before engaging the services of a CA it is important to carefully read the organizations CPS.

Registration Authorities (RA)

The registration authority (RA) is the component of a PKI which is responsible for accepting requests for digital certificates and authenticating the person or organization making the request.

The specific authentication process used depends of the class of certificate being requested:

• 'Class 1 - Involves the verification of an individual via email. A class 1 certificate can be used to digitally sign email messages. Typically requires an email address, full name and physical address. the application process will also walk the applicant through the process of creating a public/private key pair.

• Class 2 - Used to sign software so that a person using the software can verify the authenticity of the software vendor.

• Class 3 - Provided to companies wishing to set up their own certificate authority.

Once the validation process is complete the RA transmits the request to the CA which passes it to the certificate server (CS). The CS generates the digital certificate, including the appropriate information (including the applicants public key) and sends the certificate to the applicant.

Certificate Repositories

Once certificates and corresponding public keys have been generated they are generally stored in a public accessible location known as a certificate repository. Certificate repositories are typically compatible with the Lightweight Directory Access Protocol (LDAP) making access to and searching of repositories compatible with open standards. A dedicated security repository usually available for each particular PKI environment.

Digital Certificate Structure

Digital certificates are structured in conformance with the X.509 standard. This standard outlines the required fields that comprise a certificate together with acceptable values for those fields.

The fields specified by X.509 are as follows:

• Version Number - Specifies the version of X.509 to which the certificate conforms (at time of writing the current version is 3). The version number is important because it defines which other fields are necessary in the certificate.

• Subject -