Hybrid support in windows

[Firstyear]

Currently we have to mask hybrid/caBLE in windows, but it's in dev so we need to unmask this in the future.

[micolous]

tl;dr: I had a look, I don't think Windows publishes Hybrid/caBLE support yet (as at webauthn.dll v10.0.22621.755 from Windows 11)

Details

https://github.com/riverar/mach2 has a list of many/all of the feature flags in Windows, that is scraped from PDB (debug symbols) published by Microsoft.

A few weeks ago when I came across this, I noted a flag: FidoBleAddressRotation: 21326400, which @Firstyear thought may be related to Windows-native caBLE/Hybrid support. After looking into this, I don't think this is actually the case.

Since then, I started poking at Windows 10's version of webauthn.dll in a disassembler, and later set up a box with Windows 11 and poking at that one too. :)

From reading Chromium's implementation of caBLE, it looked like the v1 protocol required the platform (browser) to advertise some data over BLE; which could necessitate randomising BLE MAC addresses for privacy. But then there are a lot of restrictions about what you can broadcast on different platforms, and there's a huge web of platform-specific code, resulting in different BLE frames for the authenticator (the phone) to try to parse.

But then in caBLE v2 (which appears to be what's used now – and will probably end up in the next version of FIDO), that was switched around to make the authenticator (the phone) broadcast BLE frames for the platform (browser) to look for; this still has pretty significant restrictions on iOS, but would be possible for a mobile-platform-blessed FIDO implementation to bypass (as Apple did for Exposure Notifications).

In the end, both of these use BLE to negotiate a WebSocket tunnel for further communications. There are two hard-coded tunnel servers for V2: cable.ua5v.com (Google) and cable.auth.com (Apple), then further tunnel servers are defined by appending a uint16_le to the string caBLEv2 tunnel server domain, then SHA256 hashing the value, and then using it to derrive a domain name (eg: tunnel server ID 266 = cable.wufkweyy3uaxb.com) – so I'd expect any caBLE implementation to hard code these strings, and call out to WebSockets in a way that is quite different to a typical FIDO BLE GATT implementation.

What I've found from digging into webauthn.dll with a disassembler:

• both Windows abstracts transports into "providers". These providers are on both Windows 10 and 11:

  • MicrosoftCtapHidProvider (USB HID)
  • MicrosoftCtapNfcProvider (PC/SC / WinSCard)
  • MicrosoftCtapBleProvider (BLE)
  • MicrosoftCtapTestProvider (which I haven't figured out how to activate yet – but it appears to have a U2F and CTAP2.0 protocol handler and use a software key storage provider)
  • there doesn't appear to be any other caBLE provider

• the FidoBleAddressRotation feature flag is only on Windows 11. It's used in _BleCreateContext(), which is part of the BLE provider; so I don't think it's anything to do with caBLE support.

  This is consistent with other WebAuthn API features – Windows 11 has a higher WebAuthNGetApiVersionNumber() than Windows 10.

• there are no hits in either the Windows 10 (10.0.19041.1) or 11 (10.0.22621.755) webauthn.dll for cable or tunnel (case insensitive, both wide and narrow strings)

So I don't think Windows' platform WebAuthn API supports Hybrid / caBLE authenticators yet.