Methods for Bluetooth mesh secure provisioning, and can it be done using the serial interface?

[pilli]

Hi,
I have a question about Bluetooth mesh secure provisioning, as it is described in the spec section 5.4.3.

The  spec states that either

1) both OOB public key exchange and static OOB authentication

2) OOB input/output authentication

is needed for secure provisioning. What I don't understand is why in the first case the static OOB data is not enough, and what makes static OOB data different from input/output OOB in this regard. Put in a different way: why is OOB public key exchange needed in the first case, but not the second?

Additional question:

Can option 1 be done using the serial interface as a provisioner? How would i provide the OOB keys to the provisioner?

I see a command for setting the key-pair. Is that the correct one to use in this circumstance?

[Hung Bui]

Hi Pilli, 

My understanding is that there must be at least one real (non static) OOB method of exchanging data is used. Either it's in the ECDH calculation (Public key exchange)  or in the authorization phase where the Input/Output/static OOB is used. 

If you use static OOB, you must not transfer the public key openly (via Bluetooth). The static OOB data can be compromised if the attacker has access to device (read the flash). So if the OOB key is sent over Bluetooth, the attacker can act as Man in the middle (MITM) 

You can use serial to get the public keys. The protocol on how to send them is on your own. When you receive it you would need to wait for NRF_MESH_PROV_EVT_OOB_PUBKEY_REQUEST event, and then reply with nrf_mesh_prov_pubkey_provide()

If you want to do output/input OOB, you would need to wait for NRF_MESH_PROV_EVT_OUTPUT_REQUEST then display it or NRF_MESH_PROV_EVT_INPUT_REQUEST then reply with nrf_mesh_prov_auth_data_provide.

You can find an example of doing output OOB in our demo here, check out the my_mesh_provisionee.c file .