Forums - Low Power RF ZigBee® Software & IEEE 802.15.4 Forum - Low Power RF & Wireless Connectivity

ZStack 2.5.1, CC2530, Using Preconfigured Key without NV_RESTORE

This question is not answered

Posted by iR

on Jun 26 2012 17:04 PM

Big up y'all community brotherhood,

I want to use security by cooking up a tasty ZigBee sandwich with a base of zgPreConfigKeys = TRUE and a dash of SECURE=1. Unfortunately, it appears that I also have to enable NV_RESTORE even though I have no desire to use NVM, and it actually breaks my application for some of my device types.

What's that all about, cats!?!

So, my questions is: has anyone successfully enabled preconfigured key security without having to enable NV_RESTORE? Alternatively, has anyone enabled NV_RESTORE and eliminated all the NVM calls that would normally be made for saving, updating and recalling non-security information, just to support security?

Help me! I'm drowning in waves of bad stack vibes and code that can't keep a beat in time with the dance of progress! :)

Love and hugs,
iR.

All Replies

Posted by zhong ren

on Aug 12 2012 02:01 AM

Intellectual480 points

HI IR

first i appreciate for see you again,and i think you are the one who do the most research on TI stack .and i benefit the codes and idea from your methods about the how to mantain the boring association list whereas i think it is the TI'job .but TI drop them to us.

and about your question about how to carry out security system by the preconfig network key without the NV system.i think it is so difficulty.because i think it is defined by the zigbee specification,and it is not defined by TI. and i confused that why do not you use the NV_RESTORE.i think it is very important for the real product.

maybe you system is very special.for example you want the enddevice to research the new network to join when the device reset.is it right?

and i think if you can not change the security system with the NV_RESTORE.you should try to change your codes to accomplish your current function with the NV_RESTOER,

sorry, i just have limited ability to help you ,but i am so glad if you want to discuss it with me.

thank you

Posted by iR

on Aug 13 2012 19:47 PM

Intellectual590 points

Hi Zhong,

You are correct, my network architecture means that my ZEDs must assume the following conditions are typically true whenever the ZED intends to send a message:

The parent is unavailable
There is a new network
There is no network

The nature of our product, which moves around, means that the device is almost never in range of it's previous parent when it needs to send a message. Therefore, it's much easier to join as if it's a fresh device on a fresh network since a failed join, which is almost inevitable, results in exactly the same process only a more protracted and inefficient rejoin.

To that end, we don't have any use for NV_RESTORE on our ZED because the high mobility means that we certainly don't want to maintain association lists, neighbor tables, address tables and the like.

So, I don't understand why the two are coupled together and I would like to know how to uncouple them without picking through the ZStack codebase...again!

I have another concern, the extent of which I am still uncertain about, but which is potentially worrying: that the implementation is not completely secure. I notice that the key location and format is public which means an unlocked chip or a chip with the relevant MT protocol controls enabled, which some application use, allows the key to be retrieved. Even if the key is moved, the NVM format explicitly IDs the entry.

I suppose you can re-implement some features...but this just raises the specter, yet again, of fixing a broken stack implementation under the yoke of an incomplete specification. It's tiring.

iR.

Posted by zhong ren

on Aug 14 2012 19:58 PM

Intellectual480 points

HI IR i got it .the mobile device is normal on some system .and now our team are doing the research on EMBER stack .and yes the ember is sell to the slicon.and on ember system there is a special role ,it is mobile device .(coordinator , router ,sleep device ,mobile device ).and the ember FAE told me the mobile device is always move .so it can not store any table to it,s flash .and other .it's message is not store in the parent,s table . but we have just start the research on ember system,we have not understand it very clearly. and these days i am busy for the delivery of our zigbee products.and i will do some test on the your problem these weekend.and then if i have some reasults ,i will give your message .

Posted by zhong ren

on Aug 19 2012 23:00 PM

Intellectual480 points

i have do the test :

the coordinator have the NV_RESTORE ,and the enddevice have not.and they all run on default network key system.

-DSECURE=1

-DDEFAULT_KEY= xxxxxxxxxxxx

uint8 zgPreConfigKeys = TRUE;

so ,the enddevice can join the coordinator successfully.but if it reset,it will try to join the new network again,now if some network permit join and have the same security sets.it will join tt successfully

so i am confused that what is exact your problem?

Posted by iR

on Nov 13 2012 18:18 PM

Intellectual590 points

Hi Zhong,

Thanks for your response, sorry I was so long in getting back to the this problem. I had a conflicting configuration that was interfering with my test but you are right, this setup otherwise works perfectly. Happy days!

Right now I am trying to understand why I am seeing Transport Key packets over the air when all the devices on the network have proconfigured keys. I can't seem to get much information on the Transport Key packet yet, so if anyone has any input that would verify whether on not I should be seeing it in this setup then that would be peachy.

Laters,
iR