[HN Gopher] CVE-2021-3011: Key recovery on Google Titan Key
___________________________________________________________________
CVE-2021-3011: Key recovery on Google Titan Key
Author : hexa-
Score : 113 points
Date : 2021-01-07 19:00 UTC (4 hours ago)
(HTM) web link (ninjalab.io)
(TXT) w3m dump (ninjalab.io)
| rossmohax wrote:
| List of products affected mentions "Yubico Yubikey Neo" as
| vulnerable too
| dathinab wrote:
| 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.
| dathinab wrote:
| 1. 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 wrote:
| Unlike the Neo, the Yubikey 5 uses a chip from Infineon:
| http://www.hexview.com/~scl/neo5/.
| devy wrote:
| It looks like all hardware 2FA keys with NXP A700X chip are
| affected.
| taeric wrote:
| My 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?
| [deleted]
| lrossi wrote:
| 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.
| monoideism wrote:
| Much safer than a TOTP authentication app, which is susceptible
| to phishing attacks, unlike U2F.
| hangonhn wrote:
| I had to switch back from Yubikey to TOTP because AWS' CLI
| tools doesn't work with U2F. This really annoys me.
| akerl_ wrote:
| At 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-Yu...
|
| https://www.yubico.com/products/services-
| software/download/y...
| uep wrote:
| I'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?
| lrem wrote:
| Buy 3 keys, keep one with yourself, one at home and one
| in a distant relative's basement. Preferably the latter
| two in fireproof safes.
| Fnoord wrote:
| Buy 2. Put one in offsite location (e.g. your notary). I
| don't have a notary; I got one always in my pocket, and
| the other one at home in a safe (pickable though). YMMV.
| bostik wrote:
| The main idea with a security token is that you can not
| get the keys out of them.[ss]
|
| 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.
|
| ss: Some functionality modes allow to extract private
| keys by design.
| sedatk wrote:
| 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 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.
| remus wrote:
| AWS' support for security keys is crap in general. For
| example, you can only have a single key per account so it's
| impossible to have a backup key in case you lose your
| primary key.
| rafaelturk wrote:
| Hum... I'm the processo to add Yubikey or any U2F to my AWS
| account, can you share any advice, feedback? Risks, etc?
| ehsankia wrote:
| To be clear, "this problem" requires the attacker to have
| sophisticated equipment with physical access to your key for a
| significant amount of time. So yes still by far the most secure
| way, right below a non-clonable key.
| slimsag wrote:
| 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.
| lrossi wrote:
| If 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.
| junon wrote:
| It'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 wrote:
| I 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
| bsdubernerd wrote:
| That's all I see as well. Fortunately the direct CVE link
| works.
| Thaxll wrote:
| "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?
| junon wrote:
| If by "you" meaning the owner, than it appears not. That would
| be a remote vulnerability.
| pfortuny wrote:
| " 6000 observations". I guess a single whole night can be
| enough. You sleep at a hotel, your key fob is cloned.
| lrossi wrote:
| 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?
| ehsankia wrote:
| The article says they are "cloning" the key, which would imply
| that yes.
| supernova87a wrote:
| 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.
| paulgerhardt wrote:
| 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).
|
| 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...
|
| [5] https://showcase.withgoogle.com/titan-c/
|
| [6] https://opentitan.org/
| lambda_obrien wrote:
| I still don't understand which titan keys I have and whether
| this affects them.
| zinekeller wrote:
| Titan on Pixel -> OK
|
| 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.
| pat2man wrote:
| There is a list of other affected keys at the bottom of the
| article.
| GekkePrutser wrote:
| This 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.
| invokestatic wrote:
| 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.
| bradfa wrote:
| The 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.
| gabrielsroka wrote:
| Source: https://cve.mitre.org/cgi-
| bin/cvename.cgi?name=CVE-2021-3011
| gpvos wrote:
| Thanks, at least this page loads.
| zinekeller wrote:
| Source 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/
|
| First-party PDF: https://ninjalab.io/wp-
| content/uploads/2021/01/a_side_journe...)
| kevin_nisbet wrote:
| Just curious if anyone knows how long the 4000-6000 observations
| required would take on this particular device?
___________________________________________________________________
(page generated 2021-01-07 23:00 UTC)