Yubico Forum

Learning a chapter from the PC industry, when is Yubico going to open spec on the hardware?

BTW, got a free Yubikey from the RSA conf, after coming home, I spent 45 min to hack it and extracted the AES key inside.

I opened it up and found Yubikey uses the Cypress chip CY7C63833-LFXC. This complete key can be produced with $0.92 USD. When you get the IC from the distie direct it is ~ $0.7.

I wouldn't use this MCU, since it has no built-in protection at all and the firmware, AES secrets can be extracted as I just did it.

If you like, send me your Yubikey and I'll extract the AES secrets from it, but the key will be completely destroyed then. I may charge you a small fee for my time.

There are many things can be improved on the hardware itself. Yubico as a tiny start-up with part-time staff won't be fit to make it to the volume and price that users need. But if you open up the spec, make Yubikey a consortium/committee instead a corp, just like OATH, then that will be attractive.

If Yubico doesn't have resources on that, let others worry about h/w & f/w security.

Is it a joke ? Yubikey is using an USB controller with no ability to be hardware protected ?
Yubikey shoud have used a REAL uC with firmware protection...
You could do that with a Microchip 18f4550 for example.
Really it sounds like a beginner mistake !

This is the data sheet of the Yubikey chip:

http://download.cypress.com.edgesuite.n ... 38xx_8.pdf

It is a keyboard IC, not equipped and not supposed to have any security measures.

I'm surprised nobody cares to hack the h/w or even discussed Yubikey h/w security on the forum. But I hacked it out in 45 min.

With the firmware binary I extracted, I can, acaually anyone can, produce any Yubikey you want with some assembly help.

There are probably not many hardware gurus on this forum.

Just a reminder - hardware security is the most fundamental thing for a h/w security device!

Hardware security is not easy to achieve, but should not be taken lightly.

not usually one to feed trolls, but I will just point out a couple of things:

The YubiKey spec is effectivley open - a number of people have written software implementations for testing etc.

Rather than waste time pulling my key apart, an attacker in possession of my YubiKey would be better off trying to obtain my *other* authentication factors, then use the YubiKey as is before I have it cancelled. The AES key isn't really any more useful than they key itself, since its only used to generate OTPs.

If I want the AES key off my Yubikey (which I do...) I'll obtain it without resorting to pulling it apart (or paying anyone), thanks.

Can't help but feel you were 1/2 hours research off some good points.

Not sure who will buy a SecurID or smart cards if these devices can be easily cloned like Yubikey is.

Certainly I can use YMS to extract my AES keys officially. I'm not talking about something everyone knows on the forum, but something not discussed yet.

Now I can literally manufacture my own Yubikey and clone any Yubikey I got. After cloning and some assembly work, I put it back to your desk and you probably won't even notice it.

Having said that, a Yubikey consortium will make more sense than just hacking.

As I said in the beginning of the thread - it should be open that everyone is allowed to produce it. So h/w experts will have incentives to come in to fix Yubikey's security problems. Just like the OATH model.

I'm not talking about the software part which many contributed to it already.

Also, RSA conf is a "security" conference, I expect products I get from a presenting corp there should be more solid than that.

There's some alarming sounding stuff in this thread, so I'd like to discuss the issue from an authentication security perspective. "dan" began to do this already, but I'd like to elaborate on his points for those who are not experts and want to understand more about it.

To extract the AES key in the way described means that an attacker has to obtain and destroy the yubikey. But since they possess the key they could simply use it (intact) to make OTPs, and have exactly the same benefits. In other words, getting the AES key by destroying the yubikey does not enable ANY new attacks that could not be done much more easily by keeping the key intact and pushing its button. This hardware attack, while neat and seemingly scandalous, just doesn't matter.

In contrast, if an attacker could obtain the AES key surreptitiously (by some means without the user being aware of any foul play), then THAT would be a serious new attack vector.[1] The reason is, the user and server would continue to use the old yubikey AES identity and be unaware that it had been "cloned".

If the yubikey is stolen (whether they pull the AES key out of it or not) that factor is compromised completely. The same is true for any type of stolen token.[2] That's why two factors are so important.

The inexpensive cost of these tokens (especially in high volume) is a mitigating reason for the relative ease of "cracking" the device. If you're using 2 factor security with yubikeys and passwords, it's incredibly more secure than 1 factor with passwords alone. It's excellent protection against key loggers and other common password vulnerabilities, and all but the most "cloak & dagger" of attack scenarios. As with all security, this is a cost/benefit trade off, to be decided by each organization.


Disclosure: My company makes AuthLite, which uses yubikeys in our 2-factor logon solution for Windows networks. So I have a stake in Yubico's success, although one could also argue that if there are competing devices we could just make the software use them instead.. so I think I come out pretty balanced


[Footnote 1]: I refer to attacks such as ripping the AES off the authentication server in secret, doing side channel attacks on the intact key, or if you could perform Gleg's extraction without destroying the key (with teeny tiny drilled holes or something) and return it to the user quick enough that they don't report it missing.

[Footnote 2]: Apart from devices that need a pin code just to display their OTP; these are actually two factors wrapped together in one device.

Take a typical established OTP generator and you’ll find that they are also based on a commercially available chip with a known spec, with the generalized difference that they use mask ROM. There are quite a few companies around (although all of them not being that respected) that provide reverse-engineering services for these chips where ROM and EEPROM data can be extracted.

Hardware as such is no secret and it does not take a big brain to reverse-engineer what we’ve done. The Yubikey a simple device based on a rock-bottom low-end USB controller, just like the thread author has found out. This series of USB microcontroller has been made in the hundreds of millions over the years and is found in a large number of mice, joysticks and other consumer stuff.

So – in the short run, what difference does the thread author’s generalized claim make ? If an attacker breaks into one Yubikey that he is in possession of and spends some time extracting the AES key – what damage is made ? One can discuss the physical protection of the key memory this ad nauseam (which has been and is done) and really – what is the standard required for a device like the Yubikey ?

Pro secundo - I somewhat sense a sting of attack against the fact that we’re a startup. Nothing can change the fact that we’re a young company and some people simply don’t trust young companies. We know that and are working hard to establish ourselves and build confidence in our products. There are new generations of designs on their way with stronger both hardware and physical means to protect the key. We are about to certify and audit our products to applicable security standards. We do discuss openly with our customers and partners what kind of company we are and where we’re going. We open the curtain for the ones that ask.

Pro tertio – I really don’t understand why we should make hardware and firmware open. Do other token manufacturers do that ? Are their products as such less sensitive to bugs or security flaws ? Given that we have an open interface and publish how everything works, I believe we are less sensitive to fundamental flaws.

Pro quarto – There are a few generalized claims that there are patents around. We have made quite extensive searches and we did not exactly file our patents yesterday. This means that we have quite some knowledge about prior art. I’ve been around long enough and have enough patents filed over the last fifteen years to have heard this type of generalized claims before. It somewhat seems to be the rules of the game. Just bring up the relevant patents and we’ll examine them.


As something of a bottom line, I believe these are quite serious claims. I would appreciate if the author(s) of this thread gets a bit more specific in their claims. You’re of course free to vent your thoughts here, but I would like to take this discussion seriously. Please send me an e-mail at jakob at yubico dot com so we can get together to discuss this in a deeper detail.

With the best regards,

Jakob E
Hardware- and firmware guy @ Yubico

Not surprisingly, I've got a few questions over the last days if it really is possible just to read out the key and the firmware. No protection at all ? How can you let it be that way ?

The statement that there "it has no built-in protection at all" is of course not true and despite Gleb's statement, there absolutely is state-of-the-art firmware- and data protection in the chip Gleb so helpfully has told we're using. No secret as such (I guess the ones wondering have done like Gleb) and the good thing is that you all can go to Cypress' website and download the datasheet and check it out yourselves. Why the hell would anyone make and sell a field programmable MCU that has no firmware protection ? Why would anyone buy one ? It simply does not make sense.

The question is of course how difficult it is to break this protection and get out what you're after and how good "state-of-the-art" really is. And what damage is made if someone after all breaks up your chip ?

How good ? I would without blinking say "good enough", but by no means perfect. This discussion has been ongoing about since the EPROM based Intel 8748 was introduced in 1980, maybe longer. Any hobbyist breaking the Yubikey chip in 45 minutes ? NFW. Companies specialized in this kind of piracy and reverse-engineering activities (there are a bunch of them out there) or at a semiconductor lab (at a university maybe ?) - of course, just a matter of time and equipment. But nota bene - this requires some pretty cool stuff, not exactly found at your local Radio-Shack.

But if that's the threat scenario - then what ? Stealing a bunch of keys, break them up, get through the gooey resin, decapitate the chip with some nasty solvents and extract the information, one by one by probing and microscoping, re-assemble them with a temporary glob-top and re-apply the glue, leaving no trace... ? And then covertly restore them to their original owners... ?

Okay, the then pretty dog-eared Yubikey that has passed Gleb's desk finally arrives back after 45 minutes to Alice, Gleb still does not have Alice's username and password. There are simple ways to get these, I know... Gleb would then have some trouble covertly using the Yubikey without Alice noticing that something really isn't working as expected.

... but does this means that the Yubikey is broken ? I really don't think so. Given the effort needed for Gleb to get there, we'we really added quite some friction to this act of identity theft, just like we told people we do.


Okay, we're now finally approaching some kind of bottom line: Unless Gleb has found out some cool back-door, this is really not trivial matters and unless he is a guy working in the kind of organizations mentioned above, I seriously question the claim made. Obviously, I therefore disregard the conclusion(s) being made.

So please Gleb, given the pretty serious claim(s) you've made here – as a matter of professional courtesy, please let us and our forum readers know what you've found out if there really is something. Really - if I don't hear anything, I'll have to regard the claim(s) as just an act of trolling. What else can one possibly do... ?

As a part of our company roadmap, we are to go through appropriate security ceritifications and reviews and this documentation will of course be published as we get there. Give us a few more months...

Regards,

JakobE
Hardware- and firmware guy @ Yubico

Even if you cloned a key, using it would get you into a situation where the real key would stop working (you'd have to start incrementing the session counter until you found the one ahead of what the users is at - or, more obviously to the authentication server, you'd have to try finding a session token that matched up so you had less chance of breaking the users session). I'd definitely have an alarm set up for multiple expired tokens being presented to the auth server...

The composition of the token string is completely open, so I guess if you wanted to you could start making devices whose AES keys were stored in tamper-resistant memory... code for AES encryption and counter incrementing isn't exactly rocket science so you wouldn't even need to infringe Yubico's copyright on the firmware. The yubikey, like all physical tokens, removes a number of attack vectors. I seriously doubt the benefits of a tamper-resistant key would be worth it: you're just closing one extra vector - which is mostly going to be the domain of well-funded organisations who have plenty of other traditional methods at their disposal to get your key.

I agree with Jakob on this matter - if the key is stolen, it is compromised no matter what. Every security system requires thoughtful operation - or in other words: your system can be secure as hell, if someone is too dumb to use it, you're screwed. By 'thoughtful operation' in connection with the Yubikey, I understand, that you keep an eye on it as if it was your passport, your credit card or your house/car-keys. And in the case that you lose one of these - you act to ensure the integrity of the system (suspend your credit card, replace the locks etc.).

I could understand your critic, Gleg, if you found a way to extract the AES cypher from a Yubikey softwarewise in a matter of seconds - or as Jakob already mentioned, to extrapolate the cypher from transmitted OTPs. I am not aware of any way to get the cypher out of a Yubikey (again software-based), but please correct me if I'm wrong - and as long as AES is cryptographically considered safe, the second scenario will not happen.

_________________
"Grant me the strength to accept the things that I cannot change,
the courage to change the things I can
and the wisdom to know the difference."