(Updated) Evaluating the security of the YubiKey

The folks over at Yubico have responded to this article, and I'm happy to post their letter. It gives a little additional context to the issues I presented and a critical 'other-side' response. I'm happy to see the company actively engaging and addressing the issues really quickly.  There's a couple bits that need clarification. For example the nonces I point out are actually used in other places than inside the synclib, and the 'facilities' issues re the las vegas 'shipping center' were purposefully left vague of the full detail to avoid exposing what appears to be a residential address.

-- Yubico Letter --

At Yubico, we enjoy reading articles from security experts such as yourself, and we appreciate the visibility you provided Yubico through your detailed evaluation of our Yubikeys. Our security team at Yubico takes your assessment very seriously, but there are some clarifications and intricacies that we wanted to share with you that we’re confident will convince you that the Yubikeys offer the highest grade of enterprise security in a comparative product class. Please feel free to contact us if you have any further questions/comments…

The Protocol.

- The Yubikey personalization app saves a .csv logfile with the programmed key values meaning a malware-based attack may discover the log files on block devices even when the files have been deleted

In the most popular scenario, customers choose to use YubiKeys configured by Yubico, where the cryptographic secrets are generated using the YubiHSM’s TRNG programmed into YubiKeys in Sweden the UK or US at our programming centers that use air-gapped computing [at least 1 air gap between the programming station with its control computer and any network]. The plain text secrets database generated on the YubiHSM is encrypted by the customer’s validated Public PGP key, signed by the programming station’s control computer’s secret key, the plain text file is zapped in place and the secrets securely deleted from disk and memory on the programming station. At Yubico, we call this the “Trust No One Model”!

The Yubico personalization app provides customers the flexibility to program their own keys at their convenience. Yubico does acknowledge that customers programming their own keys may not be aware of this risk that the AES keys are in the .csv file and we are working to change the default behavior and provide additional warnings to inform users of the potential risks.  

- Replay prevention and api message authentication is implemented on the server receiving the otp — this has resulted in a number of authentication attacks like https://code.google.com/p/yubico-pam/issues/detail?id=18 which are now corrected in later versions of the protocol. The design, however, trusts the server with the authentication security and thus presents a problematic architecture for shops that do not have crypto-aware developers and system admins able to verify the security setup is working as intended

As you have astutely observed, we’ve fixed the issue you’ve seen in later versions of the protocol. For customers who don’t have adequate crypto-aware developers and system admins, to secure authentication servers should work with solutions from our trusted partners.

- The replay prevention is based heavily on the server tracking the session and use counters and comparing them to a last seen nonce. It also depends on application admins comparing public identities. This should ensure that the keys cannot be intercepted and replayed. Some servers do not properly validate the nonce, the hmac or properly protect their databases from synchronization attacks. Some implementations do not even match the token identities and accept a status=ok as a valid password for any account. (try a coworkers yubikey on your account!). The weak link in the Yubikey-with-custom-key scheme seems to be the server-application layer.
- The Yubikey protocol when validating against Yubico’s authentication servers suffers from credential reuse. It is vulnerable to a hostile server that collects a valid otp and uses it to login to another service, and its vulnerable to hacking or maliciousness of the authentication severs themselves. You are delegating the access yes/no to Yubico under the cloud scheme.

Customers who are concerned about using the YubiCloud infrastructure for YubiKey OTP validation should consider implementing their own authentications and validation servers. Yubico provides all the necessary server components as free and open source code. Customers may also chose to configure and use the YubiKey with own OATH based authentication servers. 


The code.

- The yubikey-val server contained a CURLOPT_SSL_VERIFYPEER = false security vulnerability in the synchronization mechanism.

We have fixed this issue about certificate validation when using https for sync between validation servers. We do however want to point out that the vulnerability had only limited repercussions. This case is closed on GitHub, https://github.com/Yubico/yubikey-val/issues/15

- The nonce and other yk_ values however were not and could be modified by a MITM attack. The attack presents a DoS attack against the tokens (by incrementing the counters beyond the tokens) and possibly a replay issue against the nonces. — however replay concerns require further study and I have not confirmed any exploitable vulnerability.

The nonce used in the ykval protocol from the php client is predictable but it is unclear if this is an issue. We will be doing further review to address any possible exploit vectors if they exist. The case is still open https://github.com/Yubico/php-yubico/issues/5

- There were also instances of predictable nonces. The php code ‘nonce’=>md5(uniqid(rand()))) is used in several key places. This method will not produce a suitable nonce for cryptographic non-prediction use.

The server_nonce field is only used inside the synclib code to keep track of entries in the queue table so we deem this as acceptable. We provided further explanation on GitHub https://github.com/Yubico/yubikey-val/issues/14

- The php-yubico api contains a dangerous configuration option, httpsverify which if enabled will disable SSL validation within the verification method.  Again defence-in-depth approach protects the transaction, with the messages being hmac’d under a shared key, and mitigating this as a practicable attack.

We are working to resolve this issue that was highlighted in order to provide the defense-in-depth protection to eliminate the possibility to turn off https certificate validation in the php client. This case is still open, https://github.com/Yubico/php-yubico/issues/6

- The C code within the personalization library contains a fallback to time-based random salting when better random sources are not available [ https://github.com/Yubico/yubikey-personalization/issues/40 ] however, I cannot figure a time when a *nix-based system would not have one of the random sources it would try before falling back to time salts.

We made the relevant changes to the code and addressed this issue about salting when deriving a key in the CLI personalization tool on windows. Thank you for pointing this out. https://github.com/Yubico/yubikey-personalization/issues/40

The Neo

- As a result, for both personalization issues and third party software, these modes aren’t useful in a real-world deployment scenario, but may be useful to developer users. That said, other smartcard solutions support RSA signing in a smarter way than layering the OpenPGP application on a JavaCard, so are likely a developer’s choice over the YubiKey Neo in CCID mode.

We don't quite agree your analysis of our NEO product and want to point out that there is a distinction between YubiKeys use for development work versus production roll-outs. We intentionally allow users to re-configure the keys and this allows for possible attack vectors but this does not mean the product or protocol is insecure. In a production roll-out, most of our customers choose to protect their Yubikeys with a configuration password.

Therefore, for the NEO, we allow development users to turn on and off the CCID functionality as they choose. In a production roll-out, this function is pre-configured and protected. In addition, It is not obvious to us what makes the NEO in CCID mode less usable than any other CCID + Javacard smartcard product implementation. We have also introduced a PIV applet that allow for all flavors of PKI signing including RSA.

Logistical Security

We respect the due diligence done by you to find out about our locations through public information available on the web. However, although Yubico resides in a shared facility which houses other popular internet companies, we have a dedicated office which is accessible by authorized Yubico employees only. Our current focus is on delivering products with the highest level of quality and security, and the big corporate office will come soon ☺.

Just-In-Time Programming & Efficient Packaging offers Yubico a competitive advantage:
Because of the size of the YubiKey and our unique packing technology, 1 operator and the Yubico Just-In-Time Programming Station can program over 1,000,000 YubiKeys per month.  YubiKeys are handled in slabs of 10 trays of 50 YubiKeys [500 YubiKeys in total] with 4 slabs per 10kg box [2000 YubiKeys].  A pallet of 100,000 YubiKeys weighs less than 500kg. Therefore, Yubico logistics and programming can be performed in facilities that are not available to other authentication hardware companies. Our logistics and programming team have all been with Yubico for more than 5 years and are among our most loyal and trusted employees. We pay particular attention to the security of our programming centers, and update our processes consistent with the advice of our market renounced security experts.  


Thank you!

 

-- Original Article Below --

Every so often I get to take a look at a new security device with the hopes of replacing our existing PKI-based systems, which while very secure are an administrative nightmare and dont lend themselves to roaming profiles very well. This time it’s the Yubikey Nano and Yubikey Neo devices from Yubico that I’m evaluating.

All Yubikey devices support a custom OTP generator based on a home-rolled OTP implementation. There’s a pretty good lack of formal proof on this scheme, but the security boils down to an AES 128 shared secret design, which is reasonably secure against in-transit interception and key leakage. This appears to be the primary threat model the Yubikey is trying to protect against and may be its most secure property.

The Protocol.

The protocol appears to have seen limited review against privileged attacks, and presents a number of security concerns, including:

- The ability to reprogram the devices to a chosen key before account association due to default configurations being shipped both programmed and unlocked. Users are warned against reprogramming their devices as they will lose the API validation ability, however an upload mechanism exists to restore it. Check to see if your key starts vv rather than cc when using the Yubico auth servers as this may indicate reprogramming.

- The Yubikey personalization app saves a .csv logfile with the programmed key values, meaning a malware-based attack may discover the log files on block devices even when the files have been deleted. Needless to say, with the AES keys from the CSV, the security of the scheme fails.

- Replay prevention and api message authentication is implemented on the server receiving the otp — this has resulted in a number of authentication attacks like https://code.google.com/p/yubico-pam/issues/detail?id=18 which are now corrected in later versions of the protocol. The design, however, trusts the server with the authentication security and thus presents a problematic architecture for shops that do not have crypto-aware developers and system admins able to verify the security setup is working as intended.

- The replay prevention is based heavily on the server tracking the session and use counters and comparing them to a last seen nonce. It also depends on application admins comparing public identities. This should ensure that the keys cannot be intercepted and replayed. Some servers do not properly validate the nonce, the hmac or properly protect their databases from synchronization attacks. Some implementations do not even match the token identities and accept a status=ok as a valid password for any account. (try a coworkers yubikey on your account!). The weak link in the Yubikey-with-custom-key scheme seems to be the server-application layer.

- The Yubikey protocol when validating against Yubico’s authentication servers suffers from credential reuse. It is vulnerable to a hostile server that collects a valid otp and uses it to login to another service, and its vulnerable to hacking or maliciousness of the authentication severs themselves. You are delegating the access yes/no to Yubico under the cloud scheme.

The code.

Yubico has taken a radical transparency approach and published all their source code on https://github.com/Yubico…. despite what follows below, this approach should breed confidence in the product over time. When compared to closed-source products, the Yubico product would appear to have the leg up when it comes to identification and correction of security flaws. They are also taking a defence-in-depth approach to API security by signing and checking values even over TLS links. However, while this mitigates a number of coding concerns, it may introduce new concerns and I remain concerned about the use of a hmac signature, over user controllable data, encrypted under TLS as it is a case of a mac-then-encrypt scheme.

I did some basic analysis of the PHP and C code, and found a number of concerning items. The yubikey-val server contained a CURLOPT_SSL_VERIFYPEER = false security vulnerability in the synchronization mechanism. Thankfully the developers had taken a defence-in-depth approach to the API and session and use counter were restricted from being decremented. The nonce and other yk_ values however were not and could be modified by a MITM attack. The attack presents a DoS attack against the tokens (by incrementing the counters beyond the tokens) and possibly a replay issue against the nonces. — however replay concerns require further study and I have not confirmed any exploitable vulnerability.

There were also instances of predictable nonces. The php code ‘nonce’=>md5(uniqid(rand()))) is used in several key places. This method will not produce a suitable nonce for cryptographic non-prediction use.

The php-yubico api contains a dangerous configuration option, httpsverify which if enabled will disable SSL validation within the verification method.  Again defence-in-depth approach protects the transaction, with the messages being hmac’d under a shared key, and mitigating this as a practicable attack.

The C code within the personalization library contains a fallback to time-based random salting when better random sources are not available [ https://github.com/Yubico/yubikey-personalization/issues/40 ] however, I cannot figure a time when a *nix-based system would not have one of the random sources it would try before falling back to time salts.

Logistical Security

I also took the opportunity to look at the security of the Yubico logistics process, and came up with a number of questions, not the least of which was that my Yubikey was apparently shipped from a residential address in Las Vegas Nevada. This gives me pause with regard to Yubico’s claims that the keys are “Manufactured in USA and Sweden with best practice security processes”. I have questions about the chain-of-custody of the keys.

Public sources investigation into the addresses provided on the Yubico site suggest the addresses are shared with other firms and seem to be co-working spaces rather than the typical corporate offices as one would expect of a company providing security products to companies like Facebook and Google.

The Neo

The Yubikey Neo includes a JavaCard based CCID/smartcard device and the ability to support the OpenPGP app. In testing this is clearly beta software and requires kludgey ykpersonalize commands with arguments like -m82. Its obviously not intended for widespread use, and as such it was discounted over more mature ccid products.

Some of the YubiKeys also provide a challenge/response and hotp/totp clients. They’re implemented via middleware that isnt first party and is commercial software on OSX and requires users to learn hotkeys to use.

As a result, for both personalization issues and third party software, these modes aren’t useful in a real-world deployment scenario, but may be useful to developer users. That said, other smartcard solutions support RSA signing in a smarter way than layering the OpenPGP application on a JavaCard, so are likely a developer’s choice over the YubiKey Neo in CCID mode.

Summary

In the end, I cant recommend the Yubikey to replace our PKI systems. The Yubico authentication server api represents a serious information leak about when users are authenticating with the service, and puts Yubico in a trusted authenticator position. It’s also the worst form of credential reuse, and a hostile/malware infected server can compromise unused OTPs and use them against other services.

What this means is that when using the default, pre-programmed identity, if someone were to break into any Yubikey-cloud based system we use, they could break into all of our systems, by collecting and replaying otp’s that have not yet authenticated with the cloud. While you’re using application x, its using that credential to log into application y and is pilfering data. Despite telling them not to, most users reuse passwords across services, and so the login credentials from one service will usually work with another, and the attacker has everything needed for successful login. This is in stark contrast to PKI based systems that always implement a challenge/response using public key cryptography. This also applies to any corporation using pre-programmed keys in a single-sign-on type scheme, as any of the hacked application servers can attack other servers within the sso realm.

Yubico’s or our own loss of the API keys (not the token’s aes key) used for server-to-server hmac validation would also silently break the security of the system.

Because of the problems with the authenticator service architecture, we would have to program the keys into a single security zone, significantly weakening our currently partitioned services (currently multiple pki keys can be stored and automatically selected via certificate stores and/or pkcs11). In the best case scenario, this would leave us to program the Yubikeys ourselves and ship them out to end-users, adding significant costs to an already expensive device and weakening our security architecture in the process.

In short, the device’s default configuration is not sufficiently secure for e-commerce administration and the pre-programming of the device is not financially viable due to shipping and administration costs. The sso architecture creates a single security zone across many services and this is not desirable or best practice.

I will continue to seek out and evaluate solutions that offer PKI-level 2nd factor authentication security without the headaches of administering a production PKI.