Security for mySensors

[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 ..