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




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