Security

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.

Add a MAC + nonce to a plaintext MySensors command sent to a critical actuator.
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.

marceltrapman

@Zeph said:

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

This is vital imho. We have to be pragmatic about this.

I see it like this:
I have camera's around the house. No alarm. Proper locks.
The 'recreational' burglar comes by the house, sees the camera's and moves on.
The 'amateur' burglar will think that it might be worth a shot. Next he sees the locks and he/she will split because it is too difficult and risky.
The 'professional' burglar will go in anyway, whatever I have installed.

daulagari

@Zeph said:

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

Yes, also I am more "scared" about other things than people accessing the mysensor network but I do not need remote controlled locks :smile: For me, thinking about it is good fun that can be hopefully helpful in the end.

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.

Based on streamciphers the ARCFOUR assembler implementation looks like a nice pick. The problem however for stream ciphers is:

The starting state (seed) needs to be different for every packet sent
The seed needs to be known by sender and receiver but must be secret for others
Authenticity is not guaranteed, the message contents can be change without problems and that while authenticity seems to be more important than confidentiality

This makes me think that for a "good-enough" streamcipher too much additional components are needed like a hash to get ourselves a seed and additional code/data to improve authenticity.

I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption.

A counter is largely predictable and a generic problem with sensor data is already that it is highly predicable making a "known plaintext" attach easier. You need some kind of counter to prevent replay attacks but provided the counter is encrypted, the acceptance range (N+1 to N+m) is not too big how much would we really need?

Given the problem I see around a streamcipher implementation and a "known" plaintext I think the drawback/overkill of blockciphers that the block size is too big (64/128) byte might become handy so we can fill up thing with random padding.

Had a look at XTEA and think I like it because of size and performance. But I much better would like that there is some kind of version or cipher field (four bits?) that specifies which cipher is used so things can be mixed and upgraded.

Yveaux

@daulagari Agree; I would always keep the option in to send both encrypted and unencrypted messages over the same network, e. g. By using a encryption - type value in the header. For development we would make it very difficult to analyze the (on air) messages when everything is always encrypted.

Damme

I do not know how much memory it would take, but why not use frequency hopping? Would make it an ass to intercept.. But I do not know how practical it is, I have zero experience with it.

daulagari

why not use frequency hopping

The algorithm for the hopping will be open-source I hope if it is part of MySensors, so that is easy to crack unless the hopping sequence is scrambled by a key and then again you need some kind of crypto to do the scrambling...

Zeph

@daulagari said:

I'm thinking of using a 32 bit incrementing counter appended to the end of a payload before encryption.
A counter is largely predictable and a generic problem with sensor data is already that it is highly predicable making a "known plaintext" attach easier. You need some kind of counter to prevent replay attacks but provided the counter is encrypted, the acceptance range (N+1 to N+m) is not too big how much would we really need?

I'm not sure if you wind up agreeing that an acceptance range of N+1 to N+m (out of 2^32) is sufficiently robust (for our purposes) or not.

I was suggesting that the 32 bit value be appended to the end of the payload, so it would not make for a predictable start. And "predictable" is relative - an attacker doesn't know where in the 32 bit space you started your counter, so it's a weak sort of initialization vector in addition to the cipher key per se. The more predictable contents of a packet is probably a larger weakness, if known (or almost known) plaintext attacks are the concern. However, I think that cracking a decent stream cipher under these circumstances is non-trivial. Somebody with that level of skill and determination would probably not waste it raising my blinds.

I started with the idea of a 4 byte random number and a 4 byte counter, but 8 bytes of overhead per packet seems like a poor tradeoff. So I thought of reducing each to 16 bits. Then I thought about allocating a varied number of bits to each. Then I thought - starting with a random 32 bit number and then incrementing it is a fairly reasonable compromise for a modest security system like this. I also considered using a PRN generator for the sequence instead of a counter, but if the encryption is decent, that would not help the security much, and it makes testing for validity much slower.

The first goal is to authenticate and prefent playback attacks; confidentiality is secondary. And this is not going to be used in banking.

Given the problem I see around a streamcipher implementation and a "known" plaintext I think the drawback/overkill of blockciphers that the block size is too big (64/128) byte might become handy so we can fill up thing with random padding.

We can pad, but the packet is only 32 bytes (1..2 or 1..4 blocks). If we wanted to leave the network headers in plaintext, then it gets worse; with AES, that leaves you with exactly one 16 byte payload - no room for two. I'm not liking that as well as a stream cipher, but it's a judgment call rather than a fact.

Had a look at XTEA and think I like it because of size and performance. But I much better would like that there is some kind of version or cipher field (four bits?) that specifies which cipher is used so things can be mixed and upgraded.

I'm not thrilled with needing to implement multiple ciphers in small machines; even one takes up signficant Flash and RAM.

Of course, you could say that all of a given network would use the same algorithm, in which case the "which cipher" code only confirms they are using the same one. But in that case, you could just silently choose the same algorithm for all your nodes, and that's just one more thing an attacker would need to discover. If they steal one of your nodes and read it - game over anyway.

Currently, I think just getting one encryption protocol and algorithm implemented is challenge enough.

daulagari

@Zeph said:

The first goal is to authenticate and prevent playback attacks; confidentiality is secondary. And this is not going to be used in banking.

Yes I agree first is authentication and and preventing playback attacks

To do that reasonable secure you need either a keyed-hash (HMAC) with sufficient length and a counter with sufficient length or block cipher with a (shorter) counter.

For the HMAC + counter approach 16 bits each is pretty short I think, remember that apart from passive scanning a "hacker" can also actively scan sending "probe" packets and see what the response is, a well known attach for 802.11 WEP. Need some more time to come up with some numbers.

Re-reading my story above I noted that it was based on wrong a wrong idea.
Yes, with a block size of 64 bytes you need already two+ packets, with 128 (like AES) even four+. That sounds not attractive and likely overkill. On AVR-Crypto-Lib I see no block ciphers with a block size of 32 bytes or smaller...

I'm not thrilled with needing to implement multiple ciphers

No that is for sure something that I did not have in mind for nodes but maybe ... for the gateway. If somebody likes to do locks one day, the requirements will be higher than authentication and preventing playback and it would be good to be future proof for that.

Security

19

11.7k

11.2k

113.1k