Note, Google in typical fashion has named 6+ products "Titan." (Titan M, Titan C, Titan Security Key (available in USB A, C, Bluetooth versions), Titan Security Module, OpenTitan, and maybe a few more if you count the old Bluetooth versions that were recalled that look identical to the new Bluetooth version).<p>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.<p>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.<p>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].<p>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.<p>[1] <a href="https://duo.com/decipher/hack-the-titan-m-get-usd1-million" rel="nofollow">https://duo.com/decipher/hack-the-titan-m-get-usd1-million</a><p>[2] <a href="https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext" rel="nofollow">https://cloud.google.com/blog/products/gcp/titan-in-depth-se...</a><p>[3] <a href="http://www.hexview.com/~scl/titan/" rel="nofollow">http://www.hexview.com/~scl/titan/</a> - note the migration from the NXP A7005a to A7005c<p>[4] <a href="https://www.engadget.com/2019-05-15-google-recalls-some-titan-bluetooth-security-keys.html" rel="nofollow">https://www.engadget.com/2019-05-15-google-recalls-some-tita...</a><p>[5] <a href="https://showcase.withgoogle.com/titan-c/" rel="nofollow">https://showcase.withgoogle.com/titan-c/</a><p>[6] <a href="https://opentitan.org/" rel="nofollow">https://opentitan.org/</a>
> 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.<p>This is a wildly impressive vuln to discover. Cheers to these guys. Holy hell.
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.
At least they acknowledged that exploiting this requires physical access to the key, expensive equipment, etc. and on balance is not so realistic for most people that they should stop using the key.
"It allows attackers to extract the ECDSA private key after extensive physical access"<p>So if you have physical access of the device is it an issue?
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.<p>This is one of the commonly used devices, which has a NXP P5CC081 chip:
<a href="https://www.usmartcards.com/downloads/dl/file/id/156/product/365/starsign_crypto_usb_token.pdf" rel="nofollow">https://www.usmartcards.com/downloads/dl/file/id/156/product...</a><p>I wonder if similar attacks could be applied to these keys, and what would be the implications.
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.
> an attacker can create a clone of a legitimate Google Titan Security Key<p>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.<p>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.
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?
Is there a wallet product out there for keeping a Yubikey or titan safe from physical harm as well as stray readers? Or is that just silly at this time? I've seen a pocket knife like wallet on Walmart. Would be nice if it were lined with metal mesh.
This is really excellent work! Very in-depth but clear to read.<p>I hope this will be taken into account into future products, as of course hardware is hard to fix.
1. Can people pleas stop using light gray text, low contrast text is a major accessibility issue.<p>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.<p>Now I'm wondering if my Yubikey is affected? While they list the Yubikey Neo the Yubikey 5* products are not listed.
Why does this blog have a loading bar that gets stuck around 99% for me? Every request has loaded and is cached by my browser, yet it hangs at 99% artificially for like 30s.