19 ms·

EUCLEAK Side-Channel Attack on the YubiKey 5 Series

706 points by GTP 2y ago

AdmiralAsshat 2y ago
Did they verify whether older keys are vulnerable, or did they not bother to test?
Arch-TK 2y ago
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 2y ago
> 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 2y ago
  Seriously, it's trivial to fry a key and swap it with the working spare if you have access to it
- bigfatkitten 2y ago
  > 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 2y ago
  > 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 2y ago
    > 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 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 2y ago
      > 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 2y ago
Subdermal Yubikey when?
- lxgr 2y ago
  Whenever you're ready! Hardware: https://dangerousthings.com/product/flexsecure/ https://dangerousthings.com/product/flexsecure/ Software: https://github.com/darconeous/u2f-javacard https://github.com/darconeous/u2f-javacard (or https://github.com/BryanJacobs/FIDO2Applet 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 2y ago
    Are they all based on Java?
    - lxgr 2y ago
      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 2y ago
    oooo that is tempting
- DANmode 2y ago
  Troll the right ActivityPub posts, you'll find someone(s) who have put an NFC key under their skin.
  - SV_BubbleTime 2y ago
altairprime 2y ago
> YubiEnterprise Subscription customers can leverage their available replacement entitlements to receive YubiKeys with the new firmware.
create-username 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
      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 2y ago
> 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 2y ago
  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 2y ago
  It's one of the first things I check for in my reviews of ECDSA code. It's embarrassing for Infineon.
- lxgr 2y ago
  > 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 2y ago
    > 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."
xyst 2y ago
> 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-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 2y ago
  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-Infineon-ECDSA-Private-Key-Recovery-Customer-Resources https://support.yubico.com/hc/en-us/articles/15705749884444-...
- gwbas1c 2y ago
  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 2y ago
  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 2y ago
    > 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?
    - anilakar 2y ago
      Software that keeps revocation lists (or whatever they are called) up to date stopped accepting keys generated on that hardware. The Yubikey itself continued to work just fine, but I had to switch to externally generated keys.
rpncreator 2y ago
TIL you need to update the firmware on Yubikeys.
- HeatrayEnjoyer 2y ago
  Update by buying.
  - autoexec 2y ago
    That's convenient for the company selling products that need to be updated to be secure.
  - badgersnake 2y ago
    Last time they sent me a replacement for free. This was for a problem with generating ssh keys.
alienchow 2y ago
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 2y ago
  >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 2y ago
    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 2y ago
    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.
    - heavyset_go 2y ago
      They can, but assuming the law is actually being followed, you can only be held for so long without charges, and can be compelled to provide so much testimony. Being able to quickly clone keys gives any LEO an opportunity to access your digital life as part of a simple stop versus a full criminal case.
rasengan0 2y ago
gotta bunch of yubis and was about to ask about https://store.google.com/product/titan_security_key https://store.google.com/product/titan_security_key then found https://ninjalab.io/a-side-journey-to-titan/ https://ninjalab.io/a-side-journey-to-titan/ by the same folks
lxgr 2y ago
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.
auugngg 2y ago
[flagged]
globalise83 2y ago
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.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
visualblind 2y ago
Looks like the site is down. Appears to be a VPS on Ghandi's platform.
tommiegannert 2y ago
> 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 [---]
- lxgr 2y ago
  On the other hand: The commonly-used library contained a vulnerability that went undetected for 14 years. Yubico is also very much in the business of embedded and side-channel-hardened cryptography. This might just be one of the cases where switching to custom code is the right move.
jwr 2y ago
Good thing I use my YubiKeys with RSA keys, protected with a PIN, following the most excellent guide by DrDuh.
- lawn 2y ago
  Be a bit careful with RSA keys as keys shorter than 3072 aren't recommended anymore.
nicman23 2y ago
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
elena567 2y ago
[dead]
hacker_88 2y ago
The happiest are Hollywood writers .
nullc 2y ago
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 2y ago
  > 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 2y ago
    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().
romybrielle1 2y ago
[dead]
gatestone 2y ago
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 2y ago
  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.
deleted 2y ago
[deleted]
nabla9 2y ago
Daniel J. Bernstein https://mathstodon.xyz/@djb@cr.yp.to/113079723152809027 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 https://gcd.cr.yp.to; (2) switching from ECDSA to EdDSA, typically Ed25519; (3) using TIMECOP (https://bench.cr.yp.to/tips.html#timecop https://bench.cr.yp.to/tips.html#timecop) to scan for leaks.
madisonandrea 2y ago
[dead]
Chambermason864 2y ago
[flagged]
Danielle029 2y ago
[dead]
deleted 2y ago
[deleted]
jcfrei 2y ago
FYI: This page gets stuck at 99% on firefox (130.0).
- totony 2y ago
  I used ublock origin to block the overlay and loading indicator. A loading indicator on a website is bad practice anyway imo
- USiBqidmOOkAqRb 2y ago
  .pace-overlay{display:none} I don't get why people add these loaders.
- scrlk 2y ago
  Was quite slow for me, but eventually loaded. Here's the Yubikey security advisory: https://www.yubico.com/support/security-advisories/ysa-2024-03/ https://www.yubico.com/support/security-advisories/ysa-2024-...
- amatecha 2y ago
  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 2y ago
  https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucleak.pdf https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl... Write up there.
- deleted 2y ago
  [deleted]
TavsiE9s 2y ago
Does not sound like they're issuing replacement devices.
- cryptonector 2y ago
  Yeah, I see no indication of that on their blog, and you can't flash the firmware.
  - traceroute66 2y ago
    > 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.
    - cryptonector 2y ago
      > Not being able to flash the firmware is a feature, not a bug. :) Indeed, but I didn't say otherwise :)
    - wiktor-k 2y ago
      > 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 2y ago
  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 2y ago
    IIRC the last time something similar happened they issued replacement devices... I'm a bit baffled that they're not offering a replacement programme.
tomas789 2y ago
> 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 2y ago
  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 2y ago
    No worries. I trust my government.
madars 2y ago
PDF of the EUCLEAK writeup: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucleak.pdf https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl... Yubico blogpost: https://www.yubico.com/support/security-advisories/ysa-2024-03/ https://www.yubico.com/support/security-advisories/ysa-2024-...
bangaladore 2y ago
Additionally, it looks like this vulnerability exist on on all Infineon trusted X (platform modules, microcontrollers, etc...) that use the same internal crypto libraries.
- _dabs 2y ago
  This vulnerability is present when using the affected combination of Infineon Hardware with the infineon cryptolib
  - bangaladore 2y ago
    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.
noodlesUK 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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
deleted 2y ago
[deleted]
edent 2y ago
As per https://arstechnica.com/security/2024/09/yubikeys-are-vulnerable-to-cloning-attacks-thanks-to-newly-discovered-side-channel/ 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.
- MetaWhirledPeas 2y ago
  > 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 2y ago
    > 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 2y ago
      But if you store everything in the password manager, it's no longer two factor.
      - lxgr 2y ago
        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 2y ago
ycombinatrix 2y ago
i guess this breaks fido attestation for a lot of use cases since most yubikeys can be spoofed now
mcwhy 2y ago
Infenion strikes again, 7 years ago: https://en.wikipedia.org/wiki/ROCA_vulnerability https://en.wikipedia.org/wiki/ROCA_vulnerability
OptionOfT 2y ago
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-vulnerable-to-cloning-attacks-thanks-to-newly-discovered-side-channel/ https://arstechnica.com/security/2024/09/yubikeys-are-vulner... [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_sometimes_not_required/ https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...
- webstrand 2y ago
  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 2y ago
    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 2y ago
      You register 4 keys on each website?
      - fragmede 2y ago
        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.
tptacek 2y ago
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 2y ago
  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 2y ago
Huh I thought they used an NXP secure element. But I see now that was the yubikey neo, the 5 is Indeed infineon
jenny91 2y ago
You have to practically destroy the YubiKey in the process of extracting the secret, however.
- Pr0ject217 2y ago
  Is that relevant? The secret is the value.
  - lima 2y ago
    Could just steal the key at that point.
- clysm 2y ago
  Doubtful once the attack is refined. Their capture requirement of 200 traces is trivially low.
traceroute66 2y ago
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-yubikey-5-series-and-security-key-series-with-new-5-7-firmware/ https://www.yubico.com/blog/now-available-for-purchase-yubik...
- dlgeek 2y ago
  > 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 2y ago
    When was the first time?
    - dlgeek 2y ago
      2017: https://www.yubico.com/support/security-advisories/ysa-2017-01/ https://www.yubico.com/support/security-advisories/ysa-2017-...
- umvi 2y ago
  When was 5.7 released?
  - ethanol-brain 2y ago
    Around June of this year.
shellcromancer 2y ago
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 https://www.w3.org/TR/webauthn-2/#attestation
- sitharus 2y ago
  > 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 2y ago
    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 2y ago
    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 2y ago
jacekm 2y ago
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 2y ago
  Once it's cloned can't the attacker create a new one for you that looks like the previous one you had?
  - cvhc 2y ago
    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.

706 points by GTP 2y ago

Did they verify whether older keys are vulnerable, or did they not bother to test?

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 2y ago

> 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 2y ago
Seriously, it's trivial to fry a key and swap it with the working spare if you have access to it
bigfatkitten 2y ago
> 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 2y ago
> 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 2y ago
  > 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 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 2y ago
    > 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 2y ago

Subdermal Yubikey when?

lxgr 2y ago
Whenever you're ready! Hardware: https://dangerousthings.com/product/flexsecure/ https://dangerousthings.com/product/flexsecure/ Software: https://github.com/darconeous/u2f-javacard https://github.com/darconeous/u2f-javacard (or https://github.com/BryanJacobs/FIDO2Applet 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 2y ago
  Are they all based on Java?
  - lxgr 2y ago
    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 2y ago
  oooo that is tempting
DANmode 2y ago
Troll the right ActivityPub posts, you'll find someone(s) who have put an NFC key under their skin.
- SV_BubbleTime 2y ago

altairprime 2y ago

> YubiEnterprise Subscription customers can leverage their available replacement entitlements to receive YubiKeys with the new firmware.

create-username 2y ago

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 2y ago
> 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 2y ago
  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 2y ago
    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 2y ago

> 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 2y ago
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 2y ago
It's one of the first things I check for in my reviews of ECDSA code. It's embarrassing for Infineon.
lxgr 2y ago
> 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 2y ago
  > 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."

xyst 2y ago

> 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-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 2y ago
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-Infineon-ECDSA-Private-Key-Recovery-Customer-Resources https://support.yubico.com/hc/en-us/articles/15705749884444-...
gwbas1c 2y ago
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 2y ago
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 2y ago
  > 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?
  - anilakar 2y ago
    Software that keeps revocation lists (or whatever they are called) up to date stopped accepting keys generated on that hardware. The Yubikey itself continued to work just fine, but I had to switch to externally generated keys.

rpncreator 2y ago

TIL you need to update the firmware on Yubikeys.

HeatrayEnjoyer 2y ago
Update by buying.
- autoexec 2y ago
  That's convenient for the company selling products that need to be updated to be secure.
- badgersnake 2y ago
  Last time they sent me a replacement for free. This was for a problem with generating ssh keys.

alienchow 2y ago

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 2y ago
>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 2y ago
  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 2y ago
  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.
  - heavyset_go 2y ago
    They can, but assuming the law is actually being followed, you can only be held for so long without charges, and can be compelled to provide so much testimony. Being able to quickly clone keys gives any LEO an opportunity to access your digital life as part of a simple stop versus a full criminal case.

rasengan0 2y ago

gotta bunch of yubis and was about to ask about https://store.google.com/product/titan_security_key https://store.google.com/product/titan_security_key then found https://ninjalab.io/a-side-journey-to-titan/ https://ninjalab.io/a-side-journey-to-titan/ by the same folks

lxgr 2y ago

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.

auugngg 2y ago

[flagged]

globalise83 2y ago

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.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

visualblind 2y ago

Looks like the site is down. Appears to be a VPS on Ghandi's platform.

tommiegannert 2y ago

> 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 [---]

lxgr 2y ago
On the other hand: The commonly-used library contained a vulnerability that went undetected for 14 years. Yubico is also very much in the business of embedded and side-channel-hardened cryptography. This might just be one of the cases where switching to custom code is the right move.

jwr 2y ago

Good thing I use my YubiKeys with RSA keys, protected with a PIN, following the most excellent guide by DrDuh.

lawn 2y ago
Be a bit careful with RSA keys as keys shorter than 3072 aren't recommended anymore.

nicman23 2y ago

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

elena567 2y ago

[dead]

hacker_88 2y ago

The happiest are Hollywood writers .

nullc 2y ago

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 2y ago
> 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 2y ago
  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().

romybrielle1 2y ago

[dead]

gatestone 2y ago

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 2y ago
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.

deleted 2y ago

[deleted]

nabla9 2y ago

Daniel J. Bernstein https://mathstodon.xyz/@djb@cr.yp.to/113079723152809027 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 https://gcd.cr.yp.to; (2) switching from ECDSA to EdDSA, typically Ed25519; (3) using TIMECOP (https://bench.cr.yp.to/tips.html#timecop https://bench.cr.yp.to/tips.html#timecop) to scan for leaks.

madisonandrea 2y ago

[dead]

Chambermason864 2y ago

[flagged]

Danielle029 2y ago

[dead]

deleted 2y ago

[deleted]

jcfrei 2y ago

FYI: This page gets stuck at 99% on firefox (130.0).

totony 2y ago
I used ublock origin to block the overlay and loading indicator. A loading indicator on a website is bad practice anyway imo
USiBqidmOOkAqRb 2y ago
.pace-overlay{display:none} I don't get why people add these loaders.
scrlk 2y ago
Was quite slow for me, but eventually loaded. Here's the Yubikey security advisory: https://www.yubico.com/support/security-advisories/ysa-2024-03/ https://www.yubico.com/support/security-advisories/ysa-2024-...
amatecha 2y ago
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 2y ago
https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucleak.pdf https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl... Write up there.
deleted 2y ago
[deleted]

TavsiE9s 2y ago

Does not sound like they're issuing replacement devices.

cryptonector 2y ago
Yeah, I see no indication of that on their blog, and you can't flash the firmware.
- traceroute66 2y ago
  > 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.
  - cryptonector 2y ago
    > Not being able to flash the firmware is a feature, not a bug. :) Indeed, but I didn't say otherwise :)
  - wiktor-k 2y ago
    > 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 2y ago
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 2y ago
  IIRC the last time something similar happened they issued replacement devices... I'm a bit baffled that they're not offering a replacement programme.

tomas789 2y ago

> 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 2y ago
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 2y ago
  No worries. I trust my government.

madars 2y ago

PDF of the EUCLEAK writeup: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucleak.pdf https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl... Yubico blogpost: https://www.yubico.com/support/security-advisories/ysa-2024-03/ https://www.yubico.com/support/security-advisories/ysa-2024-...

bangaladore 2y ago

Additionally, it looks like this vulnerability exist on on all Infineon trusted X (platform modules, microcontrollers, etc...) that use the same internal crypto libraries.

_dabs 2y ago
This vulnerability is present when using the affected combination of Infineon Hardware with the infineon cryptolib
- bangaladore 2y ago
  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.

noodlesUK 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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

deleted 2y ago

[deleted]

edent 2y ago

As per https://arstechnica.com/security/2024/09/yubikeys-are-vulnerable-to-cloning-attacks-thanks-to-newly-discovered-side-channel/ 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.

MetaWhirledPeas 2y ago
> 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 2y ago
  > 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 2y ago
    But if you store everything in the password manager, it's no longer two factor.
    - lxgr 2y ago
      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 2y ago

ycombinatrix 2y ago

i guess this breaks fido attestation for a lot of use cases since most yubikeys can be spoofed now

mcwhy 2y ago

Infenion strikes again, 7 years ago: https://en.wikipedia.org/wiki/ROCA_vulnerability https://en.wikipedia.org/wiki/ROCA_vulnerability

OptionOfT 2y ago

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-vulnerable-to-cloning-attacks-thanks-to-newly-discovered-side-channel/ https://arstechnica.com/security/2024/09/yubikeys-are-vulner... [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_sometimes_not_required/ https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

webstrand 2y ago
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 2y ago
  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 2y ago
    You register 4 keys on each website?
    - fragmede 2y ago
      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.

tptacek 2y ago

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 2y ago
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 2y ago

Huh I thought they used an NXP secure element. But I see now that was the yubikey neo, the 5 is Indeed infineon

jenny91 2y ago

You have to practically destroy the YubiKey in the process of extracting the secret, however.

Pr0ject217 2y ago
Is that relevant? The secret is the value.
- lima 2y ago
  Could just steal the key at that point.
clysm 2y ago
Doubtful once the attack is refined. Their capture requirement of 200 traces is trivially low.

traceroute66 2y ago

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-yubikey-5-series-and-security-key-series-with-new-5-7-firmware/ https://www.yubico.com/blog/now-available-for-purchase-yubik...

dlgeek 2y ago
> 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 2y ago
  When was the first time?
  - dlgeek 2y ago
    2017: https://www.yubico.com/support/security-advisories/ysa-2017-01/ https://www.yubico.com/support/security-advisories/ysa-2017-...
umvi 2y ago
When was 5.7 released?
- ethanol-brain 2y ago
  Around June of this year.

shellcromancer 2y ago

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 https://www.w3.org/TR/webauthn-2/#attestation

sitharus 2y ago
> 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 2y ago
  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 2y ago
  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 2y ago

jacekm 2y ago

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 2y ago
Once it's cloned can't the attacker create a new one for you that looks like the previous one you had?
- cvhc 2y ago
  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.