[security] Introducing signing support to MySensors

[rvendrame]

@Anticimex , fantastic take. One question so far --- Is (or will be) possible to a gateway working with both signed and non-signed messages? I don't have OTA, and to re-work all my existing sensors it will demand a considerable effort.

Having security on further sensors is anyway amazing.

Thanks a lot!

[Anticimex]

@rvendrame Thanks.
Yes. You can mix everything. You can have some nodes which require signed messages and some who does not in the same network at the same time. This should also work though relays (sign messages can pass relay nodes that are incapable of signing).
The gateway will keep track on which nodes that require signing and which who don't, and do signing accordingly.
So you can leisurely introduce signing only on newly added nodes or only activate it for the existing nodes that you want it on. It should even be possible to keep old nodes without reflashing their firmware (although that is a usecase I have not tested).

[Anticimex]

EDIT: Moved the location of the SHA204 personalizer in the first post since it has moved in the tree.
Also, I have noticed that recent activity on development branch seem to have broken the signing support. I am investigating the issue.
Life on the development branch is 'hard'. I am sorry about the outage, but these things are to be expected when many developers work on the same code piece and are not fully in-sync with each others activities. I will post here a SHA to a known "good" state once I have sorted the issue. I encourage all to test this out once I do, so we can get more test-coverage on this quite big feature in the library. Once we have it stabilized, it might get included in a "v1.5" of the library and then live a happy stable life on 'master' :)

[Anticimex]

Now a patch is merged to 'development' for the issue. Please give it a go. I need help in testing. I have tested it successfully with the SecureActuator sketch and the ATSHA204 signing backend.

[Dirk_H]

@Anticimex Wow this is really good work AND explanations.

I'm thinking about one issue: Lets assume I use a remote as garage opener. Now on a bad day I loose this remote. Is it possible to block the commands of the remote. I.e. have a blacklist like thing? Is it even possible to (in theory with the used components and in practise with the current code) to identify each SHA device? I.e. does Bob know "the message comes from someone I turst" or does he know "the messages comes from allice (which I trust)".

Obviously I'd be unable to change the PSKs because I need to lock the PSK Memroy area... So I'd have to throw away all devices for this approach - right?

Thanks for your great work again.

[Anticimex]

@Dirk_H Thanks!
Well, the ATSHA itself does support this kind of thing. But it is difficult to make it generic enough to open up for other backends to share the same functionality. It IS possible to skip locking the data area and still have signing working though. But that obviously opens the possibility to physically attack the node and read or replace the key. However, if someone got physical access to your node, they already have physical access to your garage. So the door would already be open.
So if we assume you skipped locking the data section of the ATSHA204 you could bring down the node and revoke the PSK by writing a new one. That would invalidate any "rouge" nodes with the old PSK.
Personally, I do not think I will ever lock down the data section since it is anyway only by physical access to the device you can rewrite or read the PSK and with physical access to the node..well...you are pretty much owned then in any case.

[Dirk_H]

Ok thanks for clarification Anticimex. I meant if you have a remote to open your garage and leave it in your car which e.g. gets stolen. However it good that you pointed out that locking the device is no "must". I think in many applications it might be even contraproductive.

locking the device would only prevent the thief from copying but not from using - Which would have higher importanance in this case. Maybe this lokcing feature is generelly more used for dongle like applications.

[Anticimex]

@Dirk_H yes if you have a handheld device that moves about, I recommend locking it to prevent key tampering in case it is lost. That makes it a black box.
I do understand what you mean. My point is, you have a node in the garage that is the actuator. You do not want your actuator to be tampered to accept different keys (or having the firmware replaced entirely). So you need to protect you actuator in any case. Looking the chip data in the actuator then has little benefit since if someone had access to it, they could just flash a firmware that ignores signatures.
But your keyfob is "public" so it is the typical part you want to lock. If you loose it nobody would be able to exploit it to transmit valid signatures if you replace the key in your actuator. I will consider updating the post with a number of use cases and highlight when data locking is advisable and when it is not.

[Anticimex]

EDIT: I have added a "usecase" section outlining three typical usecases. In summary: keep data section unlocked on all nodes that you can guarantee will be tamper-free. Lock data area on all nodes that require (or do) signing and are located in a more "volatile" environment (where they can be stolen or tampered with).

[rvendrame]

@Anticimex, let me try to get a holistic view:

• I think commercial solutions like z-wave have even less security (as they are design to work across multiple vendors / solutions, so no pre-shared key). Have a look on this http://research.sensepost.com/cms/resources/conferences/2013/bh_zwave/Security Evaluation of Z-Wave_WP.pdf

• The use case discussed here (lost garage remote): If I remove the remote from my automation software, the remote will not be able to open my garage, right? What you are saying is that if someone finds the remote, by hacking it it should be possible to obtain the pre-shared key (but it involves a considerable effort , maybe even SMD de-soldering and so)... Correct?

• Ok, now that someone else have my pre-shared key (and assuming that I didn't change it): He/she needs to sniff into my MYS network, learn MYS protocols, monitor the traffic for some time, and with all that, it should be possible to emulate the GW telling the garage door to "open".

• I guess the same applies to my wi-fi network --- If I loose my iphone, someone can break it and retrieve my router wi-fi password, connect into it, and unlock the door via my door lock App, right?

Sorry if those questions sound too stupid --- I'm new to all of this things... But I think MYS is primarily targeting for home DIY users, so if we achieve the same level of a house alarm for example --- wouldn't that be enough for a first step?

[Anticimex]

@rvendrame In security, there are no stupid questions.
Regarding the lost keyfob case, if we assume that you use the ATSHA204 device (not the software emulation) and you have locked the device, the PSK is unobtainable. Even if the device is picked apart, there is no way to extract the PSK from the ATSHA204 device.
However, also assuming that you do not alter your PSK in the "receiving" end, you are still at risk, much in the same way as your car is at risk if you loose the keyfob to it.
Also, if you use the same PSK on other parts of your system (like your GW) an attacker could pick the stolen ATSHA device and put it in their own device to allow it to transmit signed messages to any node in your system until you revoke the PSK in your GW (and corresponding nodes).
This is unfortunate, but with the limited memory we have in the current design, it is unfeasible to have a GW (or a node) keep track on white and/or blacklisted devices. I have not been able to figure out a way of doing that with the ATSHA in a way that does not prevent a SW emulation of the feature that is acceptable enough from a security point of view.
Basically: Keep track on your transmitting nodes.
My ambition with the signing feature is to protect a network from external attackers. More sophisticated features are needed to also protect against attackers using your own devices against you. I would like to investigate the possibility of blacklisting further, but I only have so much time, and Arduinos only have so much memory so that is something either someone else need to investigate further (I really want to start focusing on sensors myself now) or something to be considered with more sophisticated hardware. The ATSHA204 can cover for this as well, but it will require more memory on the devices using it.

And yes, if your controller is accessible through internet or through wifi, an attacker will most likely come from that direction, and not directly on your nodes. But "MySensors" cannot cover security in those areas.

[rvendrame]

@Anticimex said:

Also, if you use the same PSK on other parts of your system (like your GW) an attacker could pick the stolen ATSHA device and put it in their own device to allow it to transmit signed messages to any node in your system until you revoke the PSK in your GW (and corresponding nodes).

But that requires SMD-desoldering right? I guy who knows SMD + network sniffing + MYS hacking certainly will target something much bigger than my house ;-)

[Anticimex]

@rvendrame Hehe, well, if they go for hacking you keyfob, they probably know enough to realize that desoldering is not necessary. Just tap into the programming interface of the Arduino and write your own sketch to it ;)
However, they DO need to figure out your network topology, understand the MySensors protocol and so on. But we have to assume that is the case since we are open source. So everybody knows (or has access to) everything. The essential security here is your PSK. Your PSK must never EVER fall into the wrong hands. Either by theft or by accidental reveal (publishing it here for instance).
As long as you keep your PSK private and make sure the nodes that has the PSK programmed in on way or another do not fall into the wrong hands, you should be OK.

[Anticimex]

@rvendrame Actually, I have been thinking and I think I have figured out a way to implement diversification in the signing protocol without revealing IDs over the air. I need some more time to think about it, and make an feasibility assessment on wether it is possible on the limited space available (perhaps to make it an optional feature).
I will post an update here if I figure it out (or if I deem it to much work or simply can't be bothered ;) )
Anyway, the end result (if I succeed) will make it possible to revoke nodes on an ID-basis in case a node/device is lost/compromised. So if someone steals your keyfob they will have to go through quite some trouble to be able to use the device to hijack into your network (if you update your network to not accept that particular keyfob anymore).
I'll think about it. But this weekend I have to be social, so don't expect the solution (if any) anytime soon.

[rvendrame]

@Anticimex , thanks a lot. In the way it is currently it is very good. I was thinking about a logic of having to propose to you, but didn't conclude it yet. But definitely it would requires more memory at the gateway side at least, and a good online backup of GW eprom ;-)

Something like in the node registration to the GW. The GW would ask if the node has already a PSK --- If not, it would generate one, and send to it to the node. The node then would store the PSK into the security chip, and lock it.

This is based on assumption the GW could handle multiple PSKs (one for each node with signing capabilities). If I understood right, your logic already controls, for every node, which one requires signing or not. It would be an extra handling on that.

So if a node is lost --- It should be relatively simple to backlist it. But I am not sure if association with of a old node (with its own PSK already stored and locked) within a new GW (in registration mode) would be feasible, as I think you mentioned the PSK can't be retrieved anymore (at least in a easy way) at the node side... Also if somehow the GW side loses the PSK list, everything will simple brick!!!!

Anyway, just to think about it. For now lets enjoy this nice thing called mySensors ;-) I may give a try on the security over the weekend, if family + social allows it...

Have a great weekend

[Anticimex]

@rvendrame It is a possibility. However, I do recommend a different approach, because your proposal involves sending the PSK in the clear OTA which potentially could be collected by a snooping device. This opens an attack vector.
I am more thinking in the line of hashing the calculated singature with a serial (every ATSHA has a unique serial) and then sending the salted signature to the receiver (verifier). The verifier calculates the signature on its own and then
Option A: Looks up the sender serial in a table based on NodeId and hashes the calculated signature with a stored serial for that NodeId and compares the signatures. I like this one because it is the most "anal". It is however potentially memory demanding (or slightly more complex to setup).
Option B: Traverses a list of stored serials and tries a signature comparison with all known serials and accepts the signature if any one signature matches. I like this a bit less because any stored serial is accepted without regard of the sender. But it is probably less memory "heavy".

To revoke a "lost" node, one simply updates the receiver and removes the corresponding serial. A snooper will never "detect" a serial since they are never sent OTA in the clear, and also an attacker will only be able to determine the serial of the device stolen (which you hopefully revoked once you detected the theft).
The trick is to figure out an memory and user friendly way of storing and managing the serials on every receiver.

The more I think about it, the more I want to implement it. I hate to "know" that the solution can be attacked successfully in any conceivable way. If we ignore the issue with "lost" nodes, I have not been able to identify another attack vector (not to say there is none though).
I welcome anyone to challenge and identify issues.

[lunarok]

Hi,

Is it possible to get a small schematics/howto for using ATSHA204 chip ? Maybe some references on the shop page for exemple.
Maybe newbie question, but look that the best for this signing feature will be to connect Arduino with this chip. Only information is on A3, ok but I will feel more confident with some schematic for newbies :)

[Anticimex]

@lunarok well there really is not more to it. You have three pins; data (to a3 or any digital IO of your choice) power (3.3 or 5V) and GND. I suggest @tbowmo s little minimalistic board (referenced on the main page as official MySensors board) for a schematic reference.

[Zeph]

Nice work, thank you.

I think I'd be pretty flattered if somebody spent the time to reverse engineer a lost keyfob and my MYS network. As far as I know, nobody realizes that I have three Van Gogh's and a 50 caret diamond in my crawlspace, so I mostly don't expect that concentrated an attack, when my windows are so easily broken anyway. :-)

Most people with the skills to do that already have much nicer things in their homes than I available have for them to steal (aside from those paintings and rocks).

Seriously, it's good to have the option of being relatively more secure, in particular since it seems to be fully optional. Let me check tho - this is not going to take up any program memory (Flash) if one isn't using it, right? So there's no harm or cost/bloat if you don't need it, and some really cool additional functionality if you do.

[Zeph]

Hmmm.. If somebody is taking security this seriously, they might want to use a different chip (or use the whitening technique referenced in an early post in this thread): http://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Skip back and forth in the thread.

One odd effect of using a widely used professional chip is that in some scenarios it can make one less secure - because now you are using something which has a far higher target profile than MySensors. Put another way, the MySensors community is a small enough movement that it's not worth a lot of resources to attack it; but the widely used chip IS an attractive target, and a discovered security hole might pull in MyS "for free". Not a problem if it has no vulnerabilities of course.

Notice Bill's concern that there may be a deliberate back door in the chip. A few years ago that might seem paranoid; by now we know that it would be unusual if certain security agencies had NOT at least considered working out a special deal with the manufacturer of a widely used chip.

Wouldn't it be interesting if the software implementation was, in some areas, more secure than the hardware?