Implementing QR initiated transport on linux

[jo-bitsch]

I was looking into giving it a go to implement hybrid transports in particular QR-initiated Transactions on Linux to be able to also using a phone e.g. for SSH logins and maybe git signing.

The main communication flow would be to start the command and then

1. libfido2 displays a QR code (e.g. using libqrencode)
2. Scan from the phone
3. Phone sends a BLE advertisement
4. libfido2 receives that advertisement (e.g. via dbus using libsystemd, as implemented in Extend FIDO2 BLE support also for Linux #700)
5. libfido2 connects to a tunnel service via a websocket (e.g. using libwebsockets) and authenticates
6. at this point this is a standard CTAP2 message channel

Does this sound reasonable?

To enable State Assisted Transactions, some of the state could be saved to a file.

I imagine basic usage to work kind of like

# Prepare an initial key pair for connecting to the tunnel service which is also included in the QR code
fido2-token -R hybrid:/path/to/a/state-file

# and the just normal usage.
fido2-cred -M -i cred_param hybrid:/path/to/a/state-file
# ...

Some of the open questions are:

• While on the command line, we could just print the QR code to stdout. However, when this is integrated into another app, that's probably not the cleanest way.
• How would enumeration work? (token_list --> fido_dev_info_manifest)
• How would the state file look?

Would there be interest for this type of thing here?

[LDVG]

Hi,

Would there be interest for this type of thing here?

This is a pretty heavy protocol, likely introducing multiple new dependencies to libfido2 and, as you point out, it's not obvious how these map to some libfido2 concepts such as fido_dev_info_manifest(). This means that it drastically increases maintainability overhead and adding support has a low priority for us.

Our general recommendation is that you either try to (a) make it a separate daemon that can synthesize a hidraw device that libfido2 could pick up automatically, or (b) write the transport layer in your application and use fido_dev_set_{transport,io}_functions() function(s) to hook into libfido2. If by doing so it turns out to be reasonably simple to integrate with libfido2 directly, let's give it another look.

That said, here's a couple quick thoughts to your initial questions:

While on the command line, we could just print the QR code to stdout. However, when this is integrated into another app, that's probably not the cleanest way.

We would probably prefer to not bring in dependencies for encoding a QR code and instead have a function that the application can use to retrieve the data that needs to be encoded. It is then up to the application to do that and to display it to the user.

How would enumeration work? (token_list --> fido_dev_info_manifest)

Unfortunately, I don't have a definite answer to that question. Just like the linked BLE transport implementation, it's not a great fit to our current API.

How would the state file look?

This is probably a question best answered after having completed the QR-initiated implementation.