Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh


Vikrant More <vikrant8051@...>
 

Hi Johan,

Thanks for your reply.



I've been further clearing my concept by reading above two links along with Mesh Specs.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 ?

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

& 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 ?

[  Here in both the cases, I'm assuming DEVICE generate dynamic public key (non OOB public key) which gets transfer over Bluetooth-LinK (non-OOB channel)
   And it is used by ECDH to calculate ECDHSecret on provisioner side ]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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

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

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 ?

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 ?

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

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

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

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

I agree that, Bluetooth Specs has already provided details but it not easy to interpret its correct meaning


On Mon, Jan 15, 2018 at 8:42 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Mon, Jan 15, 2018, Vikrant More wrote:
> By reading this link, I understood that netKey, appKey, dveKey are
> AES-128 *symmetric
> keys* which are exchanged over encrypted *channel* during provisioning.

That's not completely true. Only the primary netkey and the devkey are
distributed to the node during provisioning. The other netkeys (if any)
and appkeys are distributed during the configuration phase over mesh,
and are encrypted using the keys that were distributed during
provisioning phase (primary netkey and devkey).

> This encrypted *channel* is based on public-private keys. Provisioner has
> its combo of keys & similarly DEVICE has its own.
> And to create this channels both parties should aware of public-key of each
> other.
>
> And there are two ways to exchange public keys viz;
> 1) in-band
> 2) out-of-band (OOB) (eg. NFC, QR code )
>
> Two avoid *man-in-the-middle attacks *we should go with OOB
> *. *
>
>
> *Up till this, Am I right ?*

Yes, however I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level).

> *So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's
> private & public keys stored ? *

The ECDH crypto is implemented in subsys/bluetooth/host/hci_ecc.c, and
it's based on TinyCrypt (which in turn is based on uECC, but let's not
get into those details :)

> *And how to update that pair from default one ? *

Currently all these APIs are internal, but we could (and perhaps should)
make them public. They reside in subsys/bluetooth/host/ecc.h currently.
There's e.g. bt_pub_key_get() which gives you the current public key
value (e.g. to be sent over an OOB channel), and bt_pub_key_gen() to
generate a new public-private keypair. Currently a new key pair gets
generated every time you initialize Bluetooth (by calling bt_enable).

> But when we enable this,
>
>     .output_size = 6,  //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,
>
> & we get 4 digits or 6 digits or random string on DEVICE's serial terminal,
> then what is this ? this is obviously not any type of public-key ?
> Could anybody explain me, what is going on ? What is Static OOB, Output
> OOB, Input OOB ?
>
> How Static OOB, Output OOB, Input OOB are related with the public-keys
> exchange which I've mentioned above ?

Those are steps that can happen after the public key exchange. I really
recommend you to read through section "5.4.2 Provisioning behavior" in
the Mesh Profile specification. Its subsections correspond to the
various stages that provisioning goes through. E.g. section 5.4.2.3 is
the public key exchange, and section 5.4.2.4 (called "Authentication")
the one where the Static/Output/Input OOB methods can be applied.

> If Zephyr does not have own copy of public-private keys for OOB, then how
> to generate & add them in firmware ?
> How to link them with above mentioned mechanism ?

As I mentioned earlier, by making the ecc.h header file public, we could
give the app access the the public key and make it possible for it to
transfer it out-of-band to the provisioner.

One thing that is missing (since the public key APIs were not previously
available to the app) is the ability for the app to influence the
Provisioning Capabilities PDU that we send to include a flag that says
"OOB Public Key available". It's a fairly simple thing to fix though -
it'd just be one more u8_t field to the bt_mesh_prov struct.

Johan

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