Security

Damme

I've orderd these nRF24LE1 and if we are getting encryption I think it would be wise to be compatible with the embedded encryption: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24LE1

I dont know if its a waste of money but I got 2 for 3€ a piece.

Zeph

@Damme
Keep us informed of your progress!

I haven't wanted to set up toolchain and libraries for an 8051 (with which I'm not familiar), so I've not looked into that chip. And I haven't looked into what its AES acceleration feature consists of.

If it's just a speedup for software AES faster and with less 8051 code and RAM space, then it might still be possible to make use of AES in a chaining mode that makes it a stream cipher. If it's more directly tied into encrypting packets directly as a block cipher, it could be harder to use given the discussion above.

On another forum somebody considering that chip was nudged by Nordic's application engineers to use the nRF51822 instead, as their suggested replacement for the nRF24LE1. It has much better resources for not much more cost (at the chip level). And there is an Arduino derived development environment (RFDuino), as well as an mBed system that might (or might not) be adaptable. I'm more interested in facing the learning curve for ARM than for 8051. (Most developers use the nRF51822 in BLE mode, but it is also supposed to be able to emulate ESB for compatibility with the nRF24L01+)

Good luck!

Damme

@Zeph Damn you! :facepunch: now I orderd 2 nRF51822 also :innocent:
thanks for the heads up :)

hek

I received a nrf8001 BLE development kit from Nordic a week ago. Thought I should play a bit with the BLE part for presence sensing agains my phone (once the new site and 1.4 is launched).

Anticimex

I'm going for this approach. I will use this as authentication chip. I see noo benefit of encrypting the payload. Verifying it to originate from a trusted source on the other hand is essential (for locks etc.). The major problem I see at the moment is the limitation of the payload size due to RF24. The messages are going to have to be split up, thus in some respect reducing the efficiency of the authentication mechanism, but an attacker really need to be stubborn to exploit that.

Zeph

I'm rethinking this thread a bit. A key problem that complicated our discussion was the short packet length. My goal was to add no more than 4 bytes to the packet contents, which implies some compromises.

The new approach I'm considering is having an optional second packet with authentication & replay resistance resistance for the first packet.

A given sensactuator node could be programmed to require this second packet or not, depending on what it controls. If it's required, then the node must receive both the command packet and the authentication packet (within some time period) before it would take actions.

In this way, the regular packets could be unchanged and we would not need to reserve extra space.in the command packet. Meanwhile the authentication packet could have room for more information - eg: rolling code, nonce, hash of the payload of the other packet, as well as the plaintext normal routing headers.

sfam

How abour SipHash? Output is only 8 bytes and:

It adds about 1200 bytes to the code size and uses about 42 bytes of RAM.

daulagari

How abour SipHash? Output is only 8 bytes

Only 8 bytes (64 bits) output is not a plus. MD5 is 128 bits and already considered insecure (partly because of design flaws). Based in this I think 64 bits will be for sure insecure.

See also the rest of this thread, just a message digest is very likely not the best solution.

sfam

See also the rest of this thread, just a message digest is very likely not the best solution.

Of course not by itself... the idea was to use it to implement some kind of HMAC and combine it with a stream cipher or a vernam cipher.

daulagari

the idea was to use it to implement some kind of HMAC and combine it with a stream cipher or a vernam cipher.

See also the earlier discussion, I think a cipher alone can provide authentication without addition MAC.

If you can decode the encrypted message successfully you know that the party you received the message from knows the key and I think that is as good as you can get authentication.

Anticimex

That is a possibility but I believe a benefit of skipping encryption and rely on signature allows a client to ignore the security part (if so desired) which potentially allows for the protocol to implement security by default, i. e. signing all messages. Depending on where the ambition level lies this could increase the amount of traffic (passing nonce back and forth and such) but have not gotten the impression that congestion is an issue.

daulagari

Depending on where the ambition level lies this could increase the amount of traffic (passing nonce back and forth and such) but have not gotten the impression that congestion is an issue.

Yes, if you see no problem with the added data needed for the HMAC, I agree this is no problem but if you combine encryption and a hash the hash is overkill.

So I think you plan is to add say 8 bytes to the message content as HMAC?

From the My "hybrid" gateway thread I understand you plan to use the ATSHA204 that has SHA1 (20 bytes). That would be a good option and you do not have to send all 20 bytes, less bytes would mean less secure but 20 bytes is I think currently overkill for sensor data.

Anticimex

No, it uses sha256 so it's 32 bytes. Sha1 is crackable so it is useless. The messages unfortunately have to be broken into more transmissions. But for proper security I am afraid it is necessary. On the other hand, the only services that should need security on this level is remotely operated locks or something similar.

daulagari

Sha1 is crackable so it is useless.

Well, your standards are pretty high ;-)

From Wikipedia:

As of 2012, the most efficient attack against SHA-1 is considered to be the one by Marc Stevens[34] with an estimated cost of $2.77M to break a single hash value by renting CPU power from cloud servers.

Do not forget to add apart from the hash a "replay-counter" and the mechanisms to check it otherwise opening the locks next day is just a matter of copying the signed message of the day before.

Anticimex

@daulagari Well, wikipedia is not what I consider a reliable source for this kind of info ;) In my work, we have since long forbidden SHA1 usage. That said, using RF24 the security gets somewhat compromised since the messages will be split in parts. But I was thinking of countering that by scrambling the signature and data that are transmitted using a pre-shared algorithm so even if the attacker focused on a part of the message, the attacker will have some trouble figuring out what parts are signature and what part is clear text.

My flow covers replay-attacks by requiring a new nonce for every message. Each message is uniquely signed. They cannot be replay-exploited, nor man-in-the middle compromised unless the attacker knows my secret, and the unique serial of the receiver. Both which are never sent over the RF line. The chip also offers an OTP to protect against physical attack by never exposing the data on a physical pin, but if someone gets access to the Arduino controlling the lock, security on that level becomes rather pointless :)

Zeph

Let's remember the value of the target. How much is it worth to be able to remotely open some blinds? Even for a few who might want to unlock their door via MySensors (vs some other system) I cannot imagine that thieves are likely to spend the amount of time and money it would cost to break in via crytographic means, when there are so many other ways that are cheap and accessible. If anybody here keeps million dollar valued items in their home secured ONLY by MySensors wireless networks, such that a thief would find it worthwhile to mount a major crypto attack to obtain them, then perhaps they should rethink and add other security which is not MySensors based.

So we want reasonable security, within the parameters of our context.

One advantage of the "second packet" approach would be that swapping out a different algorithm would not require any changes to the main protocol.

That said, I want to acknowledge the appeal of signing all messages and leaving it up to the receiver whether it will verify that signing. I'm not sure whether that advantage is worth the effort yet, but I see why it could be good.

Anticimex

I agree on pretty much everything you say, with the additional comment that if we extend the scope of MySensors to beyond the "Garage home-automation enthusiast" some form of commercially acceptable infrastructure, security support is essential. And if we ignore the technical solution to said security support, I believe the first thing to decide is how (not if) to handle multiple packages in a good way.
If the capability of extending the protocol to include several frames in a "message" is in place, the security back-end can be selected more freely, thus also allowing it to be more back-wards compatible, like "optional" signatures and such. It would also allow higher-order encryption, should one prefer that.
I am all for the SHA204-chip so no matter what, I am going to try that out eventually since I think it is such a nice chip, but it might be that I am putting it on hold until the MySensors back-end supports juggling larger datablocks.
The advantage of deciding on signing format (or encryption) early on will enable the protocol to be prepared for this at a relatively early stage, which is nice, because then these features can be enabled "later" without having to roll the entire communications infrastructure, which will be less and less popular, the more mature the system gets. And "large" packet support I think is a cornerstone in this. But that I think is subject for a different topic than "security" per se :)

Anticimex

I have received my authentication HW now and am going to start developing some support for it.
I am going for this approach.

I am using Atmels ATSHA204A and I have also ordered a ATAES132 for encryption (but I am not sure I am going to make use of it, I see little benefit of encryption).

jametller

I found the project very interesting but I am a bit concerned about the responses on the security topic. Responses like, nobody will find out, which is the probability that somebody? who will want to...

I remember the same thing when 802.11 Wifi protocol entered the computing arena and I remember too how the Wardriving fenomenon exploded.

The adventage of mysensors (its easy setup) it is also a drawback from security point of view. In not so many time, I am sure that some "mobile" gateways/controllers will appear, maybe built over raspberry pis that will allow you patrolling cities with your car, searching or scanning for sensors to control.

I started some years ago exploring the Software Defined Radio world and you may be amazed on the quantity o fthings being hacked, you only have to google that. The tink about this is that the effort in resarch you have to do is totatlly null. You only have to google a bit and you find a project on github (like RTL_433) and a usb dongle for 10$ which allows you to sniff the sensors of nearby oregon devices (no knowledge is needed).

There are other works which show how to open cars, or garage doors, and despite there is not a lot of people investigating, there is a lot of work you can download and use. As a matter of fact, Kali linux (a penetration testing linux distribution) is incorporating these tools in its tool arsenal as being more popular amongst hackers/pentesters.

When somebody says that it will be dificult to retro-enginer the protocols, well... Lets look at the following links (and take into account this people is giving to anyone the software they are implementing):

I am agree that the project shall focus on functionality at first, it is good to start having things working first, but for me, is not acceptable having security in the project roadmap and in the top level architecture. Future fields in the messages have to be taken into account, first ideas of arduino variants with a hardware encryption engine have to be taken into account.

I was already making some projects at home with arduino and NRF24L01+ and I found mysensors quite interesting. First thing I thouught was that I would be able to escalate the number of sensors/actuators very fast with the provided infrastrutcure. However, I will not use it at the moment, because escalating the number of sensors and actuators in my house using that stuff, will also increase the severity of the consecuences if somebody palys with it.

hek

@Anticimex

Could the personalization sketch output the keys in a c-form which can be added directly in MyConfig.h?

So.. If key-code is defined in MyConfig it will be written to ATSHA204A at startup. Hope I'm clear enough?

Security

13

11.7k

11.2k

113.0k