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 private 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
• the glitch in the system
• impact of the bug
• paragraph walkthrough

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 confirms your identity. (the third kind is "something you are", that is, biometric identifiers like fingerprints. story for another time.) a yubikey is a usb stick that 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 "private key" on the device, one per website. the server that wants to authenticate you 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 private 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 private key without sending it – the server only ever sees the public key, which can't be turned into the private key.

that means that even if you get tricked into logging in to the wrong site, it doesn't matter. the impersonator will send you a random challenge, and you'll sign it, but the challenges are random, so the real server will ask for another one.

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 for the sake of brevity, 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 that the private key never leaves the yubikey. password-based equivalents still leave you vulnerable to getting tricked. 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.

because the yubikey keeps the key on it at all times, there's no way to be tricked into using it on a new site. and because the yubikey has a unique key for every site, even if you register your yubikey with a fake site, it still won't work with the real one.

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 private 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 private keys to attackers with temporary physical access.

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

• CVE-2024-45678 is just the unique serial number of this vulnerability. i glossed over what exactly cve numbers are because that's a surprisingly deep subject, but you probably guessed what it means just from context.
• timing side-channels are the type of bug we talked about: when how much time something takes leaks information that shouldn't be public.
• ECDSA signatures is just the specific kind of cryptography that yubikeys are doing to authenticate you to websites.
• Yubikeys are the little usb dongles we've been talking about this whole time, which help make logins more secure.
• private keys are the information you need to keep secret for that login security to actually be secure.
• temporary physical access is just what it sounds like: physically holding the thing, rather than accessing it over the internet or something. and temporary as in only having physical access for a little while.

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.