This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.
Parents
  • I received a reply from our Zigbee team today:

    "Our investigation showed that this seems to be an unhandled case in the stack. We have taken it for further investigation. Unfortunately, the only workaround at the moment is to join the network again, when the key is lost."

    I would also think that another workaround would be to wake up more often, so that the parent has the chance to transmit the key change before it is too late. Does your device wake up regularly? If so, on what interval?

    BR,

    Edvin

  • Hi, Edvin. Thank you so much for answering. I've been waiting for a long time. Slight smile

    Our investigation showed that this seems to be an unhandled case in the stack. We have taken it for further investigation. Unfortunately, the only workaround at the moment is to join the network again, when the key is lost.

    We will provide our product to the hotel, If the pairing is broken, our staff must be dispatched, so it is impossible to launch a product with this problem.

    I would also think that another workaround would be to wake up more often, so that the parent has the chance to transmit the key change before it is too late. Does your device wake up regularly? If so, on what interval?

    I set it to 5 seconds. However, the exact reason is not known, but if the sleep continues for a long time, there is a problem that the data request is no longer sent. I think this has to do with a stack overflow or problem of duplicated resource usage, but I have no idea how to start debugging. 

    1) Is there a resource table used by zigbee stack?

    2) Since the zigbee team has recognized this issue, will this be fixed in the future? If so, how long will it take?

    3) As I said before, The workaround you mentioned only works when using the nordic coordinator. Even if sleepy zed receives a transport key (even after switch key), it always uses the old key. When the coordinator receives the packet sent with the previous key and sends APS with the updated key, sleepy zed starts to use the updated key. However, in this way, the feature of sending a response to the previous key after the coordinator changes the key is a special way that works only in nordic, and the workaround does not work because the other coordinator does not send a response to the previous key after the key update.

    If sleepy zed doesn't receive a response encrypted with updated key, sleepy zed never update his key.

  • Hi,

    I have forwarded this to our Zigbee team, and I am waiting for a response from them to hear if there are any other possible solutions.

    Best regards,

    Marte

  • Hi,

    The only update from our developers is that they are still waiting for a workaround from DSR, unfortunately.

    Best regards,

    Marte

  • Hi,

    Sorry for the delay, but we now have a workaround for you to try. Let me know if you have any issues with it.

    TC_rejoin_workaround.zip

    Best regards,

    Marte

Reply Children
Related