Security

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

[Zeph]

Using block mode AES with 16 byte blocks means either being limited to a single encrypted block (with room for unencrypted network headers), or using two blocks with the entire payload encrypted.

How large are typical MySensors payloads?

Could we use Cipher Feedback or Output Feedback modes to get more flexibility in the size of encrypted payload?

[Zeph]

Getting more concrete, it sounds like there are two approaches to authentication currently in the air.

1. Add a MAC + nonce to a plaintext MySensors command sent to a critical actuator.

2. Add a nonce + checksum to an encrypted command sent to a a critical actuator.

In the latter case there's another issue of whether the network headers are encrypted or plaintext (does a repeating node need to decrypt to know where to forward a message?)

For (1) what kind of MAC (message authentication code) would you suggest? A long but secure hash would be too much for our tiny messages.

For (2) let's consider sending a 32 bit sequence + a 32 bit CRC of the payload + sequence. The sequence is your nonce. If after decrypting the CRC matches, then you decrypted right. If the sequence is within N future iterations of the last successful one, accept it (to handle N-1 lost packets). Iterate the sequence (which could be an incrementing integer or a PNG or whatever).

The CRC could be replaced with a fixed value - if it's correct in the decrypted message, all is OK.

That's 8 bytes. A lot. How about shortening one of those values to 2 or 3 bytes?

Or how about considering that successfully decrypting the sequence (to within a range) is sufficient evidence of using the correct decryption key AND of not being a replay.

A very simple approach: Add a 32 bit incrementing number to the end of the payload (including or not including the network header), then use a stream cypher (perhaps AES in one of the modes suggested in my previous msg) to encrypt the payload + sequence. The sender always increments the number, the receiver only accepts a message if it's within 64 counts of the last successful receive.

[Yveaux]

@Zeph said:

How large are typical MySensors payloads?

7 bytes header, + payload.
For 1.3 the payload is ASCII text (normally)
For 1.4 the payload depends on the datatype, e.g. 1 byte for uint8_t, 4 bytes for long.

The header you should probably not, or only partially encrypt as it is required for routing the messages.

[Zeph]

@Yveaux
So a command to raise the blinds could consist of:

7 bytes of unencrypted header
N+1 bytes of encrypted content:

• 1 byte of data to control the blinds
• N bytes of sequence/nonce/validity check for

This is assuming that we come up with a stream cipher and that we do not encrypt the header. If we used AES in block mode, we'd pad with zeros to 16 encrypted bytes.

If N=8, there's a lot of overhead to protect one byte :-)

But that's OK

[daulagari]

Coming back to what @axillent said:

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

Things have become more easy using the Wireless nRF24L01+ sniffer for MySensors.

On the blog from @Yveaux you can also find a link to Promiscuity is the nRF24L01+'s Duty post which indicates only two address bytes are needed. Furthermore there is information on using an AMICCOM A7125 chip that does not need address information at all it seems.

Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.

[Yveaux]

@daulagari said:

Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.

Can also easily be done using a regular nRF24L01+... I'm thinking of integrating it in the sniffer!

[Zeph]

@daulagari said:

Things have become more easy using the Wireless nRF24L01+ sniffer for MySensors.

Slightly. If you know the first 4 bytes of the address, it's easy to find the fifth anyway. That sniffer doesn't help you find those 4 bytes tho.

On the blog from @Yveaux you can also find a link to Promiscuity is the nRF24L01+'s Duty post which indicates only two address bytes are needed.

That does help you find the full address, given enough false hits over time.

Furthermore there is information on using an AMICCOM A7125 chip that does not need address information at all it seems.
Only things still need is a spectrum analyzer for the 2.4 GHz in max hold mode and you know the channel.

That could make it easier still. Or as I mentioned one could use SDR (software defined radio) to discover both (spectrum analyzing and raw packet decoding).

It's definitely feasible to break in to MySensors, with enough technical expertise and enough motivation. And a close enough location to do the monitoring and spoofing.

The same could be said for opening my automatic garage door, rolling codes and all.

But then, somebody with enough motivation could just break a window and enter while I'm gone too. It's all a matter of the costs, benefits, and odds.

We could shift the odds more in our favor with a stream encryption, at some cost in complexity and performance.

[daulagari]

@Zeph : Fully agreed, only point I wanted to make is that things have become cheaper.

Would be good to keep this thread updated with the latest on what are the costs I think.

[Zeph]

@daulagari
Yes we are agreed.

I am continuing to think about this. I think that what makes the most sense is a stream cipher which can encode 1..32 bytes, and which can include or exclude the network header. (Versus a block mode like plain AES in ECB mode, which can only encode 16 byte chunks). We could use some of the chaining modes to convert a block cipher to a stream cipher, or could just use a pure stream cipher.

We need something which has a small footprint, in code, RAM and time.

I'm currently leaning towards combined authentication, confidentiality, and playback resistance, even tho the middle aspect may not be critical. Having a large message digest isn't going to fit - the system also needs to minimize the data added to a packet.

I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption. The counter could be initialized to a random value at first and would increment with each new packet. When decrypting, the last 4 bytes would need to be in the range N+1 to N+m, where N was the last valid received counter and m is the window. If fewer than m packets are lost, we will resyncronize automatically with the next valid packet. There would be a way to transmit the shared key and initial counter value to a node, given physical access.

I think we could make it a very difficult project for a technically sophisticated neighbor to spoof (or even read) packets, without breaking and entering to physically compromise the system. That's good enough.

Given the playback resistance and given a stream cipher, I'm leaning towards leaving most of the network header in plaintext, so that repeater nodes can quickly repeat them.

And I consider this low priority for myself. The low degree of damage a cracker could cause, combined with the low chances that a nearby neighbor has both the technical expertise and the incentive to crack my system put this type of attack way low among my security concerns. Stealing the bicycle in my back yard would be much easier and more painful than raising my blinds.

I'm very amateur at this, so I'd be glad to hear other approaches and ideas. The creative synergy is one of the payoffs of this for me.

So I see the security question as technically interesting but not pragmatically vital at this time.