NRF Mesh Android Library, return device key even if provisioning fails

[jm_solar]

We use the NRF Mesh Android Library (and are developing with iOS version as well). An issue that we are running into on a small number of devices is that the library things provisioning failed, but the device being provisioned thinks it succeeded. This leaves the device provisioned with a device key that we cannot access, as the library does not provide a way to access the device key unless provisioning succeeded. 

We are addressing this on the firmware side, but more generally as a solution we would like to record every device key that we attempted to provision a device with so that we can attempt recovery from the app using these keys. Otherwise these devices end up as RMAs which is very costly when all we need to do is connect to them with the device key and reset them. 

As far as we can tell, this is not currently possible with the NRF Mesh Libraries - is this correct?

Can this feature be added so that provisioning can be made more resilient?

[tesc]

Hi,

In order to ensure we are talking about the same libraries, can you please refer to the nRF Mesh library you are using by link, and preferably also version? We can then consider adding the feature. I clearly do see the benefit in case of scenarios such as the one you describe.

Regarding the devices you are provisioning, do they have any reset mechanism that can be triggered without connecting to them from a configuration device with the correct device key? Such as e.g. long press a button on the device, or some other action requiring physical access to it? Based on your inquiry I assume they do not. I therefore also assume you are properly taking backup of the network configuration database for recovering the devices in case the configuration device should get lost or damaged.

In general, a requirement of knowing the device key for factory resetting the device may be risky in terms of device bricking. Please be vigilant, as given your inquiry I am sure you are, in mitigating this risk. Having a separate reset mechanism may of course also have security implications, and so may not always be feasible.

Regards,
Terje

[jm_solar]

This is the android library link: https://github.com/nordicsemi/Android-nRF-Mesh-Library

And iOS: https://github.com/nordicsemi/IOS-nRF-Mesh-Library

Unfortunately for us our devices are installed in an non-accessible location that requires trained personnel to access. At the point where a trained person gets sent to retrieve the device they are just going to replace it. 

Our only option for an additional reset mechanism is something wireless due to this, which obviously has significant security implications compared to something with physical access.  

We have issued a patch for devices to detect this sort of incomplete provisioning and reset themselves, however we the devices in distribution won't see this update until after successful install. We are also generally prefer to give ourselves as many options on the app side since it is much quicker to push changes, updates, etc. to users that way. 

Yes, network configuration is stored in a server with backups, not just locally on the users device and we've implemented syncing, locking, etc. 

Ultimately this is almost the Two Generals problem (except the device doesn't need to know that the provisioner knows it is provisioned), ideally we would solve it with retries - but to do so we need the same key we used to try the first time.