Authentication and Encryption

Caveat Emptor: I am not an expert in asymmetric cryptography or certificate generation.  If you spot an error or oversimplification, I would be very grateful if you would point it out so that I can learn from it!

Over the years, so many of my students have readily grasped the concept of encryption but still struggled with the equally important idea of authentication.  I mean, it's great that no third party can snoop on your messages, but what if you are sending your message to the wrong person?  How do you know who is communicating with you?

This is covered (albeit briefly) in AQA A-Level in terms of server certificates, but it is deeply technical and it misses the broader context of identity and trust on the internet.

Commercial Certificate Authorities

When a company applies for a certificate from a commercial certificate authority (CA), they need to provide a lot of identifying information, including a real-world address.  These details provide some guarantee to the CA that the company really is who they say they are.

When the company receives their certificate, they can install it in their servers (e.g. web servers).  Web browsers using https can then check this certificate against the domain you navigated to and the public key of the CA.  If it all goes well, the browser can display a nice, comforting green padlock.

Through this process, the person browsing the web can have some confidence they are actually communicating with the intended company.

NOTE: the browser is pre-configured to trust a set of known certificate authorities.  If an attacker can add a CA to this list, they can completely undermine the security of https even though all your web traffic is still encrypted!

Let's Encrypt

A problem here is that if you cannot (or do not want to) pay for a certificate, https does not allow you to encrypt traffic to/from your web server.  Let's Encrypt provides a service free-of-charge where they issue certificates to anyone who can prove they control the domain name the certificate is for. 

When you apply for a certificate, you supply the domain name.  Let's Encrypt then give you a specially generated file to put on your web server.  If Let's Encrypt can then download that same file via your domain name, they will be satisfied you are the person who controls it and they will issue you a certificate.

This will result in the same comforting green padlock on a user's web browser, even though nobody has actually checked who you are.  The benefit is that more of the world's web sites can use encrypted traffic; the cost is the lowering of confidence in a site owner's actual identity.

NOTE: if someone could attack the DNS registry, this opens the possibility of getting a certificate for someone else's domain.  DNS is a crucial part of https security!

Connections vs Content

Today's web is set up to verify the identity of the computer/person at the other end of a network connection.  However, with the increasing prevalence of deep faked content, I can see it becoming vital that individual videos and images also have some kind of creator-authentication.  How about a green padlock in your browser to show the video/image on a website was actually created by the BBC or Netflix?

Rather than an individual having to pro-actively publicise that deep-fake content is not actually them, they would have a mechanism to sign content that is actually them.  This would shift the burden of proof - if it doesn't have the green padlock, it's probably not genuine.

...and back to the KS4 Programme of Study

Authentication and identity are going to become more and more important as we wrestle with the issues surrounding generative AI and the modern web.  It is absolutely vital that we treat these with as much importance as encryption if we want to empower our students to make informed judgements about them.