EUCLEAK Side-Channel Attack on the YubiKey 5 Series
ninjalab.io
ninjalab.io
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.
NinjaLab: "All Infineon security microcontrollers (including TPMs) that run the Infineon cryptographic library (as far as we know, any existing version) are vulnerable to the attack."
- Chips in e-passports from the US, China, India, Brazil and numerous European and Asian nations
- Secure enclaves in Samsung and OnePlus phones
- Cryptocurrency hardware wallets like Ledger and Trezor
- SIM cards
- TPMs in laptops from Lenovo, Dell, and HP
- EMV chips in credit and debit cards
On a side note, used to frequent a bar where one of the creators of Ledger also did. Was nice to spend various crypto freely!
Ledger hardware wallets (which btw can serve as U2F authentication but, AFAIK, not FIDO2) are protected by a PIN: three wrong PINs and the device, unlike a Yubikey, factory resets itself.
IIUC the side-channel attack relies on a non constant-time modinv.
I don't know if there's a way to force that modinv to happen on a Ledger without knowing the PIN. I take it we'll have a writeup by Ledger on that attack very soon.
Ahem, cough...
ykman fido config toggle-always-uv ERROR: Always Require UV is not supported on this YubiKey.
Less than 10.
Not only are agents likely to be using the chip, self-service immigration gates have become really popular at airports around the world and mostly use the RFID chip together with a face scan
2. Make a fake passport with your photo (and fingerprints etc.) and add the AA key so that it passes the check
You'll still have to somehow fake Passive Authentication (in which your data, including photo, is signed by the country's public key) too, though.
Supposedly it's surprisingly (or maybe not, given how international government relations historically work) difficult for countries to exchange their public keys: Since there isn't any central authority, nor a chain of trust available (a la "this key is signed by France and Switzerland, so it's probably the real thing to us, Germany"), it boils down to n^2/2 key exchanges, and n additional ones every time a single key expires or, worse, has to be rotated on short notice. Then all of that has to be distributed to all border authority systems.
Last time I looked into this (10+ years ago), my laptop doing Passive Authentication and Active Authentication using 10 lines of Python and my country's root certificate (it's publicly available) was supposedly more than what most border checks could practically do.
It seems to be publicly accessible too. Maybe I'll add a few lines to my script if I can still find it :)
Extract those keys and your drivers can ignore all annoying work-time rules and you can just patch the files if you are audited.
Very unlikely that this will be done.
The most important parts use symmetric keys anyway.
[1] https://www.emvco.com/knowledge-hub/emv-chip-specifications-...
- Clone a passport -> why cloning if you can issue new ones - getting risked being detected while using a clone (2 entries in 2 different countries, and you also need to look like the person) not to mention you have to destroy the passport
- Phone enclaves -> see above
- Crypto -> Hardware wallets should be kept on eye as badly as your normal wallet
- SIM Cards -> Swapping is faster, or if you're the the gov, just an intercept warrant will do the trick
- Laptops -> see above
- EMV Chips -> If you have those skills and money, I don't think you'll lose time on cloning credit/debit cards
Well... not really. ICAO compliant passports do not require storing a photo embedded in the chip, as long as you can forge the physical part of the passport (or obtain blanks) you just need the digital certificates from a "donor" passport of John Doe, print "John Doe" and his personal data (birth day/place, nationality, issuance/expiry data) on the human readable and MRZ fields, but crucially the photo of the person using the forgery.
Also, there are no centralized, cross country stores of entry/departure. Lots of places don't even register it for visa-free border crossings.
Some national ID documents, e.g. the Croatian national ID card "osobna iskaznica", do store a photo embedded in the chip, so that indeed restricts a forgery from being used by a non-lookalike.
That's completely on the issuing country then, though, just like they e.g. might choose to not use dynamic chip authentication, which also makes the passport subject to trivial chip cloning.
I wouldn't be surprised if some e-border gates reject travel documents that don't support chip authentication or don't have a digital version of the photo covered by the issuer signature.
Well... not really, from the viewpoint of a bank. Look, now the user can extract the key that the bank TOTP app carefully keeps, and transfer it to another (rooted) device, or use without a phone at all, meaning that this app is no longer a "something unclonable that you have" authentication factor. From a risk management and compliance perspective, that's a contract breach: the bank is legally obliged to store that secret securely, so that the user is guaranteed to complain if it could have been used by someone else.
Experience shows that the people having the skills, money, and criminal energy to attack payment card security quite often end up doing just that.
In a way, there's an implicit and quite large pending bug bounty for EMV at all times...
India has e-passports? I am from there and I have one I renewed during the pandemic, so might have missed the news, but I didn't know we have e-passports now. I tried googling and didn't find much (the official page doesn't load).
https://passportindia.gov.in/AppOnlineProject/online/faqEPas...
Also I checked the PDF on Ninjalab port (article linked in this post) and there was no mention of India there. Is it from some other source like Twitter?
They use Infineon chips https://www.securetechalliance.org/infineon-ships-security-c...
For an individual, the answer there might be to limit the usage of the device to your "core" services, and rely on good password hygiene for everything else.
Usually this means using a password manager, and these days many of them also support WebAuthN in a way not tied to a specific device (or platform/ecosystem).
Sure, if your password vault gets breached then everything is exposed but that's extremely unlikely and you have a lot of work to do in that event regardless. It's an inherent risk to using a password manager: everything is centralized so it's a valuable target.
The point of a second separate factor is to reduce that risk.
What's the advantage here over password + yubikey? Isn't password + yubikey always going to be at least as secure as password, even if the yubikey gets lost/stolen/compromised?
FWIW, I use KeePassXC as my password manager and tag each account that uses my hardware keys, so if lost, stollen or broken, I can quickly get a list of sites from which to remove that key. I always register two keys and keep them physically separate, so I can still login in the event I lose one key.
I have a nagging memory that someone demonstrated defeating it though.
Or just give you back a different yubikey that is cloned from the original.
I’m not saying it’s not possible but 99% of normal people are really only at risk of online attacks or physical attacks which won’t be sophisticated stealth operations but more along the lines of “you’re sending me Bitcoin or I’m shooting your dog”.
Usernames and passwords are leaked all the time. Many users even re-use these across multiple services.
> they also need physical access to your key.
With enough practice, a motivated actor could make it seamless enough that you don’t notice. Or stalk the target to find a weak point in schedule and give attacker enough time to perform EUCLEAK. We are creatures of habit after all.
> And if your token is lost or stolen, you have to manually revoke every single one.
I agree here. No way to easily track. I have to make a manual note for each service in password manager.
I’d wager that people using TOTP tokens like the YubiKey are more likely to use password managers.
User Verification (including PINs) is possible for non-discoverable credentials and vice versa (e.g. Bitwarden's implementation doesn't seem to support user verification at authentication time, but supports discoverable credentials).
In any case, note that this particular attack seems to degrade the security of "Yubikey + PIN" from two factors (possession of the key, knowledge of the PIN) to one (possession of the key), as the PIN entry can be bypassed due to how user verification works in WebAuthN/CTAP2.
A supply chain attack of "here a pre-backdoored key I'm pretending it's perfectly secure, go use it" has no need for this exploit if you have manufacturing capability.
If you don't, then intercepting new yubikeys in transit, extracting the key, and sending them along the way would also be doable with the exploit described.
I agree. I've been keeping track of FIDO tokens and where they work in my password manager and it's great.
I honestly want to extend this idea not just to FIDO tokens, but for anything that would ever need to be revoked and replaced. So stuff like FIDO tokens, 2FA secrets, Passkeys (both already handled by my password manager), payment methods, GPG keys and such.
This includes access to "crypto" assets, but also more serious situations such as defense contractors.
These are scenarios where you have well-resourced, highly motivated attackers, and this is precisely what the yubikey is supposed to defend against.
So, the fob still provides fishing resistant authentication, but some of the security expectations have been subverted.
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...
I don't see this impacting me personally anytime soon, but that might change when more sites start insisting on rolling their own RKs.
Hopefully future Yubikey models will ship with more flash, enabling many more RKs if you so desire.
It's inconvenient, sure, but it's more convenient than my bank accounts that are accessible online being cleaned out.
Password manager. Primary e-mail account. DNS provider.
Other than that, it's rarely supported and rarely worth the hassle when it is.
Banks are so slow with this sort of thing, and still require SMS as a fallback option.
you register at least two keys, and when one fails or is lost, you pull the emergency backup out of a safe and register new one(s).
The fraction of people willing to regularly schedule enroll-o-ramas at each of their accounts and each of their backup key locations is probably smaller than a percent of all potential WebAuthN users.
Yubico or really any other manufacturer could totally e.g. release "Yubikey pairs", both a stateless CTAP2 implementation with the same root secret, that would correspondingly work at the same sites without having to synchronize anything.
The reason they probably don't is that their entire trust model heavily depends on the perception that nobody, including the manufacturer, has a "reserve key" to any given Yubikey, even though of course the absence of such "linked keys" doesn't demonstrate the absence of any such backdoor.
To be clear, I don't have any reason to believe Yubico does this, but it would probably be a harder story to tell, marketing-wise, if they sometimes selectively did, even if it's for a valid use case.
(Or just allow the user to generate the root key outside of the device and insert it)
I honestly think the interest from customers is just too low. I would bet the majority of Yubico's customers are enterprises where this is not really an issue for most use cases. If you loose your key used for Entra ID / SSO, just go to IT support and get a new one enrolled to your account. Much cheaper than having synchronised hot spares (at 30-50 USD a pop) for thousands of employees.
(The second idea seems better assuming the user nukes the private key once the import is done. Otherwise the weakest link in the security chain will continue to be the opsec you practice with the private key file, in which case why spend the money on the Yubikey?)
The idea I thought of is to essentially use the public key of (2) to seed the generation of the root secret on (1). Meaning the sync-pairing-setup is destructive to the root secret, and can only be done at startup (or if you are willing to reset the device).
(A mallory could of course reset it still, unless you have some e-fuse or something, but anyways that's only marginally worse than simply physically destroying it.)
You can already reset CTAP2-compliant FIDO keys using a (non-PIN-authenticated) command [1], so this wouldn't add anything that isn't already there.
I think the real issue here is that users probably don't expect having to reset/initialize a Yubikey once they take possession of it. Given the horror stories of how e.g. Amazon commingles inventory, I wouldn't be surprised if fraudsters could succeed in getting paired keys back into the supply chain.
Targeted attacks to friends/family can probably also not be ruled out ("hey, i got this spare yubikey in a black friday sale, want it?"), and unfortunately something like a family member or partner trying to take over somebody's accounts isn't unheard of.
There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.
[1] https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-cl...
Ah I did not know that, thanks.
> There are just too many ways for this to go wrong, and while Yubikey has, I believe, looked into this option in the past (there's a draft design doc for this idea somewhere), they probably came to the same conclusion.
Would be interesting to see the draft. But yes of course, there are tradeoffs. Having a LED similar to on the Bio to indicate it's paired could be one way, or selling pairs in a SKU where the user actually have to initialise them (with some clear physical difference to help solve the family/friends case). But it's complicated, and I think Yubico has made the correct decision that it's simply not worth it (not that it's impossible to do in a secure way).
However, the lack of a resonable backup solution is keeping me away from Yubikey for any non-enterprise use, where a broken key would actually lock me out of an account for real.
I just use multiple tokens, and I knew that the infineon sle78 was an intel 80251 derivative before this report ;)
I track this in my password manager. Accounts where the YubiKey is enrolled are tagged "YubiKey (FIDO)".
I just had to log into stack overflow for the first time in years, and did not remember what I used to previously log in. Once I figured it out that information went into Keepass too.
You could try every 3 - 5 years or so as it gets reassigned again
(I know because it's my specific usecase.)
> and you have a backup of the key
I've yet to encounter a site that allows to enroll a FIDO device without setting up some other form of 2FA and for me it's TOTP which are kept in the app.
This happened once when the US custom detained my electronics, including a Yubikey. Later I managed to recover many accounts that accept email for 2FA or as the ultimate auth factor (i.e., password/2FA reset). But a few, including AWS, doesn't allow that.
Many websites encourage you to enroll 2FA without clarifying the alternative factors and the consequence of lost access.
Can you elaborate on what happened?
I know that it's theoretically possible, but I thought that:
1- They would potentially detain only devices that they can extract information out of (even if encrypted), like a laptop or some hard disk... Yubikey (at least the old U2F-only ones) don't have anything that you can extract
2- They would eventually return the device to you (unless guilty of some national security violation?)
Am I mistaken on both counts?
And 2 was true. But it was after weeks, and of course I didn't wait until then to reset my account credentials.
Newer Yubikeys hold secrets that, if exfiltrated, give you access to accounts.
I assume that if it doesn't already exist, there will be a Cellebrite-like device that governments can plug Yubikeys into to dump keys quickly like they're able to with cell phones.
"Eventually" is not good enough. People take things with them on their trips, because they expect to use these things while they are traveling/doing work at a remote location. Imagine you need to do some work on a remote site and you can't log in to your company's network, because the TSA has taken away your key so that they can inspect it.
This is super annoying. I wish sites would standardize on a simple infographic saying:
You will be able to access your account with:
* Username, Password and 2FA device.
or
* 5 points from the following list: Username (1), Current password (2), old password (0.5), sms verification (1), mothers maiden name or other secret word (0.5). Email verification (2). 2 factor device (2), Video call with support agent showing government ID matching account name (1), has waited 7 days without successful login, despite notifying all contact addresses (2)
For added security, you can adjust the account to require 6, 7 or 8 points from the above list, but please be aware doing so might hinder your ability to access the account if you lose your password or 2FA device.
They use IP address, location, time since last login, number of attempts, device etc to determine how easy to make it for you to log in.
I lost a Gmail account because I no longer had an old phone number even though my password was correct.
Print those keys out, and bury them in the backyard (or something like that).
Or always add two keys.
IAM users you are correct only allow a single 2fa key (their way of deprecating IAM users), but their SSO Users can have as many as they want and are honestly much better than IAM users. Even for my personal account I've moved to using an SSO User.
AWS documentation specifies that users are allowed upto eight MFA devices each:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...
https://aws.amazon.com/blogs/security/you-can-now-assign-mul...
Apparently I haven't bothered with them for a few months and didn't notice, glad they finally added it.
Will have to try again. Presently have a user per key, named with the end of the keys ID so I know which to use, not brilliant but works.
How would this work?
Each time I go down this path with either work or personal stuff it's just people changing passwords all the time / having to re-login all the time ... there's no happy path without a huge hassle.
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…
> L. So, Yubico is providing _free_ replacements, right?
Nope, mitigations. :(
https://support.yubico.com/hc/en-us/articles/15705749884444-...
IE: If you're "worth it" to target IRL, you shouldn't use a Yubikey to begin with. Someone can swap your spare and you won't realize it until too late.
As in that the hardware broke? Or software stopped supporting it?
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?
The probe is cool though.
No, it seems to be exaclty that. What's non-constant-time is not the execution of the algorithm (as that would probably be exploitable even via USB, worst case), but rather the duty cycle of the externally-observeable RF side channel, if I understand the paper correctly.
Infineon's implementation doesn't seem to be vulnerable to a pure timing attack, as otherwise that RF side channel wouldn't be needed.
They also do implement nonce blinding, but unfortunately with a multiplicative mask significantly smaller than the size of the elliptic curve, so it's brute-forceable.
Are you sure? Section 4.3 (pg 52) starts with "The leaked sensitive information relates to the execution time of Algorithms 1 and 4."
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.
Absolutely.
In practice, the Yubikey is almost never going to be the weakest link in the chain. They could target your devices, intercept your communications, or serve warrants on/covertly exploit the services that host your data.
You can inspect a yubikeys identity with `ykman list` so you can easily have checks to check if a yubikey is broken or actually swapped. If you have high security requirements you can do this periodically and/or have the physical location of the spare be physically secured.
> use something a little more secure than a Yubikey
For a hardware authenticator what would that be?
Who's going to do that? Most of the time, when I use my Yubikey, I'm using it in a text field in a website.
But, to quote https://news.ycombinator.com/item?id=41439400
> Seriously, it's trivial to fry a key and swap it with the working spare if you have access to it
So all an attacker needs to do is swap my Yubikey with a fried one. Maybe someone will figure it out if they're tracking the numbers written on the outside.
The point is that if you require more security there are tools to check it. For me I'm comfortable enough that an attack requires physical access to my keys, so I don't.
> Maybe someone will figure it out if they're tracking the numbers written on the outside.
So if your opsec requires it keep track of which keys you have and their identities. If one is fried remove it from all the services you authenticate with.
I'm not saying its perfect but you can create practices/procedures that protect (or at least let you know it happened) from most realistic attacks.
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.
I don't see how, the attacker is cloning the secrets used to sign the request, if they have those secrets there's no way of distinguishing the clone from the original device. The whole security model of secure elements is preventing the keys from being extracted, if you can do that there's no more security than saving the key to a file on your computer.
Of course to get the key they need to physically open the device, so unless someone actually takes your key it's more secure than saving them on you computer.
Security isn't just the binary of "possible" vs "impossible". It's about *how expensive" that possibility is.
These would be stored by the device and combined with the next sessions' request data before signing. The login site does it's own combining before checking the signature.
This way any clone usage would be obvious. If the attacker uses the clone before you, your key wouldn't work for that site anymore. The site could even warn you if it keeps track of previous values.
Likewise it limits the timeframe the attacker can use the clone.
I guess even just 16 bits of data should make it quite resistant to guessing by the attacker.
This requires some non-volatile storage to keep the "future bits", but at 16 bits you can do quite a few logins before having to do a single page erase.
Then again, not my field so perhaps there's something I'm missing.
If that attestation secret is extractable in any way, nothing prevents an attacker from creating a fake authenticator able to create fraudulent attestations, despite not behaving like an authentic one (i.e. in that it allows extracting stored credentials).
You could theoretically try to mitigate the impact of a single leaked attestation secret by using something like e.g. indirect attestation and authenticator-unique attestation keys (rather than attestation keys shared by hundreds of thousands of authenticators, which is what Yubikey does), but it would be a probabilistic mitigation at best.
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...
If, however, you just need https for web pages, it's good enough to get started.
We're talking low double-digit kilobytes of persistent storage, and sometimes single-digit kilobytes of memory here.
Also, including a full TLS library seems like complete overkill if you only need some cryptographic primitives. These things are usually certified in expensive code and hardware audits; you essentially have to justify (in terms of adding complexity, and with it the possibility of vulnerabilities) and on top of that pay for every single line of code.
Because this is the second time they've had a security issue (the last time was even worse) because of their vendor? When your entire company is based around doing cryptography, it actually makes sense to hire enough applied cryptographers to own your own destiny.
For what it's worth: this doesn't matter even a little bit.
My understanding is that Infineon cryptolib causes the hardware vulnerability and that their TPMs, for example, internally use this library to implement the crypto parts of the TPM specification.
> 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 [---]
This might just be one of the cases where switching to custom code is the right move.
Not being able to flash the firmware is a feature, not a bug. :)
Its the fundamental reason I won't buy NitroHSM because of the Rumsfelt unkown-unknowns about use of the firmware flash feature on NitroHSMs as a future exploit route.
It is a feature only if they ship replacement devices in case of issues like this. If they don't and you're left with a broken device then I'd rather count it as a "bug".
Indeed, but I didn't say otherwise :)
That was under the previous leadership when Stina Ehrensvärd was CEO.
Now they've taken VC money[1], and more recently merged with a listed SPAC[2] I suspect replacement devices will never happen because, you know, shareholders come first.
I wish Yubico had some serious competition, but sadly they don't. NitroHSM is not the same thing (plus has flashable firmware, which leads to potential security risks). Tilitis looks interesting, but its far from maturity.
[1] https://www.yubico.com/blog/yubico-adds-new-round-of-investm... [2] https://www.yubico.com/blog/yubico-is-merging-with-acq-bure/
This likely wouldn’t qualify as “serious competition” but I have a few solokeys and they work fine for my use.
Despite being a bit careless with my keys (e.g. leaving them in a pocket and washing said clothing), they still work just fine. I highly recommend SoloKeys to anyone who wants to support open source hardware and firmware.
What's not the same thing as what? There's no NitroHSM (Nitrokey has 2 different HSM-related products that are different kinds of things from each other, and neither is called that), and most Yubikeys aren't their special HSM devices.
Also mentioning OnlyKey <https://onlykey.io>. You don’t need to be some big corpo to be considered ‘serious’.
That's not what I meant and I suspect you know that. :)
I meant everything from the Yubico hardware (more compact and less bulky than anything else out there) to the Yubico software (extensive featureset with more controllability than most other products out there).
Also as I said already, Yubico is one of the few (only ?) one that does not permit firmware flashing. Most competitor keys have firmware flashing capability, which to me is a big no-no as its an attack surface just waiting for an exploit.
That's what I meant by 'serious'.
Looking at the list of FIDO certified hardware authenticators alone, they definitely do.
My country's eID scheme even requires FIDO Level 2 certification, which Yubico hasn't had for a while, so they practically supported only non-Yubico authenticators until recently.
I would be feeling a bit miffed if I bought one recently, though.
One ? How about corporates who recently bought a batch ? ;)
Previously when their Yubikey 4's were found to be suceptible to the ROCA vulnerability [0], they issued replacements [1] for any customers who had affected devices. I had a few of those devices and they were replaced for free.
I guess that's a disadvantage of having a non-upgradable firmware. They can't fix these devices that are already out in the field.
[0] https://en.wikipedia.org/wiki/ROCA_vulnerability
[1] https://support.yubico.com/hc/en-us/articles/360021803580-In...
This vulnerability, meanwhile, appears to be in the class of "if someone has physical access to your hardware token, and has access to some specialized (expensive) hardware to do side-channel analysis, they might be able to do side-channel on your hardware token." But if someone has physical access to the hardware token... I mean, at that point, most people would consider it compromised anyways and wouldn't expect security guarantees from that point.
> 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.
In the cases of FIDO2 resident keys (passkey) / PIV / GPG, maybe it's possible to extract and copy the exact keys. But I guess it can be detected through attestations.
And I just looked at ykman command. It doesn't seem to allow you to import a passkey to a Yubikey.
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?
You're held in custody, detained, arrested, etc while your keys are dumped and accounts are accessed. You don't have the opportunity to revoke it without risking prison time.
This situation can happen if you simply choose to fly or visit another country.
Being able to quickly clone keys gives any LEO an opportunity to access your digital life as part of a simple stop versus a full criminal case.
In the UK, s 49 of the Regulatory and Investigatory Powers Act 2000 provides for 2-5 years' imprisonment if you were to fail to do so, depending on the nature of the offence under investigation.
In Australia, s 3LA of the Crimes Act 1914 (Cth) imposes a similar obligation with a penalty of 5 or 10 years' imprisonment.
If you find yourself in this position in Russia or China, they would just make you disappear for as long as they saw fit.
evil maid?
> If the authenticator puts the exact identical attestation key into a group of Authenticators (e.g., group of devices, phones, security keys...) so that the attestation key doesn't become a Correlation Handle, then each group of Authenticators MUST be at least 100,000 in number. If less than 100,000 Authenticators are made, then they MUST all have the same attestation key.
Yubico, to my knowledge, has chosen the latter route; this means that compromising a single Yubikey's attestation key compromises at least 100k others immediately
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?
If you do that, you could just use Bitwarden’s TOTP functionality directly.
I don’t do that myself for important accounts as it effectively collapses 2FA into a single factor, but it’s an individual security/convenience tradeoff in the end.
With the YubiKey, TOTP has become more convenient and more secure than it used to be with Authy and then Ente. But maybe I should consider integrating them for most accounts
The advantage of using the Yubikey for TOTP is that (I believe) there's no way to extract the setup secret from it, so even if somebody gains temporary access to it, they can't exfiltrate your future OTPs and would have to attempt a log-in right there and then. Storing the secret in a recoverable way negates that property.
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).
Crypto noob here, but isn't modular inverse the same as modular exponentiation through Fermat's little theorem? I.e., x^-1 mod n is the same as computing x^{n - 2} mod n which we know how to do in a constant-time way with a Montgomery ladder. Or is that too slow?
Aside, for the FLT powering ladder n need needs to be prime, but it isn't when there is a cofactor, though there is a generalization that needs phi(n)... I probably shouldn't have made a comment on the issue of being curve specific since the problem is worse for sqrt().
In any case this is a tremendous attack, good job!
I have no actual knowledge, and it makes sense to assume the PIN is required to implement the EM side channel attack, as without a valid PIN the old, vulnerable Infineon library most likely does not complete all the steps.
Since the RP challenge is not authenticated in any way, nothing seems to prevent an attacker from just preparing a "user verification not required" challenge and getting the Yubikey to sign it.
- Do as many UP-only challenges as required on a stolen Yubikey to extract the private key, not involving the RP (or maybe a single incomplete one, to discover the credentialID)
- Use the recovered private key in an UV challenge against the RP
Hardware: https://dangerousthings.com/product/flexsecure/
Software: https://github.com/darconeous/u2f-javacard (or https://github.com/BryanJacobs/FIDO2Applet if you're feeling experimentative, which you likely do if you're considering a subdermal Java Card implant)
And unlike a Yubikey, this one's even field-updateable :) (At least the applications; not so much the Java Card and OS)
For something that potentially needs surgery to remove from your body, I’d go for the most capable secure element you can afford for maximum flexibility and future proofing anyway; usually that’s also Java Card.
Resident/discoverable credentials are stored on the hardware itself. You can attack these completely offline.
Non-discoverable credentials are not stored on the hardware. To get the authenticator to perform a private key operation (which is a prerequisite for being able to exfiltrate the private key using this attack), you need to supply the credential ID to it, which contains the data required for the authenticator to re-derive the private key.
Usually (i.e. in the WebAuthN-as-a-second-factor use case), a website will only reveal candidate client IDs upon successfully entering your password.
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
Here's the Yubikey security advisory: https://www.yubico.com/support/security-advisories/ysa-2024-...
.pace-overlay{display:none}