There is a vulnerability in legacy ZHA networks in which an attacker does a Trust Center Rejoin (one in which the rejoiner doesn’t try to reuse his old NWK key to rejoin and therefore has to get the current NWK key delivered by the Trust Center in order to re-enter), or provokes an existing device into doing this kind of rejoin, and gets the NWK key of the network sent to him encrypted with the well-known ZHA Trust Center Link Key, thus compromising the NWK key and/or allowing rogue devices onto the network.
Zigbee 3.0 alleviates this problem in a few ways:
Legacy Trust Centers can also prevent the vulnerability discussed at the beginning of this KBA with a simple patch: Alter the TC rejoining policy so as not to accept TC rejoins that use the well-known link key or, if you don’t expect/support device-specific link keys, just disable TC rejoins altogether. This is possible through a new Trust Center Policy setting in our stack/NCP firmware, introduced in EmberZNet 5.7.1 and described in the release notes for all 5.7 versions.
On a related note, in EmberZNet 5.7.2 Silicon Labs updated the End Device Support plugin (which manages rejoins for end devices) so that it would no longer attempt Trust Center rejoins when the TC link key was still the well-known ZHA one, unless users specifically opted in for this potentially vulnerable behavior. For an end device manufacturer using the EmberZNet 5.7.2 or later, the stack should provide the necessary benefits they are seeking.