Hi, folks. Ed Amoroso here. In this video, what we want to do is look at an authentication protocol that's turned out to be spectacularly successful. It's one by a company called RSA. It's not the RSA algorithm, but it's a product from the company RSA. If you know anything about cryptography, you know that Ron Rivest, R, Adi Shamir, S, and Len Adleman, A, RSA, have been three wonderful contributors to cryptography, having implemented the Diffie-Hellman scheme using an algorithm that we'll go through in a subsequent video. But the company that was created partly as a result of their original work at MIT has one they create a little device, they actually acquired a company, it's called Security Dynamics many years ago, and created a device that they use to authenticate reported identities. It's very cool. It's called the SecurID, and it's a little physical thing, or you can do it virtual, you can do it on a toolbar, you can do it on your mobile, or you get something physical that you can hang in your physical keyring, and it does a very interesting sort of thing. I say it's such a popular protocol, if you came to visit me in my office, you'd see a picture of myself with the CEO of RSA probably 20 years ago or so, probably about 17 or 18 years ago. We're shaking hands and I bought the one millionth RSA SecurID token at the time in the position I was in. It was funny because they go from a million to a billion since then. Let me show you how the protocol works. It's different than handheld authenticator, even though in its formative years, it still involved something physical that you held, a tangible, physical item. So the way the protocol is going to work is that you say, "I'm Alice." and then the second step, the server is going to say, "Prove it." Not "Here's a number." it's going to say "Prove it." The reason it can get away with that is the first secret that's stored both on the little token that you're issued as part of the infrastructure, so you'll go to a desk and you'd fill out a form and somebody will give you a token, one of the things that's on there is already a seed value, a number, a nonce, a random number, a random integer. And over at the server, I'm going to write down in a little table your name, the token I've given you, and your seed value lambda. So the server has lambda and you have lambda. You got it? So I have a shared secret. Similarly, when I issue the token to you, it implements a function, just as we saw in our handheld little calculator device. So we've got a function f, I'm going to keep track of that on the server. Another thing is there's going to be a clock in both places. The server is going to keep track of the clock and the little token is going to keep track of the clock. So, I say, "Hi, I'm Alice." Service says, "Prove it." And what you're going to do then operationally, as a user, look at the device. There's going to be a number there. You're going to type it in and send it off. That's f to the n of lambda. I'll explain that in a minute. But it's f to the n of lambda, the server is also going to be computing f to the n of lambda, check to see if it matches, and then either they match and your Alice or they don't, you say, it doesn't work. Now here's how it works. At the time I issue the little device to you, the server and the device both have a clock. So they say, "All right. Ready? We both have lambda, we both know f, and when I say go, we're going to say that's time t initial. Are you ready? We synchronize the clocks." You say, "Ready? Go." Now, some set interval that the server knows and the token know. Let's say it's 15 seconds, will pass. You got to go one, two, go up to 15 seconds. At the end of those 15 seconds, both the server and the token will encrypt lambda. So, I've done f to the one of lambda. And now what? I wait 15 more seconds. You go to 15 seconds. Ready? I get to 30 seconds. Boom! I encrypt now then f to the two of lambda. Now wait again 15 more seconds, f to the three of lambda, 15 seconds, f to the four. You get the idea? They're both encrypting over and over again. And when you, the server, ask the client, "Are you Alice?" you give the number you currently have and it should match the number I currently have. Is that crazy? It's hard to believe that it would be so easy to keep that in sync, you think the clocks would drift. Sometimes they do, but for the most part, clocks have gotten pretty accurate. It works cool. When you have the thing operationally, there's usually some little lines that are going that late, it's like these five bars, and the five bars might every three seconds, one bar goes away. Next bar goes away, next bar goes away, next bar goes away. And when you see one bar and it asks you what the number is, you see one bar and you go wait I better wait because I don't want to be on the edge of the 15 seconds. You wait, boom, you get a fresh number and you usually use that one when you get a fresh number just to make sure there's no sync. Isn't that cool? That protocol, that set-up, billions of deployment. Right? And you go, all right, the calculator is zero, you make no money, nobody uses. This thing, many, many, many of them. Why? I'm not sure. I wish I could tell you there's some easy answer. In the next video, I'm going to provide maybe some hints as to why this thing was more successful than the other one. But for the most part, I think it's just maybe good marketing, good luck, but you'll see again in the next video there might be some cryptanalytic reasons for why the SecurID protocol was a little bit more successful than the previous one. So, we will see you in the next video and we'll dig into doing some cryptanalytic assessment of the RSA SecurID protocol. See you then.
