Despite recent vulnerabilities, you shouldn’t stop using hardware security keys like Yubikey
No solution is perfect, but these hardware security keys remain an awesome option in keeping accounts secure from attackers!
Google and other enterprise vendors have been pushing hardware security keys from companies like Yubico and Feitian over the past year as a solution to improving account security. And, why not? Once you’ve learned what services currently accept them and how to pair them with your accounts, they’re simple devices that keep accounts very secure.
Unfortunately, Yubico and Google announced the discovery (and patching) of vulnerabilities over the past couple months that affected their hardware security keys, which might have some worried about using the Google Titan Security Key or Yubikey going forward. Thankfully, both were patched before anyone was largely aware, and neither vulnerability was easy to exploit.
Let’s look at each disclosed vulnerability and what effort is required to even take advantage of them.
Yubikey FIPS vulnerability
Yubico made a security advisory post on their site last Thursday explaining the Yubikey issue, which involved only their FIPS keys (their more hardened keys), specifically ones with firmware versions 4.4.2 and 4.4.4. Yubico announced they have already been working on actively replacing affected keys after discovering the issue internally in March.
So, what’s the vulnerability? Basically, the Yubikey FIPS hardware security keys, when first booted up could see reduced randomness in certain use cases. Yubico outlined four scenarios: when using EC signatures or operations upon first boot up with the Smart Card, FIDO U2F upon first power-up, OATH OTPs upon boot up, and OpenPGP with RSA key generation.
During the first use after power up, Yubikey FIPS saw reduced randomness, leaving some predictable content remaining that attackers could potentially use. The amount of predictable content depends on one of the four above use cases. The OpenPGP, which involves RSA generation may have up to 80 predictable bits out of a minimum 2048 bits, while ECDSA signatures will result in 80 of the 256 bits being static.
The outcome from the above depends upon which use case the attacker wants to take advantage of. For the Smart Card situation, Yubico says that reduced randomness opens up the possibility that an attacker could potentially reconstruct the private key as well as “allow an attacker to generate certificates indistinguishable from valid ones.” The attacker also needs to have installed “specially crafted software” on the user’s computer to access or use the keys/certificates and have it running when the key is first powered up.
The FIDO U2F use case requires even more steps to implement: They would need to compromise the computer or use some TLS vulnerability, then capture multiple signed responses from the Yubikey to the Relying Party, plus know usernames and passwords. To figure out the private key for that particular Relying Party, the attacker would also need to conduct cryptographic attacks. All in all, it requires a lot to even maybe gain access to one of the accounts connected to the Yubikey.
The above use cases are only even possible when using the hardware security key upon first boot up and not any other time.
Google Titan Security Key Bluetooth issue
Yubico wasn’t the only hardware security key provider to announce a discovered issue with their hardware keys. Google announced that they had found a vulnerability affecting the Bluetooth Titan Security Keys that was due to a “misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols.” Much like Yubico, Google fixed the issue and is swapping out affected keys (those with T1 or T2 on the bottom of the back).
There are two possible ways to take advantage of this vulnerability: by communicating with the Titan key or the paired device. When first pairing a BLE Titan Security Key, an attacker can take over the process and pair a rogue BLE device in its stead. From there, they can then change the rogue device to appear as a Bluetooth keyboard and take malicious actions.
The second action an attacker can take is that whenever someone connects their BLE Titan Security Key with their device, the attacker can have it connect to their own device and then sign into your account—provided they also have the username and password.
Both situations require the attacker to be physically within 30 feet of the person with the BLE Titan Security Key.
The difficulty level is high to take advantage of either vulnerability
Both vulnerabilities were found internally and patched quickly by both companies and they publicly explained the issue and their return procedures. For enterprises, admins will have a very time-consuming task on their hands, having to swap out and audit all existing hardware security keys in use. Many individual users might not necessarily want to deal with this hassle. Given the difficulty in exploiting these vulnerabilities, many users will probably feel comfortable continuing to use their existing keys.
At the end of the day, it’s unlikely that either vulnerability will lead to widespread attacks. If you’re in a higher position of power or responsibility, enough that you’d be singled out by an attacker, then yes swap keys immediately!
Security keys remain the best option for organizations and individual users who want to keep their accounts secure. Vulnerabilities will always be discovered, but ones involving hardware security keys are narrow and difficult to exploit, requiring a lot of steps.
