By Will Young, Solution Architect, UnderwriteMe

The last blog post talked about Clifford Cocks and his secret formula, which let you encrypt text so nobody else could read it and decrypt the text if you were the intended recipient. If also provided a means to sign some text to prove that it wasn’t forged and a means to verify that signature.

But a mathematical formula doesn’t create software services. It’s one thing to have a formula for something, but nobody wants to do a math problem every time they log on to the internet. How do we at UnderwriteMe translate the formula into a secure SaaS offering?

Most of the time, when you go to a website, you assume it’s secure. But how do you know that the Amazon website that you entered your bank card details for isn’t someone pretending to be Amazon, and that book isn’t going to ever arrive?

Thanks to Cocks and RSA, a website can send you a note proving that they really are who they say they are. You can take their public key and verify this. But how do you know that their public key really is their public key? If a malicious actor could fake a website, couldn’t they fake the public key too? Moreover, if you encrypted something with the wrong public key, then an attacker could decrypt your message, re-encrypt it for the intended recipient, and you would have no way of knowing that your secrets weren’t safe. This problem leads to a class of security problems known as a Man in the Middle Attacks. If you don’t know for sure that you have the right public key, you can’t be sure at all that you have a secure connection. And if you don’t have a secure connection, a hacker could steal your credit card or read medical data.

In the example below, Alice is sending a message to Bob. There’s a bad actor, however. We’ll call her Mallory, and she wants to read the encrypted message that Alice is sending. When Bob sends his public key to Alice, Mallory intercepts the message, and replaces Bob’s public key with her own (1). Alice doesn’t realise this, since it’s the first time she has communicated with Bob, so he has to send his public key before they can communicate securely.

Next, when Alice sends the message, Mallory intercepts it. It’s encrypted using Malloy’s public key, so Mallory can decrypt it (2). Mallory now reads and re-encrypts the message, this time using Bob’s public key, and sends it to Bob (3). Mallory is able to read the message even though both Alice and Bob think the message has been sent securely.

Using a public and private key solved one problem, namely, how to send an encrypted message without sending over a key that could decrypt that message. But it also created a new problem: how do you know that the public key that you’ve received is genuine?

To solve this problem, Taher El Gamal, working at Netscape, developed SSL, or the Secure Sockets Layer. This was revised in later iterations to TLS, or Transport Layer Security. Netscape, later Mozilla and then Firefox, is a browser company created much of the Internet as we know it today. Some ideas, like displaying graphics, made the Internet accessible and exciting for new audiences. Other inventions, like the blink tag, were less successful.

If it weren’t for SSL, the Internet would still be great for sharing cat memes but wouldn’t be the business and commerce tool that it is today. If you knew the site that you were going to and had a way of communicating with them other than a web browser, then you could be sure that you had the correct key. But how could you get a key for a server that you just heard about? Once again, there is a chicken-and-egg problem.

El Gamal’s solution was to use the browser to establish a trust relationship. If you have a public key that you know is valid – originally this came from meeting someone in person to view their keys – then the holder of the public key that you know is valid could sign the keys that you didn’t know were valid. Those keys could then sign other keys, creating a “trust relationship” between the keys. If you trusted that the original key was valid, then you trust that the other keys were genuine, too.

If the browser was distributed with a set of trusted public keys, then those keys could be used to certify the validity of other keys. The private keys would sign and provide a “certificate” that proved that the certificate belonged to the appropriate person or organisation.

This would form a chain of certificates, from the top “root” certificates, issued by a Certificate Authority, or CA. The top certificates would provide a signature for the next certificate, showing it was valid. The next certificate would provide a signature for the certificate below, and so forth, until you got to a certificate for the website that you’re using.

In the diagram below, the Root Certificate Authority (far left) uses its private key to sign the Intermediate Certificate Authority’s public key. The Intermediate certificate authority uses its private key to sign the public key for a website, in this case www.underwriteme.com. Alice’s browser has the public key for the Root Certificate Authority, so she can verify that the public key that’s been presented as belonging to www.underwriteme.com is a real public key, and not one that an attacker forged.

For most websites, there are three links in this chain. There’s a root certificate at the top, that comes with the browser. These certificates are really hard to change, because it requires a browser update. That’s something everyone should do on a regular basis, but unfortunately, not everyone does do. So, the root certificate will sign an intermediate keyset, and this set of keys is used to prove that the website that you’re viewing isn’t being run by an imposter.

You can actually see this on your browser. When you go to the UnderwriteMe website, there’s a lock next to the address. This tells you that the website is secure, and that all the certificates used are valid and consistent.

Depending on which browser and type of computer you have, you need to right-click and possibly follow some prompts, but there will be a link to view certificate details.

In our case, the ISRG Root X1 certificate (marketing really aren’t involved in naming these) has signed the R3 certificate, and this certificate has signed the certificate that we use to allow you to securely communicate with us.

This lets your browser know that it has the right public key and is securely communicating with us. When you – or one of your applications – is calling our production services, like Decision Platform, there’s a different certificate, but the same process is happing under the hood. Your data is private every time, and without anyone having to do any math problems.