【Mesh Security Materials Generation】Is it possible to generate mesh security materials by users?

[xiaolongba]

Hello Nordic Experts,

I almost finished the development for my mesh project with nRF52840. But I faced some tricky issues when in mass production. that is the time for provisioning is too long. my purpose is below:

1.  the devices can be communicated with each other after downloading the FW, in other words, these devices with the default security materials, such as netkey,appkey,iv index etc.
2. at this moment, users dont need to do the provisioning process when they got the device unless they would like to change netkey or appkey or others

so my questions as follows:

1. Is it possible to generate the mesh security materials by users? Nordic can provide such one tool to customer?

2. could you point out the location for these mesh security materials in the internal flash?

Note: what does mesh security material mean is netkey,appkey,devkey,iv index,unicast address etc.

thanks.

[Mttrinh]

Hi,

1. We do have our nRF Mesh app for iOS and Android, assuming that you have support for PB-GATT and Proxy feature. The sample app is for development/protoyping purposes targeting developers to make debugging easier, so it is recommeded that you create your own app. The nRF Mesh app is open-source and can be used as a reference. It can be found on our Github, see here and here.

2. You can use this function mesh_stack_persistence_flash_usage() to get which flash areas used by the mesh stack to store the provisioning data.

[xiaolongba]

Hi Mttrinh

My comments as below:

Mttrinh said:

e don't have any PC tools for that. Our developer don't think it is possible to pre-flash security materials as there are flash headers that need to be stored as well. They also need to be dumped, otherwise stack won't be able to restore configuration.

OK, Got it.

Mttrinh said:

The mesh specification doesn't allow pre-flashing configuration. This may lead to security vulnerabilities. E.g. DevKey generated during provisioning and can't be changed until device is reset and re-provisioned.

Yes, I got it. But I don't think this a security vulnerability as this approach is only used in mass production and it just speeded up the process of provisioning, In other words, these material security materials are stored into the flash in advance and bypass the process of provisioning. Such as these security materials can be obtained from a customer's server, and others is impossible to get unless the information in the server is disclosed

Mttrinh said:

Thus, with pre-flashed configuration, the devices will anyway need to be reprovisioned for the security reasons.

why? I cannot get your point, as I said above, these mesh security materials are stored into the internal flash in mass production. they can communicate with each other after power on if the customer purchased these products from the store. 

Mttrinh said:

If you still wants to do this, there is mesh_stack_provisioning_data_store() function that is called when device is provisioned. The customer may use it to pre-configure device. It can use provisioner example to see how provisioner preconfigures itself.

OK, let me check and feedback to you soon.

Anyway, many thanks for your detailed replies.