Is there a mechanism for generate link key for zigbee 3.0?like this.

[teddyzheng]

(JN516x, JN-SW-4170)

If the link key stored in RAM or Flash, application need to create a large table for storage.

How to solve problems with too many nodes?

Like the below？

 --------------------------------------------------------------------------------------------------

Hashed Link Keys are a shortcut for unique link key storage on devices with constrained key table capacity.  They facilitate pseudo-random link keys by hashing the remote's EUI64 with a given Master Key (chosen by the centralized Trust Center and stored in the Global Link Key slot of TOKEN_STACK_TRUST_CENTER's data) using the AES HMAC algorithm.  Derivation of the key can then be done "just in time" for decryption or encryption as long as the Trust Center knows the remote node's EUI64.  Note that because there is no permanent storage of these hashed keys on the Trust Center, there is also no memory of incoming APS frame counters, so this method has a vulnerability of APS replay attacks.  Also note that the hashing only occurs on the Trust Center side, where many keys may be needed.  Other nodes receive this Trust Center Link Key upon request from the TC and treat it like any other "randomly" derived TCLK.

----------------------------------------------------------------------------------------------

OR...

When a link key is needed for decryption,  generte a event or callback to application in NXP stack?

I think this is a easier ways about NXP.

[estephania_mart]

Hello, 

Could you please check the JN-UG-3113 chapter 5.8 Implementing ZigBee Security? I believe you will find all the information you are looking for there. 

Regards ,

Estephania

[teddyzheng]

thank you for your reply.
Sorry, I didn't find the answer to the question in JN-UG-3113.
Maybe I didn't express it correctly in English. I asked one more way: How many zigbee 3.0 nodes can NXP Coordinator access?
When a zigbee 3.0 node accesses the coordinator, the coordinator needs to replace the TCLK for the node and save it. This takes at least 24 bytes of space (16 bytes TCLK + 8 bytes MAC). If the SDK stores this data in RAM, it can store about 100 (and consider other resources such as Neighbour Table, BTT, APDU, etc). If the SDK stores this data in Flash, it can store more nodes, but it won't be much better, because the SDK still needs to save some information in RAM to index Flash.
Only the SDK does not store TCLK to be unrestricted by RAM. TCLK is temporarily obtained by some calculations, such as Hash. Does the NXP SDK have such an interface?
In short, I hope that the SDK can take up as little RAM as possible, or can pass more functions to the Host MCU for processing, because there is a very large RAM and Flash on it, can the SDK be configured like this?
I saw the contents of JN518x in the SDK compilation script, but the official website can not search, can provide some JN518x information?
Thanks!

[estephania_mart]

Hello, 

Sorry for the delayed response, it will depend on how many nodes you have in your network and that at the same time will depend on your memory. 

By any chance, have you tried the extended debug? I believe that you will be able to see the information you are looking for while using it.  

About the JN518x,  please contact one of the distributors available in the Distributor Network|NXP  for further information about this product.

Regards, 

Estephania