Last week, I was attending a presentation skills course where we had to give an impromptu presentation (well, we had an hour to prepare) on a topic of our choice.  One of my colleagues, Richard Butler, gave his talk on public key infrastructure (PKI) and Richard was the first person who has explained PKI to me in a way that made me go “ah! got it!” because he used a great analogy.

So, I’m going to attempt to repeat it here (with Richard’s permission)… and hopefully I’ll get it right!

Richard’s first point was that PKI is thought of as a security tool, some technology, or something that’s needed to make the network secure. Actually, he suggests, there’s more to it than that…

The first example Richard gives is one of a server certificate (used to ensure that a service can be trusted and that confidentiality is maintained), illustrated by way of border control.

An airline passenger approaches a border (e.g. an immigration desk at the airport):

1. The border is where the passenger expects it to be.
2. A border guard wears a uniform, with an insignia (badge).
3. The passenger recognises the insignia and trusts it as genuine.
4. The passenger interacts with the border guard to negotiate entry to the country.

A server certificate is similar because it’s presented to prove that the server is who they say they are and is trusted by users accessing its services. The certificate is issued by a certificate authority, just as the border guard’s badge is issued by a government agency.

In Richard’s second example, a certificate is used to provide confidence that you are who you say you are, a process known as integrity or repudiation.

1. As a citizen of a country, I request a passport from my government.
2. The government validates my request.
3. If my request is valid, a passport is issued.
4. When visiting a foreign country, I present my passport at the border.
5. The government of the foreign country trusts the government that issued the password to have carried out the necessary background checks that confirm I am who I say I am.
6. I’m authorised to enter the country.

In this case:

• The issuing government’s passport authority can be thought of as a certificate authority (CA) or issuing authority (IA) – it’s trusted by other countries to authorise passports.
• The passport can be thought of as a validated “client” certificate – it is trusted, because the passport authority is trusted (i.e. there is a chain of trust).
• The government in the foreign country can also be thought of as a certificate authority – it is trusted and authorises the immigration control.
• As described in the first example, the border guard’s insignia can be thought of as a “server” certificate – it is trusted as the foreign country is trusted to issue certificates.
• Humans apply logic to the approach and automatically make the appropriate assumptions and associations.

In a public key infrastructure, there’s a hierarchy of certificate authorities:

• The offline root CA signs requests for sub-ordinate servers and holds the private key for the certificate root.
• A networked, subordinate CA signs requests for clients, and holds its own private key.
• A certificate distribution point stores the public keys for the root CA and the subordinate CA (used to validate requests). It also holds information about certificate revocation (to use the passport analogy, this might be where a citizen has been denied the right to travel, for example due to a pending prosecution).

Using this PKI infrastructure a number of interactions take place:

1. A device creates a signing request and sends it to a certificate authority.
2. The CA receives the signing request, validates the request, and issues a certificate signed with its private key.
3. The original device receives the signed certificate and stores it for future use as a client/server certificate.
4. When a connection to a service is attempted, the connecting device receives a copy of the certificate and validates the name and signing CA using their public key. This validates the certificate chain and the certificate is proved to be valid.

At the outset of this description, Richard explained that there is more to PKI than just a security tool, or some technology services.  There’s actually a hierarchy of deployment considerations:

• Private key protection. Private keys are critical to the ability to sign certificates and therefore crucial to the integrity of the chain of trust.
  • A chain is only as strong as its weakest link.
• Management procedures:
  • Validation of requests (stopping fraudulent certificates from being issued).
  • Management of certificates (issuing, revocation, etc.)
• Deployment procedures:
  • Deploying and managing the PKI infrastructure itself.
• Technology choices:
  • Whose PKI infrastructure will be used?

Drawn as a hierarchy (similar to Maslow’s hierarchy of needs), technology choices are at the top and are actually the least significant consideration.  Whilst having a secure technical solution is important, having the procedures to manage it are more so.

Richard wrapped up his presentation surmising that:

• PKI is 10% technology and 90% process.
• Deployment is 10% of the solution and management is 90%.
• PKI needs management from day one.

If you do still want to know more about the technology (including seeing some diagrams that might have helped to illustrate this post if I’d had the time), there’s a Microsoft blog post series on designing and implementing PKI, written by the Active Directory Directory Services team.  Other PKI solutions exist, but as many organisations have an Active Directory, looking at the Microsoft implementation is as good a place as any to start to understand the various technologies that are involved.