[ZIGBEE] Doesn't receive "Transport Key" in rejoining.

[_maibi]

SDK: 4.1.0

CHIP: nRF52840

ROLE: sleepy zed

GATEWAY: third party ember stack

old question

old story: 

- Issue: Doesn't update network key - 4.6.3.4 Network Key Update in zigbee spec.

- The current procedure of updating network key:

1) The gateway periodically changes the network key.

2) After changing the network key, The gateway doesn't receive the message encrypted with old key from the zed.

3) The zed doesn't receive APS ACK to the period request.

4) Since zed does not receive a response, it assumes that the network key has changed.

5) The zed request the rejoin message without encryption.

6) The gateway accepts unsecured rejoin .

7) The gateway send "Transport Key" encrypted with ZB_STANDARD_TC_KEY which is the same as when joining.

8) The zed processes this message and updates the network key.

It is the procedure of updating the network key has the gateway.

I has succeed until "5) requesting unsecured rejoining".

so, I received "Transport Key" encrypted with ZB_STANDARD_TC_KEY.

However, the zed does nothing. It doesn't even seem to be decryption of "Transport Key" message.

I watched the functions "nrf_802154_received_timestamp_raw" it was called and "hw_aes128" it wasn't called.

7140.pairing.pcapng

this is pairing procedure.

5722.0303-4.pcapng

this is rejoining procedure.

there are keys for pcap.

ZB_STANDARD_TC_KEY 

5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39

Current Gateway key - not necessary

7F:94:FE:28:95:41:48:83:F9:16:F2:2D:8D:4B:78:97

How can I reach the goal?

1) If I terminate the old key, Does the zed receive "Transport Key" message?

2) How can I get or delete the network keys? I can't find the related api.

I already use "zb_bdb_reset_via_local_action" function to erase all parameter. I wants to terminate only network key to rejoining the network.

3) I uses IAS zone cluster. Is it related on this issue? I found the post.

"The reason the Elko PIR sensor does not retrieve the key is because it uses a cluster called IAS Zone, which gives extra security for the device, and has an extra step in the commissioning process." what is meaning? Why is IAS ZONE CLUSTER related to zigbee network security?

4) I found zigbee spec "4.7.3.10.2 Sleepy Devices" of rejoining procedure in sleepy device. 

It is correct that i understood the procedure of rejoining. Is this legacy role? or not?

if yes, should I call "zb_set_network_ed_role_legacy" instead of "zb_set_network_ed_role"?

currently, I started rejoining procedure below the code inside the function "zigbee_default_signal_handler".
.

case ZB_ZDO_SIGNAL_SKIP_STARTUP: {
    /* At this point Zigbee stack:
     *  - Initialized the scheduler.
     *  - Initialized and read NVRAM configuration.
     *  - Initialized all stack-related global variables.
     *
     * Next step: perform BDB initialization procedure (see BDB specification section 7.1).
     */
    m_stack_initialised = ZB_TRUE;
    zb_disable_nwk_security();
    DEBUG_PRINTF("Zigbee stack initialized\n");
    DEBUG_PRINTF("bdb_start_top_level_commissioning\n");
    zb_secur_set_tc_rejoin_enabled(ZB_TRUE);
    comm_status = bdb_start_top_level_commissioning(
        // ZB_BDB_INITIALIZATION | ZB_BDB_TOUCHLINK_TARGET | ZB_BDB_REJOIN
        ZB_BDB_INITIALIZATION
        );
    DEBUG_PRINTF("initialized zb_bdb_is_factory_new(): %d\r\n", zb_bdb_is_factory_new());
    /* WORKAROUND for the ZOI-297: unlock the device's address on ZEDs to fix assertion upon leave request. */
    zb_address_ieee_ref_t addr_ref;
    /* Unlock our address: it will be locked at rejoin confirm */
    if (zb_address_by_short(ZB_PIBCACHE_NETWORK_ADDRESS(), ZB_FALSE, ZB_FALSE, &addr_ref) == RET_OK) {
        zb_address_unlock(addr_ref);
    }
} break;

without calling "zb_disable_nwk_security" function, the zed doesn't success rejoining the network.

[_maibi]

Any update on this?

[Edvin]

_maibi said:

In rejoining procedure, zigbee stack expects the transport key encrypted with the old network key.

 But if you know, based on the description from your screenshot from the first post in this ticket, that the device has lost the key update, it needs to rejoin, but: "If the parent has switched to the newer key, the sleeping device must perform a trust center rejoin". It sounds like this is what happened. Perhaps you need to rejoin the network as if had never joined earlier?

BR,

Edvin

[_maibi]

Edvin said:

Perhaps you need to rejoin the network as if had never joined earlier?

I don't know exactly what it means to rejoin as if had never joined earlier, but if this is the case, the sleepy zed need to rejoin, called a trust center rejoin which is encrypted with tc standard key. 

If the previously transmitted key seqeunce is passed several times, I think it should be a tc rejoin that can be rejoined with the tc default key because the coordinator cannot rejoin unless it has all of the previous keys.

I have tested "zb_secur_nwk_key_switch_procedure" to my nordic test coordinator based on cli_agent_router example.

the step of procedure

1> Coordinator) Transport Key to zed

2> Coordinator) Switch Key to broadcast

3>  ZED) send periodic report data encrypted with previous key.

4> Coordinator) send APS Ack encrypted with updated key (increased key sequence)

5> ZED write updated key in flash memory.

6> ZED) send periodic report data encrypted with updated key.

In this case, zed succeeds in updating the key

But if zed does not receive the key because it is in sleep state, the zed never update new key.

Even though the coordinator in rejoining procedure send Transport Key encrypted with Trust Center Key exchanged in joining procedure, the zed always uses previous key.

nrfcli-join-pwroff-switchkey-rejoin.pcapng

In upper sniffer file, the zed doesn't update new key. I made sleep state by turning off zed for test.

nrfcli-join-rejoin-switchkey.pcapng

In upper sniffer file, the zed updates new key.

Lastly, is the log I uploaded be interpretable?

[_maibi]

Even if you use the nrf coordinator and nrf multisensor examples, rejoin does not work after executing the switch key. 

In this case, there is no periodical request, so it seems that the APS Ack including increased key sequence is not received. But this clearly looks like a problem.

nrfcli-nrfmultisensor-join-switchkey-rejoin.pcapng

[Edvin]

I interpret the rejoin with trust center as a "forget network and join the network as if it was never part of the network". Or do a "factory reset" if you want to call it that.

If the key update is lost because the ZED was sleeping, then it is no longer part of the network, and it doesn't have the correct keys, right? So it can't use the old keys to re-attach to the network. Since there is no limit for how long the device can sleep, the router (parent) can't hold on to that message forever. I am just thinking out loud now, but it can't hold an unlimited amount of messages for all it's children forever, right? The same applies for the coordinator for that matter. How long should the old keys be kept alive?

BR,
Edvin