Digital Certificate Operation in a Complex Environment
homebackgroundprojectdocumentsdesignglossary
navigation search
search query:

PKI Primer and Project Background

8. Public key infrastructure

8.1. Why 'infrastructure'?

Trust has been mentioned in previous sections in this document and the whole system of...

  • checking someone's identity
  • then issuing them with a certificate (or signing their self-generated certificate)
  • and issuing lists or maintaining databases of revoked certificates (revocation is discussed in a later section)

... necessary for the certificates to be trusted can be thought of as an 'infrastructure'. The infrastructure is clearly made up of technical and human administrative components. This infrastructure is reliant upon public (and private) keys and is thus termed a public key infrastructure (PKI).

The Internet Engineering Task Force (IETF) defines [a] PKI as: "The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke Public Key Certificates based on public- key cryptography".

8.2. A few notes about cryptography...

Cryptography is a collection of mathematical techniques for protecting information. Information is made unintelligible by the use of a key and is later made readable by the use of the same, or another, key. Up until the 1960s or 70s, cryptographers used only symmetric keys.

8.2.1. Symmetric key encryption

Symmetric encryption is like having a code-sheet where the letter 'a' becomes the letter 'c', 'b' becomes 'd' etc. etc. So you write your letter using the code sheet and it is unintelligible (except that the code would have to be a bit more complex than this, to be useful!). When your correspondent wanted to de-crypt the letter that you had sent to him, he would need to use the same code-sheet (let's call this a key). Therefore the same key is used to encrypt and de-crypt - hence symmetric encryption.

Symmetric encryption is less processor-intense than asymmetric encryption but requires a key exchange at some stage. Keys have to remain secret and a different key may be required for every entity that communicates with you. Therefore, secure encryption using symmetric keys alone does not scale well. Symmetric keys are often exchanged under cover of asymmetric encryption to save on processor time/costs.

8.2.2. Asymmetric key encryption

Asymmetric encryption was invented independently by academic cryptographers at Stanford University in the USA (in the 1970s) and by military cryptographers at Britain's GCHQ (probably in the 1960s). It is the basis of public key encryption, although a 'public' key is not strictly necessary. Information is encrypted by using one key of a pair and can only be decrypted using the other key.

This is like the equivalent of having a code-sheet (as in the previous example) but you would be able to hand out your code-sheet without worrying about the bad guys seeing it. You could even pin it to the supermarket notice board. If anyone wanted to send you a secret message, they can encrypt some information using your 'public' key, but no-one else could de-crypt it. No-one can de-crypt a message using the same (public) key. Only the private key can be used to de-crypt the message.

NOTE: Keys occur in pairs, with usually one private (i.e. kept secret). Something that is encrypted with a public key can only be decrypted with the private key. The reverse is also true: something encrypted using a private key can only be decrypted using the public key.

So, you've received a message from Alice who used your public key that was pinned up in public. (Actually, you don't have to keep the key in public - it just doesn't matter where you keep it!). When you receive Alice's unintelligible message, you de-crypt her message using your private key. Now that key is really private and should be kept top secret. Therefore, two keys have been used: one to encrypt and another to de-crypt.

However, you can't send Alice a message back unless you know her public key.

But let's assume that Alice has sent you a message using your public key. She could also send you an encrypted message to you that included a symmetric key. That would then allow you and her to communicate (more easily - as it needs less processor time) using symmetric encryption!

8.3. Asymmetric encryption in PKI (or PKIX)

In 1975, two Stanford University researchers, Whitfield Diffie and Martin Hellman effectively designed a public key encryption system. However, as we mentioned at the start of this section, an infrastructure is needed for the system to be trusted by others who wish to authenticate the entity communicating via a public/private key pair.

Gradually some standards were built up. The best known is the X.509 standard for digital certificates and how they are used. This standard has been around for some time and is now up to version 3, but the standard is not universally adopted and so there are differences. There are other standards, such as those used in 'Pretty Good Privacy' (PGP) email communications. These use different types of digital certificates.

We have used the term PKI several times now and it should be noted that the use of the term from here on in this primer should be taken to mean 'PKI using X.509 digital certificates'. (Other writers sometimes use the term PKIX to avoid this confusion).

8.4. So, how does PKI help with authentication?

Hopefully, it is now easy to imagine how encryption and PKI can be used to send messages securely from one user, or entity, to another. encryption helps to mask communications from others, so that data is unintelligible to anyone listening in. However, one-way or asymmetric encryption can be used to encrypt or 'sign' the message in a way that it could only have come from one known entity.

If you avoid thinking of a message as an email or an important document and now think of a short message such as a randomly-generated short stream of numbers and alphanumerics, you may be able to see how this kind of message could be used for authentication.

Consider what happens when you try to connect to a 'secure' server. The server could generate the following 'random' string: "1040d81e4ab38d41edaa06be57138e3b". You could present your digital certificate to the server (which contains your public key). The server trusts your certificate because it is signed by another trusted entity. However, alongside your certificate, you send the Random connection identifier back - "1040d81e4ab38d41edaa06be57138e3b" - but this time it is encrypted using your private key. The server can de-crypt the encrypted string and check it is the same as the original it sent to you.

The server is now 'happy' that you are who you say you are and you are the entity defined by your public key. In this way authentication can be performed using signed/trusted digital certificates and public/private key pairs

The server now allows you to access the service.

*(While you are using the service, your communications could be encrypted for privacy, but this has nothing to do with using public key encryption for authentication - this has already been achieved.)

8.5. Summary

Therefore, public key infrastructure employs digital certificates, public/private key pairs and a whole 'system' (administrative and technical) that can be trusted by other people and services. PKI is a combination of clever encryption and a system that can be trusted for authenticating people/entities.

The next section looks at other authentication methodologies and considers the alternatives to PKI.

Up: Contents Previous: 7. Security and digital certificates Next: 9. Other authentication methodologies

Oxford University Computing Services Mimas Athens access management services Oxfore e-Science Centre Systems and Electronic Resources Service Joint Information Systems Committee