Hi folks, Ed Amaroso back. So you probably noticed a little pattern to the learning here and to the presentation on these videos. I get all excited about something and then I say, but! There's a problem, right? [LAUGH] There's a great idea, and then a problem, great idea and then a problem. And it's sort of how science moves forward. So Diffie and Hellman, their key exchange algorithm, we love. The Turing Award, beautiful, it changed our world. But there's a problem. And the problem is I haven't told you yet how you get those public keys to each other, right? We said, if you assume you put it in a directory somewhere or, I mean, do you do that with Amazon when you go buy a book? Do you look up their public key? I bet you don't, so it must be something else. Now let's look at a couple of dopey options. One is manual distribution. Some of you might use OpenPGP or some mechanism with your friends for doing cryptography. And if you do something with your friends, you can have a little key exchange party where everybody shares keys. That's fine, but it doesn't scale. And you're certainly not doing that with an online store. So that's not going to be a scalable option. Another one would be to use a directory. You generate your key pair and then post it to a directory. And a lot of tools like PGP and others will do that. And actually, I've hashed this to directory entries. You could put the hash on your credit card and use that as an index to find somebody's key. It's okay, but it's not going to work for e-commerce. Neither of these schemes actually work. What the community came up with is this new concept called a certification authority or CA. You can see on the screen here, I've shown you a little diagram that sort of shows the schematic of a certification authority. The idea being, a new third party is going to jump into the game here. Now you might say, didn't we want to get rid of third parties before? We didn't like a key distribution center. Now you're going to put a certification authority in the middle doing something. Well, it turns out the CA is just going to do a little bit of administrative work at the infrastructure level. And we're going to try and minimize the amount of work for clients, and accept some level of work that needs to be done if you want to use cryptography for things like commerce. And it's going to be referred to in our industry as signing your server. You might have done some of that. Many of you watching have sold a single item on the internet from a server that you manage. And you will have gone through the process that I described here. Now here is the idea. A certification authority is going to be an active entity in this whole game, having its own public and private key pair. We're going to refer to the central certification authority as a CA. And our PCA, SCA has it's own key pair. And what's going to happen is that it's going to, in some sense, vouch for a certificate that'll be provided to you on request, that includes a public key that you need. Do you get that? I'm going to say to you, hey, give me your public key. And instead of you just mailing it to me, which could be easily spoofed. You're going to mail me a certificate that's signed by that guy, the big CA somewhere. And I'm going to need a protocol in place to validate its authenticity, do you follow? So that's the protocol, that's how it works. Now, here's the first step. A server will send to a CA its name and public key that it generated locally, and ask for the CA to bind or sign in to a certificate. The name and public key in this case would be Server Bob. Now, it turns out there's three levels of assurance for doing this. One would be, I just email you my public key. You look at my email address. You see it's some reasonable company name .com. It's not one of these email accounts that you can get for free that would be anonymous. But it actually ties to a domain that seems legit, seems legit. And that's called a low assurance process, resulting in a low assurance certificate from a CA. Here in the US, you might pay a few dollars for something like that. A second possibility is that the CA makes you do a little more work. You give just a legitimate two-factor authentication, to increase the likelihood that you really are who you are. You're some website selling sneakers on the internet. You're WeSellYouGreatSneakersOnTheInternet.com. And you want the CA to take that public key and bind it to your domain. So it might require that you send an email. And then maybe it sends you a mobile code. And then you put the code in, or whatever. But they'll be some sort of a handshake that's more than just checking your domain. That's called medium assurance. And then the third, the most important, the most high assurance obviously is in person, in person identity proofing. Where you show up physically, you provide credentials to the CA. I remember many, many years ago when I was working at Bell Laboratories, we went through this process using an old box from a company call BBN. And we had these crypto-ignition keys that we used to generate our key pair, which we presented at the time to one of the early browser vendors. And we each, a bunch of us on the team there at Bell Labs had one of these physical crypto-ignition keys. This was in 1994, I think. I remember my daughter was one. She's now a graduate of NYU, but I remember she was eating it. She had, it was an AT&T Bell Lab, had a one of the, a piece of their crypto-ignition keys generating their key pair in her mouth. I thought that was so cool. But anyway, so there's those three levels of assurance, low assurance, medium assurance, high assurance. Once you get that certificate, you drop it on your server. Now you're set, because a protocol that we would now call SSL or secure sockets layer can happen. Here's how it works, very simple. And the beauty of understanding how things are set up, is I probably don't even need to show you. I'm going to show you, but I think you can figure out what's going to go on here, right? The client is now going to visit a website and say, I would like to buy a pair of those sneakers. They look really great. Hey, are you really you? Send me something that I can use to make sure that I'm really sending to you. The server's going to provide a certificate and it follows a standard. There's a standards group that created a structure, it's called X.509. It's part of the X.400, X.500 series of international standards. But X.509 dictates the stuff that's in the cert. There's going to be serial numbers, and expiration dates, and all kinds of stuff about who signed it, all that. But the main thing for you is, it's got your public key, the public key of the website. And the name of the website comes to me. And it's essentially signed by the CA. Signed by the CA, that means the CA signed it with their secret key. Which means, I have to get a public key of the CA now. So how am I going to do that? Because again, the reason I'm asking you for this is because, if I have your public key and I trust that it's you, then I put my credit card in. And I encrypt my credit card with your public key. Remember, we said the public key of the recipient. Encrypt the credit card, boom, send it to you. Laser it across the Internet, it gets to you. Nobody on the Internet sees it, except you. It totally rocks, but now I have this problem. How do I get the public key of the certificate? Now, I think there's two reasons anybody does anything in computing. One, is because they want to achieve some sort of fame or contribution, some non-monetary stuff. And two, is monetary. And they're both valid, perfectly reasonable. It turns out that Diffie and Hellman, and so on, those were not financial motivations that drove them. These were academics. And they're not opposed to making money, but it wasn't that was the main driver. But you'll see on our next video that the primary driver here between the solution to this problem and implementation was one rooted in economics, and something that was embedded in the way the Internet was evolving. And you'll see in a minute the way, assuming you go on to the next video, the way this thing was solved. So we're going to sort of leave it at that. I've got a little quiz here just to sort of test your understanding of CA. The answer is actually b, [LAUGH] it's a weird answer. It is a pretty good business. Now, is it done with mobile devices, probably not. It's probably not going to be done. And it isn't insecure, it's different levels of assurance. But is it a decent business? There's an awful lot of companies, go look and you'll see. I'll bet you there's a thousand CAs. And we prefer CAs to be large, and omnipotent, and available. But it turns out that that isn't exactly right. There are some big ones, and there are some small ones. But on our next video, let's dig in. And we'll see how a really interesting solution to the SSL-CA public key problem was solved by somebody that I'll bet you've heard of. We'll see you in the next video.
