Security for mySensors

[dzairo]

Hi.
some time ago we talking about security .
I talking with my old friend and he working with linux system .. we talking about AES , signed message .. etc ..
MySensors and many other Arduino board used ATmega328 or different ATmel 8-bit chip .. it's easy , cheap .. but not fast .. and security on this chip is really problem.
and if we use nRF24L01 then this RF module have max 32 bytes buffer then message (payload) is not possible easy to signed because we have small Tx buffer..
use external chip is OK .. but more expensive .. more complication .. and need hardware upgrade board..
then question is why protect communication??
and for who we want protect communication.. for NSA, KGB, GRU , MOSSAD, MI5 , MI6 , MI7 ...etc .. or only my neighbours or some guys who live near my house.. and know detect my signal .. received it .. and attacked me .. small network..?
then we find this solution .. use 4 bytes from 32 byte buffer.. 2 bytes - random number , 2-bytes 16bit CRC of all 32 bytes buffer .. and make XTEA.. only for this 4 bytes .. and this encrypt random number with CRC only .. payload is not encrypted .. and send ..

why we need encrypted payload ??? outer temperature , internal temperature , humidity , garage door close - open , light , mail box .. etc .. doesn't matter if see my payload .. I need to know only if received message is from my sensor or not .. if sensor received message (open door , power up light ..) etc .. is from my controller ..
then with XTEA we can easy sign complete MySensors communication .. but payload buffer will be 4 bytes less ..
yes of course this is not wery secured because 16bit random number is small but we can use random number 3-bytes and 1 byte CRC.. (we don't need big CRC because nRF24L01 protocol use own hardware CRC)..and there will be more combination to decode our random number.. but still we don't know signature (XTEA key) .. yes with fast computer we can find XTEA key too .. but .. as I write .. for who we want protect payload..
and this solution is perfect for secure communication between sensor with more gateway.. because all sensor have own secret key .. and gateway store this key (while registration) to memory .. and use .. then we can with one key fob controll more gateway .. and gateway don't need to be identical secure setting..

this is my idea .. I look to source code to MySensors .. and is possible update this solution.. what do you think about it ??

best regards..

[hek]

http://forum.mysensors.org/topic/1021/security-introducing-signing-support-to-mysensors

[pit007]

@dzairo This is also my prefered solution - perfect for cheap, small and battery powered devices. I don't can spent energie and space on the PCB for extra chips and overall - I don't can replace my hardware in some weeks. Not all nodes have there own designed PCB, some are based on original Arduino minis. Blockencryption can be done in a softwareupdate - individual for each node (exept routers and GW)!

In general it's clear, that the 'integation' of an new, 'homeless' sensors in your private network needs a teach-in step. Something must be exchanged between the both sides and it must be keept a secret.

In my case I encrypt the hole payload (and more) by a key in the node (actual the same in all nodes) - And I don't need extra bytes for the encryption in the telegram!?

• Pit

[dzairo]

hehe.. hmmm .. ok .. there is no problem encrypt head , payload or complete tx buffer .. but if you not generate random number then your data are same like previouse if no change , and how prevent repeated data , etc .. what encryption method you use? aes , des , or? .. I test xtea .. 1.4ms time to encrypt 32bites - yes 4 byte .. hmm

write more about your solution..

[Anticimex]

If you want encryption that much, why don't you just use an rf solution that does it for you. RF69 for instance offer AES-128 encryption. It is not implemented in the driver we use currently, but you are welcome to do it if you feel it adds any value it ought to be really simple as AES is a symmetric key scheme.

[dzairo]

ehm.. rf69 .. yes have aes .. but .. if start sensor you must send key to rf69 from mcu .. and this is problem .. if rf69 will have eeprom memory and user can not read this memory only write then will be better ..but right now .. this is my idea .. xtea is easy .. I don't know .. I just thinking about it ..

[Anticimex]

@dzairo So fuse your arduino to prevent memory readback then. I still fail to see any benefit of encrypting mysensor communication anyway. Any attacker with any brains will still figure out the nature of the communication even if they cannot read it in clear text so encryption the way I see it adds nothing. Most sensordata is binary in nature. Authentication is much more important and it is already solved.

[dzairo]

hehe.. I'm not write about encryption .. I use xtea for authentication ..generate random number .. encrypt with xtea ... send with mysensor data .. data will be same .. only random number will be encrypted .. if will have some time then try something ..

[Anticimex]

@dzairo sorry. I do not understand your question. I have implemented signing and authentication for MySensors. It uses HMAC-256 with random nonce and white listing with unique serial. That should be secure enough for any purpose unless encryption is a requirement.

[dzairo]

ehm... your solution is best of the best .. but use more rf resource .. and need external hardware .. I talking about more easy and cheap solution.. ..

I waiting for first example of firmware and hardware .. or you have it already for test ??

best regards..

[hek]

@dzairo

You don't need any external hardware. We provide a software driver that does (almost) exactly the same as the hardware (only a bit less good randomisation).

Xtea is just a block cipher, does not add any real security.

I would suggest you read the long text @Anticimex wrote were he explains the basics of security.

[dzairo]

sorry .. you send link .. I read it, but not very well ... you use software hmac-256 . how is it fast ? hmm.. I not tested it .. but this will be implemented in new release 1.5 ?? ehmm.. why you thinking that xtea is not good to use for authentication .. if generate 24bit random number .. then make 8bit crc and use xtea .. receiver see .. sensor number id .. read key from memory .. decrypt random number .. make crc .. compare .. if match then know that message is from correct sensor .. if use ring number then prevent to reply attack.. all do this in one packet .. less rf sources ..
best regards.

[Anticimex]

@dzairo how can you use random nonce without exchanging it first? My solution handles this. Please evaluate it and study the performance of the solution that implement all that you ask for. I think you will find that it had a very modest impact on performance while remaining a high degree of security and flexibility when it comes to payload sizes. I believe your solution will not be able to provide the same level of security if you intend to pack nonce, encrypted data, sequence/serial number, packet header and payload in one single 32 byte rf frame.

[pit007]

@dzairo Late, but to answer your question: It's also XTEA with a compiled master-key and variations over node id and rf freq. And you are right, on repeated date without random input it's a bad solution... Thx for hint... -Pit

[dzairo]

@Anticimex .. sorry but I have very poor English..
Your solution is better , more secured of course .. this is fact ..
My solution is more easy , not very secured .
My solution use from 32bytes , 5bytes for : random number 3 , 8bit crc 1 , 1 for cycle number .
on firs generate number , then make crc from this number, use xtea , cycle number increase .. now mysensor protocol use 27bytes payload .. - 5bytes then final size of payload will be 22 only. to packet add my encrypted random number with crc + cycle number .. and send ..
gw receive , decode random number with crc , make own crc and compare if same then know that data are original , and check if incoming packet have cycle number higher than stored in memory for actual node .. and store new cycle number .

it's standard like keyfob what you use in car .. yes there is more problems .. but is possible to solve .. if gw reply to node random number then node know that gw is mine . and do it again with different random number .. etc.

forget it .. your solution is better..

[dzairo]

I don't know .. but ideally is if nrf24l01 set ack with payload .. and this payload will contain random number or rtc time .. encrypted with xtea . all node or repeater if receive ack then got this number or rtc time .. and use in next packet .. nrf24l01 chip can make 50%work alone ..

node if send data packet then wait for hardware ack . and this ack can contain payload .. this payload will be starting point ..gw will generate actual payload for ack sequence ..

It's just idea ..