EUCLEAK Side-Channel Attack on the YubiKey 5 Series

An attacker not only needs your username and password, they also need physical access to your key. They then have to disassemble the device. If they want to give it back to you, they'll need to reassemble it.

So not exactly trivial!

A blob of nail-varnish over a plastic seam might be a useful canary.

But this does highlight one weakness of these FIDO tokens - you have to manually maintain a list of where you've registered them. And if your token is lost or stolen, you have to manually revoke every single one.

Regardless of whether you're using passkeys or the non-discoverable ones, you need to manually go through each account and replace the YubiKey with a non-vulnerable key before decommissioning this one.

And then there is the non-discoverable part. I don't remember where I've used my YubiKey in the past.

Also, on the Ars article [0] there is mention of a PIN:

> YubiKeys provide optional user authentication protections, including the requirement for a user-supplied PIN code or a fingerprint or face scan.

This is not a YubiKey thing, but a FIDO thing [1].

[0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...

[1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

Oh, so I just need to update the firmware on the physical hardware token.

> YubiKey Firmware is Not Upgradable

https://support.yubico.com/hc/en-us/articles/360013708760-Yu...

L. So, Yubico is providing _free_ replacements, right?

I have a handful of these Yubikeys…

That isn't exactly some subtle side channel involving tiny emissions of radio waves... The time depending on the secret data is pretty much the first thing that any side channel audit ought to check.

It's super simple too - simply verify that all operations always take the same number of clock cycles, no matter the data. Errors too - they should always be thrown after a fixed number of clock cycles, independent of the data.

How did auditors miss this?

Something to consider: If someone is going to go through the effort to get physical access to a Yubikey, they only need to swap it with one that has a similar level of wear and a similar appearance. At that point, the victim will merely believe that their Yubikey is broken; and/or the attacker will have enough time to use the Yubikey.

For example, I have two Yubikeys. Someone could sneak into my house, swap my spare, and I wouldn't figure it out until I go to use my spare.

Basically: This attack is only "worth it" if your target is so valuable that you can target them in person. At that point, I'd think the target would use something a little more secure than a Yubikey.

Yubico blogpost: https://www.yubico.com/support/security-advisories/ysa-2024-...

> An attacker could exploit this issue to create a fraudulent YubiKey using the recovered attestation key. This would produce a valid FIDO attestation statement during the make credential resulting in a bypass of an organization’s authenticator model preference controls for affected YubiKey versions.

1. https://www.w3.org/TR/webauthn-2/#attestation

Elsewhere on the Yubico website[1] they state that a feature of 5.7 release was ...

    Migration to Yubico’s own cryptographic library that performs the underlying cryptographic operations (decryption, signing, etc.) for RSA and ECC

[1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

For what it's worth: this doesn't matter even a little bit.

> Some tools at different layers that would have stopped timing attacks against ECDSA nonce-inversion software: (1) the safegcd algorithm, https://gcd.cr.yp.to; (2) switching from ECDSA to EdDSA, typically Ed25519; (3) using TIMECOP (https://bench.cr.yp.to/tips.html#timecop) to scan for leaks.

The paper specifically calls out PACE as also using modular inversion, but I don't understand either that or Ed25519 enough to get a sense for how bad this is for algorithms beyond just ECDSA.

Found vuln in library used by many for 14 years. Solution: switch to custom code. That's a bold strategy. I hope it pays off.

> Infineon has already a patch for their cryptographic library [---]

> the adversary needs to open the device (...) Then the device must be re-packaged and quietly returned to the legitimate user (...) assuming one can find a reliable way to open and close the device, we did not work on this part

Yubi Keys are supposed to be tamper-evident and you can also put tamper-evident stickers on them. I am more concerned that a determined attacker may eventually find a way to record the signals without having to remove the casing.

The biggest problem with FIDO keys isn't the fact that people can gain access to your accounts if it's physically stolen.

I have redundant keys for backup access. But I have no idea which accounts I used the lost key for, in order to log into them one by one to revoke the key.

How does everyone here keep track? A post-it note in the cookie jar?

Then, I do not store that password. But if I stored it on Bitwarden, I could easily create a YubiKey backup or set it on another app like ente.

I have not kept that password because I considered that it could be easily compromise my security. I have kept the backup codes nonetheless.

Should I keep the TOTP configuration password that the website gives me when I tell it that I cannot scan the QR code?

So I wonder if some things using the same chip/library are not actually vulnerable because they blinded the operation?

It's *better* to use a constant time algorithm, but that's harder to do in a curve generic way and has a pretty significant performance impact (particular before the safegcd paper).

In any case this is a tremendous attack, good job!

But I see now that was the yubikey neo, the 5 is Indeed infineon

This is yet another example of why you don’t f around with crypto and auth in general. Just use best practices and you might be OK.

software otp in a phone or something that is able to be updated seems to be a better choice