Answer: Yubikeys are shipped without any programming password set, which means that its internal configuration can be read and written to. However, you can not change the firmware – only the settings you can set through the application programming interface. What you can change includes for example the AES key, the yubikey ID, the URL it automatically navigates to (enabled again in 1.3.4!), that it should generate a valid OTP and send to that URL automatically, etc. About reading things out: You can not, as far as I can see, read out the AES key, you can only change it, so this is good. However, consider this: Since you can write to it that you want it to autonavigate to a site and give a valid one time password and then press enter – this also means that by that write you also read out a valid key and send it over the Internet to the attacker. So the writing in this context is in fact enabling the reading. If programming password is set, some firmware versions in the future (not today), will protect against autonavigation changes. Also if programming password is set, no other things in the internal configuration can be changed. Can someone write a brute-force test that tries programming passphrases? I suspect that it will be pretty quick to circumvent the programming password. For example, a four figure PIN will take seconds to break, after which the key is open to changes again.

2) How can Yubikey be used to download and execute malicious code on computers?

Answer: With write access to the automatic navigation feature, the attacker can change the URL that the key automatically navigates to. The attacker must only control one of the computers you use your key in (e.g. in an Internet Café). Now the attacker changes the URL from http://www.mashedlife.com to http://www.smashedlife.com/newfirmware.exe and adds an [enter] in the end (you can do this through the API). With what other tool (other than a keyboard – because it is a keyboard) can you circumvent all controls and malware protection? It is possible to initiate the download and execute code downloaded just using the yubikey. All automatically three seconds after the key is inserted the next time. In addition to the autonav-feature, there is a place in the key to store other keystrokes that was supposed to be used as a prefix for localization problems that is not used (and should be taken out). This is a second place where an attacker potentially can store keystrokes for an attack.

3) A Yubikey lost means the pass code revealed, since it has no lock. This is not true if two factor authentication is used (PW + OTP).

Answer: I agree with you. If you have both a password and a one-time passphrase from the yubikey, then you need not to worry SO much if someone can read out a valid key when you are not watching. However, the security gain you have with the yubikey is very marginal unless the valid OPTs in the keys are protected secrets. If someone knows a valid key, then you are back with your password as the only protection. Look at many yubikey services that are developed now – they are NOT two factor solutions. Yubicos own wiki, and the smart password services use only the key OTP as the only credentials (not even a separate user id). Before: userid + password, Now: one yubikey string. You can have userid + password + yubikey string, like you point out. But will this be the common use?

4) The Yubikey validation service is not backed by the vendor – it is offered as “best effort”. TRUE. I was the person to uncover replay attack bug in the server. But this brings me to my next point.

Answer: Yes, and this is really important. Many users, including myself thought that the validation server was in some kind of production state. Look now, you have many services using this as the back-end validation server. It was just later through some forum posts and emails from Yubico I understood that they do not guarantee the validation service at all. it is just some kind of experiment environment so far. Thank you for uncivering the replay attack. This was very important, because it clarified the situation.

5) Open source of code makes it easier for attackers.I believe this to be NOT TURE. It was the source code (I’m still reviewing) that lead me to discover the bug in item 4. People make mistakes. Review uncovers them.

Answer: You are right. Without Yubicos openness, they would be worse off. However, in the current situation were they are in between experiments and production, and failing to communicate this to users, the availability of code makes attacks much more probable. Yubico has contacted me twice to ensure me that they are working to implement more then one of the recommendations in this post. What really surprised me though, was to hear that they are again enabling the previously temporary disabled automatic navigation feature in the default firmware. This is just amazing, given how difficult it it to protect this. The attacker can just change a hosts file on the computer to get a valid one-time pass sent. The user does not even have to press the button. An this is a very large deviation from the principles of a security device like this as I see it. The principle beeing to 1) keep it simple, and 2) only generate a password when the only button is pressed, and 3) only give passwords to someone physically present at the key, and 4) do not send the key off somewhere in the Internet.

Thanks Mark for your reply. Yubikey is truly a cool thing. In the future it will probably be a cool secure thing too.

/Fredrik

I would like to discuss your points about the Yubikey and the Yubico service. I’ll start by addressing some the points you have made here.

1) Yubikey is not a read-only device. Its internal configuration is unprotected.
Can be read out of the device or can be over written? The first would be a total disaster. The second would be a DOS but I don’t see how it would lead to unauthorized access to service protected by it.

2) Yubikey can be used to download and execute malicious code on computers
You didn’t explain this one at all. I don’t see how this is possible. Unless?, your thinking the Yubikey can be put into static password mode and malware coded into its small length?

3) A Yubikey lost means the pass code revealed, since it has no lock.
Not true if two factor authentication is used. PW + OTP Anything is like walking around with your passwords on a slip of paper in your pocket.

4) The Yubikey validation service is not backed by the vendor – it is offered as “best effort”.
TRUE. I was the person to uncover replay attack bug in the server. But this brings me to my next point.

5) Open source of code makes it easier for attackers.
I believe this to be NOT TURE. It was the source code (I’m still reviewing) that lead me to discover the bug in item 4. People make mistakes. Review uncovers them.

If you would like to discuss these point or others about the Yubikey, please email me at
Mark (at) Grennan.com.