Hacker News Reader

Comment by edent | Hacker News Reader

As per https://arstechnica.com/security/2024/09/yubikeys-are-vulner...

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.

View on HN

It's not just YubiKey.

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

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!

This is an entire class of attacks known since almost forever. So yeah, some of us already considered this so we'd like to gross over it this time.

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.

> - 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.

Yubikeys don’t use a pin by default, but at least the ones I use all have the option to set one.

Whether a PIN is used is determined by the RP on a per-authentication basis, so unfortunately this attack likely breaks that mechanism.

> Whether a PIN is used is determined by the RP on a per-authentication basis

Ahem, cough...

    ykman fido config toggle-always-uv

Does that work for Yubikeys other than the Yubikey Bio?

I just tried it on a 5C NFC (firmware 5.4.3) and got:

    ERROR: Always Require UV is not supported on this YubiKey.

So I'm really not sure this is an option for non-Bio keys, unless it was introduced quite recently.

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.

I'd be surprised if the chip even gets activated in 50% of all validations, to be honest.

All globally?

Less than 10.

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

So what would an attack of the RFID chip look like, if the person still is facially identified using a face scan?

1. Obtain a donor passport, get the chip, dump the Active Authentication key which is used to ensure you can't clone the chip

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.

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.

Isn't this what the pouch and ambassador is for?

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.

https://www.icao.int/Security/FAL/PKD/Pages/default.aspx

Oh, that is very neat, thank you!

It seems to be publicly accessible too. Maybe I'll add a few lines to my script if I can still find it :)

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!

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.

PACE does use (EC)DH. Not sure if that’s vulnerable as well, or if this is once again a footgun specific to (EC)DSA.

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.

Yeh, it's a bingo list of the news stories to watch out for. I guess some restricted/critical/secret infrastructure stuff as well.

Infineon chips are used in some smart tachographs in EU. This is likely to get very messy.

Extract those keys and your drivers can ignore all annoying work-time rules and you can just patch the files if you are audited.

Not really, as it is an expansive procedure which needs to be done on every single device.

Very unlikely that this will be done.

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.

[1] https://www.emvco.com/knowledge-hub/emv-chip-specifications-...

The attack is on elliptic curves...

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.

> - Phone enclaves -> see above

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.

Two factor auth is often just used to shift blame anyway.

> - EMV Chips -> If you have those skills and money, I don't think you'll lose time on cloning credit/debit cards

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...

> Chips in e-passports from the US, China, India

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?

India's e-passports https://passportindia.gov.in/AppOnlineProject/online/faqEPas...

They use Infineon chips https://www.securetechalliance.org/infineon-ships-security-c...

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.

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.

Aren't EMV and secure enclaves big deals?

> 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.

3 keys is where it's at. One at office, one at home, one in a bank locker that has a lot of foam.

I agree this is not trivial, but yubikeys are (at least sometimes) used in context with very high stakes.

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.

A well resourced attacker could manufacture a replacement backdoored key with your ECDSA 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).

But if you store everything in the password manager, it's no longer two factor.

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).

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.

It is not extremely unlikely, all it takes is for you to unlock your password database on a device with some malware.

The point of a second separate factor is to reduce that risk.

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.

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.

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.

> 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.

> Usernames and passwords are leaked all the time. Many users even re-use these across multiple services.

I’d wager that people using TOTP tokens like the YubiKey are more likely to use password managers.

What about passkeys? I think it's possible to sign into a passkey-supporting site with just the physical credential and its PIN.

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.

Someone was shipping something and was using sparkle nail polish on the screw holes. They took pics and claimed the pattern was hard to duplicate.

I have a nagging memory that someone demonstrated defeating it though.

> If they want to give it back to you, they'll need to reassemble it.

Or just give you back a different yubikey that is cloned from the original.

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.

You would replace it with a dummy that unlocks that functionality but looks physically the same.

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”.

Get Chinese knockoff and some coins in a tumbler

This is more probable, yes

Can they give you back a duplicate?

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.

This is inaccurate as clay is not digitally signed.

Reply on news.ycombinator.com