PKI (or Public Key Infrastructure)
Perhaps better posted in r/programming but figured i’d try here.
In: Technology
So, to start with, we need to encrypt some data. Why? Maybe you’re cheating on your wife. Maybe you’re buying her a surprise.
Whatever, you want to hide your communication from prying eyes.
So, we can agree method to do so.
Perhaps we’re going to talk in French. Or maybe we’ll use a simple, home made method. We’ll move each letter one place to the right on our keyboards (wrapping to the left, when we reach the end).
So, rmvtqyopm od vppl! Tophjt?
The above message was written using a standard U.K. iPhone keyboard. Decrypt it!
Simply put, encryption is taking some data, and transforming it in such a way that it can only be returned to to its original form by following a set of instructions.
In the real world, we use huge mathematical problems which are really easy to do one way, but really hard the other. Think “multiply x by y to get the answer”, where both x and y are *huge* prime numbers.
The issue there is, we need to negotiate our method of translation in the public space of the internet. Back in the day, one might just have left it in an envelope in a crack in the wall, but we can’t do that anymore. There’s no hidden walls on the internet that you can tuck an envelope into and be certain no one can find it.
Introduce, public key encryption.
We negotiate a mutually *shared secret*, using a combination of our *public* and *private keys*. Professor Mike Pound on the YT channel Computerphile has done an excellent video on public key exchanges, and I don’t want to butcher his explanation, so I’d suggest watching that, but the simple version is; using a mix of our public and private keys, we encrypt data.
On to PKI. This gets messy, so strap in.
So, to start with, we have a *certificate authority*, which we’ll call Root CA. Because he’s the Root of our Tree.
The Root CA is something, or someone, we’ve decided is trustworthy. How we philosophically trust that entity isn’t the issue here.
A root CA, commercial or otherwise, issues a *certificate*, which they have *signed*, using their *private key*. The certificate contains the Root CA’s *public key*. A signed certificate is a technical method of saying “I trust that this person is who they say they are”. For example, Google will trust YouTube, and so will sign a certificate, and issue it.
The next person (YouTube, in this case) will send this certificate out to anyone who asks for it, and when you look at it, you’ll see “YouTube, certified by Google”. Literally, go to YouTube and click the padlock, then view Certificate Path (or chain, depending on browser).
From that point, your browser will check its “people I trust” list (Trusted Certificate Authorities, they come pre bundled with the browser and/or operating system).
If the Chrome finds YouTube on its “people I trust” list, it will say “yep, ok” and begins using the encryption method that the certificate has instructed it to (the public key which it found on the certificate).
At this point, you’ve begun an encrypted channel of communication between server (YouTube) and client (you).
All because you implicitly trust Microsoft, who also implicitly trusts Google, who trusts YouTube.
So, You >>trusts>>Microsoft>>trusts>>YouTube.
What happens if Chrome can’t find it on the “people I trust” list? Well, it can look at the “people I don’t trust” list (Certificate Revocation List, CRL for short).
If any of the members of the chain are on the list, we don’t trust it, which means we get the “This connection is not trusted/secure” error.
Okay, so how does this apply in the real world?
Well, when you start a website, by default, *no one will trust you*. Which means *everyone* will get an error warning them of a not secure connection. Bad news. I won’t enter my credit card details into that.
You approach a Public CA and ask them to sign your certificate (a Certificate Signing Request, or CSR) – lets say you approach GlobalSign.
They ask you to prove you’re trustworthy, and then you receive your certificate, which you can then photocopy and staple to the back of your own, which you’ll send out.
So your customer>>trusts>>Microsoft>>trusts>>GlobalSign>>trusts>>www.opswebsite.com.
Your customers now have an encrypted channel to use when they’re ordering all the hentai you sell. Grand.
I have an envelope with a secret message that I want to send you. My goal is to ensure only you can open the envelope and read it.
You and I both have a unique lock and its key each. What I do, is seal the envelope with your lock and send it to you. Only you have the key to open that lock. The envelope can reach anyone in the middle but they cannot snoop into it.
Now you received a random envelope with your lock on it. How will you know who sent it and what’s the guarantee that I sent the letter and not someone else pretending to be me? To fix this, what I also do is stick my key on the envelope as well. Now if that key is able to open my lock then you know for sure that I sent you the envelope.
In the real world, the “lock” is known as a public key. Every door has a lock but only it’s corresponding key can open it. The “key” which opens a lock is known as a “private” key. The key is not supposed to be shared with anyone. If I have the key then I can open the lock and pretend to be you.
You might ask why would you stick the key to the letter and send it? In real life, you don’t do that. You use your key to do some magic to ensure that only your lock is able to recognize said magic.
Also note this is highly ELI5’d
So, public key encryption works because of these funny little math equations that are unidirectional – you can put a number into the equation and get a result, but you _can’t_ have the result, do the equation in reverse and get the original number back. The only way to get the original number back is to use a second equation that is capable of taking the result and giving you back the original number.
The specifics of how this works are beyond an ELI5 (and something I don’t fully understand, TBH).
So, public/private key encryption uses these equations to allow secure communications. You publish one of they two equations (the public key) and tell folks, “Use this key to encrypt your transmissions to me”. They then send you encrypted data from that key. You take that data and run it through the second equation, which you have kept to yourself (the private key) and decode it. This works because, thanks to those one-way equations, people can intercept the encrypted data and can’t do anything with it, even if they have the key that was used to encrypt it.
This also works in reverse – you can publish data encrypted with your private key and say, “Use this data to verify I am who I say I am” – since anyone can access the public key, they can decrypt the data packet and verify that you do in fact hold the private key for that pair and you are who you say you are. This is how browsers know when a fishing attack is going on – the fake website can’t produce the right data packet for the official public key.
Latest Answers