[HN Gopher] EUCLEAK Side-Channel Attack on the YubiKey 5 Series
___________________________________________________________________
EUCLEAK Side-Channel Attack on the YubiKey 5 Series
Author : GTP
Score : 681 points
Date : 2024-09-03 12:54 UTC (1 days ago)
(HTM) web link (ninjalab.io)
(TXT) w3m dump (ninjalab.io)
| jcfrei wrote:
| FYI: This page gets stuck at 99% on firefox (130.0).
| scrlk wrote:
| Was quite slow for me, but eventually loaded.
|
| Here's the Yubikey security advisory:
| https://www.yubico.com/support/security-advisories/ysa-2024-...
| amatecha wrote:
| Yeah, same. Not sure why - nothing is loading. Just a broken
| site theme, I guess. Switching to reader mode in your
| respective browser should instantly show the post content (or
| at least it did for me in Firefox).
| bitexploder wrote:
| https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
|
| Write up there.
| totony wrote:
| I used ublock origin to block the overlay and loading
| indicator. A loading indicator on a website is bad practice
| anyway imo
| USiBqidmOOkAqRb wrote:
| .pace-overlay{display:none}
|
| I don't get why people add these loaders.
| TavsiE9s wrote:
| Does not sound like they're issuing replacement devices.
| cryptonector wrote:
| Yeah, I see no indication of that on their blog, and you can't
| flash the firmware.
| traceroute66 wrote:
| > and you can't flash the firmware.
|
| 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.
| wiktor-k wrote:
| > Not being able to flash the firmware is a feature, not a
| bug. :)
|
| 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".
| cryptonector wrote:
| > Not being able to flash the firmware is a feature, not a
| bug. :)
|
| Indeed, but I didn't say otherwise :)
| rasse wrote:
| They really should. The recovery of the one secret the device
| is supposed to keep is catastrophic. Sure, the recovery itself
| might be an edge case, but Yubikey users buy the product to
| protect themselves from edge cases.
| TavsiE9s wrote:
| IIRC the last time something similar happened they issued
| replacement devices... I'm a bit baffled that they're not
| offering a replacement programme.
| traceroute66 wrote:
| > I'm a bit baffled that they're not offering a replacement
| programme.
|
| That was under the previous leadership when Stina
| Ehrensvard 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/
| TavsiE9s wrote:
| Thank you I was not aware of that. That's unfortunate.
| baseballdork wrote:
| > I wish Yubico had some serious competition, but sadly
| they don't.
|
| This likely wouldn't qualify as "serious competition" but
| I have a few solokeys and they work fine for my use.
|
| https://solokeys.com/
| koito17 wrote:
| I have used SoloKeys since v1. Currently own two v2
| SoloKeys, and they "just work" for anything involving
| FIDO2. I specifically use them for storing SSH private
| keys and WebAuthn credentials. The key can be used on any
| device with a USB-C port (there is also a variant
| supporting NFC, but I don't have that variant)
|
| 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.
| pxc wrote:
| > I wish Yubico had some serious competition, but sadly
| they don't. NitroHSM is not the same thing
|
| 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.
| toastal wrote:
| > I wish Yubico had some serious competition, but sadly
| they don't
|
| Also mentioning OnlyKey <https://onlykey.io>. You don't
| need to be some big corpo to be considered 'serious'.
| traceroute66 wrote:
| > 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'.
| bigfatkitten wrote:
| Swissbit[1] is another, but I have no personal experience
| with their products.
|
| [1]https://www.swissbit.com/en/products/ishield-key/
| excalibur wrote:
| I think it might be a tad early to say whether they will or
| not. This exploit doesn't even have a CVE yet.
| aebeppos wrote:
| CVE-2024-45678
| Retr0id wrote:
| I suppose I'm not a regular consumer, but I buy devices like
| these under the expectation that they will eventually succumb
| to practical low-cost attacks.
|
| I _would_ be feeling a bit miffed if I bought one recently,
| though.
| traceroute66 wrote:
| > I would be feeling a bit miffed if I bought one recently,
| though.
|
| One ? How about corporates who recently bought a batch ? ;)
| Retr0id wrote:
| Well then it's a mere budget rounding error. But, the
| overall risk assessment shouldn't have been much different.
| zxcvgm wrote:
| Yeah. That's what I came here to say too.
|
| 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...
| jcranmer wrote:
| As I understand it, the ROCA vulnerability is "the secrets
| generated by a YubiKey may be susceptible to classic
| cryptographic breaks", something along the level of "the
| cipher is inherently weak."
|
| 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.
| tptacek wrote:
| Yes: the _keys_ the Y4 tokens generated were susceptible to
| attacks; here, it 's the _device itself_.
| tomas789 wrote:
| > This vulnerability - that went unnoticed for 14 years and about
| 80 highest-level Common Criteria certification evaluations
|
| 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.
| mistercheph wrote:
| Don't ask question about cryptography friend! Just use
| excellent library that implement best practice elliptic curve
| parameters chosen (of course) *completely* randomly from hat
| and stop thinking about it!
| tomas789 wrote:
| No worries. I trust my government.
| madars wrote:
| PDF of the EUCLEAK writeup: https://ninjalab.io/wp-
| content/uploads/2024/09/20240903_eucl...
|
| Yubico blogpost: https://www.yubico.com/support/security-
| advisories/ysa-2024-...
| noodlesUK wrote:
| From a practical perspective, what protection does the use of a
| fido2 PIN provide here? Is the EM side channel exposed without
| knowledge of the PIN?
|
| In any case this is a tremendous attack, good job!
| sounds wrote:
| Information is light about an actual Proof of Concept here.
|
| 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.
| lxgr wrote:
| Requiring/not requiring the PIN is a per-authentication flag
| that the RP can set though, as far as I know.
|
| 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.
| lxgr wrote:
| Oh, potentially important corollary: This means that this
| vulnerability allows breaking an "always UV" credential as
| well:
|
| - 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
| bangaladore wrote:
| Additionally, it looks like this vulnerability exist on on all
| Infineon trusted X (platform modules, microcontrollers, etc...)
| that use the same internal crypto libraries.
| winux-arch wrote:
| This vulnerability is present when using the affected
| combination of Infineon Hardware with the infineon cryptolib
| bangaladore wrote:
| Are you sure about this?
|
| 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.
| edent wrote:
| 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.
| panarky wrote:
| 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
| madars wrote:
| 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.
| notarealllama wrote:
| 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!
| rfoo wrote:
| 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.
| pshirshov wrote:
| 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.
| TacticalCoder wrote:
| > - 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.
| Xylakant wrote:
| Yubikeys don't use a pin by default, but at least the ones
| I use all have the option to set one.
| lxgr wrote:
| Whether a PIN is used is determined by the RP on a per-
| authentication basis, so unfortunately this attack likely
| breaks that mechanism.
| traceroute66 wrote:
| > Whether a PIN is used is determined by the RP on a per-
| authentication basis
|
| Ahem, cough... ykman fido config
| toggle-always-uv
| lxgr wrote:
| Does that work for Yubikeys other than the Yubikey Bio?
| lxgr wrote:
| 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.
| hadlock wrote:
| 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.
| lxgr wrote:
| I'd be surprised if the chip even gets activated in 50% of
| all validations, to be honest.
| DANmode wrote:
| All globally?
|
| Less than 10.
| wongarsu wrote:
| 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
| stingraycharles wrote:
| So what would an attack of the RFID chip look like, if
| the person still is facially identified using a face
| scan?
| notpushkin wrote:
| 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.
| lxgr wrote:
| 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.
| wbl wrote:
| Isn't this what the pouch and ambassador is for?
| FateOfNations wrote:
| 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
| iancarroll wrote:
| 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.
| lxgr wrote:
| 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.
| consp wrote:
| 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.
| trebligdivad wrote:
| Yeh, it's a bingo list of the news stories to watch out for.
| I guess some restricted/critical/secret infrastructure stuff
| as well.
| cotillion wrote:
| 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.
| PinguTS wrote:
| Not really, as it is an expansive procedure which needs to
| be done on every single device.
|
| Very unlikely that this will be done.
| lxgr wrote:
| 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-...
| xeyownt wrote:
| The attack is on elliptic curves...
| mirages wrote:
| 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
| mschuster91 wrote:
| > - 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.
| patrakov wrote:
| > - 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.
| nly wrote:
| Two factor auth is often just used to shift blame anyway.
| crossroadsguy wrote:
| > 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?
| morpheuskafka wrote:
| 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.
| natpalmer1776 wrote:
| 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.
| numpad0 wrote:
| Aren't EMV and secure enclaves big deals?
| MetaWhirledPeas wrote:
| > 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.
| lxgr wrote:
| > 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).
| davidt84 wrote:
| But if you store everything in the password manager, it's
| no longer two factor.
| lxgr wrote:
| 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).
| hypeatei wrote:
| 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.
| davidt84 wrote:
| 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.
| duckmysick wrote:
| 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.
| davidt84 wrote:
| 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.
| Matumio wrote:
| 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.
| remus wrote:
| > 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?
| haroldp wrote:
| > 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.
| bbarnett wrote:
| 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.
| aidenn0 wrote:
| > 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.
| acdha wrote:
| 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.
| xvector wrote:
| You would replace it with a dummy that unlocks that
| functionality but looks physically the same.
| acdha wrote:
| 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".
| wbl wrote:
| Get Chinese knockoff and some coins in a tumbler
| a1o wrote:
| This is more probable, yes
| xyst wrote:
| > 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.
| colejohnson66 wrote:
| > 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.
| sowbug wrote:
| What about passkeys? I think it's possible to sign into a
| passkey-supporting site with just the physical credential and
| its PIN.
| lxgr wrote:
| 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.
| throwaway48476 wrote:
| A well resourced attacker could manufacture a replacement
| backdoored key with your ECDSA key.
| dgoldstein0 wrote:
| 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.
| jerieljan wrote:
| > 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.
| lallysingh wrote:
| Can they give you back a duplicate?
| laserbeam wrote:
| 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.
| ddtaylor wrote:
| This is inaccurate as clay is not digitally signed.
| perlgeek wrote:
| 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.
| ycombinatrix wrote:
| i guess this breaks fido attestation for a lot of use cases since
| most yubikeys can be spoofed now
| mcwhy wrote:
| Infenion strikes again, 7 years ago:
| https://en.wikipedia.org/wiki/ROCA_vulnerability
| OptionOfT wrote:
| I think the most annoying part of this is that you cannot just
| replace a YubiKey.
|
| 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...
| i80and wrote:
| For sites that use a resident webauthn token like GitHub, you
| can list the known sites on the key. The UX for all this is not
| where it should be, however.
| vaylian wrote:
| Are you sure that GitHub uses resident keys? I'm fairly sure
| they use non-resident keys.
| bigfatkitten wrote:
| They do now, but they didn't in the past.
| vaylian wrote:
| Any idea why this was changed? The big advantage of non-
| residential keys is that they do not take up any space on
| the Fido token and thus you can have an unlimited number
| of them.
| bigfatkitten wrote:
| They wanted discoverable credentials to enable the magic
| username-less "sign in with passkey" auth flow.
| vaylian wrote:
| I really couldn't care less about that. But I do care
| about the limited space on my fido token.
| bigfatkitten wrote:
| I've used five RK slots out of 25 available on my daily
| driver keys. Three of those are for SSO providers that
| provide access to the majority of the other apps I use. I
| opt in to "sign in with Google" etc wherever I can.
|
| 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.
| webstrand wrote:
| I've always hated that I couldn't clone or backup my personal
| yubikey. It's one of the reasons I've avoided using it
| everywhere.
| kyrra wrote:
| I mean, that's the security story around it. You solve this
| and buying multiple yubikeys. Google and others support
| multiple keys, which gives you the backup story (I have 4
| keys in various places).
| jzig wrote:
| You register 4 keys on each website?
| fragmede wrote:
| I mean, not all at once, but (I only have 3) there's the
| one when I bought a new laptop in 2019 which I setup when
| I got that laptop and became the old one when I got a new
| laptop in 2021 and setup a second one. And then the third
| one is a backup key I made at some point and is stored
| offsite in case I/my house gets robbed/burgled or my
| place burns down in a fire.
|
| It's inconvenient, sure, but it's more convenient than my
| bank accounts that are accessible online being cleaned
| out.
| michaelt wrote:
| You register multiple keys on a handful of critically
| important websites.
|
| Password manager. Primary e-mail account. DNS provider.
|
| Other than that, it's rarely supported and rarely worth
| the hassle when it is.
| brendoelfrendo wrote:
| It _is_ really annoying that more sites don 't support
| multiple security keys, though. As far as I can tell,
| it's not encouraged by the FIDO Alliance and I can't
| think of a good technical reason for it.
| vel0city wrote:
| The vast majority of sites I've used Yubikeys for have
| supported multiple. About the only one that I use which
| still doesn't to my knowledge is Paypal.
| brendoelfrendo wrote:
| Maybe I'm out of date, then! I don't enroll new keys very
| often. Paypal is a great example of a service that I
| would like to support multiple keys, though, so it's
| disappointing that they still only support one.
| fullstop wrote:
| I forget which financial institution I was using at the
| time, but they explicitly only supported _one_ key. That
| is, you add a new one and the old one is expunged.
|
| Banks are so slow with this sort of thing, and still
| require SMS as a fallback option.
| beezle wrote:
| How often do you check to see that those other/backup
| keys are still secure? This attack becomes easier if the
| attacker knows of the secondary key(s) location and
| because of disuse they aren't even necessary to replace.
| DANmode wrote:
| If you have a hardware key setup for _anything_ you want
| sustainably operated in the future,
|
| 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).
| nicolas_17 wrote:
| You also have to pull the emergency backup out of the
| safe when signing up for a new thing. It's highly
| inconvenient.
| throwaway48476 wrote:
| Still more convenient than getting locked out.
| drdaeman wrote:
| It becomes questionable if you're halfway across the
| world from your safe.
| lxgr wrote:
| True, but what's even more convenient than that is to
| just not use hardware authenticators for anything but the
| most important accounts/sites, and e.g. use syncing
| credentials (as provided by many password managers,
| Google, and Apple).
|
| 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.
| lxgr wrote:
| There's no fundamental reason it needs to be this
| difficult.
|
| 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.
| filleokus wrote:
| I mean you could also design keys to be synchronisable by
| the user. Generate a key-pair inside of key (2), transfer
| the public key from (2) to (1). Encrypt the the root key
| inside of (1) with the public key, transfer it over to
| (2).
|
| (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.
| KAMSPioneer wrote:
| But what stops Mallory from simply using this sync method
| to sync your private key to her Yubikey? I mean, look at
| the kerfuffle that's been kicked up by this
| vulnerability, and a key-sharing scheme like the above is
| much easier to exploit.
|
| (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?)
| filleokus wrote:
| Yeah of course the operation needs to be
| (cryptographically) authenticated somehow, I edited my
| comment in haste while going to work and accidentally
| messed it up completely. Thanks for pointing it out!
|
| 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.)
| lxgr wrote:
| > (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...
| zahllos wrote:
| HSMs support these kinds of scenario (high availability
| clusters, wrapped keys etc) but I agree. For enterprise
| use there's no interest or need, and for end users the
| feature would potentially be confusing.
|
| I just use multiple tokens, and I knew that the infineon
| sle78 was an intel 80251 derivative before this report ;)
| thadt wrote:
| Good news then, since the article is discussing the discovery
| of that exact feature.
| mimimi31 wrote:
| >I don't remember where I've used my YubiKey in the past.
|
| I track this in my password manager. Accounts where the YubiKey
| is enrolled are tagged "YubiKey (FIDO)".
| dotancohen wrote:
| This would probably be a good place to suggest to others here
| to track which accounts you've logged into via Google or
| other social media oath.
|
| 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.
| shepherdjerred wrote:
| 1Password has this functionality and it's excellent.
| pjot wrote:
| Just fyi, Google lists sites you've used to "sign in with
| Google" in your account setting page. Apple and GitHub have
| this as well.
| dotancohen wrote:
| Thank you, I should review that.
| throwaway48476 wrote:
| You should assume Google, GitHub, and Apple are hostile
| and try to limit your blast radius. If you have an
| account problem they have no customer service to help
| you.
| hamburglar wrote:
| Yes, this is exactly why I won't use these federated
| identity features of platforms like this. I have a
| reasonable amount of trust that they are mostly secure,
| but I have zero trust that they will be _helpful_ if I
| ever have account troubles. What I don't need is to have
| Google (etc) auth problems cascade down to every other
| account I own.
| dotancohen wrote:
| Very well stated, concisely. Thank you.
| qingcharles wrote:
| I can't get into my Google account that's almost 20 years
| old because I only have the username, password, recovery
| email and have all the email forwarded to me, but I no
| longer have the phone number and they silently enabled
| 2FA SMS at some point.
| layla5alive wrote:
| +1
| quacksilver wrote:
| I wonder if you can phone the phone number, explain the
| situation and offer to venmo/paypal the new assignee
| money for the 2FA code
|
| You could try every 3 - 5 years or so as it gets
| reassigned again
| qingcharles wrote:
| I tried this before, but I haven't tried for a couple of
| years -- you're right, it might have got reassigned -- I
| will try again!
| nozzlegear wrote:
| I really wish Bitwarden had more robust tools for organizing,
| sorting and tagging passwords. The current system of sorting
| them into folders is practically useless.
| Arch-TK wrote:
| If you're using a yubikey solely for its PGP key stuff and you
| have a backup of the key or have a key hierarchy then replacing
| a yubikey is pretty trivial.
|
| (I know because it's my specific usecase.)
| lima wrote:
| Only if the key is generated off-key
| Arch-TK wrote:
| I meant to imply that with this statement:
|
| > and you have a backup of the key
| xaduha wrote:
| > I don't remember where I've used my YubiKey in the past.
|
| 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.
| girvo wrote:
| Yeah I stick to TOTP for the most part which means the YubiCo
| app has the list. I always enrol two keys though, one back up
| and one active.
| cvhc wrote:
| Another side. I always worry more about being locked out by 2FA
| (a main use case of non-discoverable FIDO keys) as a
| consequence of lost/retired-then-forgotten keys.
|
| 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.
| berdario wrote:
| > the US custom detained my electronics, including a Yubikey
|
| 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?
| vanchor3 wrote:
| If they just seize it, it will typically be returned at
| some point. If they decide it's subject to forfeiture, it
| is now their property. You can contest this with the
| forfeiture department but I guess if they decide the item
| is guilty of a crime or other excuses to keep it there's
| nothing you can do.
| plagiarist wrote:
| That's right. It will be United States v. Some Person's
| Yubikey. And you can hire it a lawyer if you want,
| because they will NOT give it a public defender. Massive
| violation of Constitutional rights if you ask me.
| cvhc wrote:
| For 1, tbh I don't know the rules. technically it was a
| regular model and can store some data. Or maybe they simply
| suspected it's a usb disk.
|
| And 2 was true. But it was after weeks, and of course I
| didn't wait until then to reset my account credentials.
| heavyset_go wrote:
| > _Yubikey (at least the old U2F-only ones) don 't have
| anything that you can extract_
|
| 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.
| lxgr wrote:
| The entire point of Yubikeys is that such a device should
| be impossible, and vice versa, if such a device were to
| exist, the Yubikey is nothing but an expensive USB flash
| drive.
| schoen wrote:
| It should also be a dramatically smaller attack surface
| than a smartphone!
| vaylian wrote:
| > 2- They would eventually return the device to you (unless
| guilty of some national security violation?)
|
| "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.
| londons_explore wrote:
| > without clarifying the alternative factors
|
| 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.
| throwaway48476 wrote:
| Unfortunately identity systems have adopted security
| through obscurity instead.
|
| 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.
| willis936 wrote:
| Maintaining a phone number is not security through
| obscurity.
| throwaway48476 wrote:
| The obscurity is that you have no idea what is required
| to log in.
| rodgerd wrote:
| There's a reason that Apple won't let you enable FIDO keys
| without having two of them to enroll.
| jopsen wrote:
| Most sites let you print recovery keys.
|
| Print those keys out, and bury them in the backyard (or
| something like that).
|
| Or always add two keys.
| alecco wrote:
| You should always have more than one 2FA. Especially for
| anything Google as you'll never ever recover the account
| (unless you are famous or go viral <1%).
| gabeio wrote:
| > But a few, including AWS, doesn't allow that.
|
| 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.
| oasisbob wrote:
| I don't think this is accurate - I have multiple MFA
| devices associated with all my AWS IAM users on multiple
| accounts of various ages.
|
| AWS documentation specifies that users are allowed upto
| eight MFA devices each:
|
| https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credent
| i...
| dboreham wrote:
| Sounds like functionality you could implement on a
| blockchain...
| lxgr wrote:
| You can implement most things on a blockchain, but only very
| rarely does that make any sense.
| DANmode wrote:
| > you cannot just replace a YubiKey.
|
| How would this work?
| duxup wrote:
| Everything about security / auth sucks in this age.
|
| 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.
| tptacek wrote:
| _3. Infineon has already a patch for their cryptographic library,
| to our knowledge it did not yet pass a Common Criteria
| certification evaluation._
|
| For what it's worth: this doesn't matter even a little bit.
| tialaramex wrote:
| As distinct from the attack itself? This is an interesting
| exercise and worth publishing, but in practice I don't see much
| real world consequence even for a notionally vulnerable device.
| wkat4242 wrote:
| Huh I thought they used an NXP secure element.
|
| But I see now that was the yubikey neo, the 5 is Indeed infineon
| jenny91 wrote:
| You have to practically destroy the YubiKey in the process of
| extracting the secret, however.
| Pr0ject217 wrote:
| Is that relevant? The secret is the value.
| lima wrote:
| Could just steal the key at that point.
| clysm wrote:
| Doubtful once the attack is refined. Their capture requirement
| of 200 traces is trivially low.
| traceroute66 wrote:
| I see the Yubico website says 5.7 or greater not affected.
|
| 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
|
| Hopefully they've had lots of eyes looking at that ! Not sure why
| anybody feels the need to write their own crypto libraries these
| days, there are so many implementations out there, both open and
| closed source.
|
| [1] https://www.yubico.com/blog/now-available-for-purchase-
| yubik...
| vlovich123 wrote:
| An embedded platform that hasn't been ported to and may be
| impractical to port to because it's so different. There may be
| other reasons and for closed source there may be economic
| considerations especially since this is a migration from a
| previous closed source (probably source available) vendor to an
| in house solution.
| kevin_thibedeau wrote:
| MbedTLS has all the crypto primitives and runs anywhere.
| bsder wrote:
| And had so many _stupid_ bugs that it looked like it was
| written by summer interns. Everybody I know who actually
| worries about actual security ran far, far away from it.
|
| If, however, you just need https for web pages, it's good
| enough to get started.
| lxgr wrote:
| Including the very, very limited environment of secure
| elements, and the capability of interfacing with the
| sometimes very specialized cryptographic
| accelerators/coprocessors required for adequate
| performance?
|
| 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.
| dlgeek wrote:
| > Not sure why anybody feels the need to write their own crypto
| libraries these days
|
| 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.
| Night_Thastus wrote:
| When was the first time?
| dlgeek wrote:
| 2017: https://www.yubico.com/support/security-
| advisories/ysa-2017-...
| umvi wrote:
| When was 5.7 released?
| ethanol-brain wrote:
| Around June of this year.
| shellcromancer wrote:
| Fantastic research by NinjaLab. One of the most interesting parts
| to me from Yubico's advisory is that the Webauthn protocols
| attestation [1] is also defeated by this local cloning. Could the
| protocol have been better designed to resist this local cloning
| attack?
|
| > 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.
|
| 1. https://www.w3.org/TR/webauthn-2/#attestation
| sitharus wrote:
| > Could the protocol have been better designed to resist this
| local cloning attack?
|
| 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.
| jtvjan wrote:
| Perhaps some kind of rolling key system could've been used?
| If the key was rewritten on each successful login, either the
| attacker would have to use their cloned key immediately
| (alerting the user), or have their cloned key become useless
| the moment the user logs in again. This would only work with
| discoverable credentials, and would increase wear on the
| device's flash storage.
| Scaevolus wrote:
| Even with extraction possible, it's much harder to get the
| keys from this device than a file on a computer.
|
| Security isn't just the binary of "possible" vs "impossible".
| It's about *how expensive" that possibility is.
| magicalhippo wrote:
| The login service could send not just the request, but also N
| random bits for the next session.
|
| 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.
| lxgr wrote:
| Not really, unfortunately, given that attestation practically
| always depends on some piece of secure hardware being able to
| guard an issuer-certified secret with which it can authenticate
| itself to a relying party and thereby bootstrap trust into any
| derived/stored secrets.
|
| 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.
| jacekm wrote:
| If you have a Yubi Key and you are worried, read this part from
| their report:
|
| > 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.
| mzs wrote:
| Once it's cloned can't the attacker create a new one for you
| that looks like the previous one you had?
| cvhc wrote:
| In the FIDO2 case, only the derived keys are extracted. The
| master key that derives non-resident keys isn't extracted. So
| I think it's not possible to really copy the key.
|
| 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.
| AdmiralAsshat wrote:
| Did they verify whether older keys are vulnerable, or did they
| not bother to test?
| Arch-TK wrote:
| Don't have high hopes for this but I just requested a replacement
| device through their support system as the offered mitigations
| are not something I would like to consider.
| gwbas1c wrote:
| > primary goal is to fight the scourge of phishing attacks. The
| EUCLEAK attack requires physical access to the device
|
| 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.
| malfist wrote:
| Seriously, it's trivial to fry a key and swap it with the
| working spare if you have access to it
| bigfatkitten wrote:
| > 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.
| SahAssar wrote:
| > 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.
|
| 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?
| gwbas1c wrote:
| > You can inspect a yubikeys identity with
|
| 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.
| SahAssar wrote:
| > Who's going to do that?
|
| 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.
| klaussilveira wrote:
| Subdermal Yubikey when?
| lxgr wrote:
| Whenever you're ready!
|
| 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)
| toastal wrote:
| Are they all based on Java?
| lxgr wrote:
| There also seem to be simpler fixed-function implants (e.g.
| NTAG or similar NDEF-storage-only tags), but I don't think
| there's anything non-Java capable of doing something as
| complex as CTAP2.
|
| 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.
| inhumantsar wrote:
| oooo that is tempting
| DANmode wrote:
| Troll the right ActivityPub posts, you'll find someone(s) who
| have put an NFC key under their skin.
| SV_BubbleTime wrote:
| I know a guy that did it. Deviant is a lock picking guru, and
| this is a nerdy trick he does occasionally.
| altairprime wrote:
| > YubiEnterprise Subscription customers can leverage their
| available replacement entitlements to receive YubiKeys with the
| new firmware.
| create-username wrote:
| I've created two TOTP 2FA on two different YubiKeys. During the
| TOPT configuration process, the website gives me a password that
| I enter on the YubiKey configuration app.
|
| 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?
| lxgr wrote:
| > But if I stored it on Bitwarden, I could easily create a
| YubiKey backup or set it on another app like ente.
|
| 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.
| create-username wrote:
| I'd rather keep passwords, TOTP and backup keys in different
| services because I never saw the point of keeping them
| together with the passwords as you explain.
|
| 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
| lxgr wrote:
| That's reasonable, but then you can't store the TOTP setup
| code in your regular password manager (and vice versa, if
| you do, that's not different from just using the PW
| manager's native TOTP calculation feature).
|
| 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.
| londons_explore wrote:
| > due to a non constant-time modular inversion.
|
| 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?
| SV_BubbleTime wrote:
| Agreed. I was hoping to see something really high end. But it's
| a standard timing attack with a fancy probe.
|
| The probe is cool though.
| some_furry wrote:
| It's one of the first things I check for in my reviews of ECDSA
| code. It's embarrassing for Infineon.
| lxgr wrote:
| > That isn't exactly some subtle side channel involving tiny
| emissions of radio waves...
|
| 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.
| kayson wrote:
| > 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.
|
| Are you sure? Section 4.3 (pg 52) starts with "The leaked
| sensitive information relates to the execution time of
| Algorithms 1 and 4."
| lxgr wrote:
| Maybe my terminology is off here, but a "pure time leak" to
| me would be something like a given operation varying in
| return time (i.e. execution time/latency being a function
| of some secret data), whereas this seems more like all
| operations take constant time, but in that constant time,
| RF emissions vary in their timing (e.g. on/off, strong/weak
| etc.) as a function of some secret data.
| xyst wrote:
| > All YubiKey 5 Series (with firmware version below 5.7) are
| impacted by the attack ...
|
| 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...
| hi-v-rocknroll wrote:
| 5.4.3 5C Nano here.
|
| > L. So, Yubico is providing _free_ replacements, right?
|
| Nope, mitigations. :(
|
| https://support.yubico.com/hc/en-us/articles/15705749884444-...
| gwbas1c wrote:
| Yubikeys are intended to block phishing. This attack requires
| physical access.
|
| 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.
| anilakar wrote:
| The last time Infineon chips had a crypto-breaking bug,
| Estonians got new ID cards for free. Meanwhile my less than two
| months old Yubikey 4 stopped working as a hardware attested PIV
| smartcard.
| SahAssar wrote:
| > Meanwhile my less than two months old Yubikey 4 stopped
| working as a hardware attested PIV smartcard.
|
| As in that the hardware broke? Or software stopped supporting
| it?
| rpncreator wrote:
| TIL you need to update the firmware on Yubikeys.
| HeatrayEnjoyer wrote:
| Update by buying.
| autoexec wrote:
| That's convenient for the company selling products that need
| to be updated to be secure.
| badgersnake wrote:
| Last time they sent me a replacement for free. This was for a
| problem with generating ssh keys.
| alienchow wrote:
| This requires the attacker to steal your key. When that happens,
| by the time they can get the secret key I've already revoked it.
|
| 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?
| heavyset_go wrote:
| > _This requires the attacker to steal your key. When that
| happens, by the time they can get the secret key I 've already
| revoked it._
|
| 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.
| acdha wrote:
| That's a different situation outside of most people's
| reasonable threat model. The police don't need to clone your
| Yubikey if they can use it as much as they want, and if they
| decide to go NYPD on you nothing else you do is going to end
| in a different outcome unless your MFA check is an in-person
| confirmation in a location outside of their control.
| bigfatkitten wrote:
| Though in this scenario, your adversary doesn't need to
| resort to a technical attack to clone your key. They can
| compel you to comply, and keep you locked up until you do.
| pitaj wrote:
| They swap your device with an identical replacement that just
| appears to be broken. You are none the wiser while they clone
| your keys.
| WaitWaitWha wrote:
| The article notes "The attack requires physical access to the
| secure element (few local electromagnetic side-channel
| acquisitions, i.e. _few minutes, are enough_ ) in order to
| extract the ECDSA secret key." (emphasis added)
|
| evil maid?
| rasengan0 wrote:
| gotta bunch of yubis and was about to ask about
| https://store.google.com/product/titan_security_key then found
| https://ninjalab.io/a-side-journey-to-titan/ by the same folks
| lxgr wrote:
| Does anybody know if plain ECDH (as used by e.g. ICAO biometric
| passports implementing PACE) or Ed25519 (assuming Infineon's
| chips/libraries implement that) are impacted?
|
| 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.
| globalise83 wrote:
| Infineon is a listed company, not sure how much news will be
| published on this before German and Austrian markets open in a
| couple of hours so could be a profitable short selling
| opportunity.
| visualblind wrote:
| Looks like the site is down. Appears to be a VPS on Ghandi's
| platform.
| tommiegannert wrote:
| > The new YubiKey firmware 5.7 update (May 6th, 2024) switches
| the YubiKeys from Infineon cryptographic library to Yubico new
| cryptographic library. To our knowledge, this new cryptographic
| library is not impacted by our work.
|
| 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
| [---]
| jwr wrote:
| Good thing I use my YubiKeys with RSA keys, protected with a PIN,
| following the most excellent guide by DrDuh.
| lawn wrote:
| Be a bit careful with RSA keys as keys shorter than 3072 aren't
| recommended anymore.
| nicman23 wrote:
| really never got the whole concept of what is basically is a tpm
| that advertises "money here"
|
| software otp in a phone or something that is able to be updated
| seems to be a better choice
| hacker_88 wrote:
| The happiest are Hollywood writers .
| nullc wrote:
| It's really easy to blind a variable time modular inverse,
| assuming you have a random number generator handy: you want the
| inverse of x, compute instead the inverse of x*r, then multiply
| the result with r.
|
| 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).
| fuklief wrote:
| > 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?
| nullc wrote:
| The powering ladder is unfortunately quite slow compared to
| the obvious vartime algorithm which is what temps these
| things to have a vartime algorithim in the first place,
| though too slow depends on the application. It doesn't help
| that these chips are underpowered to begin with.
|
| 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().
| gatestone wrote:
| Can you explain me, why do you need to be online to extract the
| private key? Can't you just steal the token, input the nonces
| offline, and meter timing? Then, crunch out the private key, and
| only then, if needed, phish the password?
| lxgr wrote:
| Yubikeys and similar FIDO hardware authenticators roughly
| speaking have two modes of operation:
|
| 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.
| nabla9 wrote:
| Daniel J. Bernstein
| https://mathstodon.xyz/@djb@cr.yp.to/113079723152809027
|
| > 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.
___________________________________________________________________
(page generated 2024-09-04 23:01 UTC)