Security

[andriej]

How about some way of key-exchanging?
XORs? Something simplier? Like variable in "Config.h" which would let user to put 'random data' only for his installation, which will make the CRC vary and let gateway/sensors verifying it and not accepting messages with bad CRC (od bruteforced one)?

[hek]

@andriej
Security by obscurity. We better do it right or not at all.

[marceltrapman]

@HEK I agree with you, sort of.

What I learned in sales is that it is better to get started with something than not at all :)

All kidding aside, I would love maximum security but I would also like to have a bit of a 'secure' feeling.

Is there something we can do to get this thing just started?
Problem is that this is not my field of expertise so I have honestly no idea what I am asking.
So, apologies if I am asking too much or too early.

[hek]

To get started, someone could investigate some of the points in the list posted above :)

[Dennis van Velzen]

I think AES is the way to go...

https://github.com/qistoph/ArduinoAES256

Otherwise here's a list with cycle information:

http://www.das-labor.org/wiki/AVR-Crypto-Lib/en

[axillent]

currently project focused on the functionality, not security
we have to choose one or other as a priority
sure project is not designed for critical application like arduino is not designed for critical applications too
software encryption on arduino with combination with NRF24L01+ is possible but cost of this (in time spend and resources required) at current stage of the projects seems not a fair solution

my view to this - somewhere in the future as a next stage of the project development
probably the encryption should be optional keeping simple and cheap devices running
it seams it will be better to use a hardware encryption, for example XMEGA family from Atmel provide such a functionality, but it is not arduino compatible today

[Dennis van Velzen]

Okay, I agree... but this discourages me somehow to use this wireless product as a HA solution. Like for example KAKU (klik aan uit) a one way wireless product operating at 433MHz, mainly for dimming and switching appliances and widely used in The Netherlands implemented an easy hashing solution which makes it a little less "funorable" for somebody to control your appliances...

Just thinking in a simple fast solution... for this...

[axillent]

@Dennis-van-Velzen some one need to be very hungry of you to hack you applications))

because he will need to 1. knew about mysensors 2. be arduino fan 3. knew radio channel used by you 4. knew your device configuration

currently we absolutely safe from random things because 1. nrf24 has its own hardware CRC check 2. we duplicate CRC check on top of it

[hek]

@Dennis-van-Velzen

We're open to contribution in this area. But I would prefer that someone with good insight in security had time to make a somewhat thorough investigation and proposed a solution that brings in real security.

Already today you can easy select your own radio channel and base radio-id to "hide" your communication from your neighbor.

#define BASE_RADIO_ID ((uint64_t)0xA8A8E1FC00LL)

[Dennis van Velzen]

Ok ok... I am involved with some IT security on daily basis. Like programming low level, did some logic analyzing, assembly of electronics and certainly will order a couple of these RF modules to integrate them in my upcoming HA project.

So If I have the parts here I will take a look at security and I fitting some simple additional security layer. Or maybe just introduce some intrusion logic. To be continued I will watch this topic regularly...

[axillent]

@Dennis-van-Velzen intrusion is simple
but you need to know a few parameters which are hard to investigate
in general (if intruder do not knew that you are using MySensors) a complex radio sniffer hardware/software is needed
in case he/she knews about MySensor he/she still will need a complex radio sniffering if you will change BASE_RADIO_ID and radio channel

any you own customization (like hidden logic for message acceptance) to the MySensors source will make intrusion too expensive for regular people

a true security I believe requires DES/AES key exchange. Arduino hardware do not support this, software version require too many reqources

[hek]

@Dennis-van-Velzen

Looking forward to your findings! :+1:

[epierre]

Hello,

There are some posts here to search...
link text

Here is the blys for arduino with Rolling code: link text
Here is some info on Oregon Rolling code : link text
Here is an arduino clone to receive LA Crosse link text

Here is the OOK pde on rotating codes for 433Mhz protocols for Oregon: link text it is either 24 bits or 32 bits in the header.
Here i the OOK pde for RFM12B link text

[MadMac]

Another option is to use different type of radio, like the RFM69W which has onboard AES encryption.
Some of the security aspects raised here are already covered here: http://lowpowerlab.com/blog/2013/10/02/raspberrypi-home-automation-gateway . There are 5 articles in total.
The author also created a arduino library for the RFM69W. (http://lowpowerlab.com/blog/2013/06/20/rfm69-library)

How difficult would it be to support this radio ?

[hek]

Looks like they're using some sw-encryption in the library for the 12B-version. This could perhaps be an option in the MySensors library.

https://github.com/LowPowerLab/RFM12B/blob/master/RFM12B.cpp#L389

[epierre]

@hek do you think their hardware has some power usage optimization a-lurker discussed previsouly ?

[hek]

Sorry, don't remember which discussion you are referring to.

[epierre]

@hek This was this one on : battery usage , I don't know if with custom duino they solve this ?

[hek]

Normal Pro Mini boards was discussed. The optimizations is described in the Battery Powering section on the documentation site.

[epierre]

@hek Yes I saw it, I just wondered if he applied this to his motuino ? nothing is said on this... I just wondered... off topic, is there a possibility to have three batteries and have a regulation pushing to 3.3V in to have greater sensor life ?