Security

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

[Anticimex]

One way to off-load the microcontroller would be to use an off-chip security solution. Atmel actually offers something like this.

I have used a similar device when I worked on an Apple accessory. Apple uses a challenge-response mechanism using an authentication chip to identify genuine devices in order to unlock certain aspects of the protocol API to iOS (reading contacts, etc). That device used I2C and I managed to integrate it with a PIC12, so it can be done with minimum HW resources.
I have not looked deeper into how the AES chips actually work (with respect to key management, etc), but I would imagine it could be an adequate tool for the job.

If I get the time, I'll look deeper into this.

[xop]

@hek
Speed - according this http://forum.arduino.cc/index.php/topic,88890.0.html atmegas are capable of performing AES 128bit encryption in under 1 ms, seems promising at first glance
Message length - I suspect the simplest way is to make them 16 bytes
Protection against replay attacks - I think using nonces and checking message integrity with some kind of crc could do the trick
Key exchange - wouldn't pre-shared key solve this issue?

Also I'm not sure if encryption is really a must for this project. As far as I understand the most important thing is to prevent unauthorised control, and for this kind for things there are lots of MAC algorightms which are much less resource hungry than AES. Any opinions?