W3C home > Mailing lists > Public > public-webauthn@w3.org > February 2020

[webauthn] BLE Resolvable Private Address resolution using IRK (#1371)

From: rjhallock6 via GitHub <sysbot+gh@w3.org>
Date: Thu, 06 Feb 2020 20:06:43 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-561240605-1581019602-sysbot+gh@w3.org>
rjhallock6 has just created a new issue for https://github.com/w3c/webauthn:

== BLE Resolvable Private Address resolution using IRK ==

Hi, I’ve created a biometric BLE Authenticator App that operates correctly in all regard except one. 

Some background: the BLE stacks of both Android and iOS implement Resolvable Private Address for security reasons. RPA is a process where when pairing the client and authenticator device agree on IRK use. Thereafter, when authenticator initiates advertising the BLE stack on that device assigns a new device address for the advertising session. The paired client will see the new address, not the address used during pairing, and resolve it to the original pairing device address using the IRK. This occurs during the client scanning process.

The problem: the authenticators FIDO or U2F BLE session begins advertising with a new device address added by the stack after demonstration of intent from the user (button tap, bio capture/verify, or whatever). Meanwhile, the browser client app, webauthn.js for example, has executed either create() or get() doing so using the paring device address of the BLE device with FIDO GATT. If a scan had not been done before either, the access will fail and a timeout results and the FIDO or U2F attempt aborts.

Problems isolation: I believe the problem is within the webauthn.js module. Within it there is no code to force IRK address resolution that I could find. Either navigator.bluetooth.requestDevice() or navigator.bluetooth.requestLEScan() would have to be called prior to either create() or get() to resolve the issue.

As a temporary workaround I’ve created a web app I run in a separate tab along side the FIDO or U2F client. In this I’ve tried both requestBLEScan () and requestDevice() and either works to solve the problem. 

Workaround app attached.
[requestLEScan.txt](https://github.com/w3c/webauthn/files/4167490/requestLEScan.txt)




Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1371 using your GitHub account
Received on Thursday, 6 February 2020 20:06:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:37 UTC