Understanding Public Key Infrastructure Basics
Key Points
- The episode introduces public key infrastructure (PKI) by recounting a real‑world scenario of setting up a website’s HTTPS lock icon and the steps involved: generating a key pair, creating a certificate request, obtaining a certificate from a CA, and installing it on the server.
- Jeff explains that PKI relies on asymmetric cryptography, where a public and a private key are mathematically linked so that data encrypted with one can only be decrypted with the other.
- The private key must be kept secret; best practice is to store it securely—ideally in a hardware secure enclave that never exposes the key to the operating system or administrators.
- The public key is meant to be openly distributed; knowing it does not allow an attacker to derive the private key, enabling anyone to encrypt data for the key holder or verify signatures.
- A common misconception is clarified: the choice of which key is used for encryption versus decryption is arbitrary—the mathematics work either way, so the “public” key isn’t limited to decryption only.
Sections
- Understanding PKI Through a Web Setup - A host shares their experience obtaining an SSL certificate for a website and asks a security expert to clarify public key infrastructure and how asymmetric key pairs work.
- Symmetric vs Asymmetric Encryption Overview - The speaker contrasts symmetric cryptography, which uses a single shared key that is fast but hard to distribute securely, with asymmetric cryptography, which uses paired public and private keys to safely exchange the symmetric key despite slower performance.
- Understanding Certificate Authority Chain - The speaker explains how a trusted third‑party Certificate Authority issues digitally signed certificates that form a hierarchical chain of trust, allowing users to verify authenticity without directly trusting each individual party.
Full Transcript
# Understanding Public Key Infrastructure Basics **Source:** [https://www.youtube.com/watch?v=0ctat6RBrFo](https://www.youtube.com/watch?v=0ctat6RBrFo) **Duration:** 00:09:18 ## Summary - The episode introduces public key infrastructure (PKI) by recounting a real‑world scenario of setting up a website’s HTTPS lock icon and the steps involved: generating a key pair, creating a certificate request, obtaining a certificate from a CA, and installing it on the server. - Jeff explains that PKI relies on asymmetric cryptography, where a public and a private key are mathematically linked so that data encrypted with one can only be decrypted with the other. - The private key must be kept secret; best practice is to store it securely—ideally in a hardware secure enclave that never exposes the key to the operating system or administrators. - The public key is meant to be openly distributed; knowing it does not allow an attacker to derive the private key, enabling anyone to encrypt data for the key holder or verify signatures. - A common misconception is clarified: the choice of which key is used for encryption versus decryption is arbitrary—the mathematics work either way, so the “public” key isn’t limited to decryption only. ## Sections - [00:00:00](https://www.youtube.com/watch?v=0ctat6RBrFo&t=0s) **Understanding PKI Through a Web Setup** - A host shares their experience obtaining an SSL certificate for a website and asks a security expert to clarify public key infrastructure and how asymmetric key pairs work. - [00:03:02](https://www.youtube.com/watch?v=0ctat6RBrFo&t=182s) **Symmetric vs Asymmetric Encryption Overview** - The speaker contrasts symmetric cryptography, which uses a single shared key that is fast but hard to distribute securely, with asymmetric cryptography, which uses paired public and private keys to safely exchange the symmetric key despite slower performance. - [00:06:13](https://www.youtube.com/watch?v=0ctat6RBrFo&t=373s) **Understanding Certificate Authority Chain** - The speaker explains how a trusted third‑party Certificate Authority issues digitally signed certificates that form a hierarchical chain of trust, allowing users to verify authenticity without directly trusting each individual party. ## Full Transcript
Welcome to Tech Talk.
Today's topic is public key infrastructure.
Before we finish, you're going to know what it is, why it's important and how it works.
And with me is Jeff, the security guy.
I want to explain why I wanted to pick up this topic.
Last week I was setting up a web site and I wanted to get a lock icon that people expect in the web browsers. Right?
Because if you don't see that -- in fact, some web browsers, they put up a warning
and say "Hey, are you sure you want to do this?" This could be sketchy, right?
And so I was going through those steps and I pretty much just followed a run book
and that involved first generating like a public and private key.
And then from there I created a certificate request which I sent to a certificate authority.
And then finally I got my certificate, which I then installed on the web server.
But I really didn't understand how it worked.
And so can you explain that to me?
Yeah, sure.
So one of the things that was happening when you did this is you generated this key pair, public and private key.
Well, there's this thing that we call asymmetric cryptography.
Asymmetric
...because there's two keys involved.
They're mathematically related with this special property that whatever you do with one of the keys,
you can only undo with the other.
So if you encrypt the message with one of the keys, then you can only decrypt the message with the other, and vice versa.
Then what you're doing is you arbitrarily choose one of those and say "This one is my private key.
I am going to guard that like the keys to Fort Knox."
It's going to be super secure.
I'm not going to tell anyone.
In my case, I ended up putting it in as a root user.
It was only accessible that way.
Sure. That's a typical way if you're storing it from a software perspective.
An even more secure way to do it would be to store it in hardware on a secure enclave --
a special chip that never even exposes the key to the storage.
Or even the admin, for that matter.
Exactly. No one can see it.
It stays only inside there, and all of its operations are performed in the secure chip.
Got it.
So let's go on then.
So there's a private key.
That one you keep totally secret.
The public key is just the opposite.
You tell the entire world. You don't care who knows what your public key is.
Because the beauty of asymmetric cryptography is that even if someone knows this,
they have no way to reverse engineer practically to get to that.
So giving that public key information out basically tells the world how they can communicate with you,
but doesn't reveal anything about your private key.
A little true confession here:
I have to admit that I always thought a public key was just doing for decryption, and the other words used for encryption.
Yeah.
You're saying that's not true?
It's not true.
It's a reasonable assumption, but it's not the case.
In fact, the math behind this doesn't know which one you chose is public or private.
It doesn't care.
You encrypt with one, you decrypt with the other.
And it's an arbitrary decision at the time that you designate which is which.
Before we leave that, what would symmetric encryption come into play here?
Yeah. So symmetric cryptography is similar, but different.
With asymmetric we have two keys.
That's the asymmetry.
One's public, one's private.
With symmetric.
We have only one key.
That one key is used to encrypt.
That one key is used to decrypt.
Does double duty.
Exactly.
So it's symmetric.
It has symmetry.
It's the same key on both sides.
If I send you a message that I've encrypted with this particular symmetric key,
the only way you can decrypt it is to use the very same symmetric key.
But that presents a problem for me getting that symmetric key to you, doesn't it?
It absolutely does.
So the advantage to symmetric key cryptography is that it's relatively efficient.
It's fast compared to asymmetric, which is much, much slower.
The downside with symmetric is exactly the problem you said.
If I generate a key and I encrypt a message with it, now I need a way for you to know what that key is.
And if I just sent you the key in an email, someone might intercept it.
If I come up with some other kinds of means to send that to you, then there are all different kinds of problems.
So that's why we use asymmetric cryptography as a way to communicate and transmit the symmetric key.
Oh, I see.
So, for example, if I wanted to get you the symmetric key, I first encrypt it with an asymmetric key.
Send that to you, and then you can decrypt it with my public key.
Exactly.
And then I see.
And then I can you have that now, that symmetric key that we can then use to do fast exchanges.
Exactly.
Okay.
So this is why you can use both, and each one for what it's good for.
So the PKI, the public key infrastructure part, refers to this asymmetric.
And what that really solves for us is the key distribution problem that was left over by using symmetric key cryptography.
Okay, great.
I got that.
So I have that now.
My public private key, I've done my certificate request, which has a bunch of information like the website you're going to use,
the admin contact information, stuff like that.
I fill out that certificate request and it goes to a certificate authority and I get finally my certificate.
What is going on in this certificate that is going to work back on my web server?
What's going on behind the scenes?
So it's important to understand that the main thing that's in your certificate is this: your public key.
That's the information, and the certificate is the way of conveying that.
The certifcate is a way that is a trustworthy way of conveying to the world what your public key is.
Because if I want to send you that message that only you can get, then I've got to encrypt it with your public key.
But how do I know what your public key is?
I'm going to take it from your certificate.
And the certificate authority, which was given my public key, how do they verify, like when I create my web browser,
how does it verify that this actually came from them?
Yeah.
So it's going to ask a bunch of questions and it's going to populate the certificate with your answers to those questions.
But ultimately, if the certificate authority, this guy right here that we refer to as a trusted third party,
the certificate authority is someone that you trust and someone that I trust.
So I don't have to trust you.
I just have to trust the certificate authority that the certificate it gave me is in fact yours.
When you click that log lock icon, it actually shows you a list of all the authorities that were used to authenticate that.
And it shows a trust, a chain of ...
A chain of trust.
Exactly. Because you may have multiple certificate authorities, this certificate authority is trusted by another, is trusted by another, and so forth.
As long as all of those chain of certificate authorities trust each other, then the certs that they issue will be trusted as well.
And I don't have to go back to the certificate authority for each browser request, right?
In fact, you don't.
That's the beauty of this.
You could store all of these in a central database and that could be at the certificate authority.
But it doesn't have to be.
You could, in fact, store these certificates anywhere.
I could send it to you in an email.
It doesn't matter how I get it to you, as long as I get it to you.
The information in here is secure and we know it's secure because it was vouched for by the CA.
So they had a signature on it.
That's where we get this thing we call a digital signature.
Right?
I've heard that phrase used quite a bit.
Can you explained that to me?
Yeah.
So with a digital signature, that's the way the CA, once it's been satisfied that this is in fact your actual cert,
and that that is in fact your public key, and you are in fact who you claim to be,
then the CA will basically sign that all of these things are true.
The way it does that is it runs a special algorithm against the cert, a thing called a hash.
So we have a hashing algorithm that's run that summarizes the information here.
If anything changes in here, the hash value would change dramatically.
So the CA runs this hash to verify what the message is.
Then it uses, guess what?
It's private key to encrypt that hash value.
Which I can then decrypt with ...
Yes.
The public key.
Exactly.
You know, the CA's public key because it's baked into your browser in advance.
So that's how the whole process bootstrapped.
And so we're using the same techniques that we're using to communicate the keys.
We're using that same PKI infrastructure in order to do digital signing and in order to create a system of trust.
I think we've covered it now.
That was the how, the why, and the what.
So there it is, we're gonna wrap on that.
If you'd like to see more tech talks, maybe with Jeff, or on other topics, be sure and leave us a comment below.
And also please remember to subscribe so we can keep bringing you cool content like this.
Thanks for watching.
If you'd like to see more videos like this in the future, please click Like and Subscribe.