Security

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

[Zeph]

In another thread it was mentioned that the JeeNode (which uses the RF12b or RF69) already offers XXTEA encryption of on-air packets using an ATMega328p. So it's definitely do-able within our resources, and XX-TEA is probably sufficient - who's going to spend the resources to crack that just to turn on some lights?

There are a lot of protocol questions tho, and the answer depends on your imagined scenario - what are you protecting against, how much incentive is there for an attacker, how serious is your exposure if they get through, etc. There is no one-size-fits-all security design; instead you design it to fit certain scenarios and not others.

So let's start by accumulating a list of "attack scenarios", then deciding which ones we want to thwart, and design from there.

---

Scenario 1: A major terrorist is using MySensors in their home automation, and the Mission Impossible team asks the NSA to crack the system so they can turn off his/her hot tub pumps at a given time to get the target to enter the fuse box room at exactly 7:02 while an agent slips a note to the luscious companion waiting it the hot tub.

Low priority. Not low hanging fruit. :-)

but more seriously

---

Accidental interference with bogus packets (from noise or other devices) being received as legitimate, as happens with 433 MHz devices. The use of 127 channels at 3 speeds with 5 byte addresses and 2 byte hardware CRC makes this unlikely.

Accidental jamming - change channels.

Deliberate jamming, Not much we can do on the protocol level to avoid denial of service attacks. Let's skip that.

A neighbor uses MySensors and they accidnetally discover they can monitor your packets. (Not likely to mean much unless they are using MySensors). Change addresses or channels.

A neighbor not using MySensors wants to monitor your packets; they can program nRF chips to do so. They will have to do some reverse engineering to figure out what the contents mean (if unfamiliar with MySensors). Is this a problem?

A technically sophisticated neighbor wants to control your actuators: turn on your lights, open your blinds, etc They scan to find your channel and speed, they use SDR or other tricks to discover your address, and then they can then monitor all your packets. They know or find MySensors on the web and decipher the packets. They then monitor and discover the packet which opens your blinds in the morning, and can resend that packet at a time of their choosing. Is this the key attack we want the design to block?

What are some others? What do we need the design to handle?

[daulagari]

@Zeph: I think indeed that your "technically sophisticated neighbor" scenario is what first comes to mind.

That matches @xop:

most important thing is to prevent unauthorized control

But adding only a MAC and nonce (authentication only) means adding payload.
To limit the amount of additional data to be send over, I think adding nonce/sequence number and encryption with a shared key is a better idea.

[xop]

@daulagari said:

But adding only a MAC and nonce (authentication only) means adding payload.
To limit the amount of additional data to be send over, I think adding nonce/sequence number and encryption with a shared key is a better idea.

I think it's important to evaluate how much payload will add MAC, because in case of encryption (at least AES) you'll have to round your encrypted payload size to 16 bytes minimum, as far as I understand, and you'll need to add the very same nonce and some kind of crc into message to add randomness and integrity check.

Considering XXTEA - it seems even slower than AES, according to this: http://www.ei.ruhr-uni-bochum.de/media/crypto/veroeffentlichungen/2011/01/29/lw_speed2007.pdf

[Zeph]

@xop said:

Considering XXTEA - it seems even slower than AES, according to this: http://www.ei.ruhr-uni-bochum.de/media/crypto/veroeffentlichungen/2011/01/29/lw_speed2007.pdf

Good find. In his implementation AES was substantially faster (at three times the code size) than the related TEA and XTEA.

Another source suggests that XXTEA may be somewhat more efficient than TEA/XTEA as size increases, but I doubt it overcomes the speed advantage of AES.

So within the bounds of that paper, the advantage of XXTEA would be 8 byte vs 16 byte blocks, and smaller code; but AES is faster.

Another concern is RAM footprint. I think I saw that XXTEA used substantially less RAM than AES on the AVR, but I'll need to look that up again.