Public Key Infrastructure (PKI)

What public key infrastructure is

Public key infrastructure is not an end-all be-all, in that there are still ways to trick people into going to the wrong site. However, what this does is it really does a lot of safeguarding to make sure that we make it to the right site, and that the site is verified, and that the site has a certain amount of encryption and security back and forth.

Public key infrastructure really is all about managing digital certificates — managing the digital certificates that help us verify sites and help verify authenticity with all sorts of data communication. That is what public key infrastructure is. It's all the documentation, it's all the standards, it's all the different processes that this goes through, it's all of the servers, it's all the applications that go into managing these digital certificates.

There are a lot of different applications when it comes to PKI, things like digital signatures or code verification. There are a lot of areas that we can apply this to, but essentially it all revolves around communication — communication between possibly an end user and some sort of service that they're trying to access — so that they're not being redirected to another set of servers that are mimicking these servers to trick that user. We want a certain amount of authenticity, that it is coming from the source that it should be coming from.

A look in the browser

I'm on a browser and I'm on the techknowsurge.com website. Specifically, this is the newsletter sign up. The thing is that anybody could actually mimic this page right here. They could even mimic the URL — that's really easy to do. But I know this is coming from the actual techknowsurge.com, and I know that because of this lock that appears to the left-hand side.

Whenever you see the lock to the left of the URL, it's telling you two different things. Number one, it's telling you that wherever you're at — in this case it's techknowsurge.com — that that is the actual techknowsurge.com, that you're on the actual site. The other thing that it's telling you is that you have a secure communication between that site and your browser. That's important because you don't want anybody to alter this information or change the code, therefore compromising this site. So it is secure, it's encrypted back and forth.

I can actually see more details if I click on this lock. It says connection is secure, and I can click on that to find out more. It says certificate is valid, and I can actually open up the certificate. The certificate is what's actually validating the authenticity of the site, that it's actually coming from the techknowsurge.com servers, and it verifies this is from techknowsurge.com, and it's verifying it through Let's Encrypt.

The elements PKI uses

Before we go into the process of how it does that verification, let's start out by just going over a few elements that it uses, to make sure that we have that base foundation. I'm going to go over this quickly because I do cover this much more in depth elsewhere.

First of all, it does use public key cryptography. Public key cryptography is that public/private key pair, and you can encrypt a message with a private key and decrypt it with a public key. That's really critical to this whole process.

There's also a digital certificate — I showed you one in that example on the browser. The digital certificate has some information in it. Number one, it has the public key. So what you're receiving is not actually just the public key by itself; you're receiving the digital certificate, which has the public key inside of it. You also have a lot of information like when does this key expire, and what site is it for, and who is it verified by.

Public key infrastructure also utilizes hashes. A hash is that one-way algorithm where you get a unique fingerprint from data. So we can pump in a bunch of data — in this case right here it's actually pumping in all of the data of this certificate — and it's going into a fingerprint that's included then on this certificate, and that fingerprint is a representation of all of the data that's inside of that certificate.

Public key infrastructure utilizes a certificate authority. A certificate authority is going to be a third party that is actually going to verify a server. This user wants to make sure that they're accessing the correct server, but how is it going to trust a server that it's never accessed before? What's going to happen is this user is going to trust the certificate authority, and if the user trusts the certificate authority, and the certificate authority trusts this set of servers right here, then this user will trust this server right here. That's what the certificate authority is there for; it's that verification step.

So how would a certificate authority trust some sort of servers or some sort of source? What's going to happen is we're actually going to use a registration authority. The set of servers is going to turn in some data to a registration authority, and that registration authority is going to go through a process to confirm that this is legitimate. From there, once this registration authority gives the thumbs up to the CA, the CA will then trust this server. It looks a little different when we get into the process, but essentially that's what's happening here.

There is another certificate that's involved here and I want to cover what that certificate is. It's the one from the certificate authority. What that looks like here is we have a certificate from techknowsurge.com, and that certificate has the public key that aligns with the private key of these servers right here, the techknowsurge.com servers. So that is one certificate that we're going to be looking at. But there's another one here: there is a certificate that's actually already on your computer that's coming from some sort of root certificate authority, that has a public key that aligns with a private key of a certificate authority.

The verification steps

How do we go through this verification? Really there are two things that we need to verify in this process. First of all, we need to verify this digital certificate, to make sure that it's authentic — that this is the website, this is the public key associated with that website, and this is all of the information that's associated with that digital certificate. Make sure that digital certificate is authentic. That's the first thing. Second of all is the data that comes to us: we want to verify that that data is authentic.

So how are we going to verify a certificate? Within the certificate it's got a lot of different information, of which one is what the certificate authority is. This user, this machine, already trusts this certificate authority. In fact, it already has the certificate associated with that certificate authority on that machine already, and within there is the public key that's associated with the private key from that certificate authority.

What has happened ahead of time is that the fingerprint for this digital certificate was encrypted with this private key. So now, if I use this public key to decrypt this fingerprint, and then I perform another hashing algorithm on the rest of the certificate to find out the fingerprint of the certificate that I was given, and if these two are equal, then I know that this digital certificate was encrypted with the key associated with the public key that I have, that I know that I can trust. Therefore, now I can trust this certificate.

The second step to this is verifying the traffic that's actually coming to me, and I can do this pretty easily, because now I trust this certificate. I can use this public key right here to decrypt the data, and if that data gets decrypted correctly then I know that it's been encrypted with a proper private key, meaning that it came from the proper source.

The process

Now I have the TechKnowSurge website that's being hosted on some servers. I want to make sure users that are getting to my site can make sure that they're getting the correct information, that it's both secure and coming from the accurate source.

So what I'm going to do is first of all generate a key pair, that is going to be a private and a public key. I'm going to take the public key and turn that into a CSR, which is a certificate signing request. This is what I'm going to actually use to make a request for a digital certificate.

The next step in the process is to take that CSR that has the key in it and turn it in to the registration authority, the RA. Often that looks like you're just going to a CA and turning it in to the CA, and the CA has some sort of built-in RA involved in it. But the big key here is that you are going to have to verify who you are — not anybody can just say, yeah, I'm techknowsurge.com, and get a certificate for that site. Not just anybody can do that. They have to go through some verification that they actually own that domain.

Once that domain has been verified, that CSR gets turned in to the certificate authority. That certificate authority is going to generate a certificate. The certificate includes things like the URL, includes information about the certificate authority, includes the public key — it has a lot of information within it. Then what it will do is it'll create a hash of that information, that fingerprint of all of that information, then it will encrypt that hash and put it back onto the certificate. Now that encrypted fingerprint is on the certificate.

That certificate then gets shipped back to the requestor, whoever turned that CSR in, and then that certificate gets installed onto this server. So now this server has the private key that it originally had, with a certificate that includes the public key, and now the encrypted fingerprint of that was encrypted using the CA.

So what happens is, now a user will connect to the website, and one of the things that it will download is this certificate. So now this user has this certificate. Then what that computer would do is it would hash the information within that certificate, creating that unique fingerprint. It could also take the public key from that certificate authority and decrypt the fingerprint that's on that digital certificate. As long as these two fingerprints match, then it knows that it's been encrypted with this private key that is from that trusted source, and therefore this is a verified certificate.

So now all we need to do is verify the traffic, and we do that by, when the traffic comes in, we can decrypt it with this public key. As long as we can decrypt it with the public key, we know that it's been encrypted with the associated private key.

One thing to note is that these private keys need to stay private. That is, this private key that's associated with these services that are being provided — if that were to ever get out, then somebody could use that to set up a parallel system and be able to trick end users into thinking that that is the actual site. It could be devastating to the end users, it could be devastating to your company or your organization or whatever website that this is hosting for. So it's really important that you keep these private keys private.

Where PKI is used

One of the questions might be, okay, this is public key infrastructure, it does authenticity to verify where this source is, where it's coming from — so where do we use this? There are a lot of places we can use this. Websites and web services was my primary example right here, but it could be used with apps and APIs and emails and digital signatures and code signing and federation services and VPNs. There's just a whole host of different ways that we can actually use this for authenticity purposes.