«Security Now! Transcript of Episode #143 Page 1 of 30 Transcript of Episode #143 YubiKey Description: Steve and Leo delve into the detailed operation ...»
Quantity 100 is $20. A thousand of them are $16 each. 10,000, $12 each. 100,000, $8 each. So this price drops rapidly.
And their model is to sell the YubiKeys and provide everything else open source. So, for example, they've already posted their source code up on Google's code pages that shows how to decrypt the output from the YubiKey. And they're in the process of putting the technology together and the documentation for how to program the YubiKey. And, I mean, again, it's even better than I thought it was two weeks ago due to the approaches that they're taking and how open they're being about what it is that they've created.
STINA: Well, there are some bits and pieces we are, you know, we now rapidly need to put in place because there are huge orders coming in. And it's great.
[Talking simultaneously] STINA: Our developers community, I vision that to be really something dynamic, growing. But now it's just an embryo. So it's, you know, people are asking where can I find that document, and please, please, give us some weeks. But, you know, we can produce the YubiKeys in large volumes. We set up that production. And anyone can buy these from our website and start downloading whatever they can find there. And eventually there will be more. And I think instead of just fighting against these big guys that we mentioned, we believe we can do this in a different way. I mean, we can - I'm very excited of what this developers community will go.
I'm even envisioning that little guys in countries with little IT budgets could develop their own e-democracy and education and payment system based on the YubiKey and open source, and what will happen, you know, that would be really [indiscernible]. You know, there could be systems that sort of are built on this that would require so - will be so less expensive than what our, you know, the current infrastructures are for security and systems and governments and payment data.
Leo: And we should make this clear, that you run a server, so people can use your server. But...
STINA: I mean, we have - it's more for eval. And it's more...
Leo: Yeah, for security you'd run your own server. So there's a complete SDK, and there's a server, and there's everything you'd need to do that.
STINA: And it makes a free choice. And some small companies or individuals, they don't have a server, or they don't want to invest in servers. So we give them an option. But our focus is the keys. And, you know, downloading software. And we're not focusing on the server. We just have it as an option, too.
Leo: Do you see at some point some sort of unified system so that - see, I don't want to carry 20 different keys. It'd be really nice if something like the YubiKey would become kind of the standard, much like VeriSign's trying to do with their system.
STINA: Yeah. And we have a dialogue with them. We met them at the RSA show.
And, you know, we don't see it's either/or. And they support OpenID. We support OpenID. There are other standards coming. And they support OSS, and we will eventually support OSS, too. So...
Leo: Well, standards, that's all you need. If everybody supported OpenID, then I would just use my YubiKey. When a site asked for my password, I'd plug it in. It would have to interface, though, with the one-time password code; right? I mean, it would have to somehow have a server to support that.
STINA: Someone has to be the identity provider.
STINA: Yeah, that would be helpful.
Leo: And then I can go to any OpenID site because that's widely spread. I could choose that provider, whoever uses the YubiKey, as my OpenID provider, use the YubiKey, and I'm done.
STINA: Yeah. I mean, there is no limitation. You don't have to be a big guy to be an open identity provider. You could be, you know, could be a one-man guy that does it, you know.
Leo: And everything you're doing is open source, the server and everything. So that it's very transparent. People know what's going on.
STINA: Yeah, we figured out that that was the way it has to be.
Steve: And it's completely open spec, also. So for example, I mean, the business model of, you know, that we've talked about before when we were excited about the VeriSign VIP system, the football and the card, they're a big company standing behind it. But there's nothing that individuals have to use there. I mean, it's a large corporate solution, you know, an eBay, a PayPal kind of company, not something that universities or, for example, I couldn't use it as the authentication technology for my forthcoming VPN product. I absolutely can use the YubiKey. I mean...
Leo: Yeah, you could write a server, run a server, and use GRC as an OpenID provider. If people trusted you, they have the YubiKey, that'd be it.
Steve: Well, I could except that I'm going to make the VPN server itself, that is, the thing that you're connecting to will be able to authenticate your user YubiKey, I mean, right within itself.
Steve: I mean, really it's a transformational technology because these guys have committed to just opening the spec, opening the software, and selling the hardware at an affordable price.
Leo: Very interesting. Stina, we really want to thank you for joining us, and congratulations on your success. I think that's exciting.
Steve: Be talking to you in email.
Leo: That's very cool. So I know you're going to talk in more detail about how the functionality works. So we have some questions from the chatroom, but I'll hold off on those until you get, you know, kind of lay it out for us.
Steve: Perfect. Perfect. Okay. So, okay. One of the first things that they realized was since this thing was going to be a keyboard, that is, since you plug it into a USB port, the computer recognizes it as a keyboard, then at the proper time, when you want it to emit its cryptographic string, you just touch a little touch surface on it. It has a really nice sort of green glow. It is literally, it's the thickness of a PC board, a printed circuit board. And remember, Leo, many months ago when I was up in Vancouver, and I showed you something that I had just discovered? You'd already seen it, of course. But it was an SD card that was also a USB...
Leo: Yeah, you flip it open. I think SanDisk makes it, yeah.
Steve: Yes, exactly. It was a SanDisk product. And I thought, this is so cool.
Leo: Because it's as big as an SD card, but it has its own built-in USB interface.
Steve: Yeah, so it's both. It sort of has a funky little hinge. And so you're able to plug it in as an SD card. But then you're able to kind of almost, like, break it in half. And part of it hinges away, leaving the four fingers of the USB interface. Well, that's what Stina talked about seeing and realizing that they could do an authentication device rather than a memory device in the same form factor. And the brilliance of what they did is they said let's - it's going to be a keyboard. Well, so...
Leo: That's what I really think is interesting.
Steve: Well, and what they realized was, okay, the football that we've talked about so much, the VeriSign technology, and even the RSA SecurID technology, those are all sixdigit tokens because that's, first of all, they're one-time passwords, so that's enough of a string length to be - what's the chance of guessing it? Well, we know that's one in a million.
Steve: Exactly. But one of the things these guys realized was, wait a minute, since users don't have to type this string, we're not limited to, for example, something easy to type.
So we can convey much more information in our one-time password string than you could ever ask a user to type. So, for example, when you touch the contact, it emits 44 characters. It's 44 characters of gobbledygook. It goes zoop, it just kind of comes out.
Leo: Now, of course there's some user intervention involved. You have to click the field that it needs to be in. It's not going to figure that out automatically.
Steve: Yes, that's correct, because all it's doing is just shooting out this...
Steve: Yes, exactly. Now, the front 12 characters, the first 12 never change. They are essentially the public ID for your YubiKey. And every single one of them is different. So...
Leo: Ah. It has to send that, though; right? Otherwise it wouldn't be able to figure out if the remaining part of the code was correct.
Steve: Precisely. So that 12, the first 12 characters do not encode the key at all. It's just a serial number, essentially. It's the public identity for the key. Then, okay, because USB keyboards don't send ASCII, they send scan codes, that is, the actual - the USB spec, lord knows why they designed it this way, but it's actually scan codes. Well, that's a problem for internationalization because, when you move the keys around, the scan codes still refer to the same key, but that's a different character. So one of the problems these guys had to solve, and they call it "mod hex" is their name for it, they had to find scan codes which were invariant across all keyboards, so that the language-specific interface on the computer would still convey the same characters. Turns out that was not Security Now! Transcript of Episode #143 Page 17 of 30 a hard problem to solve. There are, among all the keyboards, there are enough keys that are always in the same position that therefore always have the same scan codes on the keyboard that they were able to do this. So the ASCII that you see is always the same, that is, it's...
Leo: It's kind of the standard set that every keyboard has, as opposed to the extended stuff.
Steve: Exactly. Although it's a bizarre set of characters. I mean, I'm looking at LVKCCUTLIBFIVJGUTRJNDJBUK...
Leo: So it sounds like it's alphabetic, not numeric, not punctuation.
Steve: Correct, it's all alpha characters.
Leo: Uppercase and lowercase?
Steve: Well, I'm looking at a capital "I" at the beginning. But then everything else is lower case. So it looks like maybe they just capitalize the first character.
Leo: The reason I ask is sometimes passwords are case sensitive, sometimes not.
Sometimes they require you have to do special requirements like a number at the beginning, which really drives me crazy, by the way.
Steve: Well, and see, this would not be used by any normal, like, thing that was asking for a password.
Steve: Okay. So we have - they're encoding four bits, four binary bits in each character, so they have a 16-character alphabet. So those first 12 characters that are invariant, that identify which YubiKey out of all YubiKeys you've just stuck into the keyboard, those 12 characters convert to 48 bits. So there's this 48-bit ID which the YubiKey declares itself as. Then you've got 32 characters which immediately follow. So that's a total of 44 characters, the first 12 followed by 32. Well, those...
Security Now! Transcript of Episode #143 Page 18 of 30
Steve: Oh, yeah, I mean, it just - and it's got - what I was reading a second ago was the output from my YubiKey, which...
Leo: Notice I interrupted you before you got to all 47 characters.
Steve: I was - I had four to go. But my point is that's what this thing looks like. So it's 32 characters. And of course, again, four bits per character means that it encodes 128 bits. So essentially you are sending a 128-bit blob every time you authenticate. So the YubiKey contains a write-only 128-bit AES secret key. So mine is different than yours is different than everybody else's. Those first 12 characters that the YubiKey sends in the case, for example, of authentication by Yubico, those 12 characters are used to look up in their database the associated 128-bit AES key that is also contained in the YubiKey itself. So the YubiKey encodes some data that I'm about to describe using its secret 128bit AES key. And we know AES is just Rijndael, my favorite cipher of all time. It encodes the 128 bits of data using its secret AES key, turns it into this mod hex, and spits it out.
It then travels across the Internet or to wherever it's going for authentication. The receiver knows this key's secret 128-bit symmetric key. It simply - it does a Rijndael decode to turn it back into the 128 bits of plaintext that then allows it to proceed with authentication. So the YubiKey itself, you can write the AES key into it, that is, its own secret 128-bit AES key. But there is no provision at all for reading it out. It will never tell you, nothing you can do to it will cause it to relinquish its key. You can only push the button and have it spit out these tokens. But you cannot get it to tell you its key. You can give it a key. It'll never give it back to you. It'll only give you the result. So it's very secure from that standpoint.
Leo: I think this is such a cool technology. I can see why you got jazzed about it.
Steve: Well, and so now we've got 128 bits. And, I mean, they came up with 128 bits, of course, because that's the width of a Rijndael block. So that's 128 bits is 16 bytes. The first six bytes is a unique device ID. And again, every single key ever made has a unique ID. This is part of what, you know, they're planning ahead. They're saying what if this thing really takes off? Well, we want to make sure that all keys are unique so that we can use them for identity purposes without any collision. So you've got six bytes, which is 48 bits, which is a ton. I mean, I don't have a calculator in front of me, but that's a lot of devices. That's more than we're going to need. It's like the same six bytes in a MAC address for an Ethernet controller where you want every Ethernet controller in the world to have a unique ID so that - because that's the way that the MAC address identifies Ethernet devices on an Ethernet LAN, and you don't want them to collide or you can't have those two devices on the LAN. So similarly, this prevents any collision between all the YubiKeys that will ever be made.