Updated 3: Yubico reinvents the Yubikey
Last January I did a comprehensive review of the Yubikey for a client and published the results to this blog. My overall review was disappointment and a non-recommendation for the technology. I still hold that opinion when it comes to Yubico’s OTP technology, but it appears they took my review (and similar ones throughout the industry) to heart and have spent some considerable time and effort reinventing the technology. I’m pleased to have the opportunity to review the new technology, for the same client, and with the same end-goal in mind — replacing a installed-cert PKCS12/CA PKI solution with a more easily administered solution that maintains the same (or ideally better) security level.
Yubico has launched 3 new products, the NEO the NEO-N and the U2F Security Key. You’re probably asking yourself ‘but there was already a NEO?’, and in some ways you’re right — the early NEO’s shipped under the same name but were a very different product. I panned them in my previous review for trying to make the OpenGPG application do things it was never meant to do, for having user replaceable applications and for generally having poor administrative tools. The good news is that those concerns have been addressed with the new NEO and it truly is an entirely new device worthy of a second look.
The new keys are all based on similar technology (the NXP A700x MCU) and have 3 distinct modes of operation. The U2F key being limited to U2F mode, while the NEO and NEO-n can operate in OTP, CCID or U2F modes. I’ll get into U2F shortly, but of more immediate interest is the CCID mode. They’ve fixed the user-management of the card applications, and now ship fully configured and with static configuration. The end user cannot upgrade the apps, but neither can a hacker replace them with malicious versions either. Its a solid security move and one they should be commended for.
In CCID mode the keys implement a new applet, now supporting the PIV-II standard, which is an appropriate and ideal choice for identity and authentication. With PIV-II supported, the keys can interact with pretty much any standard PKCS11 supporting software, from OpenSSH to Firefox. PIV works with proper x509 certificates, CSRs and the like, and do so in a way that is both predictable and stable. The keys still support OpenGPG, but, critically only try to do so for use with OpenGPG and not other authentication models to which it is not suited. This is as it should be and one can tell that they’ve considerably upped their game with the PIV approach.
I’ve done a thorough test and review on the PIV applet, and while there were some challenges with building, and using, the key personalization tools, these challenges did not considerably interfere with my ability to setup the key. In this regard, better end-user testing on multiple platforms and better user documentation would go a long way, but a determined sysadmin is going to work through them as I did. Once the keys are personalized, they behave as expected and actually, in my testing, flawlessly with the OpenSC 0.13.0’s PKCS11 interface. CCID smartcards are a hard technology to get right, and at least in this respect the Yubikey NEO now appears to be leading the pack.
From the perspective of a user of a personalized key, the only barrier to entry is the installation of OpenSC and the configuration of the PKCS11 modules — which may be advanced topics for some end-users, but ones that largely go with the CCID territory. In testing I was able to get SSH key authentication, with an onboard-generated RSA2048 key, working as intended with against an Ubuntu 14.04 server.
Overall if you are in the market for a CCID smartcard, I would recommend the new Yubikey NEO and NEO-n devices.
Moving on however, its generally recognized that CCID technologies are not going to be accessible to the truly end-users who really only want to use a smart card for web browser based authentication actions and expect a driverless plug-and-play experience.
Enter U2F and the FIDO alliance.
The FIDO alliance is a massive collaboration project of industry giants on what 2nd factor authentication should look like on the web — and its quite good and very ambitious. The technology involves a bidirectional authentication architecture, borrowing heavily from site pinning technologies and certificate authentication solutions. Interestingly, it has succeeded in simplifying the user-experience for certificate enrolment over traditional pkcs11 solutions, and as such is likely useable-enough for mass adoption.
From a security standpoint, the FIDO U2F standard is mostly solid, but has some caveats that can weaken or even defeat the security architecture provided. I have great reservations as to the pluggable design of the technology, and fear that cheap tokens and software-emulation will weaken the security level desired by site operators. The technology gives the user considerable rope with which to hang themselves — and thats an architecture decision I question in a security product. Fortunately these issues don’t apply directly to the Yubikey’s, but rather to the ecosystem and server middleware around them.
The only hard security concern I have with U2F relates to how keys are stored on the token devices. U2F specifies that each site will receive a unique key and that keys will not be reused between sites. This is a great design feature and ensures both privacy and security. It however requires a fairly large amount of on-device memory to store what could be hundreds of security keys. To work around the secure storage requirements, the spec also allows for tokens to use a wrapped-key pattern, where these U2F private keys are stored, encrypted, but outside of the secure element — with only the device master encryption key being stored securely in the element. The idea being that so long as the master key is secure, the encrypted-but-stored-in-insecure-memory keys should be too. I fundamentally disagree with this design decision, as it allows for token cloning by breaking the encryption scheme or by factoring one single key. This element alone likely makes the technology unsuitable to applications requiring high-level FIPS certifications, and their use in the management of classified or sensitive information. That said, the spec allows for tokens that do not wrap keys to exist, allowing end-users to choose more secure tokens from the market. (though, none exist yet!). The Yubikey NEO is a device with very limited amounts of secured memory (There is ~80Kb of eeprom in the NXP 700x) and therefore I posit that it is implementing a wrapped-key pattern. (Update 2: Yubico has released some detail on their wrapping (actually a deriviation) mechanism. Details at https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/ No technical description confirming this is available from Yubico at this time). Because of the use of wrapped keys, it is my opinion that these devices should not be recommended for high-security use where device cloning is a concern. Update 2: The Yubikey's are implementing a remotely-referenced derived-key pattern. The security of the scheme is relying primarily on HMAC-SHA256 pre-image resistance. This allows the Yubikey to derive a key based on a publicly shared combination of nonce and application id, by muxing in a master key.
The above has a caveat that the U2F specification does include a counter that should prevent long-term dual use of a cloned token. However, in testing I have determined that the Yubikey U2F developer reference application does not correctly handle the counter feature and only treats a bad counter as an authentication failure, rather than an event that locks out the token. This allows for an attacker to find the valid counter by starting at the cloned value and iterating upwards until a login is allowed. The user of the real token would see one auth failure, but likely try again and succeed. This is a serious security failure in the reference implementation. I fear, that relying on the server implementers to correctly handle complicated security protocol elements like this counter will lead to failures — we’ve seen it time and time again from verifypeer to bad random sources. Basically, if theres a way for a developer to screw it up, they will. Interestingly, I also found issues with the way randomness was being generated in the reference application, however, it was promptly fixed with a bug report and it was not likely to affect most implementations.
The specification, and technology, requires a significant level of expertise for relying parties to implement the server side correctly and this implementation should not be taken lightly. I would recommend anyone implementing U2F engage a reputable security firm and perform hostile testing against the service. Aggressive logging of certain authentication failures is an absolute must.
UPDATE 1: Oct 30, 2014
Another serious security bug in the U2F reference application was found by another developer. It's recorded as Issue 6 and the reporter 'araab' points out that the U2F challenge response mechanism is not properly being validated. This again points to the fragility of the implementation side of the U2F equation and how its so hard to program cryto software securely.
Moving beyond the specification, we get into the implementation software running the U2F experience for the end-user. Currently only Google Chrome is supported and only with an extension. In this authors testing the product launched in a horribly broken state, with the browser reliably and predictably crashing. I have verified the result on a number of machines and the reviews of the plugin also report similar issues. This is truly disappointing and the device should never have launched with such glaring problems in the accompanying software stack. That Google also launched Security Key is truly surprising and I am taken somewhat aback that this got past Google’s technical review. This issue affects Chrome 38 on OSX 10.10 and would prevent the deployment of this technology until a fix is deployed.
After complaining on twitter, I received some helpful advice — to try the beta channel of Chrome. So I did, and I’m happy to report that Chrome 39 has resolved the main crashing problem. However, problems remain with regards to multiple tokens inserted at the same time.
The issue of multiple tokens might not seem like a big deal, but if one is to use a CCID mode for SSH authentication token (say a permanently connected NEO-n) and then try to make use of U2F tokens as well, the technology will break down currently.
It is also not possible to concurrently use U2F and CCID mode from a single token. (Updated 3: This is now fixed with Yubico NEO Manager 1.0 [Released Nov 19, 2014], multi-mode use is now enabled and works as expected)
The NEO tokens are also slightly hard to configure. You need to download an application, referenced by link in a PDF document to configure the mode of the token to U2F from the default of OTP. For this reason, I would strongly recommend that anyone implementing U2F specifically target the blue U2F version of the device, which is already placed in U2F mode and is ready for registration upon first insert without further user configuration.
Here the documentation about how to get started with the token could be significantly improved.
The hardware feels surprising resilient, with the NEO-n being nearly indestructible. The NEO key format fits nicely into a USB slot on a MacBook Air, but could be snugger in the slot, as the key flops around as you try to press the button.
I believe the keys will stand up to reasonable wear and tear and are suitable for purpose.
In the last review I noted that the Yubikeys were being shipped from a residential address and gave me pause with regards to the chain of custody. I'm happy to report that my new keys arrived having been shipped from a commercial address in Palo Alto.
Overall I will likely recommend the Yubikey U2F solution to my client, but conditionally on the market adoption of Chrome 39+, and on the resolution of the multi-token problems. This likely means a pause in adoption for now, but recommending future support in the product map, and switching the functionality on at some future date when the browser experience stabilizes.
I would however not recommend the Yubikeys to anyone requiring high-level of security that would include cloned devices in their threat model. This non-recommendation is due to the wrapping (Update 2: Derived based on HMAC-SHA256 and its pre-image resistance properties) and storage of keys (Update 2: Nonce+Mac) outside the secure element and problems with the counter-verification model. (Update 2: I'm also looking at how the keys are handling counters internally, but have not yet completed my analysis) ... While I am not aware of any cloning attacks on these devices, the architecture of the key leads me to believe they are possible, and that such attacks may not be reliably detected due to defects in server implementation models. I would recommend Yubico develop a security checklist for implementers that clearly specifies what to do with a counter-conflict and other authentication failures. I would also recommend that they opensource their key-wrapping technology so as to invite peer review of the approach.