My guide to Public Key Infrastructure (PKI)
In this guide I introduce the concepts behind Public Key Infrastructure (PKI) and how it helps us with keeping our infrastructure and information secure.
Most people take it for granted that the information they put into the ‘cloud’ is safe from prying eyes. This is due to the advances in security over decades.
The truth is, when you send information to or read information from a server on the Internet, it goes over infrastructure that you have no control of. You have no idea if someone is ‘listening in’ on your connection.
Being able to send and receive information securely over such public infrastructure has been due to the use of Public Key Infrastructure (PKI).
This article introduces PKI and explains the role of the Certificate Authority or CA.
Symmetric Keys
Wow! Security gets complicated very quickly but it doesn’t need to. If, like me, the word symmetric makes your head spin, here is a quick introduction about how security works that hopefully keeps your head looking on one direction!
The aim is to securely pass a message between two points on the Internet (typically a web server and a browser on your computer), knowing that anyone may be able to read that message and/or change it in the middle. It is important to understand that ‘securely’ in this context means:
- Ensuring anyone who sees the message can’t read it
- Ensuring that the message you receive is the one that has been sent and that it has not been changed
Encryption/Decryption
The first requirement above involves encrypting the message to make it seem like gobbledygook to anyone else and then decrypting it to change that gobbledygook back into the original message.
As a child, did you ever send secret note to a friend using a secret code? Maybe you swapped letters around, such as A becomes B and B becomes C etc?
The method you used is the cipher algorithm. The algorithm tells you how to encrypt and decrypt the information. To read the message you need to know the algorithm. Generally, this information is not a secret.
Of course, swapping letters around is not very safe. Maybe you decided to make the offset from a letter to its encrypted version a number that only you and your friend knows. That offset is called a pre-shared secret or key that locks and unlocks your message. You must keep the key safe as anyone who has it can read your encrypted messages.
Ok, so this is not very secure but it helps understand the difference between a cipher algorithm and a key. One defines what you do and the other what you do it with.
Signing
The second requirement is to ensure that you know if the original message has been tampered with or not.
Back to passing notes. Let’s say you write a note and ask another person to deliver the note to the recipient. How does the recipient know if the person delivering the note has changed parts of the message or even replaced the whole thing with their own message?
You need to know that the recipient can trust the message they received is the one you sent (this is also known as non-repudiation as no one can claim the message has been tampered with).
In days gone by, it was sufficient for the sender to sign the message as it was hard to forge the signature. Today, in the digital world, this is not very secure but we can use the concept of signing the message.
Maybe you decide to run some form of calculation over the note to create a digital signature. Treating each letter as a number, eg: A = 1, B = 2 etc and applying a formula or algorithm gives a result, say 193,643,943. This number can now be added to the note as a digital signature, which is called signing the note. When the recipient carries out the same calculation, they can check the result and see if they get the same number. If they don’t, they know the message has been changed.
The formula or algorithm is known as a hash. A hash provides a single number (normally a large one and of a fixed length) for a given input. Whilst it is possible for two different messages to produce the same hash value, the likelihood of a collision is extremely low.
The diagram shows how this works. The sender calculates the hash value for the message, appends it as a signature and sends it off.
The recipient calculates the hash of the message and compares it with the signature value. If they match, the message has not been changed. If they don’t the message can be discarded as a fake.
Of course, if the note passer (the attacker) knows the hash algorithm, they can sign their version of the note and the recipient would never know. It is critical that, even if you know the hash algorithm that you cannot create a signature that looks like one the sender would create.
Like the encryption process above, you decide to include another input to the hash formula. This input (or key) is shared only with your friend and now, when the note passer (who does not have the key) creates a signature for their own message, their result will not match a signature that you would have generated as it does not include the key. In this way the recipient knows it has been changed.
Now, you may be thinking that the person passing the note can work out the key as they have the message and they have the signature. This means they can work out the hash algorithm and the key and then sign their notes in a way the recipient could not detect.
If you were thinking that, 10 out of 10 for staying with me! The hash algorithms are designed to be very hard (but not impossible) to reverse engineer the key from the signed message. Some hash algorithms have been found to be insecure for this very reason and are no longer in use (eg: SHA-1 and MD-5). Note that SHA-1 and MD-5 are still used to detect changes in files in non-security scenarios.
Sharing Keys
You can probably see that it is easy to get confused between encryption / decryption and signing as both include algorithms and keys. It is important to understand the distinction that encryption / decryption effectively hides the message whilst signing ensures it has not been modified. Typically, both are applied to messages.
In both the encryption and signing examples above, you needed to pre-share the key with your friend. As the same key is used for encryption and decryption or signing and validation, they are known as symmetric keys, meaning they are the same on both sides and can be used to encrypt and decrypt or to sign and validate the message.
Symmetric keys introduce the problem of how you share that key (which is secret) with your friend in the first place.
This is exactly the problem you have in the world of digital security and this is why the Internet rarely uses pre-shared keys.
Asymmetric Keys
Introducing the solution — asymmetric keys. Unlike symmetric keys, these keys are different for the sender and the recipient.
It is very important to understand that given a pair of asymmetric keys, say A and B, one key (eg: A) can decrypt a message encrypted with the other (B) but cannot decrypt a message encrypted with itself (A)! The reverse is true. B can decrypt a message encrypted with A but cannot decrypt a message with B.
Ok, you may think this is a bit weird. How can an algorithm work in only one direction? Here is an example of a one-way calculation:
Take a primary number. A primary number can only be calculated from a multiplication of the number itself and 1 (assumes whole and positive numbers only). Have I lost you? Let’s look at an example:
7 is prime as it can only be formed from 1 x 7.
8 is not prime as it can be formed from 1 x 8 and 2 x 4 and 2 x 2 x2.
Now we understand what a prime number is, we can now look at what happens if you multiply prime numbers together. When you do this it creates a number that can only be created from the multiplication of those prime numbers.
How does this help?
Take this calculation based on three prime numbers:
3 x 7 x 11 = 231
This is easy and quick to calculate (well, with a calculator!).
But what about in reverse? Could you determine 3, 7 and 11 from 231? This would be a bit harder but would take considerably more time.
What about 56,606,581. Do you know what prime numbers multiplied together gives you this? Now that would take a while to calculate. You would probably write a program to do it. It is actually 79 x 83 x 89 x 97 (all prime numbers).
Now, what if the numbers became so large that it would take a computer thousands of years to calculate the answer? For all practical purposes, this means that you have an algorithm that can be calculated one way but not reversed. Of course, to make it effective, the numbers involved must be very large and can have over 300 decimal digits (or 1024 bits). This means that encrypting, decrypting, creating and validating signatures is computationally expensive!
Hopefully you know understand how we can calculate things in one direction quickly but that work out what the calculation is, takes a prohibitive amount of time. And do it is with asymmetric key pairs. Once you have the key, you can encrypt/decrypt quickly.
Let’s take this one step further and introduce the idea of public and private keys.
Public and private keys
You may be wondering how a pair of asymmetric keys can help us send things securely — and you would be right to ask.
So, you create a key pair. You call one of them private and one public. They can read each other’s message but not their own.
The private one will be held securely by you and never shared.
The public one will be shared with anyone and everyone (including any attackers).
You are probably asking yourself ‘how does this help as if I encrypt my messages with my private key, anyone can read it?’
Well, we have to introduce a few more steps. Once your recipient has your public key, they can create a new key (let’s call this a session key), encrypt it with your public key and send it back to you.
As you cannot read an encrypted message with the same key, the attacker cannot read the session key but you can as you can read it with your private key. You now have a way to securely communicate.
It is important to realise that once a secure connection is made, the encryption of the messages over the connection is not done with your private and public keys but with this shared, symmetric session key.
So, everything is nice and secure, or is it?
When you send out your public key, what is to stop the attacker intercepting the message and replacing your public key with their own? What stops your recipient thinking the attacker is you?
Public Key Infrastructure (PKI)
Introducing Public Key Infrastructure or PKI. You may be wondering why this only refers to the public key and not the private one. It is because the PKI is designed to secure your public key and to make sure that no one can fake your digital identity. Your private key should never leave your sight.
The idea is this. There is a third party who can validate that a give public key does, indeed, come from you and not an attacker.
It works on the basis of certificates.
X.509 certificates
Before we continue, we need to understand what a X.509 certificate is. X.509 is an internationally agreed standard for creating PKI certificates. I will just refer to them as certificates from now on.
A certificate can be thought of a document that includes information about an entity. An entity may be a person, company or server but for ease of understanding, we will look at an example of a web server. A certificate for a web server would include:
- Information about the server, including its fully qualified domain name (FQDN)
- Information about the authority that is ‘stamping’ the certificate to say it is genuine
- The purpose that the certificate can be used for (eg: encryption, signing etc)
- The public key of the server
- A signature for the certificate added by a trusted organisation
When you receive a certificate, you can now be confident that you know who it is from, what they are allowing you to do with it and their public key. Your confidence comes from the fact is it is signed.
But who signs it?
Creating a certificate
To create a certificate, you first create a Certificate Signing Request (CSR). In this CSR you add the information that will appear in the certificate, including who you are and your public key.
You then sign this CSR with your private key.
I have not talked about signing with asymmetric keys but it works the same way as encryption. You can sign with your private key and verify with your public key or vice versa. You cannot sign and verify with the same key.
By signing your CSR with your private key, anyone can check that the information in the CSR has not been changed by using the public key in the CSR itself.
The CSR is then submitted to a Certificate Authority (CA) who then creates a certificate based on the information in the CSR, including your public key. The CA then signs the certificate with their own private key. The result is a certificate that proves your public certificate is yours.
Verifying the Certificate
Let’s make this a little more concrete. Let’s say the receiver is a browser on a user’s computer and the sender is a web server.
Ok, so you have a certificate on your web server but how does the browser know a) that this is a valid certificate and b) that the attacker hasn’t created a certificate to look like your web server?
The first step is for the browser to validate the certificate has come from a trusted CA. You may remember that the certificate has been signed by the private key of the CA. Now, all major browsers have a built-in list of certificates from reputable Certificate Authorities that contain the public key that corresponds to the private key the CA uses to sign certificates. This list is known as its trust store.
When the web server sends its certificate to the browser, the browser uses the CA’s public key in its certificate to verify that the web server certificate comes from the CA and has not been changed.
If an attacker creates their own certificate, the browser will not have the attacker’s public key in its list of CA certificates and will reject the response.
Verifying the sender
We now know that the certificate is signed by a known CA but the attacker may have created their own certificate from the CA and pretended to be your web server.
So how is this prevented? When the CSR is submitted the application needs to be vetted to ensure that it is from the entity that it says it is. This vetting is done by a Registration Authority (RA).
There are different levels of vetting that can take place. For example:
- Domain verification
- Organisation verification
- Extended verification
Domain verification uses DNS entries to prove a web server belongs to the domain it claims to be. There are a couple of ways this is done but the idea is to allow as much automation as possible.
Organisation verification may involve the RA contacting you, checking government records (such as business records) and other investigations.
Extended verifications are used by large organisations that are willing to pay for the extensive proof they need to provide to prove they are who they say they are.
Of course, CAs don’t create certificates out of the goodness of their heart (with the exception of Let’s Encrypt) and charge different amounts for different levels of vetting.
Once you have been vetted, the CA is able to sign and issue the certificate. When it comes to using the certificate, you can look at the type of certificate and decide if you want to use it for your purpose.
You now have confidence that the web server sending you information to your browser is who it says it is and you can browse the site safely. The browser will show you a padlock to show it has accepted the certificate and can show you the details of the certificate it received.
Revoking a certificate
For additional security, certificates have an expiry date and browsers will reject an expired certificate. This allows you to generate new certificates periodically, which is always a good security practice.
But what happens if you no longer want to use your certificate? There can be many reasons why this might be the case, almost all of them associated with a cyber breach of some kind. It is important that no one can use your certificate to act or pretend to act as you.
The Public Key Infrastructure (PKI) includes the facility for revoking a certificate. Each CA manages a Certificate Revocation List (CRL) which includes all the certificates that it has issued but that have been revoked. The browser must check to see if the certificate it is validating is included on such a list. If it is, it will be classed as invalid.
Intermediate CA certificates
By now you should understand that the private key of the CA is critical. It if it compromised it would mean that all certificates ever issued by the CA can no longer be trusted and would have to be reissued.
To mitigate this risk, CAs create intermediate CA certificates. These are just like any other certificate but issued with the ability to sign other certificates.
This idea that a certificate can be used to sign another creates a chain of trust. A browser or operating system can now validate the chain from the server’s certificate through one or more intermediate CA certificates to the final root CA certificate.
With a chain the CA can restrict the use of its private key to a limited number of intermediate CA certificates. Now, if an intermediate CA certificate is compromised, it does compromise all certificates.
Self-signed certificates
Anyone can create a private and public key pair. So, if you can do this, what stops you creating a CSR and signing it yourself?
Nothing.
These are known as self-signed certificates. In fact, the root certificate of a trusted CA is just a self-signed certificate created by an organisation that is trusted.
The only thing is that your browser or operating system will not have your self-signed certificate in its trust store and so it will not accept any certificates singed with your self-signed certificate.
Operating systems and browsers do allow you to add certificates to their trust store. There are valid reasons why you might want to do this but generally, distributing your self-signed certificate to everyone who wants to use your service is difficult, especially when you might want to revoke or update it.
Summary
In this guide, I have taken you on a journey to secure your communications. We looked at the difference between encryption and signing and how symmetric and asymmetric keys could be used for both purposes.
We then looked at how Public Key Infrastructure helps with the validation and management of signed certificates.
Look out for my other guides on how to create your own CA and how to use this to create your own secure VPN.
