Regarding Out of band (OOB) Public key exchange for provisioning in BLE Mesh

[Utkarsh]

ncs v2.6.1 nrf5340

 As mentioned in the document,
Q1. Does CONFIG_BT_MESH_PROV_OOB_PUBLIC_KEY need to be set on the provisioner's side as well? The document only mentions on the provisionees side.

Q2. The function bt_mesh_prov_remote_pub_key_set() needs to be called on the provisioner's side as per the document but when compared to the provisioner sample,at what point should this be set so that it is set for provisioning the right device when the provisioner will be receiving multiple beacons.

[AHaug]

Hi,

I've picked up your case and will be looking into this. For now I need some time to clarify some details with my colleagues regarding my answer. I'll get back to you when I have the clarification ready (hopefully early next week)

Kind regards,
Andreas

[Utkarsh]

This is what I have done so far:

On the provisionee

1. Generated a pair of persistent ECDSA keys 
2. Passed 32 byte private key to bt_mesh_prov prov structure
3. Passed 64 byte public key after removing 0x04 to the bt_mesh_prov 
4. Enabled CONFIG_BT_MESH_PROV_OOB_PUBLIC KEY

On the provisioner

1. Passed the public key of the provisionee to the bt_mesh_prov_remote_pub_key_set() function before the bt_mesh_provision_adv function

By doing this on the provisionee's end this is the warning I am getting :

<wrn> bt_mesh_prov: Unexpected msg 0x03 != 0xff
<wrn> bt_mesh_prov: Unexpected msg 0x05 != 0xff
<wrn> bt_mesh_pb_adv: Giving up transaction

On the provisoner I am getting a timeout

Please help me with the same.

[AHaug]

Hi,

Here's the answer from the developers regarding the initial questions:

 As mentioned in the document,
Q1. Does CONFIG_BT_MESH_PROV_OOB_PUBLIC_KEY need to be set on the provisioner's side as well? The document only mentions on the provisionees side.

Yes, this needs to be add to both sides if the key and oob info are to be used as provisioning properties and capabilities.

 To provision a provisionee using the oob public key, the provisioner needs to know that key first.

Q2. The function bt_mesh_prov_remote_pub_key_set() needs to be called on the provisioner's side as per the document but when compared to the provisioner sample,at what point should this be set so that it is set for provisioning the right device when the provisioner will be receiving multiple beacons.

As far as I understand it, bt_mesh_prov_remote_pub_key_set() is not called after the provisioner got the oob public key but called from whatever API (OOB mechanism from the customer) is run to make/read the oob public key(s) to relay the oob public key to the provisioner, before starting provisioning.

When the key(s) are relayed to the provisioner (using bt_mesh_prov_remote_pub_key_set()) is very dependent on the specific design of the OOB mechanism the customer implements. And as for ensuring the correct beacon is provisioned, the provisioning will fail if the oob public key is not correct. A common use case for this would be for example an application utilizing QR-codes. Lets say there are three provisionees around, the phone (provisioner) reads the QR codes and gets one oob public key, if there is no indication which provisonee to provision, you can try to provision all of them, but only the correct one for the oob public key will succeed.

Kind regards,
Andreas

[Utkarsh]

For development purposes, I have manually hardcoded the public key into the provisioner but I am getting the above mentioned warnings and provisioning is not working

[Utkarsh]

Also does the function   bt_mesh_prov_remote_pub_key_set() automatically recognize the type of keys being used ?