genderphasing

explaining a minor yubikey exploit

for the nerds: cve-2024-45678 / ysa-2024-3

mood: pedagogical?ramblessecurity

my goal with this blogpost is to make this sentence make sense to a layperson:

CVE-2024-45678 is a timing side-channel in ECDSA signatures on Yubikeys with firmware prior to 5.7 that leaks secret keys to attackers with temporary physical access.

along the way, we're going to learn a little bit about cryptography, the hardware engineering that secures tools like yubikeys, and the astonishing complexity of the modern internet.

but before we start the dive, let's be explicitly clear: keep using your yubikey if you have one. there's a small security flaw, yes, but a flawed yubikey is better than none! plus, this attack has very limited utility – details on that below. replace your yubikey when you can, but it's not urgent and it can wait.

anyway. let's get into it!

how yubikeys work

(don't worry, it's a very abridged explanation.) (it's still a page long. maybe you should worry.) (it's fine.)

normally, when you log into a website, you type your username or email into one box and your password in another. in technical terms, this checks "something you know" – the password is a secret, which hopefully is only privy to you.

the problem with passwords is that to prove you know the password, you send it to the server. but what if someone tricks you into sending it to them, instead? well, you've just sent them your secret, so… it's no longer much of a secret!

but "something you know" isn't the only way to prove your identity. yubikeys are "something you have" – a physical item that only you have. (the third kind is "something you are", that is, biometric identifiers like fingerprints. story for another time.) a yubikey is a special usb stick, which can prove to a website that you have it physically with you.

how does it do that? i'm glad you asked!

the first half of this is called "asymmetric cryptography". the yubikey keeps a "secret key" on the device, one per website. the website gets a corresponding "public key", which you send it when you register the yubikey with the site. when the site wants to authenticate you, it can send you a random challenge, which your yubikey will sign with the secret key. the public key verifies the signature is legit.

this sequence of events is different from a password because the yubikey proves it knows the secret key without sending it – the server only ever sees the public key, which can't be turned into the secret key, thanks to the math involved.

that means that even if you get tricked into logging in to the wrong site, it doesn't matter: your yubikey uses a new key for every site, so scammers won't be able to get things signed by the right key. their site might look like the real one, but it's not, and the yubikey knows.

the specific cryptography being done on yubikeys is called the elliptic curve digital signature algorithm – ecdsa for short. (i'd love to dive into the actual mathematics, but that's a whole deep dive on its own. maybe another day.)

but technically, you could implement that with passwords, too, and people have done just that. all you have to do is use the password to generate a key, then do the same type of back-and-forth.

so the second half, the thing that makes yubikeys really special, is their hardware. thanks to a chip called a "trusted platform module", or "tpm", the secret key never leaves the yubikey. password-based equivalents still leave you vulnerable to getting tricked into putting your password in the wrong site. after all, just because the real site does the secure thing, doesn't mean a fake site can't send your password anywhere it wants.

but because the yubikey keeps its key in the hardware, you can't be tricked into putting it in the wrong site. the yubikey just won't let you!

one crucial part of this system is that the keys need to be stored securely. "something you have" isn't much of an identifier if someone can just make their own copy, after all!

part one of this is that you can't turn a public key into a secret key, which ensures the website can't steal your keys. part two is the design of the protocol, which i've glossed over, but ensures that your computer can't steal your keys either. part three is the one relevant to this bug: the hardware security of the yubikey itself.

if someone just steals your yubikey, that's bad, obviously; they now have the "something you have". but it's also pretty obvious, and you can invalidate those keys, and now the attacker loses access.

far more dangerous is the threat of cloning your yubikey, which is why they use a special cryptographic module called a "trusted platform module" or "tpm". these are designed to be uncloneable: you cannot get the secret keys out of it. you can destroy it – obviously, that just takes a hammer – but you can't copy it.

the glitch in the system

the flaw here is what's called a "timing side channel". side channels generally are ways to get information out of a system that aren't part of its designed interface. in a yubikey, the designed interface is the usb plug, and the side channel is in the precise amount of time it takes to do the calculations.

in this case, there's exactly one operation that varies by up to a microsecond, and how long it takes depends on the value of the secret key.

that's it.

no, seriously, that is the entirety of this bug. cryptography is so hard that a single operation varying by a fifth of a millionth of a second is enough to be an exploitable vulnerability. and the standards are so incredibly high that, despite this bug being phenomenally hard to exploit, it's still considered critical.

take comfort in this. cryptography is really, really hard, but the people doing it are really, really, really good at it. and when issues like this are found, they get fixed.

impact of the bug

so what's the attack? if you use a yubikey, what are you at risk of?

well, it means that if there's an attacker who:

  1. steals your yubikey
  2. manages to partially disassemble it without destroying it
  3. successfully authenticates with the server about 200 times
  4. reassembles your yubikey such that you don't notice it was broken open
  5. replaces your yubikey

then they can extract one key used for the one site they authenticated against.

oh, and this only applies to one specific kind of key, called ecdsa. if you use any other kind of key, the bug might not exist there. (there might be others – i'll get to my opinions in a bit – but there's no confirmed bugs anywhere else.)

that is, as you can guess, an extremely limited impact. in particular, that third step requires already knowing your username and password, for most websites, and being able to get around any biometrics or pins on the yubikey itself.

so this has to be a targeted attack against you, and you have to be using ecdsa specifically as opposed to any other algorithm, and it can't be enough to just get access to your account – if they can execute this attack, they can just steal your yubikey and use it – they need to have access to your account and not let you know what's up.

so… yeah. like i said at the top, keep using your yubikey if you have one, and replace it when you can, but the bug here presents a very niche risk.

paragraph walkthrough

so if we go back to that paragraph from the beginning:

CVE-2024-45678 is a timing side-channel in ECDSA signatures on Yubikeys with firmware prior to 5.7 that leaks secret keys to attackers with temporary physical access.

we can now walk through it with a basic understanding of the tech involved:

hopefully, that makes sense. if not, i hope you at least learned something about the tech that secures your world. there's a massive and fascinating ecosystem, and it's worth diving into if you're intrigued.