• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 382 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC2530: STACK 3.0.2 - Reassociation of End Device to Gateway where it was removed.

CC2530: Rejoin Requests should not be encrypted ? - ZSTACK 3.0.2

Mario DW
Genius 3145 points
Part Number: CC2530
Other Parts Discussed in Thread: SIMPLELINK-CC13X2-26X2-SDK

 

You indicated in the related thread that "Rejoin Requests are encrypted messages,".

Figure 2.106 of the Zigbee Specification 05-3474-21 suggests an unsecured Rejoin request in Intra-PAN portability.

ZED operation is detailed in "2.5.4.5.5 ZigBee End Device", also for Intra-PAN portability.

Section 4.6.3.1 also talks about joining a secured network:

"The joiner device shall decide which PAN to join and shall issue the NLME-JOIN.request primitive to join 11239 that PAN. If the joiner already has a network key for this PAN, the SecurityEnable parameter for the NLME-JOIN.request primitive shall be set to TRUE; otherwise it shall be set to FALSE. As shown in Fig11241 ure 4.26, the NLME-JOIN.request primitive causes an association request or rejoin request command to be sent to the router."

So it seems that the (re)JOIN request should not be secure if the PAN is different from the original one.  When the Coordinator has been reinitialised, its PAN has likely changed, so the ZED should not attempt a rejoin using NLME encryption, but rejoin unencrypted.
That would enable the coordinator to issue a leave request.
The IEEE address of the coordinator allows the ZED to filter out irrelevant coordinators.

So in this perspective, should the ZED have issued an unsecure rejoin request in the coordinator?  That would resolve the consequences of a reinitialised coordinator automatically.

  • 0
    Genius 3145 points

    I checked the logs:

    - The new PAN ID is 0x181e, and the ZED uses an encrypted Rejoin request using 7ccf21f45b47ba92b10db7c537f3d725 as key;

    - The old PAN ID where the key 7ccf21f45b47ba92b10db7c537f3d725 was valid is 0xbef8 .

    So my reading of the specification indicates that the rejoin request should have been unencrypted.

  • 0
    TI__Guru**** 219977 points

    Hi Mario,

    A secure rejoin request requires a NWK key, regardless of Pan ID.  Trust Center rejoins could be performed and are unencrypted but are typically for joining devices which no longer have NWK key information, in which case the active TCLK is used.  If the ZC does not allow for unsecure rejoins then the ZED attempting this method could allow for a Leave Request to be issued, but this would also have NWK security.  Please refer to the macros/variables described in the link.  The Specification excerpt you described has to do with a new join in which the network key has been pre-configured.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3145 points

    Ok, there ill not be a leave request, but "If the router refuses the joiner, its association response frame or rejoin response frame shall contain the association status field set to a value other than 0x00, and, after this parameter reaches the ZDO of the joiner in the NLME-JOIN.confirm primitive, the joiner shall not begin the authorization routine."

    I agree that the excerpt "If the joiner already has a network key for this PAN, the SecurityEnable parameter for the 11240 NLME-JOIN.request primitive shall be set to TRUE;" corresponds to a new join with a preconfigured network key, but the part "otherwise it shall be set to FALSE." applies to the other cases.
    It is also relevant to rejoins because the next sentence in the specification mentions rejoins.

    Your link is usefull for newer stacks, but in ZSTACK 3.0.2, "BDB_SECURE_REJOIN_ATTEMPTS" does not exist,

    I've browsed through the code, but the do not seem to be any settings for this in ZSTACK 3.0.2 .

  • 0 in reply to Mario DW
    TI__Guru**** 219977 points

    The same could be said for zgAllowRejoinsWithWellKnownKey, the rejoin procedure has been greatly improved for SIMPLELINK-CC13X2-26X2-SDK.

    Regards,
    Ryan