Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Saturday, 14-Jan-2023 01:53:52 JST silverpill

   https://www.jumpstartmag.com/how-tech-giants-are-preparing-for-a-password-free-future/

   >Given the dangers of password theft, Google, Microsoft and Apple announced in May this year their plans to support a common passwordless sign-in standard created by the Fast IDentity Online (FIDO) Alliance and the World Wide Web Consortium.

   At first glance this looks like a great initiative. Key based identity etc etc. But the actual software being developed requires either spying device (aka smart phone) or worse, biometrics.

   Meanwhile, development of browser wallets continues to stagnate.

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 11:42:47 JST arcanicanis

     in reply to
     > But the actual software being developed requires either spying device (aka smart phone) or worse, biometrics.
     
     No. Not even remotely true.
     In the simplest implementation (from what I remember, just in brief summary) of a U2F hardware token there are two storage components:
     - Master key (or rather 'initial key', which is only generated once)
     - Global signature counter
     
     For 'registering' a U2F token for an account on an online service, the token is presented an RP ID (generally the protocol and domain part of the service authenticated to), and from that RP ID it derives a new private/public keypair (in-memory) from the stored master key, using a key derivation function, and presents the generated public key to the service. All these cryptographic operations happen internally on the token.
     
     Then when authenticating to the same service, the RP ID is presented again along with a challenge to the token, the same private/public keypair is generated in-memory again, and creates a signature of the RP-provided challenge as well as the current 'signature counter' state, and returns the resulting signature (as well as the current 'signature count' it was signed with) to the service, while also internally incrementing the signature count by 1 in it's internal storage.
     
     The service verifies if the signature matches up with the public key on record, and also makes sure that the 'signature count' is greater than the last time authenticated to the service. Otherwise if the signature count is the same as last time, or less than, then it would indicate a replay attack, and would be considered invalid.
     
     In this scheme, there is a different public/private keypair for every service, yet within storage, it only has to remember one key, and has to keep a signature count.
     
     Meanwhile, in further evolution into FIDO2, there's the addition of device attestation, whereas there's a separate private key and certificate burned into a batch of 100,000 tokens/devices of the exact same model, that is ONLY for a service to be able to verify the model and profile/capability of the token, as attested by it's manufacturer.
     
     Each hardware vendor has their own root certificate that certifies the hardware attestation certificate burned into the token or cryptographic component. Hardware attestation is only relevant to appeal to government and financial sectors that require hardware certification, or to have authenticators from specific vendors or profiles. Hardware attestation is just an additional option presented that's not required for implementation in online services, it's just meant for organizations that want tighter control, for example: the US DoD could prohibit a DoD system from allowing some government contractor from registering a Hauwei-brand authenticator for their account. That's the intended use-case it's targeting with that addition. The attestation information is only presented upon registering an authenticator to an account for a service--and not used for any subsequent authentications.
     
     As for biometrics and other components, that's all just internal to the implementation of the authentication token, of whether it wants to sign a challenge or not, and just being an advertised feature presented in the hardware attestation certificate, whereas it NEVER sends biometric information in any response.
     https://fidoalliance.org/fido-technotes-the-truth-about-attestation/
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 11:53:57 JST arcanicanis

     in reply to

     • arcanicanis
     and further on the communication and advocacy of FIDO2 is the absurdity where Microsoft tries to garner attention upon themselves for being a "pioneer" of the effort to "kill the password!". Where they keep using the term "passwordless authentication" which understandably should raise ire from any sysadmin, whereas apparently folks from Microsoft think they're playing some bigbrain 4D chess by using such wording, to get people to look into FIDO2, in clickbait-style tactics, when instead I believe it's scaring people away.
     
     U2F/FIDO2 is a fairly interestingly minimalist and robust concept, versus the mess of PKCS standards with smartcard authentication and management, it's just that Microsoft (and some others) are really botching the messaging about it.
     
     You can use FIDO2 authenticators for two-factor authentication, and you can certainly implement it as such in any of your applications/services. The problem is that some online services, such as crap like Azure, take an over-opinionated approach where your option is ONLY single-factor hardware authentication, which I was bitching about previously here: https://were.social/@arcanicanis/posts/AKQyHBW6ajXA0F468e
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 12:32:24 JST arcanicanis

     in reply to

     • Coyote
     and if the hardware attestation keys are dumped, congrats: the totality of damage you can do is just claim a new authenticator registration originated from a specific model of hardware, that's it. There's no damage in it beyond that from what I'm aware, as it serves no other role.
     And if a key is dumped, then the service can just restrict any new authenticator device registrations of that batch/model, versus suddenly revoking all devices registered before the key was leaked (unless the time period of the leak is completely unknown to the span of years).
     
     But yes, whitelist-only is a possible issue, but is unlikely for consumer services.
   • Embed this notice
     Coyote (coyote@social.singing.dog)'s status on Saturday, 14-Jan-2023 12:32:25 JST Coyote

     in reply to

     • arcanicanis

     @arcanicanis @silverpill I’m getting a feeling that device attestation is going to be used incorrectly to whitelist specific hardware (force some hardware feature like bio-metrics) and someone’s going to get burned by a software implementation and dumped keys.

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 13:14:48 JST arcanicanis

     in reply to

     • Coyote
     For USB token auth, it's just an HID device that communicates using the CTAP protocol to serialize requests/responses, so there's not much capacity for it to talk to the outside world, unless you fabricate some RF-emitting component inside the token to transmit to some auxiliary wireless network to exfiltrate that information. It's just a very opinionated standard of public key authentication, anyone's free to implement hardware as they so choose.
     
     My interest in it is solely for hardware-backed authentication, versus private keys that are resident within your filesystem or RAM (such as when a private key is unwrapped). You can also use a token for SSH public key auth for cheap.
     
     Of course it still falls into a matter of trust of the hardware vendor, but that's also the same dilemma but on a much wider scale with most desktop computing hardware.
     
     Nonetheless, as stated: my interest is for USB token authentication, used as a second-factor of authentication. I'm questionable in some areas, such as using a smartphone as a single-factor authenticator (regardless of whether it has it's own isolated hardware cryptographic component). I only advocate for it within the former profile. There's also the standard itself which is openly documented and inspectable (especially in the device communication), and if it starts to get shoved in the wrong usage, then of course that's time to raise hell if any of the larger orgs steer adoption in the wrong direction.
   • Embed this notice
     Coyote (coyote@social.singing.dog)'s status on Saturday, 14-Jan-2023 13:14:49 JST Coyote

     in reply to

     • arcanicanis

     @arcanicanis @silverpill There is the possibility of a MITM attack on the initial public key exchange appearing more “authentic,” but device attestation does seem pretty mundane in what it adds or loses in terms of security.

     The article you shared talks a whole lot about using it as a source of metadata, but the possibility of dumping keys points to it only really being useful to alert users that their hardware has insecurities: “hey, your authenticator’s know to phone the FBI whenever you login; you should probably get a new one.”

     I just can’t shake the feeling that Microsoft, Apple, Google, etc. will someday use it to force hardware onto people. “Sorry your token is too insecure for <service>. Please use a token with DNA authentication to continue.” Again, software solves it, as it did with TOTP, but it’s still annoying having to have password managers act as USB devices.

     arcanicanis likes this.
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 14:10:16 JST arcanicanis

     in reply to

     • Coyote
     It can all be implemented within the web application, there's no need for delegation to a "FIDO server". It's also not a direct communication between the server and the token, it's the browser or operating system that handles the CTAP communication to the token (such as filtering what 'RP ID' and other information is presented to the token, versus it just blindly passing through anything from the server), while the communication to the web application is a JSON-based format.
     
     Within the web application, you're just generating a challenge, verifying a cryptographic signature (ECDSA key, SHA-256 hash, if I remember correctly) against a public key stored with the account, and keeping track of the signature count.
   • Embed this notice
     Coyote (coyote@social.singing.dog)'s status on Saturday, 14-Jan-2023 14:10:17 JST Coyote

     in reply to

     • arcanicanis

     @arcanicanis @silverpill My example’s a humorous schizo exaggeration, but one could do it with a cellular modem or some passive antenna that only transmits when energized by a specific frequency, akin to the Great Seal bug.

     I’m somewhat interested in this stuff as means to proliferate public/private key authentication. I see the utility of bespoke hardware, but I’m not too interested in using it.

     I would’ve liked for the FIDO standard to have included a way for the authenticator to interrogate an RP server in someway. It’d be better to have the ability to use alternative sources of trust than to relay on a FIDO server existing in perpetuity.

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 14:14:34 JST arcanicanis

     in reply to

     • arcanicanis
     • Coyote
     Oh neat, I just found this project, which is very similar to another project idea I had on my list (whereas my previous project idea was to try making a 'ghetto' PKCS#11 token with a RPi Zero):
     https://github.com/mphi-rc/pi-zero-security-key
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Saturday, 14-Jan-2023 21:55:43 JST silverpill

     in reply to

     • arcanicanis

     @arcanicanis

     >derives a new private/public keypair (in-memory) from the stored master key, using a key derivation function, and presents the generated public key to the service

     This sounds reasonable. However,

     >U2F

     Is hardware token required? Even if the token doesn't leak some metadata or ID to the website, I still need to acquire it somehow. Meanwhile passwords and private keys are free.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Saturday, 14-Jan-2023 21:59:31 JST silverpill

     in reply to

     • arcanicanis
     • Coyote

     @Coyote @arcanicanis Yes, I think it's obvious that this technology will be used to promote biometrics and other creepy shit, otherwise Google/Apple/Microsoft wouldn't be shilling it so hard.

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Sunday, 15-Jan-2023 06:23:23 JST arcanicanis

     in reply to

     It kind of kills the whole point of the standard, as to not have keys that are just files on your computer, to instead have it on a separate device with it’s own storage and memory that typically prevent extraction. Same with people using TOTP applications on smartphones: any of that can be swiftly copied, as it’s just another file, and the only enforcement against that relies on the security of your entire operating system to prevent that sensitive keying information to not be read.

     Meanwhile dedicated hardware can be reduced down to the model described earlier, of something that simply takes an input of specific parameters, and signs it, with only a very narrow set of possible interactions.

     It doesn’t “require” hardware, you could do a software-based token, but that voids the whole point. You could also McGyver your own out of cheap hardware (as I have in another reply), as a balance between the two.

     But essentially isolating key storage and cryptographic operations to a separate isolated domain (separate CPU, RAM, storage) for certain applications (SSH public key auth, PGP, etc) is an improvement over doing the same on general-purpose complex networked multi-user desktop operating systems that are engineered to be used by the average normie (versus something isolated down to significant degrees of minimalism and esotericism, far more than just Qubes/Tails). Meanwhile in recent days there were Twitter-people circlejerking about how a Bitcoin developer had their wallet compromised and assets dumped, and people trying to parade the moment as a “See? If they can’t even secure their own wallet, then how is this ready for real-world use?” moment.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Monday, 16-Jan-2023 05:10:26 JST silverpill

     in reply to

     • arcanicanis

     @arcanicanis For me the most interesting part of the standard (as you described it) is where device generates app-specific key from a master key and presents it to a service. The lack of this feature is one of the major flaws in existing browser wallets. For example, in MetaMask you are supposed to use one account for everything, so all your activities across the web are linked (it's possible to use multiple accounts but it's very cumbersome).
     I'm not really interested in hardware tokens because I generally don't trust "trusted" hardware (it's a natural place to put a backdoor). Also, hardware tokens are bad from a physical security perspective: once hardware token is found, all your secrets can easily be extracted with rubber-hose cryptanalysis. It's much easier to hide a key file, you can even hide it in plain sight using steganography.

     >you could do a software-based token

     Have you seen anyone implementing that?

     >pi-zero-security-key

     I like this idea, but the project looks abandoned (no commits since 2020).

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Monday, 16-Jan-2023 09:06:21 JST arcanicanis

     in reply to
     You seem very stuck on the point about hardware: there's nothing that imposes that it requires dedicated hardware. The point of specialized hardware is to typically have storage that's engineered that you can't just crack open and do EEPROM dump to pull the keys out, or file down the coating of an IC to probe at any internal parts of the storage to do the same. Or have extra shielding to prevent voltage differences giving off spurious emissions that could infer details about the key.
     
     As for rubber-hose cryptoanalysis: someone could also engineer a dual-purpose security token that by default acts like an ordinary innocuous flash drive, and through some procedure (some button, a fake write-protect switch, or some 'port knock' like communication over USB to the device), have it switch over to presenting itself as an authentication token. Thus you could have something that looks and acts like any generic whitelabel consumer electronic and have plausible deniability and such when crossing some very invasive border searches.
     
     As a quick surface-level search on software implementations:
     https://github.com/danstiner/rust-u2f
     https://github.com/gsora/fidati (custom firmware)
     
     Also, as for some projects within the scope of the specification: there's only so much you can add/revise to a software project for something that's built/used for a very specific and narrow purpose (signing an input, and incrementing a counter), especially something meant to be minimalist, in contrast to something over-engineered like PKCS11 smartcards that can run Java applications.