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

61–70 of 80 posts

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

#61

Post by zinekeller »

AlexCoventry wrote: post #59
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?

Physics-wise in an ideal world, no. But it is possible and should be designed (like using better shielding and improving tamper resistance) so that the released radiation is minimal to the point that it is indistinguishable from noise. These are actually very possible: radiation-hardened parts are hardend against out to in radiation but usually also blocks in to out EM radiation.

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

#62

Post by tialaramex »

invokestatic wrote: post #17

I recently rolled out smartcard SSH authentication via PIV on Yubikey NEOs. Since the attack requires a few thousand observations, I’m still quite safe, right? An attacker would still need to know the PIV PIN.

This specific attack doesn't impact your usage scenario. It is impossible to say with certainty whether a hypothetical attacker, who had stolen one of the NEOs enrolled in your system, and had suitable lab equipment, could conduct a similar attack to recover authentication credentials from the NEO if they stolen the PIV PIN. Perhaps, perhaps not.

In general you should not be worried about this, it is unlikely you are so well defended that "Buy this lab equipment, hire an expert, and then steal someone's Yubikey" is the most viable attack, so time spent figuring where the low hanging fruit is will be better than worrying about this.

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

#63

Post by tialaramex »

dathinab wrote: post #36
rossmohax wrote: post #10

List of products affected mentions "Yubico Yubikey Neo" as vulnerable too

It probably shares the secure element (hardware). But that doesn't mean that the new Yubikeys (Series 5) are not affected. Just that they are not know to be affected. I hope Yubico will make a follow up post about weather or not other Yubikeys are affected too. But then given what is needed to use this exploit, it probably doesn't matter for many people.

Yes. The general idea of the attack is always going to be possible in principle. What happened here is they demonstrated they can actually do it in practice, and they gave us some parameters for how easy/hard it was. Other devices can (and in future should) make it harder than this, but it's never truly going to be impossible.

One thing I like very much about Security Keys is that the intuitive experience with ordinary physical keys applies. The idea that if someone stole your key that's bad makes sense.

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

#64

Post by vladvasiliu »

hangonhn wrote: post #19
monoideism wrote: post #14

Earlier quoted context omitted.

Much safer than a TOTP authentication app, which is susceptible to phishing attacks, unlike U2F.

I had to switch back from Yubikey to TOTP because AWS' CLI tools doesn't work with U2F. This really annoys me.

You may want to look into AWS Single Sign-On. In may not be available in the region you're mostly using but that's not necessarily an issue [0].

The service itself is free but requires an identity provider. If you already have a compatible one, you can use it at no additional cost. Otherwise, you'll have to pay for the IdP.

This setup allows you to offload MFA handling to your main IdP with the added bonus of using the same method of authentication, possibly integrated into your OS (for example if using Windows Hello / AzureAD).

At work, we use Azure AD as the IdP for AWS SSO and it works fairly well, aside from Azure's crappy (inexistent) support of security keys outside of Windows.

There is one gotcha with an easy workaround: the SDKs don't usually support the login part of the SSO flow, and sometimes don't support it at all (terraform comes to mind). To work around this, I'm aware of two tools you can use:

* aws-vault [1], which I personally use and works great for setting the required environment variables, no need to actually have it handle any sort of key

* aws-sso-util [2], which I've seen recommended but never tried

---

[0] It may be an issue if you need to use the managed ActiveDirectory service, which needs to be in the same region

[1] https://github.com/99designs/aws-vault

[2] https://github.com/benkehoe/aws-sso-util

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

#65

Post by tarruda »

For many years now, the brazilian government allowed both citizens and companies to acquire crypto usb keys tied to their identities that can digitally sign legally binding documents.

This is one of the commonly used devices, which has a NXP P5CC081 chip: https://www.usmartcards.com/downloads/dl/file/id/156/product...

I wonder if similar attacks could be applied to these keys, and what would be the implications.

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

#67

Post by bostik »

centimeter wrote: post #45
sedatk wrote: post #38

Earlier quoted context omitted.

I keep one always plugged into my computer (like a Nano model), and one on my keychain. You don't usually need more than that as there are ideally other ways to recover your account (printed recovery keys etc). If your laptop gets stolen with key inserted, and you didn't have time to invalidate the key, one still has to access your local account, and find out saved login information in order to leverage that key, and…

I have a similar setup - Nano 5C on laptop, 5C NFC on keychain (for use with iPad or iPhone), and a third one in a safe deposit box. I use them for services like Google, but also for SSH keys. (Since 8.2, OpenSSH has built-in U2F support.)

The SSH setup with a Nano and a laptop is pretty neat, in fact. Once you get it going. For a desktop it wouldn't work as smoothly thanks to the touch-for-every-auth requirement.

Even with the well-known document (by HN regular StavrosK) at hand, you can have a confusing experience getting the resident keys going at first. So I put together something to hopefully help people out: https://bostik.iki.fi/aivoituksia/projects/yubikey-ssh.html

FWIW, when I was working on the draft version, searching for the special error code brought up only three pages in Google, and only one of them was actually helpful. At least in my filter bubble.

PS. I am aware of Filippo's yubikey-agent, which AFAIU uses PIV instead of FIDO2. Looking into that will be for the future.

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

#68

Post by bostik »

dathinab wrote: post #36
rossmohax wrote: post #10

List of products affected mentions "Yubico Yubikey Neo" as vulnerable too

It probably shares the secure element (hardware). But that doesn't mean that the new Yubikeys (Series 5) are not affected. Just that they are not know to be affected. I hope Yubico will make a follow up post about weather or not other Yubikeys are affected too. But then given what is needed to use this exploit, it probably doesn't matter for many people.

I'll just add to the sibling comment with one educated guess. Since the attack requires recording of approximately 6k U2F auth operations, we can quite easily calculate the minimum wall time.

From a purely anecdotal experience, it takes between 1 and 2 seconds to "cycle" a YubiKey from a working keypress to the next working keypress. The delay is probably built in to the firmware to mitigate attacks like this. Let's be conservative and say you can run a U2F auth operation every second.

6000 * 1s = 1h40m. That's how long an attacker would have to have the key in their possession to generate enough material to run the rest of the attack offline. So perfectly doable as an evil maid attack with enough specialised gear. Infeasible as a drive-by attack.

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

#69

Post by [deleted] »

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…

[deleted]

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

#70

Post by xaduha »

> an attacker can create a clone of a legitimate Google Titan Security Key

Seems like quite a leap, from ECDSA implementation vulnerability which allows you to reconstruct ECDSA private key to claiming to be able to clone the whole device.

As far as I know on those Feitian NFC K9 fobs U2F is implemented as an applet, so that's just one applet out of several. No mention of RSA at all. E.g. I have a 'dev' version of it, it doesn't have U2F applet installed, but I can install others.

Post reply on HN