[HN Gopher] FIDO2 security key company releases hardware that's ...
___________________________________________________________________
FIDO2 security key company releases hardware that's open source and
uses Rust
Author : conorpp
Score : 377 points
Date : 2021-02-12 21:10 UTC (1 days ago)
(HTM) web link (solokeys.com)
(TXT) w3m dump (solokeys.com)
| gorgoiler wrote:
| In life, every so often one hears of a concept that is so simple
| and so elegant that the fact that one had not heard of it before
| today makes one's jaw drop in disbelief:
|
| > _Reversible USB-A. Well this maybe wasn 't the most critical
| feature anyone expected, but, consequence of our new PCB & case
| combined construction, it was easy to make USB-A reversible. So
| why not!_
| mNovak wrote:
| I'm more impressed by the cavity PCB construction--fill with
| epoxy and boom dead simple waterproofing! I've never
| encountered this before; wonder if it's available with the
| batch fabs.
| mastax wrote:
| The difficult part is the step milling for the cavity. Its
| unusual so you need to work with the fab to get it right.
| Bunny Huang had a good post about it.
| jononor wrote:
| The technique is called "potting", and is common for small
| rugged devices. I think nearly all assembly houses will offer
| it. Some electronics components, such as relays, power
| converter modules also use it.
| SecurityLagoon wrote:
| Pretty common in ruggedized devices. Has the benefit of
| keeping components stuck down under vibration and tamper
| evident too.
| JunkDNA wrote:
| USB remains the only connector I use where I routinely get the
| orientation wrong 3 times.
| t0astbread wrote:
| As someone who's not familiar with U2F or comparable standards I
| have a general question about the topic: When registering a key
| for multiple accounts (at the same site or at different sites)
| can website owners link those accounts by some common "key ID"?
| In the sense of: "Oh, this is Bob's key so this account must
| belong to Bob".
| jabbany wrote:
| There's no way to do this _discreetly_ if the key is properly
| implemented.
|
| When you register your key on a service, the service sends an
| application identifier down. Your key then creates a fresh key
| pair and sends a handle (name for that keypair) and the public
| key back to the service. Later when you authenticate, the
| service sends down the handle and challenge. Your key uses the
| handle to find the right private key and sign the challenge,
| which is checked by the service using the public key to confirm
| that you do indeed possess the private key.
|
| Since fresh keypairs (and handles) are generated each time you
| register a key, the service can't use the registration process
| to identify whether you're re-using a physical key (it should
| look no different from using a new physical key).
|
| Alternatively, a service can check if your physical key
| contains other handles by initiating requests with them, but
| this will almost always be very obvious. E.g. If they suspect
| you are Bob, they could request a challenge with _Bob's_
| handle.
|
| But they can't just spray handles, since if they do this when
| you're not expecting to authenticate anything, it will be quite
| obvious: your key, and any intermediate applications like the
| browser or OS, will behave like they are authenticating. With a
| well implemented key, you will be safe as long as you don't
| touch the key on spurious authentication attempts. The service
| won't be able to tell whether the key doesn't have the handle
| (and is ignoring the challenge) or if the key does have it but
| you just didn't touch the key because you weren't expecting an
| authentication request.
|
| This leaves the service with the final option of only doing the
| test while you're trying to log into what they suspect is an
| alternate account. That means they can only do one check and
| will have to be fairly certain about you being Bob lest you be
| tipped off. If they guess right, you won't be able to tell a
| difference but the service will know that you can authenticate
| with Bob's handle while trying to log in as Alice. If they
| guess wrong however, you might become suspicious since the
| authentication will fail and in a non-standard way (e.g. the
| key can indicate that it has received a foreign handle).
|
| All this means is that, if the service is trying to tie
| identities to "serve ads", they won't have a feasible way to do
| this with U2F. But, if it's a threat actor with nation state
| level resources and lots of time then... well... nothing
| consumer level will really help you (though U2F still puts up a
| decent fight).
| mightybyte wrote:
| I think that would be the public key. You can roughly think of
| it as the hardware key has a private key embedded in it in a
| way that it (supposedly) can't be gotten off. That private key
| has a corresponding public key. You can think of the private
| key as the password and the public key as the username. So I
| think the public key is the "key ID" you're looking for.
| sneak wrote:
| This is not how U2F works. The sites never see the device's
| long-term public key.
| nickray wrote:
| No, they cannot. This is an explicit design goal of FIDO
| (https://fidoalliance.org/specs/fido-security-
| requirements/fi...).
|
| The actual public key used for logging in to a specific site is
| completely random.
|
| Optionally, the website can ask for "attestation", which is
| intended to prove that the public key is from a specific
| vendor/model. To make this also unlinkable, devices are
| supposed to share attestation keys in batches of 100k units.
| pstrateman wrote:
| I think he's asking about have two accounts on the same
| website.
|
| I'm not so sure they cannot associate.
| t0astbread wrote:
| Ah, I see! So cross-site (across multiple relying parties)
| linking is prevented but if I have multiple accounts within
| one relying party they can be linked?
| sigmar wrote:
| Public key and key handle would still be unique and
| unlinkable for each account on the same site with the same
| u2f token. The yubico documentation is pretty good at
| explaining this https://developers.yubico.com/U2F/Protocol_
| details/Overview....
| tialaramex wrote:
| FIDO (except in resident mode which we'll ignore here)
| requires the site requesting you authenticate to hand over
| a large opaque blob called an ID that your authenticator
| gave it when you enrolled the authenticator. This ID will
| be different for every time you enrolled an authenticator,
| and it can recognise its own IDs (using modern
| cryptography). To prevent you enrolling the same one twice,
| sites hand over a list of the ones you already enrolled and
| your authenticators say "I'm already enrolled here" if they
| recognise the ID.
|
| So somesite.example if it suspects Jim and Candy are the
| same person, or at least, using the same FIDO
| authenticator, could do this:
|
| When Jim signs in, they present Candy's ID. If they're
| right, Jim's authenticator goes "Oh I recognise this,
| signed". If they're wrong, Jim gets an error. Weird.
| Presumably on a second try they give Jim's ID and it works
| so that Jim isn't too suspicious.
|
| So this attack would allow a site that strongly suspects
| you're doing this to prove it, to their own satisfaction
| anyway. But it doesn't offer any practical way for a site
| with more than a handful of users to just match all the
| users.
|
| In resident mode, you have to admit who you are as part of
| signing in - you're not separately typing in an email
| address or username or whatever, you just press the button
| on your authenticator (or touch the sensor on your phone,
| or whatever) and you're in. This obviously means it doesn't
| make sense for Jim and Candy to use one device for two
| users on the site, and most likely their device will
| prohibit them from trying to enroll the second user this
| way.
|
| Edited to add: If someothersite.example plays Jim or
| Candy's IDs from somesite.example (may it's secretly run by
| the same people, or they stole a database backup) to Jim
| (or Candy) they don't work, the IDs are bound to the
| domain, so these don't match.
| StavrosK wrote:
| I implemented this mode in a Django library [0] (demo on
| www.pastery.net) because I love the idea of not needing a
| password manager any more, just simply having a key with
| you to log in anywhere, but it doesn't seem to have
| widespread browser support yet.
|
| Maybe I made a mistake, but Firefox doesn't seem to work
| very reliably with it, and mobile support is spotty too.
|
| [0] https://pypi.org/project/django-webauthin/
| tialaramex wrote:
| Yes, resident credential (aka "Client discoverable")
| support in (at least) desktop Firefox is broken and has
| been for a long time. I believe it's also absent (but at
| least not broken) in desktop Chrome. :/
| johncolanduoni wrote:
| For U2F I don't believe that's the case for most devices.
|
| Yubikey outlines their method here[1]. They generate a
| different keypair for each website public key and have the
| server store an encrypted and authenticated copy of the private
| key using a single on-device key. So baring breaking the
| underlying primitives the server will only have a site-specific
| public key and a site-specific encrypted blob.
|
| [1]:
| https://developers.yubico.com/U2F/Protocol_details/Key_gener...
| IgorPartola wrote:
| They are asking about two user accounts on the same site, not
| with two websites on the same server. As in two GMail
| accounts.
| [deleted]
| mNovak wrote:
| Does anyone know if these types of keys and/or protocols can be
| made to work without a full USB bus? I'd love to have this kind
| of functionality in embedded systems, without running an OS.
| eeZah7Ux wrote:
| Reminder: FIDO2 is mostly useless if your browser or your OS is
| compromised.
|
| Also if someone hijacks your account using bruteforced recovery
| codes and/or email.
|
| Also if the servers are compromised or account data leaked.
|
| In short, it protects from some forms of phishing.
|
| (I'm not trying to criticize FIDO2, just pointing out what to
| expect from it)
| eeZah7Ux wrote:
| A good bunch of downvotes for this? Congratulations HN crowd.
| dhdhhdd wrote:
| Otoh if your browser/os is not compromised, it's safer than
| authentication code and SMS OTP.
|
| And hopefully recovery codes have maximum retry count?
| eeZah7Ux wrote:
| > Otoh if your browser/os is not compromised, it's safer than
| authentication code and SMS OTP.
|
| ...but less safe than an external token if someone steals
| your laptop with the FIDO2 key in the USB port.
|
| Yet, this are really very minor improvements to the (sorry)
| state of web and desktop security.
| 65a wrote:
| I'm really hoping they bring GPG to the Solokey V1, but I'm
| starting to lose confidence
| ibotty wrote:
| https://github.com/solokeys/kickstarter2021/discussions/26#d...
|
| TLDR: it's not as easy as thought. It will be easier for the
| new one.
| als0 wrote:
| > releases hardware that's open source and uses Rust
|
| This is an LPC55S69. So it's open source firmware, not open
| source hardware.
| nickray wrote:
| I see your point too, and we're looking forward to a world in
| which low-power (to enable NFC) open source chips with security
| features exist. For instance, https://tropicsquare.com is a
| project that is working towards that.
|
| For now, what we mean by open source hardware is on the one
| hand that all components are freely available (without NDAs,
| which nearly all secure elements entail), and on the other that
| the schematic of the device is open source and passes OSHWA
| Certification (the CERN license
| https://ohwr.org/project/cernohl/wikis/Documents/CERN-OHL-ve...
| is relevant here). This means that you can in principle build a
| device yourself. The certification will be done post-campaign
| (we want to avoid copycat products appearing before ours is
| available in the open market). Like we did with our three
| previous keys (e.g.,
| https://certification.oshwa.org/us000155.html and
| https://github.com/solokeys/solo-hw).
| smarx007 wrote:
| Arduino is OSHW but its AVR microcontroller isn't, yet we still
| regard Arduino boards as OSHW. But I see your point that the
| crucial component of this OSHW key is not OSHW.
| thinkmassive wrote:
| "Reversible USB-A" now there's a feature I wish we'd see more
| often!
| anonisko wrote:
| Would have been nice to be common before USB-C started becoming
| standard...
| _JamesA_ wrote:
| Is there a Linux compatible NFC reader that would allow a simple
| tap to authenticate with one of these?
| StavrosK wrote:
| This looks great and I'm very excited for it, but it's been
| "coming soon" for more than a year. The original release date was
| last June, now it's this June for the first backer keys, AFAIK.
|
| I hope it doesn't take that long, but there's a history of
| delays, unfortunately.
| leafmeal wrote:
| How does this compare to a Yubikey for example?
| _underfl0w_ wrote:
| The hardware is open-source, you can theoretically update the
| firmware so you're not vulnerable if a researcher finds a bug
| after your purchase, there's currently no support for getting
| it to act as a keyboard and type the password for you AFAICT,
| to name a few.
| ericseppanen wrote:
| I don't think this is true in the general case. Most Solokeys
| come in a "locked" form-- they will only accept firmware
| updates that are signed by the manufacturer. You can buy a
| "hacker" variant that is unlocked (meant for those that want
| to tinker with the firmware), but if you were to use one of
| those you're giving up security against someone loading
| malicious firmware onto your device.
|
| This is probably the right tradeoff for most users. Solokeys
| has done a great job of providing continuous support for all
| of their products, and their software stack has been open
| source since the beginning. That (combined with the low
| price) makes them my first choice for a hardware security
| token.
| Dylan16807 wrote:
| > You can buy a "hacker" variant that is unlocked (meant
| for those that want to tinker with the firmware), but if
| you were to use one of those you're giving up security
| against someone loading malicious firmware onto your
| device.
|
| You can't set it to wipe when updated?
| ericseppanen wrote:
| I have no firsthand information, but reading
| https://github.com/solokeys/solo
|
| "Solo Hacker can be converted to a secure version, but
| normal Solo cannot be converted to a Hacker version."
| GekkePrutser wrote:
| Yubikey supports fido2, piv like this one but also supports
| openPGP so if you need that it's not a replacement.
|
| It's more open source though. Yubikey open sources some
| components like that PGP applet but not all.
| notatoad wrote:
| am i reading their marketing stuff correctly that this doesn't
| include any new fido-protocol features vs the solo key v1? that
| is, as far as chrome sees it, it might as well be the same
| product?
| nickray wrote:
| Website can distinguish via the optional attestation key.
|
| In terms of features, CTAP v2.1
| (https://fidoalliance.org/specs/fido2/) is still draft only,
| but yes both v1 and v2 keys support hmac-secret and credential
| management. We could add authnSelection and authnConfig, but
| not clear if any browsers actually implement/use it.
|
| The major new feature is PIV.
| GekkePrutser wrote:
| Nice, I'd love this as an open source yubikey replacement.
|
| But it doesn't do OpenPGP, I rely on that way too much sadly. Not
| just for SSH which supports fido2 now but also for file
| encryption and my password manager.
|
| If they add that in the future I might jump ship.
| nickray wrote:
| We hope and think that PIV can replace all the practical use
| cases for PGP. Specifically among those mentioned, `age` for
| file encryption, and either FIDO resident keys with hmac-secret
| for password managers, or something like `passage` (fork of
| `pass` using, again, `age` for encryption). For SSH you can use
| FIDO for newer OpenSSH, and either `pivy` or `yubikey-agent`
| via PIV. Cheers!
| GekkePrutser wrote:
| Understood and it probably can but I don't _want_ to replace
| it :) I like OpenPGP (especially the newer revision which
| supports elliptic curve).
|
| The GPG toolchain is pretty great for file encryption and I
| use it for my password manager too (which is indeed ZX2C4
| Pass - passwordstore.org ). I don't want to use a fork using
| 'age' because I rely on the GPG version on my mobile (using
| the excellent OpenKeyChain app and the passwordstore app
| which talks to that).
|
| Also, I log in to SSH servers I don't have the ability to
| install stuff on, like the ILO on my servers. And again on
| mobile, there's bridges to OpenKeyChain for SSH in e.g.
| Termux which work great including agent forwarding. But not
| for PIV. So it's not a complete replacement.
|
| Sorry but without OpenPGP it's a non-starter for me. I
| understand I could use Solokey if I make a lot of changes in
| my personal setup and make some compromises especially on
| mobile. But why would I? I can just continue using Yubikey :)
| Don't forget you're in a heavily contested market, you should
| be better than the competition.
|
| I'd like to have an open-source authentication key but in the
| end it's a tool to me. Open-source is a 'nice to have'. It's
| not worth it to me to deviate too much from my existing
| workflow.
| georgyo wrote:
| What about code signing?
|
| People like to dislike PGP and replace it with a myriad of
| different solutions. But PGP is everywhere and awesome. It's
| very wide spread adoption is invaluable. I really don't want
| to see it replaced with zillions of different bespoke
| solutions.
| GekkePrutser wrote:
| Yeah I dislike PGP mainly for email by the way. It's too
| clumsy there.
|
| For file encryption and signing it's great IMO.
| tadfisher wrote:
| Yep! It's magical having everything signed automatically by
| plugging in my Yubikey and setting some git config once. I
| will not go to something that doesn't enable this.
| kevdev wrote:
| This. I'm a backer for their Kickstarter but the lack of
| PGP is unfortunate. Yes, there are problems with it. But as
| you said, it's everywhere. It's not going anywhere anytime
| soon, so what's the harm in supporting it for now?
| IgorPartola wrote:
| Why do people like to hate on PGP? It's a pretty great
| project.
| Avamander wrote:
| Because it has a shitton of issues. The implementations
| aren't great, cryptographic issues, memory safety issues,
| stable API/ABI issues. It's still not supported well by
| software that could use these features.
| GekkePrutser wrote:
| Most of the security issues are mitigated by using a
| hardware token to do the actual encryption anyway.
| motiejus wrote:
| Anything similar to https://github.com/drduh/YubiKey-Guide
| for what you have just described?
|
| I am willing to use what I can understand, backup and
| operate, and yubikey+gpg seems to be it because of this
| guide.
|
| Anything practical for what you've mentioned?
|
| Edit: for ssh and encryption.
| upofadown wrote:
| >`age` for file encryption,
|
| I can't see why one would bother. OpenPGP works and is a
| published standard that has been around forever. Age is just
| pointlessly different with fewer use cases. This has an
| example of where age is objectively worse:
|
| * https://articles.59.ca/doku.php?id=pgpfan:agevspgp
| rlctntpgpusr wrote:
| As a reluctant PGP user who has backed Solo Keys v2 for 4+
| for personal use, and who has written Rust code in the
| pursuit of using PIV over OpenPGP, this answer is
| disappointing.
|
| Age isn't there. It does NOT have good (read, right now,
| really, _any_ ) support for hardware tokens. I'm skeptical of
| what I've seen. _And_ age still punts on authentication.
| _And_ PIV still doesn 't have decent keys at decent sizes
| standardized and thus is awkward to use in practice.
|
| I'm really not convinced, and I really want to be. I wrote a
| bunch of forward-looking Rust, and then permanently
| backburner-ed it because age/yubikey just isn't there yet.
|
| Using FIDO2 for SSH, when you're used to the portability and
| versatility of OpenPGP, stinks. I can use my Yubikey
| _perfectly_ to do SSH and GPG in Windows. I can forward SSH
| agent and GPG _from Windows to Linux_ such that it is
| identical in functionality to me sitting in front of my
| actual Linux box with my Yubikey plugged in. I have _never_
| seen that done with PIV.
|
| I have this extreme fear that I'm going to wind up with four
| solokeysv2 that just sit in a drawer.
| boris wrote:
| Another thing to keep in mind about PIV is that it's
| currently limited (at the standard level) to RSA-2048 max.
|
| Would it be possible to make a custom firmware that support
| RSA-4096 PIV?
| fsflover wrote:
| Librem Key can do OpenPGP and uses FLOSS:
|
| https://puri.sm/posts/introducing-the-librem-key/
| l0b0 wrote:
| As someone who is comfortable with TOTP but hasn't tried
| FIDO-/Yubikey-style devices, I have a few questions:
|
| - Are drivers for this _already installed_ as part of desktop
| Ubuntu 20.10 /Windows 10? Any driver installation will absolutely
| make this a no-go for family members.
|
| - Is additional software required for _anything_ non-techies
| might reasonably want to do with this device, including resetting
| it, adding an entry or checking which entries are already on the
| device? The ideal would probably be if the device acts like a USB
| stick, with entries being shown as .bin /.txt files which can be
| manipulated in the normal ways.
|
| - How easy is it to create a backup? The ideal (for non-techies)
| would probably be something like plugging a device into a PC and
| simply copying files across. Ditto for duplicating to another
| device.
|
| - Is there anything else which would likely stop non-techies from
| using this for basically everything they care about?
| conorpp wrote:
| Just wanted to add since I didn't see this covered in other
| comments yet --
|
| TOTP and any sort of one time code authentication are just as
| phishable as passwords. Perhaps the biggest benefit for most
| people using U2F or FIDO2, is the large resistance to phishing.
|
| This is because of how the whole ecosystem has adopted FIDO2.
| When a FIDO2 key signs an assertion for a website, it includes
| the domain in the signature base, e.g. "example.com". The
| browser enforces that the request to the FIDO2 key always uses
| the correct name of the domain you're on.
|
| If you accidentally go to a fake website, "exaample.com", then
| the key will make a signature for "exaample.com", which is
| invalid for "example.com". Nothing can be phished to get around
| that, unlike OTP codes.
|
| Even if you have other 2FA options linked to your account, as
| long as you're using your FIDO2 key, you gain this benefit.
| Very strong benefit for both individuals and enterprises.
| vlovich123 wrote:
| I look at it like nothing < SMS 2fac, app OTP, fido2.
|
| Every layer buys you a little bit (or a lot) more, raising
| the skill level and/or cost. Fido2 is much harder to phish
| but of course weaknesses may be found in the future.
| tadfisher wrote:
| I wrote pass-otp because I want to use a hardware token
| everywhere, not a TOTP secret that can be duplicated. The
| number 1 complaint I get is that I'm defeating the purpose of
| 2FA.
| tialaramex wrote:
| > If you accidentally go to a fake website, "exaample.com",
| then the key will make a signature for "exaample.com", which
| is invalid for "example.com".
|
| This actually isn't true - the result is even better.
|
| When you visit fake.example instead of real.example there are
| two scenarios: For FIDO2 (like this product) with
| usernameless mode, just as with a modern iPhone or fancy
| Android with fingerprint reader, the authenticator knows
| perfectly well that you've never registered at fake.example
| so, you can't very well authenticate to it, you get an error.
|
| With FIDO1 (or on sites that don't use the usernameless
| feature anyway) the authenticator has no idea you've never
| visited fake.example... but the site has to hand over an
| opaque ID, a large binary blob. This is (either directly or
| in effect) actually your private key, encrypted in AEAD mode
| using a symmetric key known only to your authenticator.
| Another ingredient to this encryption is the domain name. So
| either fake.example hands over a random blob, which is
| gibberish, or they hand over a genuine real.example blob...
| but they're fake.example so the decryption fails. You get an
| error.
|
| The way I found this out was by trying it, I built a toy site
| with WebAuthn authentication. If I run the same code, on
| another site I own, it gets an error in the Javascript
| telling it that apparently I don't yet have a Security Key
| enrolled for this site, maybe it should enroll me first. If I
| tell it to pretend it's a different site, it gets an error
| saying no it isn't.
|
| [ The bad guys could enroll you, but now you're really
| signing into their web site. Which is cool, but, doesn't
| actually help them phish credentials for the other site ]
| conorpp wrote:
| You are right, I lied a bit to oversimplify :)
| lvh wrote:
| Can't speak for this thing specifically, but FIDO2 keys in
| general:
|
| - Yes, you have everything you need on every major OS/browser
|
| - These devices are zeroconf; resetting it actually kills a
| security feature (key use increments) aiming at cloned devices
|
| - The ideal backup for this is to have a separate key, both
| authorized. They don't need to have the same material, in fact,
| cloning it would be considered a weakness (how do you know
| someone hasn't cloned it without your knowledge?)
| Groxx wrote:
| > _- The ideal backup for this is to have a separate key,
| both authorized._
|
| This in particular is important. Security is only as strong
| as your weakest link, so any backup methods (e.g. "forgot
| password" flows) might as well be your primary method, if you
| actually care to strongly secure things.
|
| Adding another (or more) key gets you same-security
| redundancy if one fails or is lost. Nothing else will achieve
| this.
|
| Degrading to "forgot password" may be entirely fine for
| [person's] use of a security key, but you _must_ be explicit
| about that decision, or it 's mostly security snake-oil.
| xur17 wrote:
| This is one thing I hate about these keys though - some
| services only support one key, and for ones that support
| multiple, I struggle to figure out a storage system for my
| backup key. I don't want to keep it with me (because then I
| am at risk of losing both), but if I keep it separate, I
| need to remember to add it to new accounts - there's no way
| to see a list of accounts a key has been associated with.
|
| I'm curious how others handle this.
| Groxx wrote:
| Completely agreed. I don't have a good solution for that
| either, aside from "try harder". Which puts them in a
| fairly specific niche of reasonable use, tbh. And any
| site without the ability to set up multiple emails / keys
| / etc is not taking basic steps to allow its users to
| maintain access their account, so I think it's fair to
| rule them out simply as "bad sites" (though they're quite
| numerous, sadly).
|
| For corporate purposes, they're pretty decent. If one is
| lost or fails or whatever, they can get you a new one,
| because the company can quite-strongly verify that you
| are you - much better than your average website. A bank
| or something might also be reasonable.
|
| For general personal use... I dunno. You really don't
| want to be locked out permanently if you lose the key,
| which tends to mean they degrade to your email security,
| and they're just convenience tools. Which is more than
| nothing! Convenience that emails you when it is bypassed
| is better than no email when bypassed! But it's _very
| far_ from the security claims that tend to go along with
| these keys.
|
| Personally I'd like these keys to be a "fast login"
| convenience, and for email-reset to be delayed by a day
| or three with an easy "revoke" button. It's exceedingly
| rare that I truly _need_ backup access immediately, and
| allowing it all the time is _definitely_ opening the door
| to bulk theft of accounts.
| g_p wrote:
| This is the biggest weakness of U2F unfortunately.
|
| My approach is to keep a list (a simple text file) of
| what services are used for U2F, and which keys are
| enrolled with it.
|
| Most services ask or require you to name the token you
| enrol (if they support multiple tokens) - I gave the
| tokens names so they're consistent.
|
| Now I have 2 ways to check - logging into a site, you can
| see what keys are enrolled. And as fallback, I can use my
| underlying text file and see which keys I enrolled.
|
| You just need to make a point to check the file once
| every so often (at least first time you are near your
| backup key after having edited the text file).
|
| I've seen some interesting approaches (on modifiable
| tokens where keys can be exported) where they configure a
| backup key as a mirror of the main key, but with the
| counter advanced forward such that using the backup will
| invalidate the regular (thus alerting you to the use of
| the backup by an adversary, as long as the service
| properly validates the counter).
|
| I can't think of an easy solution to this (it is
| effectively the key distribution problem) without adding
| complexity (like manager software for tokens, and a
| Shamir's secret sharing style way to export a token's
| root key through SSS such that it can be recovered by a
| quorum of keys in an emergency). That breaks various
| aspects of the threat model though.
|
| Perhaps there's a less complex way to do it though? Like
| having up to N persistent public key slots on the token,
| where public keys of your other tokens can reside. When
| registering, the generated key is also encrypted "to"
| those tokens, and sent as supplementary key handles.
| You'd need to add a pairing relationship to validate
| authenticity of the key handles, but I suppose it could
| work.
| user3939382 wrote:
| My threat model is focused on remote attacks, I consider
| physical access to my workstation game over. So one stays
| on my keys, one on my wife's keys, and one stays plugged
| into my workstation.
|
| If I'm enrolling the keys with a given service I make
| sure to add or remove all three at the same time so I
| don't have to track which is associated with different
| accounts.
| XorNot wrote:
| This isn't really an adequate threat model today though,
| where everyone has laptops. Having a workstation stolen
| for most us is actually extremely likely - probably more
| likely then someone trying to attack our credentials.
|
| In this case though, full-disk encryption and TPM usage
| is the mitigation - provided the disk goes dead when
| anyone short of a nation-state tries to manipulate it,
| you're good.
| Arainach wrote:
| I keep one backup key in a fire safe at my residence (in
| case I lose my primary key somehow) and one with a
| trusted party in a different state (in case Mt. Rainier
| explodes and the entire state of Washington is lost -
| though at that point I have bigger concerns)
| schrodingersket wrote:
| I keep one of my keys in a fireproof safe at home, and
| the other on my keychain as my daily driver. If a site
| allows me to enroll multiple U2F keys, I just bring the
| backup to work (my home office, currently) with me the
| next day and enroll it then. For sites that only allow a
| single key (looking at you, AWS), I will usually enroll
| the key I have on me, and then when I have both, I write
| the same TOTP seed to both keys (usually by scanning the
| QR code with each key plugged into my phone before
| entering the one-time code used to verify and finalize
| TOTP enrollment) and use that instead so that there's
| effectively a TOTP duplicate.
|
| This gives me a pretty convenient list of sites I've set
| up the Yubikey with (at least for TOTP), since Yubico's
| OTP app lists all the sites I've used it for.
|
| If a site only allows a single U2F key to be registered,
| I'd rather have a backup with TOTP over the better
| security of a single U2F key, so this arrangement works
| reasonably well for me.
| taeric wrote:
| Having multiple keys without auditing when the backups are
| used, though, feels wrong. And that is my main gripe with
| these right now. Very hard to get any system to help build
| the habit of using the things. Most places default to
| remember your login. Basically forever.
| g_p wrote:
| While not cryptographic level auditing, this is arguably
| a UX feature for sites to implement -- on their
| inevitable loading spinner after login, they could show
| you the U2F tokens enrolled, and their most recent use on
| a small timeline. If your cold backup suddenly goes from
| ancient to now, that ought to be looked into!
|
| Regards habits, I find U2F is so easy to use that there's
| no real issue there. The bigger issue is that
| (relatively) few services support it. I'd much prefer to
| use it over TOTP phone generated codes, but far more
| sites seem to support phone app generated codes (while
| pretending you need their proprietary app to use them,
| even when it's just plain TOTP) or, even worse, SMS!
| taeric wrote:
| Yeah, I just installed the pass support for otp for some
| site. Can't remember which.
|
| My problem with the habit remains, though. I would love
| if my phone insisted me try a key at least once a week. I
| don't know how to force that. :(
| koolba wrote:
| Backups with lower grade _technical_ security are possible
| if you're willing to compromise speed. For example an
| offline process where you have to present yourself, in
| person, and show N forms of ID, to the service provider or
| their agent with a mandatory M day delay. Or where you can
| have X other users, who can log in, vouch for you to reset
| your access token.
| g_p wrote:
| 1. I'm not aware of any drivers being needed on any common
| platform. Support in Android apps is sometimes not perfect, but
| that's an app issue rather than a driver issue.
|
| 2. No software is required - far easier to use than you
| describe. You insert it, tap the button when prompted, and
| that's it. The token will decrypt an wrapped key (held by the
| remote service) using a hardware backed key, and sign an
| attestation using it. This attestation is tied to the domain
| name and URL scheme being accessed, so it "prevents" phishing
| as you can't trick users into relaying useful tokens.
|
| Note for FIDO2 there may be software to help manage more
| complex setups like "no username and password needed to login".
| If you're talking U2F (i.e. just 2FA), no software required.
|
| 3. You don't. There isn't anything to back up. You cannot
| export the internal key state, but services you use hold the
| (wrapped, encrypted and authenticated) key used for their
| service server-side. Your device just decrypts it, uses it, and
| discards it. You do need to think about backup, but you do that
| by enrolling 2 or more U2F/FIDO2 keys on each service you
| protect. That's the downside - you need to remember to enrol
| both keys on each service, every time you make a new account
| you protect with U2F.
|
| 4. Not really, beyond support at service side being limited
| (mostly) to big security-aware services.
| asnelt wrote:
| Regarding support on Android, if you are using a custom rom
| like LineageOS without Google Play Services then it won't
| work currently. Unfortunately, Google implemented FIDO2 in
| the play services, not in AOSP:
| https://bugs.chromium.org/p/chromium/issues/detail?id=997538
| g_p wrote:
| Interesting and disappointingly. In this case I was testing
| it with play services, using the nextcloud app. I believe
| they are using something slightly custom from an open SDK,
| and suspect the outdoor was at their end.
|
| It seems strange Google put fido2 into play services, but
| that's certainly what they seem to "need" to do to get
| things shipped, given the lack of prompt Android release
| updates (don't even start me on longevity...)
|
| Still unfortunate every time this happens, as AOSP just
| loses more and more functionality.
| sufficient wrote:
| Yep, Nextcloud is using our SDK from
| https://hwsecurity.dev/. We provide dual licensing for
| closed source and GPLv3 projects.
| arianvanp wrote:
| It uses USB HID as a transport.
|
| It should work out of the box on windows 10 and ubuntu.
| Microsoft is actually one of the largest forces behind the
| FIDO2 spec. Windows Hello implements FIDO2 too so you can use
| it dven without a dongle but just with your biometric reader on
| our laptop
| kelnos wrote:
| Others have answered most of your questions, but there's
| something I think deserves emphasizing:
|
| In general, you cannot (by design) back up these devices; if
| you could, that would defeat a lot of the security they
| provide. That means that if you lose it, you will have to find
| a way to get 2FA disabled for each and every account you
| enabled it for. Some orgs will have pretty onerous (but
| necessary!) processes for doing so, like having to provide
| government ID or physically visiting a brick-and-mortar
| location to prove your identity and ownership of the account.
|
| Some sites will allow you to simultaneously enroll two devices,
| so you can keep one as a backup, safe somewhere (though not
| _too_ safe; if you were to, say, put it in a bank safe deposit
| box, it 'd be a pain to fetch it any time you want to add a new
| account). But many sites only allow a single device to be
| enrolled.
|
| Some (like Yubico) let you purchase a "cloned" set of devices,
| where you can get two (or more) devices with the same keys on
| them, so you could actually put one of them in a safe deposit
| box as soon as it comes in the mail to act as a backup. That
| also solves the issue of some sites only supporting one device,
| as all of the devices in the set are effectively the same
| device. However, it doesn't appear that this is an option with
| the Solo keys (not certain of this; happy to be wrong about it;
| it's possible that you might be able to wipe the key material
| off new Solo keys and put identical copies of new self-
| generated material onto more than one key). On the flip side,
| if someone steals your backup key, it becomes harder to deal
| with the situation; with distinct keys, you can just revoke
| access to the stolen key. But with cloned keys, revoking access
| to the stolen key will also revoke the key you use daily.
|
| I just wanted to bring this aspect up, because people
| unfamiliar with these devices need to understand the
| consequences if they lose their key; it can be a huge pain in
| the ass to rectify that situation. This might be an
| understandably big turn-off to non-techies who are just looking
| to add a little extra security, but not a big maintenance
| burden and difficult failure modes.
| smichel17 wrote:
| > But many sites only allow a single device to be enrolled.
|
| Ugh, I hate these. I want to use u2f, but I am not willing to
| risk being locked out of my account if I lose the key. So I
| only enable it if there is some other 2fa I can enable
| (either adding a second key or totp).
| fullstop wrote:
| Google won't let you enable "enhanced security" unless you
| have more than one u2f key.
| tialaramex wrote:
| _Most_ sites which offer U2F (or WebAuthn, which is what
| they ought to be doing for new sites) have a last ditch
| "Write down this huge random string" way back in. If you're
| the sort of person who'd hate to lose an account (seems
| like you are) then you should _definitely_ write that down,
| and keep it somewhere damn safe.
|
| But, as I wrote elsewhere in this thread, the _only_ site I
| 'm aware of that forbids multiple Authenticators (Security
| Keys) is AWS. And to be fair, AWS accounts are multi-user.
| If Bob loses his Security Key and Bob was your only admin,
| the biggest mistake wasn't AWS forbidding Bob from having
| two keys (though I agree that's bad) it's you not assigning
| another admin. Jim, the company secretary, may not know a
| t2.nano from m4.xlarge but he can keep a Security Key in
| his desk drawer and never give it to anybody unless the Big
| Boss authorises it.
| Xylakant wrote:
| There's one special account though and that's the AWS
| root account. It's needed for certain special things and
| tying it to a yubikey means that you cannot easily give
| those a creds to 2 people.
| baby wrote:
| Some websites also allow you to disable or rotate your 2FA
| creds if you're already logged in, without having to re-
| authenticate with your second authenticator.
| jabbany wrote:
| This seems a little dangerous since now the logged in state
| (likely cookies but maybe also hashed with identifiers like
| IP etc.) becomes considerably more valuable to steal.
|
| I actually see the opposite done, where any changes to
| login related things (passwords, 2fa keys) mandate a 2fa
| re-auth.
| baby wrote:
| Heh, stealing a logged state is bad no matter what unless
| you're requiring re-auth on important operations. The
| risk of one losing their second factor is much much
| higher.
| stouset wrote:
| > Some (like Yubico) let you purchase a "cloned" set of
| devices
|
| Wait, they do? How?
|
| I would love to do this, but I can't find anything relevant
| on their website.
| kelnos wrote:
| After going through their "what do I need?" quiz, it
| _seemed_ to indicate that was an option. It 's possible
| that I misunderstood, and they just give you two
| independent keys.
| tialaramex wrote:
| I think that quiz would like you to buy two of their
| products, which is a thing you might want to do (I'd
| suggest maybe one of theirs and one from a rival, but
| they're not going to suggest that) but it is not implying
| those keys are identical inside, they are as you say
| "independent keys".
|
| So you'd register _both_ keys. Or if you own more, you 'd
| register at least two of them and at least one stays
| somewhere safe (but like, not in a bank safety deposit
| box, maybe the sort of place you keep a passport). This
| way, when inevitably your toddler throws mummy's key ring
| into a fast moving river, it's just very inconvenient and
| doesn't ruin your whole year. After you call somebody to
| bring a spare car key, and ask the toddler to think about
| what they did, go revoke all those now useless keys and
| order a new FIDO authenticator.
|
| Edited to add: Even if they _started_ identical you can
| reset any Yubikey, making the keys inside it random - and
| very paranoid people might want to before using it, since
| you don 't know what happened to the keys inside it
| before you got it.
| dandanua wrote:
| The existence of a cloned physical key is not possible
| due to FIDO U2F protocol. Every sign operation increases
| a counter on the device. It's supposed that services will
| keep track of this counter and don't accept signatures
| with an incorrect counter (less than known).
| _trampeltier wrote:
| The same for me. I bought 2 keys and the idea was to have
| one as a backup key. But I did not find a way to do it.
| Anyway, even after read about how it works on some websites
| and watched some videos, the whole things is still a bit of
| a black box for me. I have no idea how a non-techie at
| moment a such device can use safe.
| sammorrowdrums wrote:
| I just bought two keys and most services let me enroll
| two devices or can use Yubico Authenticator, so I scan
| the OTP barcode twice, and tap each key one time on
| phone.
|
| Then I'm going to sit with my wife and do that for some
| of her accounts and she will hold my backup.
|
| _edit_ for clarification, you really do need to have two
| devices with you to safely enough register 2fa, but
| obiously it is not safe to keep them both with you after
| initial setup, in case you lose them both. For the most
| part you just switch it on for everything with dual keys
| somehow (even if one registered key plus one Yubi
| Authenticator OTP).
|
| For services that only actually enable one key, if they
| have emergency backup codes keep them in password
| manager, physical safe or a somewhere in your home
| depending on your threat level and the risks of the
| particular service being compromised.
| mkj wrote:
| I assume the solokey generates its master key on-device.
| Seems like it wouldn't be too hard for it to perform Diffie
| Hellman key exchange with another device to get a shared
| secret (at first setup) then they could be a cloned pair.
| g_p wrote:
| The issue with this would be counter synchronisation, as
| services shouldn't accept cloned responses when the
| counter ceases to be monotonic for what should be one
| single device.
| vlovich123 wrote:
| > On the flip side, if someone steals your backup key, it
| becomes harder to deal with the situation; with distinct
| keys, you can just revoke access to the stolen key. But with
| cloned keys, revoking access to the stolen key will also
| revoke the key you use daily.
|
| Get a new key, revoke old key, switch to new one?
| kelnos wrote:
| Right, but the "get new key" bit means that your accounts
| are in a vulnerable state while you're getting the new key.
|
| If you have two independent keys, and you learn that your
| backup key is compromised, you _immediately_ revoke it with
| all services, and order a new one. When the new one
| arrives, it becomes your new backup, and you enroll that in
| everything. Your vulnerability to an attacker ends
| immediately after you find that your backup key has been
| stolen and you revoke it.
|
| If you have two identical keys, and you learn your backup
| key is compromised, you order a new one (or pair, rather),
| but you can't revoke the old key until the new one arrives,
| when and you can (simultaneously) revoke the old and enroll
| the new.
| FeepingCreature wrote:
| Of course, the problem here is that the attacker can also
| revoke your backup key, and since they're the attacker,
| they can probably do it faster than you.
|
| Preferably I'd have a certificate chain scheme where I
| have a private revocation key sitting in a safe somewhere
| whose public key I specify everywhere, so I don't even
| need to take it out of the safe to sign up somewhere.
| dheera wrote:
| The way this _should_ be solved is for everyone to enable
| multiple U2F keys in every site and de-register any device or
| key that is stolen.
|
| Unfortunately many sites suck at this. AWS, Twilio, PayPal
| all suck.
| ahnick wrote:
| Some devices derive their keys from a recovery seed that you
| can store offline in paper form. The benefit of this approach
| is that you can recreate the key on a backup device using the
| recovery seed, should you lose your primary.
| kelnos wrote:
| Ah, neat, so basically the recovery seed would let you buy
| a new device and then use it to "clone" your old one?
|
| Definitely useful in case you lose it or it gets stolen,
| but you'd end up wanting to rotate to a new key with fresh
| seeds anyway, since the old key could be in the hands of an
| attacker. I guess this is still useful in the case where
| you don't lose the old key, but instead damage or destroy
| it by accident.
| ahnick wrote:
| Yes, exactly. If you lose it or it's stolen, then you'd
| want to rotate to a new key quickly. Some of these
| devices have a pin too, so the attacker needs to crack
| the pin before they can actually use the device. This
| should hopefully buy you enough time to bring up a new
| device and switch over accounts. That's why it's probably
| a good idea to buy your second device when you buy your
| first one and store it in a separate, reasonably secure,
| but more importantly, quickly accessible, location.
| tialaramex wrote:
| > Some sites will allow you to simultaneously enroll two
| devices, so you can keep one as a backup
|
| For WebAuthn (the actual standard for how to do this which is
| what you should be rolling out if you have a greenfield
| authentication environment that doesn't already do U2F today)
| the specification explicitly says:
|
| > Relying Parties SHOULD allow and encourage users to
| register multiple credentials to the same account. Relying
| Parties SHOULD make use of the excludeCredentials and user.id
| options to ensure that these different credentials are bound
| to different authenticators.
|
| https://w3c.github.io/webauthn/#sctn-credential-loss-key-
| mob...
|
| I'm aware of (and along with many of its other users annoyed
| that) AWS only permits a single authenticator. If there are
| other popular sites that do this, this is no worse a place
| than any other to say so.
|
| FWIW I have two (or more) FIDO authenticators with Google,
| GitHub, GitLab, Facebook, Dropbox, Login.gov and Digidentity
| (the Gov.UK verify provider)
| kelnos wrote:
| That's good to hear! I was under the impression that it was
| much more common for sites to not support a second device.
| Glad to know most do.
| brewdad wrote:
| In my experience every site I set up a physical device
| with offered either multiple device support or a
| secondary method like TOTP as a backup. Not as secure,
| but much more user friendly, recognizing that we are all
| only human.
| Corrado wrote:
| > I'm aware of (and along with many of its other users
| annoyed that) AWS only permits a single authenticator. If
| there are other popular sites that do this, this is no
| worse a place than any other to say so.
|
| Just to clarify, AWS only allows a single authenticator for
| their IAM users. If you are using AWS SSO then you can have
| multiple authenticators. And yes, I am very annoyed and
| frustrating to think that IAM is forced into a lower
| security profile that it needs to be.
| godelski wrote:
| This has been a thing preventing me from getting one. A key
| that's supposed to be on you (or locked in a vault) is
| prone to getting destroyed or damaged.
|
| So since my threat model isn't high and this would be more
| a nerd thing, it doesn't seem worth it. 2FA is good enough
| I guess
| chrisdhal wrote:
| I've had a Yubikey for about 3 years that is on my car
| keys keychain which goes with me everywhere. It's been
| all over the US and into Costa Rica all in my pocket or
| haphazardly thrown into my backpack (with a bunch of
| other random things).
|
| There is zero evidence of any wear or anything. They are
| meant to be carried around, you don't need to baby them.
| I'm more worried about it being lost than damaged.
| ozim wrote:
| My friend was like "why would I pay for this when Android
| phone can act as one as well".
|
| I am more concerned with losing my phone or that my phone
| will die that something happening to my ybk.
| lucideer wrote:
| Fwiw, I have 3 of these and I have yet to encounter a
| service that doesn't support all three, so it hasn't been
| a issue.
|
| People have mentioned AWS IAMS only supports one at a
| time, but that's definitely "a nerd thing".
|
| The only "normal" user-facing service I've tried with
| some unnecessary restrictions is actually Twitch (also an
| Amazon property), so it sounds like Amazon are just
| specifically bad at this, rather than most companies
| having bad implementations.
|
| But in general, it's been fine for the vast majority of
| services.
| andrewwebber wrote:
| Looking at you AWS cloud.
| Corrado wrote:
| Just to be clear, AWS SSO supports multiple keys. Yes, AWS
| IAM only supports a single key and it's very frustrating.
| If you want multiple key support, I suggest moving to AWS
| SSO. It's much better in every way.
| xenophonf wrote:
| That doesn't help if you're trying to protect the AWS
| root account.
| jabbany wrote:
| Yeah, this is a very good point.
|
| I deal with this by always adding a second "cold" key when
| services allow multiple keys, and keeping this cold key
| somewhere secure as a backup spare. So if I do, say, lose my
| primary key, I can at least pull out the spare key to reset
| and de-associate the primary.
| roblabla wrote:
| I use a yubikey, but I suppose the Solo will be similar.
|
| > - Are drivers for this already installed as part of desktop
| Ubuntu 20.10/Windows 10? Any driver installation will
| absolutely make this a no-go for family members.
|
| On windows10, yes. I haven't tried it on Ubuntu 20.10 yet, but
| I think FIDO/WebAuthN will Just Work. (PIV will likely need
| custom software, but if you're using PIV, you probably know
| what you're doing).
|
| > - Is additional software required for anything non-techies
| might reasonably want to do with this device, including
| resetting it
|
| I mean, you rarely want to reset your key to start with, but at
| least for the yubikey, this requires external software last I
| checked. Maybe there's a button hidden in the chrome browser
| UI, but I've never found it. You need yubikey manager (which is
| yubikey's tool for doing various operations on the yubikey,
| like configuring what the touch button does, etc...).
|
| > adding an entry
|
| This is done entirely through your browser when setting up 2FA
| for a website that supports FIDO/WebAuthN. This is done
| entirely transparently for the user.
|
| > or checking which entries are already on the device?
|
| I don't think you even _can_ do this. I 'm not entirely sure
| how FIDO works, but I think the key is basically derived from
| some kind of "master" key combined with the domain you're
| connecting to. So the key doesn't actually have any memory of
| which servers it ever connected to.
|
| > - Is there anything else which would likely stop non-techies
| from using this for basically everything they care about?
|
| Well, technically, I don't think there's anything. WebAuthN is
| rock solid and the UX is really as good as it gets, IMO. The
| problem is, for many people 2FA is a hassle they don't want to
| go through. They don't see the need for it. And TBF, for many
| people, they might be right: they might not need it. So why go
| through the hassle?
| g_p wrote:
| > I don't think you even can do this. I'm not entirely sure
| how FIDO works, but I think the key is basically derived from
| some kind of "master" key combined with the domain you're
| connecting to. So the key doesn't actually have any memory of
| which servers it ever connected to.
|
| Indeed, this is one of the most elegant features of U2F - it
| preserves security and privacy even in relatively adversarial
| edge cases.
|
| Your token has a hardware-backed long term key in it (well,
| one for encryption and one for authentication). When you
| enrol on a website, the token generates a new asymmetric
| keypair internally, then encrypts and authenticates it with
| the long lived keys. The registration bundle sent to the
| server is called a "key handle", but is typically just the a
| hardware wrapped key.
|
| When you visit a site and log in, on the 2fa prompt, the site
| sends the encrypted wrapped key back to the browser, and it
| tries verifies it's a valid key, then decrypts it, and does a
| challenge-response authentication that's tied to the HTTP
| origin (domain and port) of the request.
|
| What's quite nice is that (outside of a few corner cases like
| looking at counter values and trying to correlate), you can
| safely use one u2f key with multiple accounts on multiple
| services, and none can be linked by the u2f key. (Of course
| they can be linked through other means, but the token won't
| be that link)
| damnyou wrote:
| The moment you lose your key, WebAuthN becomes terrible and
| the UX is atrocious. You may literally have to go to an
| office (in the middle of a pandemic!) to restore access to
| your account.
|
| This is bananas. We absolutely should not be recommending
| them to normal people until security researchers come to
| their senses and fix this problem.
| baq wrote:
| Nonono. We absolutely should recommend having at least 2.
| See also: car keys, house keys, any other physical lock you
| can get comes with at least 2 keys.
|
| The default product sold should be a two key bundle.
| damnyou wrote:
| With your house keys you can walk into any hardware store
| and get as many duplicates as you like. With a U2F key
| that is prohibited.
|
| U2F desperately needs a layer of indirection that doesn't
| currently exist.
| riedel wrote:
| A comment towards Windows10. You actually only would need HID
| support, but Windows takes over control over fido2 to hide it
| behind the Windows Hello webauthn API for non elevated users.
| This makes crossplatform implementations terrible. I own a solo
| somu and it has much less value due to this on Windows. It
| really discouraged me to put any more work into fido2
| implementations. I started a keepassxc integration, which
| actually worked well based on the HMAC extension. If anyone
| from Microsoft reads this: please allow hackers to set a
| security policy to allow non elevated fido access! Otherwise
| the devices are great!
| barkingcat wrote:
| The general idea is _not_ to backup these devices.
|
| To make a backup, you get 2 different keys and set them both
| up. The second one you keep somewhere safe, for example in a
| safety deposit box at a bank.
| vladvasiliu wrote:
| As others have said, the key not being easy to clone is a
| feature.
|
| While I understand why this is and which threat models this
| addresses, I still think that this shouldn't be an all or
| nothing proposition.
|
| In the general case, meaning not for people with access to
| "secure systems" (corporate) or who are high-profile enough to
| have reason to believe that they themselves may be a target, I
| think that having "less secure" keys which can be cloned by
| "non-techies" might still be an improvement to the overall
| security of the internet.
|
| I didn't do any research, but according to the linked
| Kickstarter page:
|
| _Solo V2 greatly reduces the risk of security breaches, as
| over 80% of all breaches are caused by passwords compromised
| through phishing email attacks._
|
| So physically stealing credentials isn't as widespread a risk
| as phishing, which doesn't really surprise me. Therefore I
| think Webauthn with "cloneable" keys would be a net positive
| for "regular people".
|
| This wouldn't preclude "techies" from using more secure,
| unclonable keys like the Yubikey & friends. But my grandma
| could also use a "less secure" one without the risk of having
| to go through resetting 100 different sites and would be able
| to setup a new key just by having me walk her through the
| process of restoring a key from a backup. I'm a "techie" and
| even I would like such a key for use on random "must absolutely
| register" websites.
|
| Of course there's the issue that if the key is lost you can't
| easily revoke it. But even with the proposed system of having a
| backup key registered or going through the recover account
| process, as long as you don't actively go unregister the lost
| key it's still registered and working. So if the authentication
| is based on some sort of counter, the process of effectively
| disabling the lost token shouldn't be any harder in this
| configuration.
| EvangelicalPig wrote:
| Some Linux distributions require adding udev rules for
| applications to have USB device access but other then that,
| it's pretty much plug and play.
|
| A bit more convenient than having to use the YubiKey apps for
| TOTP and such.
| amluto wrote:
| My now-defunct u2f-hidraw-policy package did this in a
| generic manner. The code was subsequently ported into the
| upstream udev code, so any up to date distro should
| automatically detect and handle U2F devices. If they don't,
| file an issue with upstream systemd and it'll get fixed. Feel
| free to file an issue on u2f-hidraw-policy too if you want my
| attention.
| EvangelicalPig wrote:
| Was not aware. Thank you!
| meirelles wrote:
| Trezor is great as an U2F device because it uses the same
| crypto seed to initialize all internal keys, including the U2F
| feature. So you only have to backup the seed phrase offline
| (paper is one of the safest medium when correctly secured, or
| you can buy a cryptosteel plates to really long-term storage).
|
| Crypto fan or not, those devices are amazingly secure, and
| certainly hold billions out there. I think it is open source
| too.
| l0b0 wrote:
| Thank you all so much for the answers! Sorry for my ignorance
| (or laziness, since I haven't read up on this and don't know of
| a disinterested guide for techies) about backups; not allowing
| it is a completely understandable trade-off between security
| and convenience.
|
| It sounds like this is a perfect solution for people at high
| risk of phishing, a good solution for somewhat technical
| laypeople with something important to protect which supports
| this (like a bank account), and too much hassle/risk of losing
| access/lack of support for most people/use cases. Does that
| sound fair?
| tialaramex wrote:
| I guess. However, I'd add that it's also definitely a
| sensible thing to _require_ of people, however non-technical,
| where you 've got some out-of-band way to issue and re-issue
| these authenticators to those people.
|
| Suppose you're Twitter. If every Twitter employee has a FIDO2
| device and they need to tap it to begin their work day, and
| to confirm any important actions like "Block YetAnotherNazi"
| or "Validate that this Twitter account really does represent
| Jim's 24 hour Celery and Dog Collar Deliveries" then
| instantly a bunch of your security problems disappear, and
| all you need are your existing procedures that stop random
| people walking into your offices off the street and
| pretending to be employees, which, I'm going to guess, is
| already a problem you've got at Twitter.
|
| I can't see any reason a university wouldn't do this for its
| students for example. Or a hospital for its medical staff. Or
| a police force for... all the cops. These are very easy to
| use, with that one sharp edge of "What if I lose it?" which
| is _not a problem_ if your organisation already has
| procedures to ensure only the right people get physical ID.
| sammorrowdrums wrote:
| No drivers were needed for my Ubuntu setup or phone, but to
| have desktop Yubi authenticator app and turn on Linux hardware
| auth for sudo, login, TTY, I did add a ppa. There instructions
| for that were good though.
|
| And when setting up any 2fa, need to have two keys and enroll
| them both, to give a chance of account recovery.
|
| _edit_ I purchased one for my wife and only properly
| understood when it arrived that it would need to be first used
| for all my 2fa, and then when helping her get setup I would
| need to have mine handy as her backup too.
| brabel wrote:
| From the founder of Solo, I assume:
|
| "I've been working on Solo for almost 3 years now. It started
| back when I was in college and on a whim, ordered a run of 1000
| security keys that I designed and then shipped them all to
| Amazon. "
|
| Hm... not sure I can trust my keys to something developed on a
| whim by a college student.
| an_ko wrote:
| Linux was designed on a whim by a college student.
| petee wrote:
| But would you have trusted your secrets on a 3yr old linux?
| leipert wrote:
| That's why it is open source. Both hardware and software. You
| should be able to trust it more than some closed source version
| because you (or someone else) could verify the security more
| easily.
| baq wrote:
| I have multiple solo v1s from the first Kickstarter. Still work
| like a charm. Haven't used the nfc version.
| Foxboron wrote:
| I'm _still_ curious how the key is tamper resistent when filling
| it with transparent epoxy. I asked when the article was published
| on lobste.rs but never got an answer. It seems to me it should be
| fairly easy to remove the epoxy and refill after tampering.
|
| I should probably email them about this at this point, but I
| think it's weird they haven't explained the "tampering resistent"
| part in their marketing material in any detail.
| zie wrote:
| AIUI, Tamper Resistant doesn't mean it's not possible to do,
| but that it will likely be obvious that tampering was done.
| Foxboron wrote:
| Then it would be tamper evident, not resistent?
| smnrchrds wrote:
| Water resistant means some resistance to water. Water proof
| means full resistance to water. And that is a standard term
| that has been in use for decades to describe watches,
| tents, jackets, etc. When I read tamper resistant, I
| imagine the tamper equivalent of water resistant.
| AmericanChopper wrote:
| Tamper evident is the correct description of what the
| parent comment is talking about. You can Google "tamper
| evident stickers" to see it's how the phrase is widely
| used. I would say the epoxy in question is both tamper
| resistant and evident though. Because it's both difficult
| to remove and you'd risk breaking the device if you tried
| it, and those seem like obvious tamper resistance controls
| to me.
| zie wrote:
| Yes, 2 birds, 1 stone.
| [deleted]
| conorpp wrote:
| The epoxy can't be physically removed without great risk of
| ripping off the electronics on the underlying circuit.
|
| The epoxy can be chemically dissolved, but would deteriorate
| the outside of the device as well. It the epoxy isn't
| completely cleaned out, then refilling it with new epoxy would
| look messy. With great care and skill, it could be done with
| little damage, but would be time consuming.
| g_p wrote:
| It's a good question, and I believe they mean in terms of the
| epoxy making it harder to get easy access to the chip to do any
| shenanigans.
|
| It's worth remembering the threat model for U2F tokens (let's
| set aside PIV, FIDO2, etc for the moment) - if the attacker has
| physical possession then they're into your account. Game over.
| As the authentication is to tap the button.
|
| Sure you can add PIN via FIDO2 (then these protections make
| more sense), but I can't see any particular threat whereby you
| would be concerned about this threat under normal
| circumstances.
|
| U2F helps normal (and expert) users resist phishing attacks,
| credential relaying, and avoid keyloggers etc. It doesn't
| protect you against in-person physical adversaries who can
| steal your things, or take them against your will.
|
| The only edge case I can see where this matters more is if a
| user leaves the token unattended (try not to! Put it on your
| keyring, though admittedly your backup token probably is at
| risk a little here) and an attacker can covertly extract the
| keys and leave it as found, such that the user is unaware. But
| at that point you are dealing with adversaries in the real
| world, and most users have already lost at that point
| (passwords written down, etc.)
| ohazi wrote:
| FWIW, their choice of microcontroller (LPC55s, which is a
| Cortex-M33 w/ crypto peripherals and TrustZone) doesn't seem
| _completely_ terrible.
|
| There's still a lot of things that need to go right for the
| whole system to be secure, but "everything happens inside one
| chip, and we cover it in epoxy" seems pretty reasonable. If you
| can get rid of the epoxy, the only tampering I'd be worried
| about is removing capacitors for power supply glitching. Power
| analysis can still be done on an uncompromised device via the
| USB port (capacitors will make this harder, but may not rule it
| out).
|
| To go beyond this, you'd probably need to decap the chip. I
| haven't seen anything about an active die shield in the
| documentation for this chip, but we're now well beyond the
| scope of epoxy tamper resistance.
|
| Edit: No die shield, but apparently "cryptographically
| sensitive" signals and bits have additional out-of-band signals
| and bits to make shenanigans more difficult. Certainly not
| perfect, but "not completely terrible" seems like a fair
| assessment.
| IgorPartola wrote:
| What would be your choice of microcontroller?
| ohazi wrote:
| I don't actually think it's a bad choice... but that may
| say more about the state of what's available than about
| this particular chip.
|
| The Cortex-M version of TrustZone is still fairly new, and
| these M33 devices are some of the first that implement it.
| You need a lot of care to use it correctly, but it has the
| potential to reduce the attack surface significantly.
| Crypto operations and key memory can live in the trusted
| world, while things like the USB stack can live in the non-
| trusted world.
|
| If you really wanted a die shield, Maxim makes a line of
| "DeepCover" secure microcontrollers (Cortex-M3/M4, no
| TrustZone) that might fit the bill. They also have tamper
| pins for driving an external shield (e.g.
| https://www.edn.com/wp-
| content/uploads/media-1203638-p118fig...). You could do
| something like that and then fill the void with epoxy.
| External shields can be somewhat useful if your device
| stores keys in battery backed RAM (e.g. ATMs, POS
| terminals), because the shield remains active even when the
| device is off (if the shield is ever de-energized, the keys
| are wiped). USB security tokens typically store keys in
| (encrypted) flash, and don't have a battery, so you can
| take all the time you want grinding off the shield while
| the token is off, and then just short the right pins
| together before you power it up again.
|
| ARM has a Cortex-M35P design that has TrustZone as well as
| some more advanced physical security features, but as far
| as I'm aware, nobody is selling one yet.
|
| Downsides across the board:
|
| Both ARM and silicon manufacturers are cagey about
| releasing any information about their security products.
| Most require NDAs before they'll even tell you what's in
| these chips, let alone how to use them, or how they work.
| I've worked with a few, and most of them have had some
| pretty scary bugs. They're worried that if they released
| the chip errata publicly, nobody would buy their chips.
| That's probably fair, but it also leaves you
| (understandably) less than confident that anyone has ever
| implemented a hardware crypto accelerator correctly.
|
| Trusted execution contexts and memory protection seems like
| a good idea in theory, but I'm worried about all the
| complexity we're adding to these little chips. To lock the
| thing down, you have to pour over a thousand page datasheet
| and disable all of the debug interfaces you find, and
| enable all of the protection features that you find. If
| you're being thorough, you might write some little test
| programs to confirm that you at least can't use the easy
| methods to access things that should be protected. But at
| the end of the day you're crossing your fingers and hoping
| that there isn't a giant gaping hole off to the side that
| you forgot about. Reference software for these platforms is
| often crap.
|
| -\\_(tsu)_/-
|
| I do have high hopes for this chip though... Apparently
| Oxide is also using it and has been sharing notes with
| SoloKeys
| (https://twitter.com/kc8apf/status/1360415931940302850). I
| think they'll get there eventually, but I think it'll be a
| while before we can be confident that it works correctly
| and that nothing obvious was missed.
| IgorPartola wrote:
| Thank you for the info!
| notatoad wrote:
| have you ever tried to remove epoxy from a PCB? it's definitely
| possible, but it's annoying and makes a mess. i'm not sure how
| you'd remove epoxy without it being blindingly obvious that the
| epoxy had been removed and replaced.
|
| they're claiming tamper-resistant, not tamper-proof. and
| counting on the epoxy for that seems reasonable to me.
___________________________________________________________________
(page generated 2021-02-13 23:02 UTC)