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