Thread network key changes when migrating from NCS 2.4.1 to 2.6.1

[Mary]

nRF52840

NCS 2.4.1  to NCS 2.6.1

My project is based on the coap_server example.  When I ported it from NCS 2.4.1 to NCS 2.6.1, the network key and PSKC changed.  All other Thread credentials stayed the same (channel, channel mask,  panid, extended panid, mesh local prefix, network name, security policy).

The project supports DFU, so when upgrading from a 2.4.1 based version to a 2.6.1 based version, the network key changed and the device cannot communicate with other devices on the original network.

Both versions use identical pm_static.yml files, so the storage settings partition has not moved.

Is this a bug?  Is there a workaround?

Mary

[Amanda Hsieh]

Hi, 

Which DFU do you use, via UART/USB or BLE?

Do you use the nRF Device Manager app to update?

Regards,
Amanda H.

[Mary]

The nrf52840 is connected to Wiznet W5500 to access the ethernet and download  app_update.bin from the cloud.  

I can see the problem just by programming with the DK.  It also happens when I go in the other direction (2.6.1 to 2.4.1).

Mary

[Amanda Hsieh]

Could you try to set the same key with CONFIG_OPENTHREAD_NETWORKKEY in the prj.conf for NCS 2.4.1 and NCS 2.6.1? Let me know if this can help or not. Here is the example: https://github.com/nrfconnect/sdk-nrf/blob/v2.4.1/samples/openthread/coap_client/prj.conf#L31 

[Mary]

I set

CONFIG_OPENTHREAD_NETWORKKEY="00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff"

in prf.conf for both 2.4.1 and 2.6.1.

 

and commented out this code:

	// if (!otDatasetIsCommissioned(instance))
	// {
	// 	LOG_INF("Thread not commissioned. Creating dataset.");
	// 	otDatasetCreateNewNetwork(instance, &dataset);

	// 	// Form network name from MAC address last three bytes (16 char limit)
	// 	// channel, panid, and networkkey will be random
	// 	uint32_t maclo = NRF_FICR->DEVICEADDR[0];
	// 	uint32_t machi = NRF_FICR->DEVICEADDR[1];
	// 	uint8_t mac[3];
	// 	mac[0] = machi;			// unique part
	// 	mac[1] = maclo >> 24;
	// 	mac[2] = maclo >> 16;

	// 	snprintk(dataset.mNetworkName.m8, sizeof(dataset.mNetworkName.m8), "MyNet_%02X%02X%02X", mac[0], mac[1], mac[2]);
	// 	dataset.mComponents.mIsNetworkNamePresent = true;
	// 	otDatasetSetActive(instance, &dataset);
	// }

I had to do a factory reset to see this network key appear. 

1. compiled with 2.4.1, downloaded with J-Link, and ran.  Old network key appeared

2. Factory reset, ran.  New hard coded network key appeared

3. Then compiled with 2.6.1, downloaded with J-Link, and ran.  New hard coded network key appeared.

4. Factory reset, ran. New hard coded network key appeared.

I'm not sure what this tells us.  I cannot use a hard coded network key for production.

Mary

[Amanda Hsieh]

Mary said:

1. compiled with 2.4.1, downloaded with J-Link, and ran.  Old network key appeared

Could you try to erase the board (nrfjprog --eraseall) before programming? Does it help?

[Mary]

I restored the fw to my original, so it's generating a random network key if it is not commissioned.

1. nrfjprog --eraseall

2. Program with fw built with NCS 2.4.1  networkkey = 916a8357f913200db83c5272ad01b2f4

2. Program with fw built with NCS 2.6.1 networkkey = 916a8357f913200db83c5272ad01b2f4

3. Program with fw built with NCS 2.4.1 networkkey = 00000000000000000000000000000000

4. Program with fw built with NCS 2.6.1 networkkey = 916a8357f913200db83c5272ad01b2f4

5. Program with fw built with NCS 2.4.1 networkkey = 00000000000000000000000000000000

6 Program with fw built with NCS 2.6.1 networkkey = 916a8357f913200db83c5272ad01b2f4

It seems the NCS 2.6.1 fw can read a networkkey that was written with 2.4.1.

Once NCS 2.6.1 runs, 2.4.1 can no longer read it.

Mary

[Amanda Hsieh]

Hi, 

Why don't you use CONFIG_OPENTHREAD_NETWORKKEY in prf.conf for both 2.4.1 and 2.6.1 to ensure they can have the same networkey?

-Amanda H.

[Mary]

Because we have devices in the field that have a randomly generated network key that need to keep using that same network key so that they can communicate with the other devices on their network.  We would update them with a 2.6.1 based version, but we can't because of this issue.

Because we don't want ALL of our customers to have the same network key.  

Because once a device sets a network key, it should never change. Even when updating with a new SDK.

The issue is that the network key should not change, but it did. Why?

Mary

P.S.  I did not mean to verify your previous response.  I hit the wrong button.

[Amanda Hsieh]

Hi,

The team has verified and cannot reproduce the issue on a clean coap_server sample.

In v2.6.1, PSA Crypto API support has been added, and keys are now stored in Trusted Storage. After upgrading from the 2.4.1-based version to 2.6.1, keys should be removed from the dataset and saved to trusted storage. Downgrading is not supported in this case.

What could have happened is you first tested the v2.6.1-based application on the device, and then flashed/downgraded to the v2.4.1-based version without erasing the settings partition (for nrf52840 trusted storage is located there as well). If that happened, the v2.4.1-based app could not find keys in the dataset and didn't support securely stored ones, so it created its own set of keys. Later after upgrading back to the v2.6.1-based version, the old set had been already saved in trusted storage, so the procedure of moving keys from the dataset was skipped.

To correctly verify the behavior, I recommend making sure that the tested device has not been upgraded to the v2.6.1 version before flashing with v2.4.1, or erasing the settings partition before flashing the lower version.

-Amanda H.

[Mary]

Thanks for the explanation.  This should be in the release notes.

Mary