Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh


Vikrant More <vikrant8051@...>
 

Hi Johan,

Many many thanks Johan, for your in detail explanation.

I don't want to use static public-private key pair for DEVICE & happy with current implementation.
It is inherently more secure since every time new pair get generated.

Now as per my understanding, it is only important to do authentication over OOB using randomly generated
(on every reset if DEVICE is in Unprovisioned state) 16-Bytes static-OOB.

OR

If I have to go with output-OOB or input-OOB but it will increase cost of BoM since we have to add NFC or small LCD etc. etc.
(Note that all budget smartphone doesn't have NFC feature)

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Second point is, I don't want to use Input-OOB & output-OOB.

By taking reference from your old reply, I have an idea to generate secret RANDOM 16-bytes static OOB using DEVICE MAC address
by executing some common vendor specific algorithm on both sides where nothing will get exchanged over OOB channel.

In case of nRF52840, we get DEVICE's MAC address by accessing oob.addr.a.val.


" Static OOB or No OOB

In cases where neither Input OOB or Output OOB are possible,

the provisioner and unprovisioned device may use either Static OOB authentication or No OOB authentication.

In this case, the provisioner and unprovisioned device each generate a random number and then proceed to the check confirmation value operation "


Now this is confusing, if I edit code as follow that means only static-OOB feature is working

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,

    .static_val = static_oob,  // <-- randomly generated after every reset
    .static_val_len=16,

    //.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,
    //.output_string = output_string,

    .complete = prov_complete,
    .reset = prov_reset,
};


And as per that link, if random no. is different for DEVICE & Provisioner then how they will authenticate each other

( assuming OOB channel is not at all in existence) ?

Is OOB channel is mandatory to exchange those 2 static-OOB ?

In case of #meshctl, it ask only for DEVICE's (16-bytes ) static-OOB & nothing provide from own side for DEVICE.

Is OOB channel/tunnel approx. mandatory concept of #BluetoothMesh ? 

Thank You !!

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


On Jan 17, 2018 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.