Hardening user logins with 2FA is becoming must-feature of Web services; most of the services I use daily (such as GitLab instances) are already enabling it. Although it’s a bit cumbersome to enter secondary factor manually, using hardware tokens (such as FIDO2 authenticators) simplifies the process to a single tap, also making the entire authentication more secure based on public key cryptography.
On the client side, major browsers provide built-in support for hardware tokens (at least CTAP1), though sandboxed applications cannot benefit from this without allowing direct access to the host hardware. To improve the situation, we had several discussions in forums last year and somehow reached a rough consensus: we need a proxy for those authenticator devices.
Norbert Pócs in our team tackled this problem and has managed to create a D-Bus based proxy service that can bridge the device access to sandboxed applications. At DevConf.cz 2021, we presented our effort covering a proof-of-concept Firefox/Flatpak integration (special thanks to the people behind zbus, which made this pretty straightforward).
If you are interested in this topic, take a look at the recording of our presentation. Slides are also available. It’s still up in the air how to properly integrate this feature into browsers, but maybe the next step would be to finalize the protocol to allow different implementations.
The most interesting part for me is actually the TPM2 backend. I hope it will finally allow Linux to have a “platform authenticator” alongside Windows Hello.
Will that be sandbox-only, or were there any plans to emulate an actual /dev/hidraw device through CUSE (as done by soft-u2f)?
That TPM2 demo is a quick hack and we haven’t done thorough research on that use-case yet 🙂 We are, however, aware that one of the hardest part is device attestation. Somebody told me that there is an ongoing effort to map between TPM2 attestation and FIDO2 attestation, though I haven’t had chance to look into it.
Regarding the device emulation, I suppose it would be possible to convert back from D-Bus to HID through gadgetfs or such, but I’m not sure if there is a practical use-case of that setting.
Very interesting stuff, thanks for posting this. My trusty Yubikey not working is basically the only remaining issue I have with the Flathub build of Chromium so this work looks very promising to me. I added a note on https://github.com/flathub/org.chromium.Chromium/issues/20 about this post.
Thanks for doing that, this is great! As you’ve already started adding support in Rust for Firefox, could you also consider rewriting your daemon in Rust? You might be able to leverage code from https://belmoussaoui.com/article/13-oxidizing-portals.