Epic: caBLE authenticator support

[micolous]

This is to track work and ideas relating to supporting caBLE authenticators (aka: authenticator on your mobile device), and acting as a caBLE authenticator.

At present (2023-08-10), our implementation of the caBLE authenticator and initiator is fairly complete; the only gaps are DPK and pairing (both are Android-only). It's otherwise completely usable as an initiator with Android and iOS devices acting as authenticators.

Merged

• Add basic support for caBLE authenticators / initiators #232 (MVP)
• Allow overriding tunnel server protocol/domain for caBLE #295
• caBLE tunnel server #291

In review

In progress

Future work ideas

Not a commitment to deliver it, and not in any particular order:

• Port to some embedded system
• Tunnel server frontend

Authenticator features

• Improve QR code scanning for cable_tunnel example #296
• Use bluez Rust bindings to send advertisements on Linux, rather than needing a serial Bluetooth HCI controller

Initiator features

• Hybrid Transport (caBLE): State-assisted Transactions #446 (pairing / Linking / "Remember Device" (Android + Chrome)). The current implementation just ignores it, because Chrome on Android will always send it.
• DevicePubKey extension (Android + Chrome). You can have the authenticator device attest its identity and give out a SafetyNet attestation.

Discarded work ideas

• Figure out how to use Apple's tunnel server as an authenticator (if possible)

[Firstyear]

I'm not sure DPK is worth supporting at this point as previously discussed.

[micolous]

FIDO Alliance recently published a review draft of the CTAP 2.2 specification, which includes a caBLE specification. Some observations:

• The protocol for an authenticator establishing a connection to a tunnel server is considered "a private detail of the authenticator's implementation".

  As a result, I've dropped supporting Apple's tunnel server as an authenticator from the list, because webauthn-authenticator-rs (and our cable-tunnel-server) implements Chromium's protocol, and I presume Apple will do something different here.

• Chromium differs from the spec in many ways, which would make it incompatible. I'm otherwise pretty confident that webauthn-authenticator-rs implements the protocol correctly-enough.

• The major gap for webauthn-authenticator-rs is implementing pairing (state-assisted transactions); though I think only Android implements it.

  From the looks of it, the dependency on Firebase Cloud Messaging would make it difficult to implement an authenticator using a non-first-party tunnel server, and also makes implementing pairing on our cable-tunnel-server somewhat complicated.

[Firstyear]

I think for the moment that what we have is a really good demonstration of what's possible, especially for other libraries like the webauthn portal library, but until there is more demand outside of testing and smaller use cases we probably don't want to stress about details like pairing :)

[micolous]

The main issue with pairing is that the library would need a place to store some state (the contact list), and interfaces to manipulate it. This would make things more complicated for an application using webauthn-authenticator-rs.

AFAICT only Android supports pairing, and I'd like to see another implementation before going down that rabbit hole. However, I don't know if Apple will even bother with that, given that the Apple ecosystem solution is that applications use their platform WebAuthn APIs to access the iCloud Keychain.

[AlfioEmanueleFresta]

I'd like to try and pick up the work on State-assisted Transactions (STs). I believe hybrid transport is crucial to unlock Passkey adoption across platforms, and STs are highly desirable for our use case.

As @micolous pointed out, this requires storing authenticator information. I propose applications wanting to use state-assisted transactions should provide storage, by means of optionally providing an implementation of a storage-provider interface. For example, it would be the responsibility of the Linux FIDO2 portal to store known devices, and the security properties of this storage may be adapted depending on the use case - eg. using the TPM to bind the state to a specific device.

Created #446.