Security

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

18

11.7k

11.2k

113.1k