[security] Introducing signing support to MySensors
-
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?
@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.
-
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?
@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 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.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
Home Assistant / Vera Plus UI7
ESP8266 GW + mySensors 2.3.2
Alexa / Google Home -
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
@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.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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.
@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...
Home Assistant / Vera Plus UI7
ESP8266 GW + mySensors 2.3.2
Alexa / Google Home -
@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...
@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.
-
@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 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.
@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. -
- 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.
-
@Anticimex Thanks a lot! Its a great work.
Does signature feature supports for node to node communication (I mean without gateway)? -
@Anticimex Thanks a lot! Its a great work.
Does signature feature supports for node to node communication (I mean without gateway)?@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.
-
@hek do you have any plan to use this logic in new version api?
@Anticimex awesome work! -
@hek do you have any plan to use this logic in new version api?
@Anticimex awesome work! -
Thanks guys! Glad to see that it's appreciated :)
I am now working on strengthening the nonces and implementing whitelisting. I hope to be able to finish it in time for the 1.5 release.
Voluntary testers are desired!
I will update the first post also with more instructions on how to handle whitelisting and also update it so it reflects the more recent changes on the development branch with respect to configuration as soon has I have finished the hacking. -
UPDATE: Thread topic post updated with a lot of stuff. Whitelisting is now "in" and explained. Various updates to the text to make a few things more clear and some code examples added to show how this ties into the updates on development branch when it comes to construction of the library class and how signing comes into play.
-
@Anticimex This really is great work!
I have one question regarding ATSHA204A: do you know where to buy ATSHA204A-STUCZ-T? I couldn't find any supplier in Europe and even on Aliexpress, I could onlyfind the ATSHA204 in SOT23-3.
