Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh


Johan Hedberg
 

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.