Despite this affecting only FIDO and barely any Yubikeys are being used for that, it’s important to keep in mind that exploits and attacks get worse over time. For now it’s just FIDO and requires complex hardware and practically destroying the key. I wouldn’t be surprised if this exploit is just the beginning.
It doesn’t affect their newest keys, but you can’t upgrade an older key to fix it:
All YubiKeys running firmware prior to version 5.7—which was released in May and replaces the Infineon cryptolibrary with a custom one—are vulnerable. Updating key firmware on the YubiKey isn’t possible. That leaves all affected YubiKeys permanently vulnerable.
Which is why I’m now questioning why I even bought them to begin with. Any time a security flaw is found I need to spend another $50-60. Seem crazy and wasteful.
Reading the article I think most people don’t need to worry about upgrading because of this flaw; this would be a very targeted attack. And I can understand not letting the firmware upgrade; I’m pretty sure I’ve seen examples of nation-state hacks for phones that involve attackers installing an “upgraded firmware” that disables security protections to access otherwise secured info. But yeah, cost is definitely a risk with this design.
But there’s open FIDO2 sticks around. One would be SoloKeys. Then there’s other competitors, though not open.
But if you mean, simple authentication via stick, sure. Or you could do your own thing, watching via udev for the MAC ID, write a file somewhere sensitive and look in your login script if it exists.
apparently this is an issue with some part of the hardware that lots of hardware security devices use too, so not as simple as just buying/building an alternative
The attacker would need physical possession of the YubiKey, Security Key, or YubiHSM, knowledge of the accounts they want to target and specialized equipment to perform the necessary attack. Depending on the use case, the attacker may also require additional knowledge including username, PIN, account password, or authentication key.
The attacks require about $11,000 worth of equipment and a sophisticated understanding of electrical and cryptographic engineering. The difficulty of the attack means it would likely be carried out only by nation-states or other entities with comparable resources and then only in highly targeted scenarios. The likelihood of such an attack being used widely in the wild is extremely low.
Given this massive caveat I’d almost call that headline misleading
I would argue that if the attacker has physical possession of my yubikey, that alone means the accounts tied to it are vulnerable. While the information isn’t technically wrong, I feel like that headline is misleading and this isn’t as big of a deal as some would like to make it out as.
Knowledge of the account is an obvious caveat.
Yubikey-based MFA is an added layer of protection for accounts, so any kind of attack against MFA assumes the attacker already knows which account to target.
It’s like saying “our door lock is flawed, but the attacker would need to have knowledge of the door”.
The cost and complexity is what’s noteworthy and is more relevant. Although attack cost and complexity usuallu goes down with advances in tooling and research. So it may be a good idea to plan a progressive retirement of affected keys.
While the researchers have confirmed all YubiKey 5 series models can be cloned, they haven’t tested other devices using the microcontroller, such as the SLE78 made by Infineon and successor microcontrollers known as the Infineon Optiga Trust M and the Infineon Optiga TPM. The researchers suspect that any device using any of these three microcontrollers and the Infineon cryptographic library contains the same vulnerability.
Both. The cryptographic library in question is also used in other cryptographic applications too, so it’s a huge mess.
It’s due to a cryptographic library implementation in a controller used in the yubikey. It’s a third party controller, and this isn’t exclusive to yubikeys either, a shitload of other stuff uses the same controller and is likely vulnerable to the same attack.
Also, the attack requires around $10k worth of equipment and physical access to the yubikey, so while a valid attack vector, it’s also not something to get into a panic about.
In fact reading through the article it sounds like they would need to use it to extract the secret. I guess the end goal for this would be to maintain surreptitious access to something after returning the key to the target, either to build a criminal case or for espionage purposes.
Given that the vulnerability may also apply to other secure access card/devices I suppose it could also be used if a nation-state wanted to use an impostor to access secure facilities.
Can i create such a thing for qubes os? Would be cool the have decryption screen look like windows login and if duress password entered it boots to a live windows image instead and obviously sends out relevent alerts etc. I suppose u would also want a second duress password that just shreds everything as well.
It’s pretty concerning if my backup key can just be cloned that easily. It means now I need to invest in a much better safe, which I guess was probably always a good idea.
Also, at least for the Yubi implementation, fixable in software, firmware >= 5.7 not vulnerable. Also not upgradeable, so replace keys if you’re worried about nation-state attacks.
I went into the article thinking I’d need to replace my keys, and after reading decided I’m a very unlikely target for this attack. My threat model doesn’t include nation states, so I’m gonna keep using my yubikeys for the foreseeable future.
I have been thinking about new hardware key(s) that can handle more than 20 passkeys, but that’s not a high priority for me right now.
It’s definitely not something a regular user should panic over. But it’s a huge deal since a lot of high security, sensitive targets also rely on the same library.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !privacyguides@lemmy.one
In the digital age, protecting your personal information might seem like an impossible task. We’re here to help.
This is a community for sharing news about privacy, posting information about cool privacy tools and services, and getting advice about your privacy journey.
You can subscribe to this community from any Kbin or Lemmy instance:
Check out our website at privacyguides.org before asking your questions here. We’ve tried answering the common questions and recommendations there!
Want to get involved? The website is open-source on GitHub, and your help would be appreciated!
This community is the “official” Privacy Guides community on Lemmy, which can be verified here. Other “Privacy Guides” communities on other Lemmy servers are not moderated by this team or associated with the website.
Moderation Rules:
We prefer posting about open-source software whenever possible.
No soliciting engagement: Don’t ask for upvotes, follows, etc.
Surveys, Fundraising, and Petitions must be pre-approved by the mod team.
Be civil, no violence, hate speech. Assume people here are posting in good faith.
Don’t repost topics which have already been covered here.
News posts must be related to privacy and security, and your post title must match the article headline exactly. Do not editorialize titles, you can post your opinions in the post body or a comment.
Memes/images/video posts that could be summarized as text explanations should not be posted. Infographics and conference talks from reputable sources are acceptable.
No help vampires: This is not a tech support subreddit, don’t abuse our community’s willingness to help. Questions related to privacy, security or privacy/security related software and their configurations are acceptable.
No misinformation: Extraordinary claims must be matched with evidence.
Do not post about VPNs or cryptocurrencies which are not listed on privacyguides.org. See Rule 2 for info on adding new recommendations to the website.
General guides or software lists are not permitted. Original sources and research about specific topics are allowed as long as they are high quality and factual. We are not providing a platform for poorly-vetted, out-of-date or conflicting recommendations.
I spent so much on these keys wth
Despite this affecting only FIDO and barely any Yubikeys are being used for that, it’s important to keep in mind that exploits and attacks get worse over time. For now it’s just FIDO and requires complex hardware and practically destroying the key. I wouldn’t be surprised if this exploit is just the beginning.
It doesn’t affect their newest keys, but you can’t upgrade an older key to fix it:
Which is why I’m now questioning why I even bought them to begin with. Any time a security flaw is found I need to spend another $50-60. Seem crazy and wasteful.
Reading the article I think most people don’t need to worry about upgrading because of this flaw; this would be a very targeted attack. And I can understand not letting the firmware upgrade; I’m pretty sure I’ve seen examples of nation-state hacks for phones that involve attackers installing an “upgraded firmware” that disables security protections to access otherwise secured info. But yeah, cost is definitely a risk with this design.
Can I roll my own with just USB and GPG?
https://old.reddit.com/r/privacytoolsIO/comments/ibajud/is_it_possible_to_make_a_security_key_by_myself/
But there’s open FIDO2 sticks around. One would be SoloKeys. Then there’s other competitors, though not open.
But if you mean, simple authentication via stick, sure. Or you could do your own thing, watching via udev for the MAC ID, write a file somewhere sensitive and look in your login script if it exists.
apparently this is an issue with some part of the hardware that lots of hardware security devices use too, so not as simple as just buying/building an alternative
It seems to be largely the same attack that succeeded against Google’s Titan keys a few years ago, according to the article
SoloKeys has open hardware sticks.
Thanks
Overrated…
Given this massive caveat I’d almost call that headline misleading
The fact that this happened is surprising in general, but not super practical.
What’s the big deal? A: It affects other types of hardware which also used these crypto libraries. Some are easier to address than others.
Cheaper just to beat you until you give them what they want.
I would argue that if the attacker has physical possession of my yubikey, that alone means the accounts tied to it are vulnerable. While the information isn’t technically wrong, I feel like that headline is misleading and this isn’t as big of a deal as some would like to make it out as.
Knowledge of the account is an obvious caveat. Yubikey-based MFA is an added layer of protection for accounts, so any kind of attack against MFA assumes the attacker already knows which account to target.
It’s like saying “our door lock is flawed, but the attacker would need to have knowledge of the door”.
The cost and complexity is what’s noteworthy and is more relevant. Although attack cost and complexity usuallu goes down with advances in tooling and research. So it may be a good idea to plan a progressive retirement of affected keys.
“Our door lock is flawed, but the attacker would need physical access to the key”
deleted by creator
Is this because FIDO2 is flawed, the yubikey hardware design is flawed or both?
Both. The cryptographic library in question is also used in other cryptographic applications too, so it’s a huge mess.
It’s due to a cryptographic library implementation in a controller used in the yubikey. It’s a third party controller, and this isn’t exclusive to yubikeys either, a shitload of other stuff uses the same controller and is likely vulnerable to the same attack.
Also, the attack requires around $10k worth of equipment and physical access to the yubikey, so while a valid attack vector, it’s also not something to get into a panic about.
Couldn’t you just use the yubikey like normal if you have physical access to it instead of copying it ?
In fact reading through the article it sounds like they would need to use it to extract the secret. I guess the end goal for this would be to maintain surreptitious access to something after returning the key to the target, either to build a criminal case or for espionage purposes.
Given that the vulnerability may also apply to other secure access card/devices I suppose it could also be used if a nation-state wanted to use an impostor to access secure facilities.
xkcd
And this is why Duress passwords exist
Can i create such a thing for qubes os? Would be cool the have decryption screen look like windows login and if duress password entered it boots to a live windows image instead and obviously sends out relevent alerts etc. I suppose u would also want a second duress password that just shreds everything as well.
It’s pretty concerning if my backup key can just be cloned that easily. It means now I need to invest in a much better safe, which I guess was probably always a good idea.
Do you consider $10,000 of equipment plus breaking your safe and extracting your pin to be easy? Who did you get on the wrong side of!?
Also, at least for the Yubi implementation, fixable in software, firmware >= 5.7 not vulnerable. Also not upgradeable, so replace keys if you’re worried about nation-state attacks.
for reference 5.7 began shipping with keys May of this year.
I went into the article thinking I’d need to replace my keys, and after reading decided I’m a very unlikely target for this attack. My threat model doesn’t include nation states, so I’m gonna keep using my yubikeys for the foreseeable future.
I have been thinking about new hardware key(s) that can handle more than 20 passkeys, but that’s not a high priority for me right now.
It’s definitely not something a regular user should panic over. But it’s a huge deal since a lot of high security, sensitive targets also rely on the same library.
Definitely. Not to be ignored, but for lots of yubikey users, also not something to be overly worried about.