As we go about our daily lives we use our devices (computers or smartphones) for things like web browsing, online banking, shopping, emailing and connecting VPNs. Our devices connect to the servers that provide these services and we trust them to connect as securely as possible. We want to ensure we are connecting to a legitimate website and not a spoof site setup by a cyber-criminal. We also want the data (which may include usernames and passwords) to be encrypted while being transmitted over the Internet.
It may also be that you need to prove your identity to a server – to authenticate yourself to a VPN server for example.
It is the job of certificates to do this. A certificate provides a method to prove identity and encrypt data. We will look at how certs are created, what they look like, and how they work.
Here’s a real cert from the amazon.co.uk webserver:
The important part of the cert are:
- The Common Name under ‘Issued To’, which should match the address of the server
- The dates between which the cert is valid
- The certificate fingerprint, which proves ID
- The public key, which is used for encryption
The are a few more fields not displayed here that are of interest which we will cover later.
Certificate Creation
Certificates are created by an IT admin. She needs to know what the certificate is being used for – a webserver, VPN server or user ID. She needs to know the name or names of the server that people will use to connect, such as www.amazon.co.uk. If the cert is being used for user authentication she needs to know the username.
There are several different methods to create a certificate – you can apply to an authorised Certificate Authority (CA), setup your own CA on a server, or use a mini-CA in your PC or in a router.
Usually, the IT admin will enter the information above into a form on the server or router which will generate a ‘request’. This is just a small piece of encoded text which is then sent to a CA for checking and processing. The CA returns a certificate, in the form of a file, which she imports into her server, router, or PC. If this sounds complicated, it is. Using a mini-CA is simpler, but the certificate can usually only be used for internal purposes, not for a public webserver, for example.
Technicalities
The CA starts cert creation by generating two numbers that are different but mathematically related. A piece of data based on large prime numbers is fed into a mathematical function which outputs two numbers, known as ‘keys’ or a ‘key pair’. Here is an example of a real key (from the Amazon cert):
| 99d1b441de2999b376adefa9c4838b86afe291ff80c16f5d64ffc588f7afcb1c |
Each key in the pair has a name. One is called the public key and the other the private key. The keys are used to prove ID and encrypt data.
| Key | Encryption | Signing |
|---|---|---|
| Public | Encrypt data | Check signature |
| Private | Decrypt data | Create signature |
Encryption
The public key is used to encrypt data and the private key for decryption. The private key decrypt the data that was encrypted by associated public key (remember the two keys are mathematically related).
The private key is stored securely in the server and is kept secret. The public key is stored in the servers certificate, which is publicly available – see the Amazon cert above. When your device connects to a server it asks for a copy of the cert then uses the public key to encrypt data and send it to the server. The server, which has the private key, decrypts the data.
This is not the whole story regarding how webservers encrypt data. More detail on this below. For now, hold on to these fundamental truths:
- When a certificate is created, two mathematically related keys are also created.
- One key is called the public key and is used for encryption. This key is stored in a cert and is freely available.
- The other key is called called the private key and is used for decryption. This key is stored on the server and is kept secret.
Back to creating our certificate. When a certificate is created the two keys are automatically created with it and stored in their respective locations – private key securely on the server, public key in a freely-available certificate. The certificate is assigned to a server and can then be used by clients when they connect.
That covers data encryption – but what about the other purpose of a cert – ensuring the server really is who it says it is? That the www.natwest.co.uk website really is the NatWest banking site, and not a similarly-named but spoof www.natwest4U.co.uk site setup by a cyber-criminal?
Every cert contains a name. The cert name must match the URL that you use to connect. When you type ‘www.natwest.co.uk’ in your browser (or click on a link) your device connects, asks for the certificate, and checks that the name on the cert is the same as the URL in your bowser. If the name is incorrect, your device errors.
This prevents a cyber-criminal from setting up a spoof website named www.natwest4U.co.uk that looked just like the legitimate site, adding a cert named www.natwest.co.uk, and interfering with your computer so that you are redirected to his site instead of the legitimate site. If your device notices the difference between the browser URL and certificate name it does not connect and displays an error.
But what stops a cyber-criminal from creating his own cert with the legitimate name? Certificates are issued by well-known and trusted authorities such as DigiCert, Sectigo, and Let’s Encrypt. If you want a cert for your webserver you submit an application to an authority who will, after payment of a fee, check your validity and issue you with a cert. In this case they will check that you really are representing NatWest and that you control the domain name natwest.co.uk. If they are happy, you get your cert. A cyber-criminal cannot obtain a cert using any natwest.co.uk name. When connecting, your device checks that the cert was issued by one of these trusted authorities by looking at the ‘Issued By’ field in the cert (see the samlple cert above). If it cannot verify this trust, it does not connect and displays an error.
Lastly – what stops a cyber-criminal from creating a cert with the name of a legitimate Issuer? Well, this is the heart of the matter, and is another dollop of cunning on an already cunning-rich pie.
Introducing hashing, signing, and the ‘Trusted Root Certificate Store’ on your (and indeed everyone’s) computer.
A cert is a piece if digital data that, once issued, never changes (at least, not normally). The data is always the same length and always has the same content. Hashing is a way of proving that the data has not changed. It invloves feeding the data into a mathematical function, which produces a small piece of data that is representative of the original. I’ll try and represent this with a diagram:
Reference
Encryption and decryption using keys
Imagine taking a piece of raw data, adding the public key and feeding it into an encrypting app. The output looks like gobbledegook but is actually the original data that has been encrypted by a sophisticated mathematical function. So, raw data + key = gobbledegook. (NB this example is for illustration, using shortened key).
| raw data: | + encryption key: | = encrypted output: |
|---|---|---|
| The quick brown fox | 30 82 01 0a 02 82 01 01 00 b3 88 79 | VGhlIHF1aWNrIGJyb3duIGZveA |
The encrypted data can now be safely sent over the Internet to the recipient. An eavesdropper would see only gobbledegook and would be unable to decrypt the contents because he does not have the private key. The recipient, however, is able to remove the encryption using the private key. So, gobbledegook – decryption key = raw data.
| encrypted data | – decryption key | = raw output |
|---|---|---|
| VGhlIHF1aWNrIGJyb3duIGZveA | 6a 57 8e 86 b1 bd 20 44 98 c2 4e 60 | The quick brown fox |
How does the recipient get the private key? Well, he owns it. The way it works is this: The server owns the key pair. The private key is secret and is stored securely. The public key is stored in a certificate that can be given to any device trying to connect. As your device connects it requests the public key, encrypts your data and sends it back to the server. The server, which owns the private key, decrypts your data. And there a a piece of cunning, if ever there was one.
Many readers may have noticed that this explanation only encrypts data in one direction. Two-way encryption uses the above techniques but requires a piece of uber-cunning that we shall visit later.
Hashing and signing
This is a very simplified illustration of how hashing works, but the idea of dividing data into blocks and performing a mathematical function on the blocks is valid.
- Take a piece of data – in this case the phrase ‘The quick brown fox’
- Divide it into fixed-size blocks (in this case blocks of 4 bytes). Pad the end with spaces.
- Using the numerical value of each byte, sum each row (I used the UNICODE() function in Excel)
- The resulting column is a hash and can be expressed as 321-434-351-372-365
- Store the hash with, but in a separate section from, the original data
- Anytime you want to check the integrity of the data, just recalculate the hash and compare with the stored value. If they are the same, the data is unchanged.
- Now see what happens if the data is changed to ‘The slow brown fox’. The calculated hash is different from the stored hash – you know that the data has changed!
What is to stop the data being changed AND a new hash stored? Introducing…
Signing
Signing takes hashing one step further. The hash encrypted with the server’s private key (yes – signing uses the keys the opposite way around from encryption). This little piece of data is known as a signature and is stored with the original data.
Now, the recipient of this piece of data cannot decrypt the signature – he does not have the private key. But what he can do is re-hash the data, and use the public key to encrypt his hash. If he gets the same signature he knows that the data is unchanged.
The cyber-criminal cannot change the data without his actions being discovered. He does not have the correct private key. if he uses his private key, the signature would be incorrect.