The litephone is too basic and the HiSense A5 etc do not work on US networks.

I looked at building a 5.2" e-ink phone for the US market and did some fun mock-ups, but it would be a huge undertaking with my limited hardware background. Smaller phones just have fundamental limits due to battery size that are difficult to work around, and Android has basically no e-ink support as it's such a niche type of display for a phone.

1. Keep keys in a file/the keyring. This protects them somewhat from non-root users on the same machine. It also provides phishing protection, which is really the most important aspect of U2F/WebAuthn to most people. If your computer is compromised, all the keys are compromised.

2. Keep keys in the TPM. The only additional protection over #1 is if you recover your computer after it is compromised, you can be reasonably certain the attacker could not make a copy of the keys and thus can no longer use them to authenticate. Arguably this is not a particularly useful protection.

3. Keep keys in the TPM/secure enclave and unlock them via biometric. This does provide meaningful extra protection if every use requires an unlock. Then if your computer is compromised, the attacker will have to either defeat the biometric unlock, or trick you into unlocking for every authentication attempt.

#1 is what I do right now for rust-u2f, and I think you're right #2 is not really useful. So maybe it's worth just implementing FIDO2 without worrying about TPM support. What I really was talking about was doing #3 for Linux, but I don't see a way to meaningfully accomplish it without tight hardware integration.

P.S. It is recommend to register multiple FIDO keys and/or have backup codes for accounts as a way to mitigate the issue of one physical device breaking toasting an identity. Not all providers may support this, for silly reasons.

That said, my reading of this post is that FIDO2 support will get built into Chromium directly, which is itself open source. Or if you do want a hardware key but running open software, I'd definitely recommend https://solokeys.com/, I've been following them for a long time.

Also there was some related discussion on this same article last week: https://news.ycombinator.com/item?id=31274677

edit: I see someone already pointed you to my project earlier, feel free to poke around and I'm also open to contributions!

And yep Apple is way ahead on this imo, the touch sensor securely communicates with the Secure Enclave, I'm not aware of other laptop hardware doing that. (https://support.apple.com/en-bh/guide/security/sec067eb0c9e/...)

I'd love to have something equivalent for Linux, but given that requires hardware support I think relaying auth requests to your phone is the closest equivalent.

I wrote that U2F implementation in software because I wanted phishing protection without needing to carry a hardware key. Well, and to learn Rust :) It's certainly a security trade-off to just store secrets in your keychain like I choose to, it is not meant to be a replacement for a hardware key and in fact I have a Yubikey I use when the situation calls for it.

I'd love to use TPM and biometrics to implement U2F/WebAuthn on Linux and have a proper, secure solution. Similar to what Apple has done with Touch ID. But that's no easy task. TPM support is poor on Linux and other options like relaying auth requests to your phone for approval and storing secrets in the Secure Enclave is no easier.

I'm just emulating a USB device and using OpenSSL to do the signing, is there a better approach I should be looking at? (perhaps PKCS #11)

Issue: https://github.com/danstiner/rust-u2f/issues/19

Though it suffers from the caveat that secrets are just stored as a file in $HOME. I'd love to support more secure methods but haven't seen enough interest in the project to justify the dev time that would be required.