Security

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?

Anticimex

@hek
Not sure I follow. The key is permanently stored in the device. It is not supposed to change ever once written. If zones are locked, it will also not be possible to change. The personalization is a one-shot operation. Why would you like to write the key on every start?
Sure I could update the personalization sketch to emit the auto-generated key in C-syntax form for easy copy+paste, but there is no requirement that the key is generated by the device. You could use "My secret key" as key if you wanted to.

hek

Ok. Understand.

Anticimex

Perhaps I should post an update on my signing development here.
I have implemented a unique nonce-based signature mechanism using ATSHA204 in the protocol.
I did have to make a sacrifice due to the size limitation of a RF message so the signatures will be truncated. However, analysis show that even truncated HMAC-SHA256 are extreamly difficult to beat, so we should be pretty well covered.

Architecturally, the signing driver will be a "plug in". A dummy signing driver is enabled by default, and signing is only done if requested. I will post detailed descriptions and guides once I manage to optimize the SHA204 library and signing implementation down to fit together with an ethernet GW sketch in a Nano (which I think is the most "crowded" usecase).

The design will allow for other signing backends to be used instead of ATSHA204, but as that is the only HW I got that is the backend I am implementing support for.

marcusvdt

I'm very interested in this topic. Looking forward for the final conclusion.
Thanks.

Anticimex

@marcusvdt I believe the conclusion is here

freerpg

working with security on a daily basis I just wanted to point out.... if they want to get it they will....
I sincerely hope the new additions to the security don't slow down the sensor network.
if someone wanted to make sure no one was listening into a radio broadcast.... I would personally go wired...... I see the security issue for this type of network is at best an authentication problem nothing more.
I love the addition of the authentication as a basic security measure and it just adds to the fine work you are doing.

Anticimex

@freerpg i also work with security on a daily basis and I share your opinion on the matter totally. Hence my decision to leave encryption out of it and focus on authenticity.

Avamander

@Anticimex How far are you with authenticity verification?

Anticimex

@Avamander what do you mean? I consider myself done with security implementation. I don't see a need for more security functionality now when we have both encryption for rf24 and rf69 as well as hmac authentication and white listing.

Avamander

@Anticimex I am not familiar with MySensors so sorry for the questions, who are the "we" you are speaking of having the features? Is this something MySensors now supports?

Anticimex

@Avamander "MySensors" has had support for this for quite some time yes. As you can read in the topic post of this thread. Encryption is discussed elsewhere on the forum.

Security

10

11.7k

11.2k

113.0k