Difference between revisions of "An Overview of Public Key Infrastructures (PKI)"

Revision as of 15:31, 3 March 2008

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.

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:

• 'Issuing CA - The name of the certificate authority which issued the certificate.

• CA Digital Signature - The digital signature of the issuing certificate authority.

• 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.

• Serial Number - A unique number identifying the specific certificate issued by a particular CA.

• Subject/Owner - The owner of the certificate. Possible values include a person, company, department, network device, application etc.

• Owner's Public Key - The public key associated with the certificate and corresponding to the certificate owners private key.

• Validity Period - The dates during which the certificate is deemed to be valid.

• Certificate Usage - Specifies the approved uses of the certificate.

• Signature Algorithm - The hashing and digital signature algorithms used in the creation of the certificate.

In addition to the standard certificate fields, certificate extensions allow addition of custom data to digital certificates.

Certificate Lifecycles and Key Management

The certificate lifecycle consists of many (but not necessarily all) of the following event:

• Key Generation - The creation of the public/private key pair associated with the certificate

• Identify Submission - The credentials of the party requested the certificate are submitted to the CA.

• Registration - The request for a new certificate is registered by the CA.

• Certification - Requesting party's identity is validated and a certificate is generated and digitally signed with the CA's digital signature.

• Distribution - The certificate is published by the CA.

• Usage - The requesting party uses the certificate for the authorized purpose.

• Expiration - Unless renewed or revoked, the certificate expires based on the expiration date built into the certificate at generation time.

• Revocation - At any time prior to expiration a certificate may be revoked (for example if it is being used for malicious purposes or the private key is compromised).

• Renewal - At the request of the owner a certificate may be renewed by the CA. This process requires the generation of a new public/private key pair.

• Suspension - The certificate is temporarily suspended, for example is a user goes on sabbatical and does not plan to use the certificate during this period of time.

• Recovery - The process of recovering the key pair from a backup in the event of corruption (in order to qualify for recovery the keys must be considered to still be trusted and valid).

• Destruction - When the key and certificate lifetimes expire and a suitable period of time has elapsed to avoid receiving information encrypted using the keys (a period known as the key history maintenance period) it is essential that all copies be destroyed from any locations where they might have been stored. For examle, copies on workstations, laptops servers, key servers and removable media) must be deleted.

Centralized and Decentralized Infrastructures

The key pairs used in a PKI are generated using centralized or decentralized methods. The choice of approach typically depends of an organizations security policy.

Keys that are generated and stored on local computer systems for use by those systems are said to conform to the decentralized approach.

Keys that are generated by a central server and transmitted to hosts on an as-needed basis are referred to centralized.

It is important to note that these distinctions are not necessarily mutually exclusive and that there is room for some overlap. For example, in a decentralized environment it is still possible for the keys to be generated by the local system, and the public key then provided to the central server for the creation and distribution of the corresponding certificate.