[HN Gopher] What's the risk from fake Yubikeys?
___________________________________________________________________
What's the risk from fake Yubikeys?
Author : edent
Score : 97 points
Date : 2022-03-06 12:36 UTC (10 hours ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| Syzygies wrote:
| What's the risk from replacing YubiKeys with software that relies
| on the internal security chips in modern computers?
|
| My most cited paper was used by the original BitCoin paper, so I
| can attempt to listen to a security argument. I have yet to hear
| anyone justify external USB key security when computers have
| security chips. I also follow the progress in provably correct
| programming; saying we're too stupid to allow the computer to
| handle it isn't a compelling argument. Write some provably
| correct secure code for this!
|
| I would so love to see Duo and YubiKey go out of business.
| However, if they had been more respectful of my time, I wouldn't
| have this thought.
|
| My college and university both require multifactor authentication
| for logins required by my daily work. They have chosen Duo Two
| Factor Authentication, preferring that I find my phone and launch
| Duo's app for each login. YubiKeys are supported as an
| alternative. I have a YubiKey in each of five machines; I'm no
| more willing to move around a single YubiKey than I am willing to
| find my phone.
|
| Duo's implementation requires numerous extraneous mouse clicks.
| They don't autodetect if a registered YubiKey is already present.
| Rather, they present a global default choice of YubiKey, and
| force a click for the dialog that supports then tapping a
| YubiKey. If one doesn't change the selection, one gets an error
| message that the YubiKey isn't registered, when it is; it's there
| on the original menu. Duo doesn't accept direct user feedback,
| further ingratiating me with my IT department when I file reports
| about this.
|
| I'm starting to feel that this is all deliberate obfuscation, to
| draw attention away from having to tap the YubiKey, which is
| security theater a company like Apple cold put out of business in
| a heartbeat. I'd go to prison for life for kidnapping, but when a
| corporation dilutes this same harm, stealing five seconds each
| daily from many users, it gets excused as incompetence. The kind
| of incompetence Steve Jobs would never tolerate if he were alive.
|
| Most people are extraordinarily clumsy with computers, expecting
| random mouse work. I embrace agility tasks while cooking, but I
| take extreme umbrage at this clumsy interface being forced on me
| every day. My first memory of school was a student teacher
| leaving the classroom in tears after I taught half the class to
| play Simon Says backwards. I didn't take the time to customize
| QMK firmware for my keyboards, only to have some CEO I've never
| met force me to play Simon Says.
|
| If one wanted to automate tapping a YubiKey, it just needs a
| connection to ground while it flashes, which would be a cute
| Arduino-class project.
| Forbo wrote:
| How does recovering from a broken/lost/stolen device work in
| this scenario? I'm assuming it's the same as other MFA methods,
| namely using a recovery code that was given at the time of
| enrollment, or am I wrong in that line of thinking?
| rootusrootus wrote:
| Recovery code or another key. You can enroll multiple keys.
| As long as you have one of them, you can use your access to
| disenroll the broken/lost/whatever key and enroll a
| replacement. I have one key that I keep with me, and another
| that I keep in my safe. If I lose both, I'll use a recovery
| code that I keep in an encrypted vault online (as well as in
| my safe in paper form, but assuming that whatever destroyed
| the key in the safe also destroyed the list of codes in the
| safe...)
| aborsy wrote:
| There are a number of hardware security keys: OnlyKey, SoloKey,
| NitroKey, Google Titan and Yubikey?
|
| Can someone compare these?
| 6figurelenins wrote:
| Pardon the domain.
|
| https://www.buybitcoinworldwide.com/dongle-auth/dongles/
|
| Personally:
|
| - NFC Yubico with my car keys. I can't remember ever using NFC
| to authenticate directly on mobile, but I like having a
| hardware backup for time-based one-time password (TOTP) codes.
| (Google Authenticator / Android)
|
| - Tiny Solos (Somu[1]) live in my keyboard, laptop ports for
| "touch to login" (universal 2nd factor, U2F). - Open hardware a
| plus. Pre-order fundraising is 100% legit. Hotplug works well
| in Debian. - Original Solo was a bit loose in a USB-A port. It
| was tricky to press the button without pins losing contact.
|
| - Pixelbook power button can act as U2F, which is neat.
|
| [1] https://solokeys.com/products/somu-tiny-security-key-two-
| fac...
| bombcar wrote:
| If a duplicate code generating tool isn't a risk factor then the
| second factor isn't that important at all.
|
| It's obviously a risk factor and one that should be considered -
| especially if you consider a targeted attack against a particular
| person.
| spicybright wrote:
| So legit though... How are any of these solutions that much
| better than a tiny book of passwords if your place of living is
| secure? SSH pass phrases, writing down randomly generated
| passwords, etc.
| kingcharles wrote:
| How secure is your place of living? If the police break down
| your door at dawn and arrest you in your pajamas, do you have a
| chance to snatch up your book of passwords and swallow it
| before they put the zip ties on?
| rootusrootus wrote:
| The key proves you have it physically in your possession. It
| cannot be phished, nor stolen without you being aware.
| jhnct wrote:
| My yubikeys were sent in an envelope identifying its content, I
| thought it wasn't a smart move at the time :/.
| sascha_sl wrote:
| If you're at risk...
|
| Yubikeys are exceptionally bad targets to intercept and modify
| if someone wants to send you an implant. It's more likely
| they'll get you with the next mass storage device or data cable
| you buy on Amazon.
| jhnct wrote:
| Totally agree, anything with a (big) firmware or mass storage
| looks like a better device to compromise.
| kingcharles wrote:
| You'd have to be an NSA-level target for them to take a
| Yubikey out of the mail stream and modify it. And at that
| point you're going to have all sorts of worse things to worry
| about.
| xaduha wrote:
| So much confusion around this topic out there. Not helped by the
| fact that there's distinction between Security Keys by Yubico and
| Yubikeys. Security Keys can't do much other than FIDO2.
|
| Yubikeys on the other hand are split into old ones that did have
| smartcard functionality unlocked so you could upload your applets
| into and newer ones which are locked. Locked ones are only
| marginally easier to tamper with than proper smartcards, nearly
| impossible to be worth it for anyone than state actors.
|
| If you have any proof of it happening anywhere, then show me a
| source. Closest I have is this https://ninjalab.io/wp-
| content/uploads/2021/01/a_side_journe..., which is about Google
| Titan aka reskinned FEITIAN ePass NFC with some functionality
| turned off
| nbernard wrote:
| Well, considering that Yubikeys can generate crypto keys (for
| SSH, PGP, etc.) on device, I assume it would be possible for a
| fake one to use a backdoored/weak random number generator so that
| encryption/authentication based on these keys could be broken...
|
| Another potential attack (for those who use them to store keys
| created on another device), would be to have a way, for an
| attacker that would steal your (fake) Yubikey, to get back the
| secret key (which is normally impossible/hard on a genuine
| Yubikey).
| adtac wrote:
| Tangential but IMO it's almost always better to generate the
| private key off-device and store it somewhere securely. It
| doesn't matter when the Yubikey gets lost because you'll be
| revoking the GPG key, but when you accidentally destroy your
| Yubikey, it's convenient to be able to set up a new Yubikey
| without generating a new GPG key and changing it everywhere.
| knorker wrote:
| Strong disagree on that.
|
| That means the key has existed in RAM, which largely defeats
| the point of it being HW based.
|
| The point of HW based is that no matter what, if a key is not
| connected then it is not used to auth. If it requires touch
| then all the hackers in china cannot auth using it, without
| getting on a plane and breaking in.
|
| You should have a backup hardware device, and for GPG subkeys
| or something.
| tadfisher wrote:
| That's why the standard recommendation is to generate keys
| on an airgapped computer without persistent storage, and
| run keytocard from there.
|
| I have a set of dead Yubikey 4s that are blacklisted from
| GitHub because the onboard key generation code generated
| insecure keys (nevermind that I didn't use that feature,
| but wygd).
| upofadown wrote:
| > ... generate the private key off-device and store it
| somewhere securely.
|
| Doesn't even have to stored securely if it is protected with
| a strong passphrase. You can keep it anywhere. ... and with
| contemporary versions of GPG that might only have to be 4
| diceware words.
|
| For PGP stuff, the advantage of something like a Yubikey is
| that the unencrypted private key is never exposed to a
| possibly insecure end device. The actual cryptography is done
| on the Yubikey. This is a somewhat different situation than
| with other uses where the Yubikey only protects the secret
| information.
| woodruffw wrote:
| This is bad advice, for _precisely_ the reason you 've
| described. It should not be possible to sign things with a
| key that has been ostensibly destroyed.
|
| If you need to be able to recover from a destroyed key, you
| should either (a) repeat your initial trust process, or (b)
| prematurely attest to a second key using your first one.
| thfuran wrote:
| Doesn't taking the key off the device sort of defeat the
| purpose?
| tomxor wrote:
| Yubico have a verification page for this purpose:
| https://www.yubico.com/genuine/
|
| In theory this is enough to prove it's genuine because they are
| supposed to be tamper-proof, i.e even if you buy indirectly or
| it's intercepted in transit.
|
| The only thing I can see this failing to detect is an
| intermediate layer that intercepts USB and has access to the
| physical button... e.g If an attacker embedded a genuine small
| form-factor key into a larger package that mimics a larger form
| factor. This would be useful to an attacker which could get a
| target to trust the key, believe it's genuine and start
| associating it with services, and then be able to remotely
| activate it once they have gained the users trust... still a
| tough challenge to pack all of that with wifi etc into a small
| enough package with a micro yubikey or something inside.
|
| I don't think this is a very realistic possibility currently, but
| if you are concerned, you could simply buy the smallest possible
| yubikey form factor.
| robryk wrote:
| The attack you're describing doesn't require wifi. If the
| victim visits the attacker's page, the attacker page is free to
| request signatures (also non-presence-attesting signatures)
| from the key. This can be used to send data to the key (in the
| nonce) and from the key (the signature is nondeterministic). I
| don't know if this can be done without user's awareness in the
| new web api for security keys, though.
| mirekrusin wrote:
| How can it protect from cloned hardware? Ie. they get keys,
| clone them, sell at discount - and sell shipment address +
| software/hardware backdoor on the side.
| jsmith99 wrote:
| Whoever cloned the hardware would need to know the private
| key Yubico embed in it, and those aren't east to extract,
| although presumably feasible for cutting edge chip reverse
| engineering labs.
| Nextgrid wrote:
| Out of curiosity, why are keys not generated upon first
| run? Why is there something to extract out of a brand new
| YubiKey to begin with?
| [deleted]
| tialaramex wrote:
| For FIDO, which was the main topic of the original post,
| the Yubikey has a symmetric key inside it.
|
| Choosing a random new key invalidates all your existing
| credentials enrolled with that Yubikey, since your
| Yubikey will no longer be able to decrypt the identifier
| provided and sign proof that it knows the associated
| private key (in practice what it decrypted _was_ your
| private key for that account, and now it can 't do that)
|
| This "reset" operation is supported on Yubikeys, and you
| perhaps should do it when you get the key (Don't do it
| now! It invalidates your credentials as I described!),
| although most users probably don't. However, even if you
| do this if your key is _fake_ why would the
| initialisation actually work? The same adversary could
| modify it to just ignore this reset attempt and use a
| symmetric key they know. So there is no benefit from
| hypothetically requiring you to perform this
| initialisation step, nor from having the device do it
| when first used.
| tialaramex wrote:
| To do FIDO the Yubikey has a _symmetric_ (typically called
| "secret" but here it isn't really functioning as a secret
| since nobody else knows what it is) key but not a private
| key baked inside it.
|
| Hiding such symmetric keys (typically AES) from adversaries
| with fairly large budgets who have physical access to your
| device is already a thing. Would I bet my life on it if I
| was Edward Snowden? Maybe not. Am I comfortable with this
| for securing a bank account with my life savings in it?
| Yes.
| amelius wrote:
| Or whoever manufactured the Yubico chip in the first place.
| yjftsjthsd-h wrote:
| I wonder if you could mitigate that by manufacturing them
| without a private key and then have Yubico themselves
| program the keys (in one-time programmable memory) before
| shipping to the customer.
| GekkePrutser wrote:
| That's infineon for the latest generation:
|
| http://www.hexview.com/~scl/neo5/
| cromd wrote:
| Here's an example from 2018 of someone trying to extract
| secrets from a Yubikey.
| https://duo.com/labs/research/microcontroller-firmware-
| recov.... Seems they don't get very far. Or it's at least
| very laborious. But as you say, who knows what a cutting
| edge lab can do. Skimming the web, it seems like people
| have had more success with things like Google Titan keys.
| jsmith99 wrote:
| If you are interested in this topic, the physical
| security chapter of Ross Anderson's Security Engineering
| has a nice intro. The second edition is free online
| https://www.cl.cam.ac.uk/~rja14/book.html
| GekkePrutser wrote:
| That's not a yubikey but a standard pic microcontroller
| not designed for security applications.
|
| And as far as I understand he's now describing his
| methods there rather than particular attempts?
| drdaeman wrote:
| There's a bit about Yubikey at the very end of the
| article.
| Havoc wrote:
| Thanks for that link didn't know about that. Helpful since I
| got mine off Amazon which as we all know has occasional uhm
| issues
| dylan604 wrote:
| I like how you uhm issues, but not occasional.
| aborsy wrote:
| It's worth mentioning that, although hardware keys are
| increasingly supported, if they are not available, there are
| usually fallbacks to less secure factors, such as email or phone
| numbers.
|
| What's the point of a hardware key then, if email also works?
| [deleted]
| toastal wrote:
| Why should I buy a Yubikey with its closed-source firmware, when
| OnlyKey and Nitrokey offer open-source firmware (that get
| updates) for a similar price?
| fullstop wrote:
| While I'm not a fan of closed-source firmware, there's
| something nice about the firmware being indelible.
| hashimotonomora wrote:
| Do these keys work well under FreeBSD?
| LinuxBender wrote:
| They are just a "keyboard" as far as the hardware is concerned.
| If your OS can support a generic USB keyboard they will work
| fine.
| tialaramex wrote:
| Only the weird Yubico-specific OTP thing is a keyboard. The
| FIDO features are HID (Human Interface Device, the USB
| protocol for keyboards, mice, etc.) but they are not
| keyboards, when asked what _sort_ of thing they are in HID
| they say they are 0xF1D0 ie FIDO devices, which means
| software looking for them can find them in order to speak the
| FIDO sub-protocol. I presume the PGP key stuff similarly uses
| its own standard protocol.
| hvinayan wrote:
| It shows up as a CCID reader with a card attached for PGP
| stuff.
| GekkePrutser wrote:
| Yes I use mine on FreeBSD in OpenPGP mode. Fido mode I didn't
| test because Firefox doesn't do password less Fido (still....)
| And I never use Chrome
| tialaramex wrote:
| I don't run FreeBSD, so perhaps a FreeBSD user with a Yubikey
| will chime in, but as I understand it FreeBSD has Firefox and
| OpenSSH, and both these programs can use the FIDO feature
| (which is the focus of the article) on a USB Yubikey to
| authenticate you successfully to a remote system so it ought to
| work out of the box on up-to-date software.
|
| The other features like using it to store PGP keys are a bit
| more fiddly to set going and you may need to read instructions
| specific to FreeBSD for those.
| TacticalCoder wrote:
| > A Yubikey can be hacked to send arbitrary keystrokes - but
| that's of limited usefulness. I guess an attacker could force
| open a browser window to download malicious software, but that
| would be fairly obvious to a user.
|
| If it can send arbitrary keystrokes, it's not just a "way in"
| (trying to download malicious software): it's also a way to
| exfiltrate the data (for example keylogged inputs) it collected.
|
| As for being fairly obvious to the user: what about waiting for
| command+t (or whatever the command is) plus something looking a
| website to be typed, then wait for 4 minutes of user inactivity
| (no keyboard input, no mouse input) before sneakily opening a tab
| and quickly closing it? Sure, some user may notice it but many
| won't for after 4 minutes of inactivity they won't be looking at
| their screen (and the screensaver won't have kicked in already).
| rfoo wrote:
| Not to say such attack scenario does not exist, but:
|
| A USB HID device cannot listen on what other keyboards typed,
| except for NumLock/CapsLock/ScreenLock indicator.
| kevin_thibedeau wrote:
| USB isn't a party-line bus. An HID can't see anything from
| other branches of the USB subsystem. State changes have to be
| explicitly relayed by the host.
| elric wrote:
| Agreed. The OP is overly optimistic in their assessment. A
| rogue USB device which can enter input, is pretty much game
| over. It can do anything on your computer that a physical user
| can. Phoning home and installing a boatload of malware before
| you can even blink would be a good start.
|
| Windows users in particular have been conditioned to not react
| to evil things like autoplay when inserting USB devices. "Don't
| mind me, I'm just installing drivers". I've seen USB headphones
| (!) launch programs on first insert. By the time you click
| "cancel", any number of things could have happened.
| md_ wrote:
| It's a little odd to me that the author hopes FIDO keys as a
| single factor is rare. This is explicitly supported by FIDO and
| Yubico, and available in the Microsoft ecosystem
| (https://support.microsoft.com/en-us/windows/sign-in-to-
| your-...)!
|
| As tomxor said elsewhere here, though, batch attestation allows
| you or relying parties to check that the key is a "real" Yubico
| key.
| sascha_sl wrote:
| It's available, but in practice it is almost never used without
| very robust backup factors because the support overhead from
| people losing their keys would be immeasurable. Much easier to
| bind people to phone numbers, despite them being really bad
| identifiers.
| edent wrote:
| (Author here) I hoped it was rare because it seems like an
| obviously bad idea. I can see how it would be convenient - but
| that's often the opposite of secure.
|
| I wonder where it would make sense though?
| yjftsjthsd-h wrote:
| Why is it an obviously bad idea? It reduces login to a single
| factor of a physical object you possess, but for many people
| that's probably good enough. I mean, most people's physical
| houses are only protected by a physical key with single
| factor authentication and nobody seems to mind that.
| judge2020 wrote:
| I guess for physical keys, it means you losing it instantly
| triggers anyone with it access to your M$ account, so eg.
| TSA could take it from checked luggage, plug it in, and go
| snooping through your email. Webauthn on Windows via
| regular TPM is good in that it's not really tied to the
| computer's cryptographic key, it requires some wrapped data
| stored by Windows as well (when I reinstalled Windows
| 11->Windows 11 from scratch none of my Webauthn logins
| worked, it was like I had a new key entirely).
| postalrat wrote:
| The physical keys I have require a PIN to be entered
| before they function. I haven't looked into the specifics
| but it's possible the token denies attempts after a
| certain number and possibly deletes itself after a
| certain number of attempts fail in a row.
| petepete wrote:
| Doesn't the PIN mean it's not single factor?
| postalrat wrote:
| Probably depends who you ask.
| smileybarry wrote:
| Passwordless login doesn't necessarily mean a physical
| separate dumb key, it can have many implementations that make
| sense:
|
| 1. WebAuthn (current spec) is also implemented by Android,
| iOS macOS and Windows 10/11 (natively); that makes your
| device a possible "passwordless factor holder". You then
| essentially tie your authentication with your device passcode
| and/or biometric ID, similar to what a password manager would
| do, except there's no password to steal.
|
| 2. YubiKey BIO supports biometric authentication (I presume
| with on-board fingerprint verification) to use the device's
| keys. So it's essentially a biometric-protected private key.
|
| 3. IIRC some hardware crypto wallets can act as WebAuthn
| devices and display the website domain when asking you to
| touch it. Maybe they support passcode protection?
|
| 4. Even if you were to use a "raw" WebAuthn key stored on
| your computer (on TPM, Secure Enclave, or even filesystem) --
| if you protect it with a password, you essentially have
| pubkey authentication with a second factor of password.
| b3morales wrote:
| How would this differ from using an SSH key? Don't we do this
| all the time? Given prior authorization to add the factor, it
| is afterwards used on its own to authenticate.
| tialaramex wrote:
| Almost anywhere? It's much more convenient than the "type in
| your username" step.
|
| To be clear: Things you can do with FIDO2 include:
|
| * Just a "second factor". The authenticator has no memory of
| who it is, RPs (Relying Parties, e.g. web sites) basically
| provide prompts, which they derive from looking up a username
| you entered. The RP says if this is tialaramex, you'll
| recognise _this_ arbitrary ID you gave me when enrolling and
| sign this freshness proof. The authenticator checks if it
| recognises the ID and if so retrieves the private key and
| signs the message, voila.
|
| * "Passwordless". The authenticator is behaving the same, but
| now the RP is only taking a username first, there may be no
| second factor. This is more secure than most passwords today,
| but is only a single factor.
|
| * "Usernameless". The authenticator now needs to remember
| every RP it has enrolled with, because the RP won't prompt
| it. Given the name of an RP (e.g. "news.ycombinator.com" the
| authenticator needs to replay the ID it gave when enrolling,
| and sign a freshness proof "I'm still, uh, tialaramex
| apparently".
|
| In a corporate environment, or perhaps banking, you can
| insist (via a thing called "Attestation") that the
| authenticator provides proof it is a real authenticator made
| by, e.g. Yubico and based on that claim trust it to do multi-
| factor authentication itself.
|
| Yubico's cheaper products do PIN auth, so you touch the
| sensor and type in say, "MyFuckingSecret" as PIN, the PIN is
| not sent to the Relying Party, they just get a message saying
| "Here's proof I'm that Yubico Yubikey which enrolled, and I
| say this is still the same human who enrolled me, I checked
| using a method my vendor says is suitable".
|
| Yubico's most expensive product, and the Google Pixel series,
| and some iPhones, use a fingerprint as their additional
| factor. Again though, the authenticator just says "I promise
| I checked, this is who made me, trust or don't" it doesn't
| send fingerprints anywhere.
| waffleiron wrote:
| > Other than the risks inherent in any USB device, what's the
| worst that could happen? A cloned device might let an attacker
| have a duplicate key. But that's useless unless they also have
| your username and password.
|
| So if this isn't a risk ("it's useless") then doesn't that
| automatically imply that there are no benefits of using a
| Yubikey?
|
| edit: To add, this comment is in reply to the final question of
| the article "What's the worst thing that can be done with a
| compromised Yubikey?".
|
| My answer being, the risk would be that you think you are using
| 2FA but you "aren't".
| sascha_sl wrote:
| Or the USB device could turn into literally anything else, from
| an ethernet interface to a keyboard. This is a classic case of
| overthinking your threat model and missing the more obvious
| attack vectors.
|
| And for enterprises that want to make sure people enroll with
| genuine keys (as they sometimes also use these keys as physical
| access tokens), they can already use the factory-set OTP slot
| (the one with the cc instead of vv code) to check if a token is
| actually from Yubico.
| dmurray wrote:
| You are using 2FA. If just one of your two factors is
| compromised, that doesn't mean you "aren't" using 2FA - just
| that there exists an attacker who is one step closer to
| breaking into your account.
|
| Any attack on 2FA requires the same attacker to compromise your
| password and your physical device. If one adversary phishes
| your password and someone else finds the YubiKey you dropped on
| the train, you're almost certainly still OK. You need to ask
| whether there's a reasonable threat model where the same guy
| gets your password and also gets you to use his own fake key.
| waffleiron wrote:
| But the author argues, and sets up the following scenario:
|
| >A cloned device might let an attacker have a duplicate key.
| But that's useless unless they also have your username and
| password.
|
| That even in case there is a cloned device, it's not an issue
| because you still have your password.
| xenocratus wrote:
| > the same guy gets your password and also gets you to use
| his own fake key.
|
| The article started from an event happening at a conference.
| I haven't been at many, but I assume: 1) at some you have a
| badge identifying you; 2) even if you don't, depending on who
| you are, it could be easy to identify you from other sources.
| At that point, if your identity is revealed and you're using
| the fake token, you're no longer using 2FA. This is not the
| same as "some guy finding your lost token on a train",
| unless, of course, that person saw you losing it and knows
| who you are, but even then - if you lose your token, you
| wouldn't/shouldn't keep using your spare...
|
| I mean, if you get a notification from HIBP that some
| password has been compromised on some account, I assume you'd
| change it, you wouldn't just go "meh, I have 2FA, why
| bother". Why would you ever keep on using a (potentially)
| fake Yubikey?
___________________________________________________________________
(page generated 2022-03-06 23:01 UTC)