PKI Bootcamp - What is a PKI?

hi this is Paul Turner with meni and today we're going to talk about public key infrastructure or pki as it's commonly called may have heard this term and wondered what is a pki so let's get

into this to do this what we're going to do is we're going to walk through kind of a scenario where we've got Bob here he's got a web server we'll we'll call his uh website bob.com we got Sally and

she wants to connect up to that website she's going to put in her password and so Bob and she want to make sure that that's secure so Bob's going to go get a certificate

for that website for bob.com so he goes to a certificate Authority and uh says hey I'd like to get a certificate and the certificate Authority needs to

verify that Bob is actually allowed to request a certificate for bob.com and so somebody needs to check that out or there needs to be some automated process for that and the role that's assigned

for doing this is called a registration Authority this can either be a person or it can be an automated process and what that registration Authority is responsible for is ensuring that Bob is

allowed to request certificates for that particular domain that they have control over that domain or he has control over that domain once the registration Authority does that then the they'll

give approval to the certificate Authority and the certificate Authority will issue a certificate it's not typically through the registration Authority as I've shown here it was just easier for me to get everything on the

slide showing it that way now once the certificate has been issued just to cover terminology the web server to which that certificate has been issued is the subject of that certificate a lot

like when you have a book and uh there's a character who's the subject of that book this in this case the web server is the subject of this particular

certificate now when Sally connects up to uh the website now the server will turn around and return its certificate and she's going to rely on that certificate right she's let's say she's

connecting for the first time she gets a certificate back and what she's really looking to ensure is that she's connected up to the right website that she's not going to be giving her

password and other information to some Rogue website so she's relying on that certificate and in that context we call her the relying party and this is very broadly used terminology in the industry

to call her the relying party because she's relying on that certificate now next you might ask yourself okay so she's getting this certificate how does she know that that certificate's authentic it's just you know this

electronic document in a sense that she's received and she does in fact needs something from the certificate Authority that she can use to validate that in fact as we'll talk about in a

future segment she needs to use their certificate or public key to verify the signature on that particular certificate and you might think to yourself okay so every time that she's going up to get a

certificate now she needs to find the relevant certificate author connect to them and then whatever they're going to provide she's going to trust well not really it turns out that what happens is

that the certificate authorities work with software manufacturers whether it be Microsoft Google Mozilla Oracle with Java the certificate authorities work

with them to embed their certificates what are ultimately called brot certificates we'll talk about that in a moment into software and so this process of validating certificates is actually

facilitating by the software manufacturers putting the relevant certificate authorities in the software now later on additional ones can be added by a organization or

even by a user but in this case what we've got is we've got uh the relying party leveraging the the certificates that have been provided in the software

to validate the certificate now as the designers and there's a variety of different parties and groups that have been involved with this as they were looking at this and looking at best practices they found that it actually

made sense not to have the certificate authorities that were issuing all the certificates on a regular basis online and subject to attack giving their root

certificates to uh the software manufacturers what they found was it was actually best to have a different certificate Authority something called a root certificate Authority that could be

used very infrequently it would only be brought online to issue certificates to uh is issuing certificate authorities or to use that term twice and by virtue of

that then they could be taken offline stuck in a safe and very difficult to compromise and this would allow for much better security because if for example

we were using these issuing Casa and one of them got compromised all of the software manufacturers would need to update their software and that's can be a very disruptive sof uh process

actually today it's is much easier than in the time that uh all of this was being designed so now instead of the issuing certificate Authority providing

uh their certificate what happens is the root CA they actually as they're setting up a root CA they have to go through a very stringent security process to set

everything up and so they go through that entire process then they get a required audit that confirms that everything that they've done is is has

been done properly they take this audit certification to the the soft manufacturers and say will you put our root certificate into your software and

I believe for a nominal fee most of the software manufacturers will do that so now what we have is a mechanism where this relying party is able to take and validate that this is an authentic

certificate actually issued from the certificate Authority or one of the certificate authorities that they trust in their software now there's one final element that we need to put into all of

this and that's determining if a certificate if um isn't in fact on an ongoing basis to be trusted because let's say that Bob who's responsible for

this web server his he's he's got somebody Rogue within his organization or somebody breaks into the organization and steals the private key associated with the certificate now Bob wants to

tell everybody hey you can't trust this certificate anymore I don't want anybody using it and so what he'll do is he'll go up to the certificate Authority and say hey can you go ahead and tell everybody that this certificate

shouldn't be trusted I I'll get a new one from you and so what the certificate Authority does is they put this on what's called a certificate revocation list every certificate has a serial

number and the certificate revocation list is a list of all the serial numbers from that particular CA that can't be trusted anymore for some reason um they can't be trusted whether it's a private

key compromise or some other uh issue and each relying party based on the policies that each CA publishes is required when they're uh

taking and connecting up to a particular site or using a certificate they should go check that now there's there's been some changes and best practices and such we won't get into that in this

particular session but let's just assume that this relying party wants to validate that that certificate is still valid and the way that they'll do that is to go check the crl the certificate

rication list using u a what's called a crl distribution point which is just a public site where that crl is available now pulling down these crls it turns out

over time became a very arduous process because the crls became very big right some of the crls you'll find out there maybe 30 or 40 megabytes and so somebody

uh a few years back actually uh in the mid90s proposed an alternative protocol called online certificate status protocol that would allow somebody just ask for the status of a single

certificate instead of having to download all of the robok certificates they could just say hey is this certificate still valid or is this one still valid and they could actually ask

for a group of certificates but this would enable much more efficient requesting of status for certificates so now what you start to see is that in addition to just being

able to validate is this actually a certificate that was issued from a CA that I trust is this still trusted because you know these certificates typically are valid for a year or two but in the meantime they're could have

been something that has invalidated that certificate now in addition to the issuing ca's issuing crls a root CA can also issue a crl now more recently

Google has proposed an alternative method for validating and keeping track of valid certificates called certificate transparency or CT and what they've

really promoted is each certificate Authority going ahead and Publishing their issued certificates to this log so that everybody has a view of all the

certificates and even if somebody goes and issues a certificate that's bogus now it's part of a public log and everybody can uh check that and say wait a minute we're looking at this and this

this certificate it's a duplicate of another one one of them has to be invalid so it gives a much better ability and much better visibility now this works great on public certificates

but on private certificates those that are used within an organization it it can provide more information that many organizations want publicized outside of that organization so there's some places

still where that's not applying but what now you see is when you when you think about or when you hear the term public infrastructure or

pki this is a pki all of it everything that you see in addition there's other things that you don't really see when an certificate Authority set up they

actually publish uh policies as certificate practice statements a certificate policy and those are also part of that infrastructure they're part of the legal infrastructure all of these

are required to make certificates work and what you start to realize is that all of this is also part of the attack surface for certificates and attacker who's trying to get a bogus or a rogue

certificate May exploit any portion of this they may exploit weaknesses in the software that's used to generate key pairs because that software isn't generating good ones Debian had an issue

back in 2008 with that they may exploit the fact that the relying party software is not properly validating the signatures on certificates so you can see there can be a lot of little cracks

in this infrastructure that an attacker can exploit so this provides you an overview of a public key infrastructure thanks a bunch for joining