#BluetoothMesh OOB authentication

[vikrant8051]

I hope Nordic Semiconductor is working on #BluetoothMesh provisioner & configuration App like Silicon Labs already has.

But could anybody inform me, how you are going to implement OOB authentication which happens during provisioning process ?

Currently I am testing Zephyr OS #BLEMesh (running on nrf52840-PDK) using Silicon Labs Mesh App. I'm able to replicate this www.youtube.com/watch demo using #nRF52840-PDK.

In this case, to complete OOB authentication during provisioning process I have to access serial terminal of nRF52 to read a number which is alloted my APP. It is like mobile OTP verification. We can't use this method with actual products otherwise end-user have to connect device to serial-terminal to get that OOB number.

Mr. Johan Hedberg (Zephyr OS developer behind #BluetoothMesh ) gave me following reply when I asked him about it -

In the Mesh Profile Specification, you can find the other types of input
& output OOB actions e.g. under section 5.4.1.2, in particular tables
5.22 and 5.24. The only reason the Silicon Labs App uses display number/string
is that it is designed for a setup with a text-based console.

The general consensus within the Mesh WG is that the
input/output OOB action mechanism is not sufficiently secure and should
only be considered to be a minor improvement over non-interactive
provisioning. The recommendation for secure provisioning is to use OOB
Public Key transfer or a 16-byte static OOB value. The actual mechanism
to do this is left up to the implementation - you can e.g. have a URL in
the node's advertising data or have a QR code printed on the node which
the provisioner reads. Using NFC is another option. IIRC, there should
be a whitepaper coming out from the Mesh WG soon which covers
recommended practices for secure provisioning.

Any other additional information will be appreciated !!

Thank You!!

[Hung Bui]

Hi Vikrant,

Static authentication (including OOB static authentication) is already used in our example. Currently we used a fix data (look for STATIC_AUTH_DATA). But you can use NFC, QR code or anything to update this value (on both provisioner and provisionee). It should be pretty straight forward to implement. Have a look at the config_params in main() in our light switch example.

[vikrant8051]

I don't want to use OOB channel for authentication like NFC, display etc. etc. Can I generate 16 bytes of Static-OOB using DEVICE (nRF52) MAC address using some algorithm ? The same algorithm will work on Provisioner to generate 16-byte static-OOB to authenticate DEVICE (here I'm assuming provisioner has fetched MAC address from DEVICE advertisement)

[Hung Bui]

Yes, I don't see any problem with that. Currently our static data is hardcoded as STATIC_AUTH_DATA.

You can use your algorithm to generate your own static authentication data. Make sure you match them on both the provisionee and provisioner.