[security] Introducing signing support to MySensors
-
@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. -
hello, i'm making some mysensors board that I'll present you a bit later and I've add a place for the Atsha204 sot23-3.
I can't find it in Europe still and I would like to know if is it possible ton connect it on pin A6 instead of pin A3. I would like to keep the A0 to A5 for the user and use A6 for Atsha204 and A7 for Atcha204 floating point. Can anyone test it for me please?
Thank's verry much!
-
hello, i'm making some mysensors board that I'll present you a bit later and I've add a place for the Atsha204 sot23-3.
I can't find it in Europe still and I would like to know if is it possible ton connect it on pin A6 instead of pin A3. I would like to keep the A0 to A5 for the user and use A6 for Atsha204 and A7 for Atcha204 floating point. Can anyone test it for me please?
Thank's verry much!
-
Ok, So I've to connect it on A3 (default value in mysensor?) and let the A7 floating? The A6 is not used so? (other question : I can't use digitalWrite on A6 pin?)
Thank's verry much for the details on ATSHA204A instead of ATSHA204. The ATSHA204A is in SOT23-3 too? so the A7 is only use inside the Atmega library?
-
Ok, So I've to connect it on A3 (default value in mysensor?) and let the A7 floating? The A6 is not used so? (other question : I can't use digitalWrite on A6 pin?)
Thank's verry much for the details on ATSHA204A instead of ATSHA204. The ATSHA204A is in SOT23-3 too? so the A7 is only use inside the Atmega library?
@Tibus A6 and A7 are analog input pins. You can use them as such but not as digital I/O.
ATSHA204A is identical but more feature-rich compared to ATSHA204. One added feature is a SHA256 which is required for MySensors use. ATSHA204 is discontinued by Atmel. You can connect the ATSHA to any digital I/O pin you like but you will have to patch the config if you pick anything not called "A3".
