• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 1428 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.

ZStack 2.5.1, CC2530, Using Preconfigured Key without NV_RESTORE

iR
Intellectual 590 points

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.

  • 0
    Intellectual 500 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

  • 0 in reply to zhong ren
    Intellectual 590 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:

    1. The parent is unavailable
    2. There is a new network
    3. 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.
  • 0 in reply to iR
    Intellectual 500 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 .

  • 0 in reply to zhong ren
    Intellectual 500 points

    HI 

    IR 

    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?

  • 0 in reply to zhong ren
    Intellectual 590 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