Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2021-3011: Key recovery on Google Titan Key

ninjalab.io

Post reply on HN
Print view View original

51–60 of 80 posts

Re: CVE-2021-3011: Key recovery on Google Titan Key

#51

Post by maerF0x0 »

ehsankia wrote: post #21
lrossi wrote: post #12

Even with this problem, using the keys for U2F is safer than SMS two factor auth. Possibly also safer than authentication app on phone, which could be compromised in various ways.

To be clear, "this problem" requires the attacker to have sophisticated equipment with physical access to your key for a significant amount of time. So yes still by far the most secure way, right below a non-clonable key.

But that significant amount of time could have been in the supply chain prior to your acquiring it.

attributing who got what would be a challenge though.

Re: CVE-2021-3011: Key recovery on Google Titan Key

#52

Post by gabrielsroka »

zinekeller wrote: post #13
gabrielsroka wrote: post #8

Source: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3011

Source of what? If it's the PDF, sure, but the post is the reporters' summary. (For future reference Posted link as of comment: https://ninjalab.io/a-side-journey-to-titan/ First-party PDF: https://ninjalab.io/wp-content/uploads/2021/01/a_side_journe... )

My link is to the CVE official site.

Re: CVE-2021-3011: Key recovery on Google Titan Key

#53

Post by tialaramex »

maerF0x0 wrote: post #51
ehsankia wrote: post #21

Earlier quoted context omitted.

To be clear, "this problem" requires the attacker to have sophisticated equipment with physical access to your key for a significant amount of time. So yes still by far the most secure way, right below a non-clonable key.

But that significant amount of time could have been in the supply chain prior to your acquiring it. attributing who got what would be a challenge though.

That doesn't work.

The attack recovers an ECDSA private key for one account. So e.g. maybe your Google account. But this key does not exist when you receive the Titan in its packaging, it's created (randomly) when you enroll the key for your Google account.

These devices create entirely random ECDSA private keys for every single enrollment, and this attack recovers one key, using a real challenge from the relying party for that key. If they want your GitHub, or Facebook or your US government account, those have separate keys which need a separate attack.

Re: CVE-2021-3011: Key recovery on Google Titan Key

#54

Post by viraptor »

maerF0x0 wrote: post #51
ehsankia wrote: post #21

Earlier quoted context omitted.

To be clear, "this problem" requires the attacker to have sophisticated equipment with physical access to your key for a significant amount of time. So yes still by far the most secure way, right below a non-clonable key.

But that significant amount of time could have been in the supply chain prior to your acquiring it. attributing who got what would be a challenge though.

Does the Titan key not allow you to regenerate the key? That normally should be the first step after getting a hardware key. Yubikey definitely allows a full reset.

Re: CVE-2021-3011: Key recovery on Google Titan Key

#56

Post by tialaramex »

lrossi wrote: post #15

Something that just crossed my mind is whether this method is destructive or not. Is it possible to steal the key, read it, then give it back to the owner?

Their method was destructive to the outer casing, because it was easier. If you wanted to clone a key it is likely you could find a way to either avoid destroying the outer packaging or replace it with an apparently identical case, at some expense. They don't necessarily need to damage the actual chip (although they did trash at least one during R&D)

Re: CVE-2021-3011: Key recovery on Google Titan Key

#57

Post by sneak »

tialaramex wrote: post #53
maerF0x0 wrote: post #51

Earlier quoted context omitted.

But that significant amount of time could have been in the supply chain prior to your acquiring it. attributing who got what would be a challenge though.

That doesn't work. The attack recovers an ECDSA private key for one account. So e.g. maybe your Google account. But this key does not exist when you receive the Titan in its packaging, it's created (randomly) when you enroll the key for your Google account. These devices create entirely random ECDSA private keys for every single enrollment, and this attack recovers one key, using a real challenge from the relying par…

It's been a while since I've read the U2F spec and my info may be a major version out of date but I understand that the enrollment-specific key was encrypted to the long term device key then returned to the service for storage.

The attack to mount would be against the long-term device-specific key, no?

Re: CVE-2021-3011: Key recovery on Google Titan Key

#58

Post by tialaramex »

sneak wrote: post #57
tialaramex wrote: post #53

Earlier quoted context omitted.

That doesn't work. The attack recovers an ECDSA private key for one account. So e.g. maybe your Google account. But this key does not exist when you receive the Titan in its packaging, it's created (randomly) when you enroll the key for your Google account. These devices create entirely random ECDSA private keys for every single enrollment, and this attack recovers one key, using a real challenge from the relying par…

It's been a while since I've read the U2F spec and my info may be a major version out of date but I understand that the enrollment-specific key was encrypted to the long term device key then returned to the service for storage. The attack to mount would be against the long-term device-specific key, no?

You are correct about how this works. I think the "Side Journey To Titan" paper makes it obvious the authors also understand how it works.

So if you can magically summon working attacks, you would choose the symmetric AES key yes.

One conclusion you could draw from this paper is the authors are idiots and didn't realise they should attack that key or else didn't have the relevant expertise to do so.

Another, I suspect far more likely conclusion is that protecting AES keys in dedicated security hardware is a problem lots of people already put effort into and these researchers wisely concluded they wouldn't get any traction there because this is a standard component.

Re: CVE-2021-3011: Key recovery on Google Titan Key

#59

Post by AlexCoventry »

ajsharp wrote: post #48

> Our work describes a side-channel attack that targets the Google Titan Security Key’s secure element (the NXP A700X chip) by the observation of its local electromagnetic radiations during ECDSA signatures (the core cryptographic operation of the FIDO U2F protocol). In other words, an attacker can create a clone of a legitimate Google Titan Security Key. This is a wildly impressive vuln to discover. Cheers to these…

> observation of its local electromagnetic radiations during ECDSA signatures

Is there any hardware which is invulnerable to this type of observation?

Re: CVE-2021-3011: Key recovery on Google Titan Key

#60

Post by AlexCoventry »

uep wrote: post #49
bostik wrote: post #31

Earlier quoted context omitted.

The main idea with a security token is that you can not get the keys out of them.[ß] So for a truly secure and reliable setup, get three. Enroll them all as parallel 2FA tokens. Keep one with you, one in a relatively easily accessible but non-obvious place, and one in a safe or bank deposit box. That way when the one you have with you breaks or you lose it, promote the secondary to your primary and order a new one to…

Is it considered a no-no to use it with a password manager for other accounts that I consider less critical? I was thinking that for most accounts, I would use the password manager, but use 2FA for the password manager. My primary email account that everything links to, would just be 2FA. Meaning, I would only really have to remember two strong passwords. The rest would be strong passwords, but without 2FA, and easil…

Why not use 2fa on all sites which allow it?
Post reply on HN