802.15.4 stack help - security PIB

[hcglitte]

Hi,
Has anyone here worked with 802.15.4 stack? I am looking for guidance regarding security setup of frames.

[ataradov]

I worked with 802.15.4 stacks, and even participated in making one as part of a ZigBee stack. However, I have never seen security features of the 802.15.4 itself actually used or implemented, since ZigBee does not use MAC layer security.

I may still be able to answer some questions.

[hcglitte]

ataradov: thanks. I am specifically using the TI 15.4 stack. I would like to store 2 security keys in the collector (gateway), A and B.
Likewise I would like to store the same keys in the sensor node. The collector does not know in advance which of the keys that the sensor will use, so it must be able to accept both keys. I don't think this scenario is possible, since each device must be put in a security list. An object in this security list has several credentials specific to the sensor node (addresses, security lookup table, key index etc), so how can I specify to accept both key A and B?

The actual use case is that I would like sensors to initially use Factory AES key. Then if the sensor has been authorized by the user, the sensor will receive the Network AES key and start using this. However, the gateway must be able to accept both type of keys, since new sensors may be in an authorizing process (started by a human), and still the network must work with all the other sensors installed in the network.

[ataradov]

If I understand you correctly, your scenario is that a sensor that was already provisioned, may go into the factory-default state again. And you want to be able to receive the frames from that sensor with the factory key. This will create some additional problem, like rolling counter. You can't have the counter be reset on the device.

Accepting both keys from the same address is not possible in a standard implementation. I'm not familiar with TI stack, they may have something non-standard to support this. We did similar thing with the ZigBee stack (on NWK and APS layers) to support similar real life scenarios.

How does the information about the devices ends up in the gateway in a first place? Is it just the factory configuration? How do you plan to replace dead devices?

[hcglitte]

TI did provide an answer to the solution, finally. Now I must test it. They accept to store the same device multiple times in the device table, with their unique keys and frame counter etc. I find the documentation hard to understand, and it requires a lot of research...

Actually no, that is not the scenario I was thinking about. However, it is a good point, since the sensor may be factory reset by the end user (not an ordinary thing to do, but it should still be able to connect and work again by doing the initial authorizing procedure - again!). The gateway will not accept normal data frames when factory key is used (dropped in application layer). The factory key is just used when the user authorizes the sensor for the first time with the gateway. This key is to prevent third party sensors to function with my gateway. I understand your frame counter issue, good point. The gateway has already stored the current frame counter value, and expects a higher value etc... The solution could be that the factory AES key does not implement frame counter security. Then when authorization is happening, the gateway will check if there is a record in the device table for this sensor, and if so it will delete it and store it again as a fresh sensor. When the network key has been delivered to the sensor, both the gateway and sensor can delete the factory key in their device tables for this device, since this key will no longer be used for this particular sensor.

The gateway will receive the network key from server. This way multiple gateways belonging to the customer can have the same key, and a sensor can connect to any of them. The authorization procedure would be like this (maybe): The sensor turns on and will connect to gateway (factory key), provided that customer allows this (button in web GUI). This device shows up on web/app as an unauthorized device. The customer presses a button on the sensor. The web GUI highlights the specific device (after all, many sensors could be present in GUI if the customer has turned on many sensors). The customer names the sensor in GUI. When naming is done, the sensor turns on a LED etc to inform that its done (network key transferred). The possible problem here is that another "criminal" could also have turned on a sensor of his own and pressed the button on his own sensor. The customer would then see 2 highlighted sensors appear in GUI. So the GUI should not allow authorization when more than just one sensor is highlighted, perhaps... Another fact is that when naming is done, the customer would not notice the LED-done if a criminal was trying to authorize his sensor. But the customer would then have to pay attention to this. But if the sensor is not "green" and still provides data, he should be a bit suspicious?! Another solution is to use very low transmitter power (or only accept high rssi) while in this process, in order to stop criminals with their sensor outside the close vicinity of the gateway. However, the customer may like to authorize sensors far away from the gateway... If you have any inputs to this authorization procedure, please let me know!

[ataradov]

I would definitely go for filtering based on RSSI. That's what ZigBee ZLL (Philips Hue and such) does and it works perfectly. If sensors are mobile, then bringing one within 1-2 meters from the gateway should not be a problem.

But keep in mind that attacker will still be able to sniff all your communications, so he will be able to replay the communication to his device. And if device has the same factory key, it will be provisioned with the same network key. There is no real way to avoid this apart from implementing Diffie-Hellman key exchange. All you can realistically do is minimize the attack window and hope for the best.

ZLL used to have a super secret key, which was protecting everything, but that leaked fast.