Topics

understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh


Vikrant More <vikrant8051@...>
 

Hello World !!

By reading this link, I understood that netKey, appKey, dveKey are AES-128 symmetric keys which are exchanged over encrypted channel during provisioning.

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 ?

So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's private & public keys stored ?
And how to update that pair from default one ?

//----------------------------------------------------------------------------------------------------------------------------------------------------------------

Previously, I had asked following Question, (at that time I had forgotten to add zephyr-devel@... in CC)

//----------------------------------------------------------------------------------------------------------------------------------------------------------------


For testing I always comment-out following lines

    //.output_size = 6,
    //.output_actions = (BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING),
    //.output_number = output_number,
    //.output_string = output_string,

,otherwise I have to read that value from nRF52 terminal .

How this mechanism is going to work with actual products based on #BluetoothMesh ?

We can't ask consumer or end-user to attach device to serial terminal to get that value like we does to complete OOB-authentication procedure.

On that Mr. Johan replied as ->

In the Mesh Profile Specification, you can find the other types of input
& output OOB actions e.g. under section 5.4.1.2, in particular tables
5.22 and 5.24. The only reason the sample apps use display number/string
is that they're designed for a setup with a text-based console.

That said, the general consensus within the Mesh WG is that the
input/output OOB action mechanism is not sufficiently secure and should
only be considered to be a minor improvement over non-interactive
provisioning. The recommendation for secure provisioning is to use OOB
Public Key transfer or a 16-byte static OOB value. The actual mechanism
to do this is left up to the implementation - you can e.g. have a URL in
the node's advertising data or have a QR code printed on the node which
the provisioner reads. Using NFC is another option. IIRC, there should
be a whitepaper coming out from the Mesh WG soon which covers
recommended practices for secure provisioning.
//-------------------------------------------------------------------------------------------------------------------------------------------------------------
//-------------------------------------------------------------------------------------------------------------------------------------------------------------

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 ?

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 ?


Thank You !!





Johan Hedberg
 

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


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


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


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


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


Johan Hedberg
 

Hi Vikrant,

On Sat, Jan 20, 2018, Vikrant More wrote:
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 ?
I answered this already here:

https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/008734.html

I'm sure we'll eventually have proper support for it, but if you want to
get it sooner feel free to send patches for it.

Johan