17 ms·
CVE-2021-3011: Key recovery on Google Titan Key
- deleted 6y ago[deleted]
- slimsag 6y agoWhy 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.
- junon 6y agoIt's this new frontend craze of putting artificial loading bars as a placebo effect. Github does it, for example. The site is just really slow, and the status bars are rarely, if ever, hooked up to the actual loading metrics.
- tyingq 6y agoI don't know why it does that, but I looked at it and it's using something called "Pace Progress Bar". Source for it: https://github.com/CodeByZach/pace https://github.com/CodeByZach/pace
- lrossi 6y agoIf you do client side “rendering” (which means that you get page content from the server in json format, and generate the html from javascript), you have to show a placeholder until the webpage content gets generated. Otherwise the user sees an incomplete page with elements jumping around for a fraction of a second on load. But the placeholder might get stuck if anything goes wrong. Personally, I hate it. Better to use static html for blog content.
- bsdubernerd 6y agoThat's all I see as well. Fortunately the direct CVE link works.
- Thaxll 6y ago"It allows attackers to extract the ECDSA private key after extensive physical access" So if you have physical access of the device is it an issue?
- pat2man 6y agoThere is a list of other affected keys at the bottom of the article.
- gabrielsroka 6y agoSource: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3011 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3011
- zinekeller 6y agoSource 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/ https://ninjalab.io/a-side-journey-to-titan/ First-party PDF: https://ninjalab.io/wp-content/uploads/2021/01/a_side_journey_to_titan.pdf https://ninjalab.io/wp-content/uploads/2021/01/a_side_journe...)
- gabrielsroka 6y agoMy link is to the CVE official site.
- gpvos 6y agoThanks, at least this page loads.
- rossmohax 6y agoList of products affected mentions "Yubico Yubikey Neo" as vulnerable too
- dathinab 6y agoIt 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.
- tialaramex 6y agoYes. 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.
- bostik 6y agoI'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.
- lrossi 6y agoEven 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.
- monoideism 6y agoMuch safer than a TOTP authentication app, which is susceptible to phishing attacks, unlike U2F.
- hangonhn 6y agoI had to switch back from Yubikey to TOTP because AWS' CLI tools doesn't work with U2F. This really annoys me.
- akerl_ 6y agoAt risk of telling you something you already know: you can use the TOTP mode on the Yubikey, if you’re looking to use it for AWS secrets despite AWS’s lack of support for U2F for CLI workflows. 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-YubiKey-Manager-CLI-ykman-User-Manual https://support.yubico.com/hc/en-us/articles/360016614940-Yu... https://www.yubico.com/products/services-software/download/yubico-authenticator/ https://www.yubico.com/products/services-software/download/y...
- uep 6y agoI've been meaning to buy a Yubikey. What is the best practice for using a security key? Is there a mechanism for backing my keys up somewhere safe so that a loss of key doesn't mean a loss of my accounts?
- 6y ago
- lrossi 6y agoSomething 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?
- ehsankia 6y agoThe article says they are "cloning" the key, which would imply that yes.
- xaduha 6y agoThey aren't cloning shit though. They are getting single ECDSA private key after six thousand operations or something.
- tialaramex 6y agoTheir 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)
- paulgerhardt 6y agoNote, 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). 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 https://duo.com/decipher/hack-the-titan-m-get-usd1-million [2] https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext https://cloud.google.com/blog/products/gcp/titan-in-depth-se... [3] http://www.hexview.com/~scl/titan/ 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-titan-bluetooth-security-keys.html https://www.engadget.com/2019-05-15-google-recalls-some-tita... [5] https://showcase.withgoogle.com/titan-c/ https://showcase.withgoogle.com/titan-c/ [6] https://opentitan.org/ https://opentitan.org/
- lambda_obrien 6y agoI still don't understand which titan keys I have and whether this affects them.
- invokestatic 6y agoI 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.
- bradfa 6y agoThe attacker needs physical access to your Yubikey NEO and to then run a few thousand observations. Using a U2F dongle is still MUCH better than many other types of 2 factor authentication. 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.
- tialaramex 6y agoThis 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.
- xaduha 6y agoIt only affects ECDSA, if it affected RSA or general smartcard security like PIN access it would be an earth-shattering story since it would affect SIM cards, banking cards, satellite CAM cards, you name it. That's why any talk about cloning should't be so casual and misleading, it promotes FUD.
- taeric 6y agoMy biggest gripe on the security keys are that I want to use them daily. By having something that is so infrequently used... How do I know it works?
- kevin_nisbet 6y agoJust curious if anyone knows how long the 4000-6000 observations required would take on this particular device?
- rstuart4133 6y agoQuoting https://arstechnica.com/information-technology/2021/01/hackers-can-clone-google-titan-2fa-keys-using-a-side-channel-in-nxp-chips/ https://arstechnica.com/information-technology/2021/01/hacke... : > 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.
- devy 6y agoIt looks like all hardware 2FA keys with NXP A700X chip are affected.
- GekkePrutser 6y agoThis is really excellent work! Very in-depth but clear to read. I hope this will be taken into account into future products, as of course hardware is hard to fix.
- supernova87a 6y agoAt 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.
- dathinab 6y ago1. Can people pleas stop using light gray text, low contrast text is a major accessibility issue. 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.
- fsh 6y agoUnlike the Neo, the Yubikey 5 uses a chip from Infineon: http://www.hexview.com/~scl/neo5/ http://www.hexview.com/~scl/neo5/.
- jhfdbkofdcho 6y agoHow is this a CVE? Lots of stuff leak through side channels. I don’t get it.
- ajsharp 6y ago> 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 guys. Holy hell.
- AlexCoventry 6y ago> observation of its local electromagnetic radiations during ECDSA signatures Is there any hardware which is invulnerable to this type of observation?
- zinekeller 6y agoPhysics-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.
- deleted 6y ago[deleted]
- duckfang 6y agoIndeed it is impressive but not wildly so. Most consumer-ish hardware falls prey to all sorts of various TEMPEST attacks. You can even get started with a HackRF and some inductive loop antennas. It would set you back $130 or so on ebay. 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.
- slaymaker1907 6y agoI'm very glad that they mentioned this attack is only applicable under a very specific threat model.
- tarruda 6y agoFor 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/365/starsign_crypto_usb_token.pdf 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.
- Aissen 6y agoVery impressive cross-disciplinary research, combining chip decapping for side-channel probing, reverse engineering, machine learning (albeit unsuccessful?) and a cryptographic attack. Kudos.
- xaduha 6y ago> 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.
- ohiovr 6y agoIs 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.