CVE-2021-3011: Key recovery on Google Titan Key(ninjalab.io) |
CVE-2021-3011: Key recovery on Google Titan Key(ninjalab.io) |
The various Titan Security Keys are also made by Feitian who sometimes use the same auth chip and sometimes don't but externally look identical.
The products sole purpose is to establish a secure chain of trust and starts out the gate broken with ambiguous or misleading claims for verifying exactly which Titan it is.
Google will pay you $1 million to hack the Titan but not the Titan hacked here - the other Titan[1]. Furthermore they are happy to tell you that their products, like Google Cloud Platform, are "Secured by Titan" but not which Titan [2].
This is frustrating because the Titan M is an absolutely brilliant device, with some real advancements to normalize embedded security, including an SPI interposer to monitor communications (a real leap forward) - and should not at all be conflated with a generic, whitelabeled, non-hsm product that makes no claims whatsoever and has been broken at least twice before [3] [4]. The Titan C is an even bigger improvement over the Titan M but not in anyway they care to disclose which may or may not indicate weaknesses in Titan M [5]. Likewise, OpenTitan[6] is crashing through barriers others didn't even know were there in establishing verifiable silicon roots of trust but is ambiguously different than Titan M because of various foundry and PDK issues which may be as innocuous as having to run the chips through at different process sizes but who knows because while OpenTitan is verifiable; Titan M/C aren't.
[1] https://duo.com/decipher/hack-the-titan-m-get-usd1-million
[2] https://cloud.google.com/blog/products/gcp/titan-in-depth-se...
[3] http://www.hexview.com/~scl/titan/ - note the migration from the NXP A7005a to A7005c
[4] https://www.engadget.com/2019-05-15-google-recalls-some-tita...
Titan BT or NFC -> Physically not OK, but remote attacks still impossible so unless you're targeted and somehow got access to your fob, it doesn't matter.
It's nice they have a secure chip (titan m) like the secure enclave of apple. But the security keys imply more sense of security as there are not running a lot more apps on this device like on a smartphone.
This is a wildly impressive vuln to discover. Cheers to these guys. Holy hell.
From there, you would have to establish some sort of baseline - that would be the hard part. Once done, you're going to be dealing with amplitude based signals (2ASK primarily). The next step is to determine the frequency the device is running at, and tune to it or 2nd or 3rd harmonics.
From there, it's getting the signal out of the noise, and decoding it for the win.
I've done it a few times. Sorry, I don't have a CVE to my name.
Is there any hardware which is invulnerable to this type of observation?
attributing who got what would be a challenge though.
Compared to TOTP, U2F uses asymmetric cryptography to avoid using a shared secret design, which strengthens authentication against server-side attacks. Hardware U2F also sequesters the client secret in a dedicated single-purpose device, which even given the vulnerability described here still has a tiny fraction of the attack surface of a TOTP app and its general purpose host device.
> Extracting and later resealing the chip takes about four hours. It takes another six hours to take measurements for each account the attacker wants to hack. In other words, the process would take 10 hours to clone the key for a single account, 16 hours to clone a key for two accounts, and 22 hours for three accounts.
So if you have physical access of the device is it an issue?
(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...)
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.
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.
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.
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.
My family are enrolled in Google Advanced Protection and some of our U2F dongles are the affected Titan keys. I'm not at all concerned and am not rushing out to switch to different dongles.
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.
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.
I hope this will be taken into account into future products, as of course hardware is hard to fix.
Besides that while it does sound bad and probably is bad for some companies using this chips for high security (e.g. Google itself) for many users it lukily will most likely never matter.
Now I'm wondering if my Yubikey is affected? While they list the Yubikey Neo the Yubikey 5* products are not listed.
But the placeholder might get stuck if anything goes wrong.
Personally, I hate it. Better to use static html for blog content.
Source for it: https://github.com/CodeByZach/pace
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.
The attack to mount would be against the long-term device-specific key, no?
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.
That at least keeps more of your MFA key material on the hardware token and off of your phone / other shared devices.
The easiest way to do that is via the ykman CLI or Yubico Authenticator application (TOTP secrets stored on the key via either method go to the same place, so you can use both interfaces to access the same codes):
https://support.yubico.com/hc/en-us/articles/360016614940-Yu...
https://www.yubico.com/products/services-software/download/y...
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 replace the promoted one.
The third is your emergency backup, for when both normally needed keys are destroyed or lost.
Now of course, this only works when the accounts you want to secure allow to enroll more than one FIDO2 token. Which is, sadly, not the most common setup still. For instance AWS only allows to enroll one 2FA token per account.
ß: Some functionality modes allow to extract private keys by design.
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
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 that's until you notice that your computer's stolen and invalidated your key everywhere. Otherwise, it's just another random key for the thief.
I don't find that part of my threat model, and I've got my laptop stolen before with key plugged in.
I use them for services like Google, but also for SSH keys. (Since 8.2, OpenSSH has built-in U2F support.)
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.
Meaning, I would only really have to remember two strong passwords. The rest would be strong passwords, but without 2FA, and easily changeable without forcing myself to remember yet-another password and which account it belongs to.