LowPowerLab Forum

Hardware support => Moteino => Topic started by: SadE54 on February 11, 2015, 03:27:06 AM

Title: Jamming detection and security features
Post by: SadE54 on February 11, 2015, 03:27:06 AM
Hi,

I'm starting to design an homemade alarm ( using existing detectors), and I'm considering several transmitters. The RFM69 looks very fine for the purpose as well as the Moteino ans it's library :)
But I would like to increase the security and add a jamming detection feature like the one on commercial alarm systems. Here's some idea that could be added to the library maybe :
- jamming detection : several ways here, but the global idea is the gateway/alarm central is monitoring long term median rssi and short term rssi from each node.
- rolling code feature : add unused random data a each real data section to 'salt' before being encrypted by AES . So a same command for example will never be the same .
- Add a frame counter to be transmitted by nodes. It adds 'salt' to the encryption and allows the gateway/alarm central to know the packets lost for each node (better jamming detection)
- Not really necessary because we can program directly the keys into nodes, but a automatic keys distribution to the nodes could be nice :)

Just some ideas here, a starting point for discussing :)
Title: Re: Jamming detection and security features
Post by: SadE54 on February 11, 2015, 06:27:33 AM
Concerning the rolling code security hole described here :
http://lowpowerlab.com/blog/2014/10/02/closing-the-security-gap/#more-1476

If we are in the situation each sent message from the sender need to be acked by the receiver:
you could always use a counter, salt, and a new field another one with a new index to an secret shared array
If the sender frame is jammed, it does not receive any acked.
It's maybe jamming , or not. so the sender  switch to a predetermined index , and fill the new field with it. The frame counter is set to the value pointed by the index
If receiver get the frame, it can see there was not previously acked frames sent by the node and get the array index in the frame.
With this array index , the receiver knows what counter value it must get in the next frame.
Using this concept (probably have to be checked), the receiver knows what counter is really expected and reject spoofed frames