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
Ledger uses STMicroelectronics secure elements and should not be affected by this. Trezor Safe uses Infineon OPTIGA though. See https://bitcointalk.org/index.php?topic=5304483.0 for a table with wallets and their respective microcontrollers/secure elements.
Nice to see a fellow enthusiast here, this is a nice point that different hardware will have different levels of related risk. But this is kind of an entire class of attack where similar paths may be able to be used on these other controllers. Don't gloss over it.
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 literally supports key extraction as a feature and pushes hard the firmware updates. Last S firmware w/o key extraction still works, while the same X version cannot be used anymore.
Passports are kind of a big deal. The customs agent is going to visually verify the photo vs the holder, but the customs agent is going to trust the valid RFID chip probably 100% of the time as it's assumed to be unbreakable.
However if we look only at border checkpoints (including airports) in first world nations the number is probably a lot higher.
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
On the bright side, this bug seems to require an ECDSA operation, and I would guess that most ePassports are using RSA. Can't seem to find any statistics but the standards support both.
Since it's a non constant time implementation of a specific part of the EC operation (modular inversion) my guess would be they reused the code for that everywhere and it's probably also present in ecdh and all other algorithms requiring a modular inversion.
That's assuming that the validation software even has all issuing countries' root keys available.
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.
ICAO, the international organization which maintains the standards for travel document interoperability does have a public key directory that a reasonably large number of countries now participate in. The beauty of international organizations is that the individual members don’t all have to be on the best terms with each other.
Yeah, it’s surprisingly not straightforward. In my home country (Russia), only some biometric passports issued inside the country can be used on the automatic gates – mine was issued in an embassy overseas, so I can’t use them. It works just fine in Malaysia, though!
Fortunately (in this case) the payments card industry only acknowledged the existence of Elliptic Curves in 2021 [1], so most EMV cards should be safe.
The most important parts use symmetric keys anyway.
Sounds like they buried the lede with this one then. Some of the items on that list being 'crackable' seem infinitely more dangerous than a general-purpose device such as a YubiKey.
> - Cryptocurrency hardware wallets like Ledger and Trezor
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.
This is at best another forensic tool (unlocking the TPM of a locked laptop/phone for prosecution) and at worst a red herring for security flag.
- 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
> - 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
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.
> ICAO compliant passports do not require storing a photo embedded in the chip
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.
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).
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?
If I remember correctly, Infineon already had a big TPM recall a while back. I remember my T470p had to first install a BIOS update to enable userspace updating of the TPM, then the TPM update itself. And I think some Yubikeys were replaced for free due to the same or similar issue.
> But this does highlight one weakness of these FIDO tokens - you have to manually maintain a list of where you've registered them.
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.
A small advantage to this attack is they don't need their own manufacturing and can attack keys which are already in use.
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.
> you have to manually maintain a list of where you've registered them
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.
> 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).
It's still two factors regardless of storage. Say you accidentally paste your password into the wrong field and post it on a forum. Whoever gets that still needs the second factor.
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.
If there's malware on my device, isn't it game over already? Even if I have a second factor elsewhere, the malware can access session keys to whatever service I logged into from that device, among other things.
In theory. But if everything is in the password safe, the malware can just grab that and upload? And cover its traces. As opposed to patching every application/service you might use, and get access only when you use it.
It's certainly not good, but if you require 2FA to, say, change the email address attached to your account, or make withdrawals, or other important actions, it's not game over.
Yes, but I don’t need/want 2FA everywhere, and it’s still a strictly better single factor than a password (since WebAuthN is resilient against server-side database leaks and phishing).
> 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.
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?
> 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.
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.
> An attacker not only needs your username and password
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.
That's less related to passkeys, and more to what the site (i.e. the Relying Party in WebAuthN parlance) requires in terms of authentication security.
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.
You can’t do that without the same assembly issue. Yubikeys don’t let you generate the FIDO2 keys at all and I believe there’s a flag on x509 keys which were imported rather than generated on the device.
The “looks physically the same” part is the problem I was referring to: this attack needs a lab and some time. If they have to add reprogramming a key and weathering it to look like yours to the task it’s certainly not impossible but it moves even further into “are you at war with a nation-state?” territory where the attacks are both unlikely to be worth the cost or easier than alternatives.
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”.
Cloning a functional piece of hardware that behaves like the original yubikey doesn’t imply the clone looks and feels like the original. It sounds to me it’s like someone would make a clay copy of a key. I don’t think the attacker gets to replicate the manufacturing process to make an item the same shape and size as the original.
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.