[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]

Edvin said:

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.

As far as I can understand, trust center rejoin is a common rejoin method to request in case zed lose or miss network key.

Edvin said:

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.

yes it is. I made this condition by turning off zed and perform switch key.

_maibi said:

nrfcli-join-pwroff-switchkey-rejoin.pcapng

After the power is turned on, the zed requests rejoin method without security.

The coordinator responds to rejoining request with success.

and it send Transport Key message.

this message encrypted with Trust Center Link Key which exchanged in joining has new network key.

-> Trust Center Link Key In Joining

Since the new key was encrypted with the exchanged key in joining called Trust Center Link Key, although zed can decrypt the key, but the key is not updated at all.

the zed always uses old key sequence and value.

[_maibi]

In my opinion, firstly, the transport key message should be decrypted with the trust center link key, but it seems that the decryption is attempted with the previous network key.

secondly, I think zed should receive and execute the trasnport key message instead of receiving and executing the subsequent APS Ack message.

What's going on on this issue right now?

[Edvin]

Let me check with our Zigbee team how to approach this issue.

I will get back to you as soon as I hear from them.

Best regards,

Edvin

[_maibi]

Thanks for your reply. I will wait for your response.

[_maibi]

Any update on this issue?

I have tried to test emberznet zed example which is made by silicon labs with nrfcli for a coordinator.

I attach a sniffer log that zed handles properly during the network key change process.

In this log, After switching key, zed tried 3 times of secure rejoining request. and finally tried to unsecure-rejoining request.

The zed also received transport key encrypted with TC-Link Key.

After this, the zed broadcasted Device Announcement encrypted with updated network key.

nrfcli-emberznet-join-rejoin-pwroff-nwkkeychange-rejoin2.pcapng

The Nordic Stack must also behave the same.

And although not exactly, it seems that there is an overflow inside the stack. I am not able to find a way to do anything because I am not able to debug right now.