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
