[HN Gopher] EUCLEAK Side-Channel Attack on the YubiKey 5 Series
___________________________________________________________________
EUCLEAK Side-Channel Attack on the YubiKey 5 Series
Author : GTP
Score : 290 points
Date : 2024-09-03 12:54 UTC (10 hours 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
| 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".
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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.
| 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).
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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
| 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)
| DANmode wrote:
| Troll the right ActivityPub posts, you'll find someone(s) who
| have put an NFC key under their skin.
| 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.
___________________________________________________________________
(page generated 2024-09-03 23:00 UTC)