[psanford]

FIDO usb devices just use the HID protocol so they work fine on linux. Chrome and Firefox both support them.

I wrote a FIDO implementation that protects the signing key using the system's TPM specifically for linux: https://github.com/psanford/tpm-fido

There is no reason why you couldn't implement a similar syncing strategy in a tool like this if you wanted to.

[tialaramex]

> just use the HID protocol

This is literally true, and covers what was important in context, but warrants a little extra explanation. Since these devices are specifically for humans to interface with (they typically have a button or contact sensor, though some have keypads or a fingerprint reader) they are logically Human Interface Device class USB devices, but they do not speak the HID Keyboard or Pointing Device sub-protocols like your mouse or keyboard (or the built-in "take a photo" button on your web cam). Instead they provide a FIDO-specific HID sub-protocol, which is publicly documented, instead of operations like "Caps Lock pressed" it's got stuff like "Begin enrolment" or "PIN xxxx entered by the user" which only makes sense for this specific problem.

[_ea1k]

Oh, thanks for the explanation. I guess this new protocol is why I don't see as many tokens randomly appearing in chat sessions these days.

[ptman]

some yubikey modes of operation do emulate keyboards and paste a string of characters in text fields or terminals

[tialaramex]

They do, and an earlier version of my post mentioned that but I edited it down.

However, FIDO mode does not speak the keyboard sub-protocol. This means on the one hand it's not useable out of the box with some random device that allows USB keyboard input like the custom Yubico OTP mode is, but on the other hand it's able to deliver a good UX while having excellent security properties that would not be practical using keyboard emulation.

[tkanarsky]

Oh dang, thanks for writing tpm-fido! It works really well for my use case -- avoiding mandatory and incredibly annoying Duo Mobile 2fa on my school's website -- although I tore the presence verification out of the code for my purposes :)

iirc, this relies on the uhid module to mock a physical fido2 key, and I'm not sure if there's a way to present a mock fido2 key OS-wide without relying on a virtual USB device. This was a bit of an issue when I tried setting up a similar fido2 emulator in a container, as the Google container OS doesn't allow loading kernel modules. Do you know if that's still the case, or if there's a way to mock a fido2 key systemwide without uhid?

[psanford]

> there's a way to mock a fido2 key systemwide without uhid?

On Linux, Chrome and Firefox interface directly with the USB and Bluetooth interfaces. There is no OS level abstraction for FIDO devices on Linux.

[balena]

Isn't this approach significantly less secure than Apple's though? As far as I understand the secure enclave coprocessor in Apple devices stores key material and implements user verification (TouchID etc.), right? Instead software like tpm-fido bridges (in software) a user verification mechanism (maybe even a fingerprint reader) and the system's TPM. But such a system can be interposed with mere root access, and the TPM tricked in giving out its secrets, no? Please correct me if I'm getting it wrong, but Apple's approach is instead resistant even to full kernel compromise, precisely because the communication between TouchID/FaceID and the secure enclave cannot be interposed.

I'm a tpm-fido user myself by the way, thank you psanford!

[psanford]

Yes, having the verification done by the secure enclave itself is more secure. The TPM spec does allow for direct integration with biometric devices, but I'm not aware of any general purpose computers that ship in this configuration.

> TPM tricked in giving out its secrets

To be clear, the key can never leave the TPM (with how tpm-fido is implemented). The threat is an attacker can perform an online attack by getting the TPM to sign messages it shouldn't. But you couldn't steal the key from the TPM and use it somewhere else.

But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.

[balena]

> To be clear, the key can never leave the TPM (with how tpm-fido is implemented).

Yep sorry you're right you wouldn't get the actual keys to use elsewhere, you can just use them as if you had them on the "compromised" device only, my bad.

> But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.

If you're using WebAuthn to authorize the emission of session tokens you're absolutely right, just get root and steal them from the browser :) but WebAuthn is more versatile than that. You could e.g. require a WebAuthn assertion to authorize a payment. In that case root access still doesn't help you with a secure enclave, but is sufficient to trick your server in believing the user has authorized the operation with tpm-fido, right? Again I absolutely don't mean to detract from tpm-fido, just pointing out that, very sadly, I don't think a TPM+fingerprint reader+software can really replace integrated solutions like Apple's secure enclave, or a yubikey, etc. In general unless I'm mistaken, it's not a tpm-fido shortcoming specifically.

[mwwaters]

A compromised main UI device could also show the wrong account recipient, even if hardware key is used. The text could be changed on the screen when the user meant to send a small payment to someone else. Yubikey will be pressed like usual. Apple's standard prompt on the phone may not have the recipient shown.

[psanford]

I agree that the secure enclave with integrated touch id is more secure. However, if your threat model is an attacker has root on your system, the secure enclave isn't going to protect you from much.

[raxxorraxor]

Is there a software implementation that would work without a TPM module where I can generate the keys myself?

[psanford]

Check out rust-u2f/softu2f[0].

[0]: https://github.com/danstiner/rust-u2f