Digital certificates with public key infrastructure (PKI)

- One of the big challenges to using asymmetric encryption is the fact that, well, if you're going to do asymmetric encryption, you're going to generate a public, public keys will be red this time, and a private key. So you're going to generate this key pair. Now, in this particular example, let's say that I am a web server and I own a company called Total Seminars, and the website is www.totalsem.com, and I want people to be able to buy stuff on my website. So I want to set up a secure web server. So in the most simple world, what I would do is I would generate a public and private key pair, and anytime anybody logged into my website, I would automatically just send them this public key, and then that way we could start asymmetric encryption. Well, that's a problem, that's a big problem. The problem with asymmetric encryption is the public key. If you get a public key from somebody, and by the way, when you log into a secure website, when you type in https:/www.ebay.com, you automatically get the public key sent from that website straight to your system, okay? So it's not like your email, where we'd have to send it via email or anything like that. But the problem is, is do you, as a person who is running a little web client, do you know that this public key is for www.ebay.com? Yeah, it may say it up on the screen, but there's ways to get around that. So the problem with asymmetric encryption is not the public private key, that works pretty much perfectly, the problem is in the key exchange. How do you know A: where did this public key come from? And B: is it the person that you think it is? So there's two problems here. So in order to get around this, there's actually something really cool I want to tell you about. Now remember we've said in previous episodes that you always encrypt with the public key and you decrypt with the private key. And that's true, but I'm going to let you on a little secret. There is no difference between a public and a private key. I mean, there are different numbers, they're just binary strings, and they're different binary strings, but there's nothing special about the public key that it can only encrypt. There's nothing special about the private key that it can only decrypt. When you generate a public private key pair, either one of these could be the public key, just by convention, we pick a particular one. So again, the public and private key are just a string of ones and zeros. They're different strings, but they're just strings of ones and zeros. Anything you encrypt with this can be decrypted with this. Anything you encrypted with, this can be decrypted with this. Now, we never do that. We never, never ever do that. The reason we don't do it is because if we started to encrypt with both sides of this, there are ways that it can be hacked and naughty things happen, and we don't want to ever do that. However, there are some cool things we can do. Let me give you one example. Okay, so I'm going to start off with my key pair here. I'm going to send this public key in just a minute, but I'm not going to send it by itself. So watch what I'm about to do. So let's go ahead and set the public key aside for a moment. Now, using this private key, the first thing I'm going to do is I'm going to hash something. In this case, we're on a webpage, so let's just go ahead and create a hash of that webpage. Now, using the private key, we are going to go ahead and encrypt that, making an encrypted hash. Now, this encrypted hash is a very, very powerful tool, and the term we call this is a digital signature. I'll show you how that works here in just a moment. So what we'll do is we're not going to just send the public key over to the client. What we're going to do is we're going to attach this digital signature to the public key and watch what happens. So let's go ahead and send the public key with the attached digital signature over to the web client. Now, what this client's going to do is he's, first of all, going to decrypt this digital signature using the public key that was just sent with it, which is going to bring back a hash. Now, since he's on the exact same webpage, he's going to go ahead and hash that webpage and compare the results of his hash to the decrypted digital signature, which is now just a hash, that was just sent over. If these match, we know something very, very important, and that is that the public key that you just got came from the actual entity, which holds the legitimate private key, and that's the whole goal of a digital signature. With the digital signature, you know that you got the public key from the true holder of the private key. Well, that's great, but it's not complete. See, the problem that we're run into now is that, again, let's go back to my www.totalsem.com, and so you go on www.totalsem.com and you go and you want to start buying stuff and it kicks over into a secure webpage. So, boom, comes down, the public key. Boom, comes down my digital signature. Did it really come from www.totalsem.com? I mean, sure, it says www.totalsem.com, but I can beat that. There are ways that I can spoof those addresses and fool you. Or what if I stole somebody else's certificate? What if I stole a certificate from www.intel.com and passed that down? The problem you have now is that you can't say for sure that I, Mike Meyers, am the person, or I, totalsem.com, am the person from which this public private key pair was generated. So to get around that, what we're going to do is you and I are going to shake hands, and before we start doing any business, we're going to agree on a third party. Let's say you and I both know my buddy Janelle, alright? So what I'm going to do is I'm going to go to Janelle and I'm going to say, "Hey Janelle, I would like you, "because you and I know each other, "we've been friends for 30 years. "I want you," and by the way, you have one of my public keys, I have your public key, whatever. "What I need you to do is generate "your own digital signature, "not based on this relationship here, "but based on your and my relationship. "And what I'd like to do is attach that digital signature "to my public key along with my digital signature." So what we've done now is we have a public key, and this public key says, well, this my public key. Then we have a digital signature, which guarantees that whoever actually owns that private key is associated to that public key. And then we have a third party that says, "Yep, I guarantee, "well as much as money and law will allow, that this is Mike Meyers "and it's the www.totalsem website and it is okay." So this all sounds pretty good, but we don't ever send public keys by themselves. We don't send piles of keys with all these digital signatures. I guess with email we could make three attachments or something. What we do instead is we generate something called a digital certificate. A digital certificate is a document, it's like a Word document. It's like a halfway filled in Word document and you fill in the blank spots. And if you send anybody a public key, you don't send a public key by itself. It's never done. You send a certificate, and inside that certificate is going to be my public key. It's going to have, let me make sure I get the right one. It's going to have my digital signature, knowing that it came from my key pair. And it's going to have the third party that you and I trust that says, "Yep, this is really Mike Meyers." What we'd normally do is we go to a third party and we go, "Would you create me a certificate?" And that person knows us in some fashion. We may have met with them, they know my company, whatever it is. And they already have my public key. So if they don't, I can hand it to 'em, give 'em my public key, give them my digital signature, and then they will generate a certificate. It's the actual process of generating a certificate is trivially easy. You can do it any copy of Linux, any copy of Microsoft Windows, and you can generate the certificate. They'll generate the certificate. But what they do that makes it important and good and amazing is that they add their third party digital signature that says I'm good. And that's where the challenge comes in. Oh, and by the way, once I have this certificate, I can pass it out to anybody. I can take the certificate, put it into my web server, and anytime anybody logs into my web server and wants to go secure, boom, they automatically get a copy. I can, if I want to do this for email, I can take this certificate, embed it into any email, not an encrypted email, just a regular email, and go, "Hey, here's my certificate." We pass out certificates like crazy because this is how we move public keys. Okay. The trick here is who do you trust? Because the whole power of a certificate is that we have people that we trust, well, that the two sides of this equation trust, and say, "Yep, this is somebody I'm going to trust "and do business with." So there's really three ways to do trust. The first way to do trust is to generate a certificate on your own. Forget the third party, just make your own certificate. It's easy enough to do. And that's called an unsigned certificate. Unsigned certificates are fantastic as long as both people understand that there is no third party vouching for you. We use unsigned certificates here at Total Seminars. I have some in-house web servers and people want to access them. We all know each other. I mean, you can't even get to this web server unless you're an employee of mine. So unsigned web servers are very common and they work fine, but only if you have some other form of trust, like you work for me. Other than that, you've got two other choices, Web of Trust and PKI. So let's start with Web of Trust. I got a little graphic for you to show you how that works. So here's me and I want to get a certificate. Now in order for me to get a certificate, in this particular situation, this web of trust, we don't have a particular authority. So what I have to do is find other people who are using this type of certificate. So here's a couple of people I know and I can get them to sign my certificate. Now, depending on how this is done, and you see this with email a lot of times, you almost never see this on web browsers, what will happen is that I will have to probably call this person on the phone. I might have to send 'em a photocopy of my driver's license. It really just depends on how rigorous a particular web of trust is. And now these web of trusts can grow. So let's make this a little bit bigger. And over time with a Web Of Trust, you end up having a fairly complicated setup where you have a lot of people who trust each other. Web of Trust works beautifully as a trust model for certificates, but it has some problems. The big problem to Web of Trust is that it requires a lot of people doing a lot of work to administer and make this happen. There's very little to Web Of Trust that's in essence automated. You've got to work hard to keep it up and going. That's why Web of Trust has never really taken off. It's had its moments for email certificates. It's had its moments for, believe it or not, even hard drives encryption and stuff like that. But if you really want to do trust with certificates the right way, you do something called Public Key Infrastructure. Public Key Infrastructure is a hierarchal method that starts off with root servers up at the top, intermediate servers, and goes down to users. So there's always a boss at the top. Let show you how this works. Public Key Infrastructure is based on the idea of a hierarchy. At the top of this hierarchy are what we call the Certificate Authorities. A Certificate Authority is an organization that pretty much just issues certificates. These are usually big companies, probably the most famous as Verisign, but Thawte would be another name that comes to mind. There's just a few hundred of these. And these organizations simply based on the full faith and credit of your and my trust in them generate certificates that everybody knows and recognizes. Now, if we have a lot of people who are going to these Certificate Authorities, the challenge that we run into is that they can get kind of busy. So normally what we'll do is between us, the users of those certificates and the Certificate Authorities, are intermediate Certificate Authorities who are only there to take the load off of the Certificate Authority themselves. So basically we have a nice little hierarchy like this. PKI is the way we do the internet. If you're going to be dealing with certificates on the internet, particularly in an e-commerce way, you're going to be dealing with PKI. And anybody who's ever set up a website that actually uses HTTPS realizes that you got to go to people like Verisign and Thawte and folks like that.