Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh


Vikrant More <vikrant8051@...>
 

>> How provisioner will understand from where to received/read DEVICE
>> public key out of *Bluetooth-Link* or *OOB* channel ?

>I believe this is out of scope for the specification, since any OOB
>channel is by definition something else than Bluetooth. In practice this
>would then have to be a vendor-specific solution. There could e.g. be
>hints in the advertsing data, or behind the optional URL in the
>advertising data, as to what kind of OOB channel the unprovisioned node
>wants to use.

But as per this link, https://blog.bluetooth.com/provisioning-a-bluetooth-mesh-network-part-1 ,

In the exchange public keys phase, there are two possible ways for ECDH public keys to be exchanged.
They can be exchanged over a Bluetooth link or through an OOB tunnel.
In the provisioning invitation phase, the unprovisioned device has already reported whether or not it supports sending its public key via an OOB tunnel.
If it does, the provisioner can proceed to use it and informs the unprovisioned device by sending a Provisioning Start PDU.

could you please tell me, is this taken care by you ?
Where to edit, when I want to send ECDH public keys over OOB tunnel ?
Or is it also in development phase ?


Thank You !!

On Wed, Jan 17, 2018 at 2:15 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Jan 16, 2018, Vikrant More wrote:
> When I comment-out following lines as below
>
> static const struct bt_mesh_prov prov =
> {
>     .uuid = dev_uuid,
>
>
> * //.output_size = 4,    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
> BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
> //.output_number = output_number,*
>     .complete = prov_complete,
>     .reset = prov_reset,
> };
>
> , flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I
> right ?

Yes.

> & when I uncomment following lines as below
>
> static const struct bt_mesh_prov prov =
> {
>     .uuid = dev_uuid,
>
>
> * .output_size = 4,    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
> BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
> .output_number = output_number,*
>     .complete = prov_complete,
>     .reset = prov_reset,
> };
>
> , flowchart follows path as per attached FlowChart_2.pdf. Am I right ?

Yes.


> DEVICE's Public key can be static or dynamic plus it can exchange over
> Bluetooth-Link or OOB. Am I right ?

Yes.

> As per current implementation, we are using *dynamic Public Key*
> *& *both sides public keys are get exchanged over Bluetooth-Link instead of
> OOB. Am I right ?

Yes.

> But when I want to use static Public-Private keys for DEVICE (provisioner
> may have dynamic pair), how & where to edit so that provisioner will
> understand that DEVICE has static public key ?

The provisioner doesn't really need to know if the key is static or
public. It just needs to know which key to use for the provisioning.

What the implementation is missing right now is a way to use a static
private-public keypair instead of a dynamically generated one. We would
probably need to introduce new Kconfig option and extra code to the
current ECDH implementation (in subsys/bluetooth/host/hci_ecc.c) to read
a pre-existing public key from some persistent location instead of
generating a new key pair.

> How provisioner will understand from where to received/read DEVICE
> public key out of *Bluetooth-Link* or *OOB* channel ?

I believe this is out of scope for the specification, since any OOB
channel is by definition something else than Bluetooth. In practice this
would then have to be a vendor-specific solution. There could e.g. be
hints in the advertsing data, or behind the optional URL in the
advertising data, as to what kind of OOB channel the unprovisioned node
wants to use.

> If public keys get exchanged over insecure channel, then what is
> significance of OOB tunnel over Bluetooth-Link ?

You might want to read up on how Diffie-Hellman key exchange works:
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

You essentially acheive confidentiality for the link with the peer
you've exchanged public keys with, but only through the OOB
authentication phase will you be able to authenticate that the peer
really is who you think it is.

Johan

Join devel@lists.zephyrproject.org to automatically receive all group messages.