Security

[andriej]

When I was (trying to) develop my own a'la library you've done very well, I was concerned about security of the protocol.
Currently (correct me if I'm wrong) everyone can sniff and send any values to gateway or nodes, which is pretty normal behavior (as it can be done i.e. with RF433MHz protocol devices).

But have you ever thought about how it's possible to make whole thing more secure?
Pre-shared key?
I know the limitation is within the RF24 library, which should allow to put bigger messages thru...

[jka]

Could this we worth looking at?
http://forum.arduino.cc/index.php/topic,88890.0.html

Is it possible to split the encoded messages in many parts and send them using the RF24 library (overhead?)

[hek]

I agree that security is important. But it is also hard to do it right. Especially with the Arduinos fairly limited resources.

It would be great if someone would have time to research the options we have and perhaps do some tests.
I'm particularly interested in:

• Speed (how large keys kan we use and how does the Arduino hardware cope with calculations)
• How much would the message header need to grow
• How do we stop replay attacks?
• How could a key exchange be look like when a new sensor wakes up?
• How should we route encrypted messages? (keep header unencryped?)
• Is it possible to utilize PA_MIN radio transmit power when exchanging keys?
• Support for both encrypted and unencrypted data in the same radio network would also be good.

Here is a link that popped up during previous discussions.
AES- http://utter.chaos.org.uk/~markt/AES-library.zip

[Malx]

100% security is probably to hard for arduino (especially on those 3.3V units). So this type of sensors and actuators should not be used for any critical applications. (Do NOT control your stove).
However, there is still use for something between 0 and 100% security, especially to create subnets that don't have the possibility to affect each other.

[marceltrapman]

Is there something that any of you can think of that would make this project just a little bit more secure?

I am not super concerned about this but I would hate to see my lights go on and off like I experienced with my 433MHz devices...
Or is that not possible?

[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