[security] Introducing signing support to MySensors

[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?

[Anticimex]

@Zeph yes, backdoors in crypto HW will always be a concern for non open designs. However, these are probably not generally known and besides, they still require physical access to the device in question. And since my recommendation is (also after whitelisting feature is implemented) that PSK is revoked if a secure node is lost, a backdoor will get you nowhere as the security protocol as such is based on an open and widely regarded secure standard. If you are really paranoid, you simply need to weigh the hard option against the soft. The hard at least in theory protects you from revealing tour secrets, but the soft does not. But the soft option gives you more insight in the mechanisms used to generate the signatures.

[Anticimex]

@Zeph Regarding the whitening, yes, that is probably a good idea. Currently the slimmed down ATSHA driver does not implement the SHA command, but I need it anyway since it will be used for the whitelist-feature. So I can add the random improvement to both the hard and soft backend together with the whitelist stuff. I just hope I can squeeze everything down enough. The limiting device is an Ethernet GW which I believe is the "largest" (have not evaluated MQTT though).

[rvendrame]

@Anticimex

Believe it or not I discussed the topic with my wife this weekend, and she asked me if each ATSHA doesn't have a unique serial... :-S

Very good - I assume this will requires more RAM in GW (only), completely acceptable in my opinion.

I more like your option "A" ;-)

Cheers

[Anticimex]

@rvendrame Your wife is perfectly right, and I have indeed starting looking into option A. It will unfortunately break compatibility with ATSHA204, but I do believe everyone will use ATSHA204A so that should be fine. I hope to be able to fit everything into flash. The signing backend constructors will be updated to take a whitelist that the "verifying" end of a node network will provide. The whitelist feature overall will be an optional #define controlled feature since it will change the message signature, so if one half of Alice and Bob use it, the other has to as well. But since it will "cost" a bit both RAM and ROM, I prefer to have that feature optional since it is not really required for a "locked" network where all nodes are inaccessible.
And still, revoking the PSK if the network is compromised is my strong recommendation. But a "blacked-out" node will require even more effort to hack for the network to accept it.

This feature does require you to know the serial of the transmitter and it's NodeID. The serial will never be sent OTA in clear text so it is easiest obtained during personalization (it is printed on UART then). The "soft" backend will have a "fake" serial set by the "user" who hopefully makes it unique for every node. Set either through constructor or as a #define. I have not decided yet.

In any case, once I am done, the top post will be updated to include the whitelist option and how to use it.

[rvendrame]

@Anticimex , amazing. I understood your concerns with transmitting the serial number over the air --- But assuming the GW only enters in '"Inclusion mode" by pressing a physical button (or via its controller request), and it lasts only 1 minute typically --- Do you still see a big risk?

Otherwise --- On everyone new node it would require a re-flash of GW, adding the new node serial to it ? Perhaps I didn't get it in the right way...

[Anticimex]

@rvendrame
Serials are static so those are a one-shot config. The node ID is not that static, but once assigned, it is persisted in the EEPROM on the node so it is static enough I believe.
I prefer not to have any useful information sent in clear text at any point sine it is difficult to ensure that a node cannot be "enticed" to reset and retransmit data at will.
We have to remember that secure exchange does not necessarily go through a GW. In the case of keyfob -> garage door, there is no reason to relay through a GW. The keyfob could transmit to the garage-door motor directly. So relying on "inclusion" to set up secure communications is not a dependency I want to have. Any node should be able to establish signed communication with any other node. It is just a matter of the sketch used transmit the signing requrement message itself. In the GW case, the library takes care of this, but nothing prevents a node to transmit it's signing preference directly to another node in the network (such as a garage door to an associated keyfob).
So if we assume the garage door require signed messages, the keyfob then have to transmit it's serial at some point so the garage door can "learn it" (per your suggestion). So if the keyfob is stolen, that feature can be exploited to reset the garage door nodes whitelist. Therefore I do believe the garage door has to have a hard-coded whitelist which cannot possibly be changed without physical access to it.
Call me anal, but better safe than sorry ;)
And yes, this is probably all overkill...but if we go overkill..let's do it with a vengeance. After all, anyone who thinks this is unnecessary can simply choose to not use it.

EDIT: On the topic of reflash, yes. If a receiver is to be made aware of new nodes it is expected to verify messages from, it has to be updated. But to me, that both makes sense and is desired. You never want a node to automagically start accepting messages from "unknown" nodes for whatever reason. I think a bit of convenience has to be sacrificed on that topic.

[sharath krishna]

@Anticimex really a cool thing :+1: i just wanted to know if the rasp pi version of the mysensors will also get this ? it will be very useful when we use the raspberry pi as the gateway using pigateway serial.

[Anticimex]

@sharath-krishna Thanks! The software driver has no real hardware dependency so yes, that should work. You will need to patch to patch the random number generation though.
I do not think the hardware driver really needs to be ported since a raspberry will likely not be used in an environment where it can be stolen/tampered with so extra protection of PSK and such will not really be needed.
Sorry to say, I do not have the bandwidth to support this on all hardware. I will however encourage the community to port it anyway it likes and will support as much as I can. I will try to maintain it for Arduino and am still working with strengthening it and there are a few bugs left to iron out before it can me submitted to master.

[daulagari]

@rvendrame:

• The ZWave paper you point to describes a problem implementation, not the protocol itself it seems to me:

The root cause of this issue was lack of state validation
in the key exchange protocol handler programmed in the Z-
Wave door lock firmware.

• Yes, if you lose your normal key anybody that knows to which lock it belongs can break in.
• But, if your key has no information on to which lock it belongs to the risk is small, the same is true for a remote.

[jkandasa]

@Anticimex Thanks a lot! Its a great work.
Does signature feature supports for node to node communication (I mean without gateway)?

[Anticimex]

@jkandasa thanks. Yes it does. But then you (as sketch developer) is responsible for sending the internal I_REQUEST_SIGNING message to inform the other node of your nodes signing requirements. The library manages this automatically for the node2gateway (and gateway2node) but not for node2node messages since the library "does not know" anything about that.