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.
I've considered adding FIDO2 support to the software-only U2F token I wrote in Rust. It's a fair bit of work though, and I am not sure how comfortable I am with passwordless login unless the keys are kept purely in hardware such as a TPM.
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.
> I am not sure how comfortable I am with passwordless login unless the keys are kept purely in hardware such as a TPM.
Shouldn't this be something for the user to decide? Using a TPM as a key is a bit silly; it amounts to turning the computer as a whole (strictly speaking, its motherboard and/or CPU) into a big smartcard/FIDO key. If that physical device breaks down, the associated identity is toast. A purely software-based key you can always back up.
Yes that's fair, it's a trade-off. Thinking more, there are really three levels of protection I see.
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.
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.
> relaying auth requests to your phone for approval and storing secrets in the Secure Enclave
Like the acquired/abandoned https://github.com/kryptco/kr [key stored in a [...] mobile app] with iOS and Android apps all under an "All Rights Reserved"-source license?
Also, newer Macs have a Secure Enclave (supports 256-bit secp256r1 ECC keys):
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.
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.
Thanks for the suggestion. It hasn't been a focus yet because it doesn't bring much security for me personally, but it is something I would like to do eventually.
Neat! Is there a reason why it says at the top it only supports Google Chrome? I haven't looked into it too deeply, but a cursory glance seems to suggest there's no Chrome-specific extension, so I assume you're just hooking into the normal pkcs-related frameworks on Linux?
I would love to have a hardware-backed soft U2F daemon for Linux. It would be great if this could use a TPM to encrypt the data. What would it take to add such capability to your software? I would be happy to lend my (limited) Rust experience to help make it happen.
I would too. Go ahead and open an issue and we can chat more, but in short I think the biggest hurdle is understanding TPM2 and what API to use to interact with the device. (TPM2 is necessary so the key material never leaves the TPM, signing happens in the device itself)
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.