[security] Introducing signing support to MySensors
-
@Anticimex Hello, I found this thread now. I'll ask a few more questions, sorry. This all seems really-really great.
-
If someone wishes to use TMRh20's RF24Mesh instead of MySensors how would one sign the messages sent with that library? Is is even possible? What should be done to use that functionality?
-
Also, as I understand it is possible to emulate the ATSHA204A, on what hardware is is possible (on Uno's ATMega too?)?
-
Is it also possible to use whitelisting with RF24Mesh somehow?
Again, sorry for any dumb questions and my poor English.
-
-
@Anticimex Hello, I found this thread now. I'll ask a few more questions, sorry. This all seems really-really great.
-
If someone wishes to use TMRh20's RF24Mesh instead of MySensors how would one sign the messages sent with that library? Is is even possible? What should be done to use that functionality?
-
Also, as I understand it is possible to emulate the ATSHA204A, on what hardware is is possible (on Uno's ATMega too?)?
-
Is it also possible to use whitelisting with RF24Mesh somehow?
Again, sorry for any dumb questions and my poor English.
- Signing as described in this post is specific to users of the MySensors library. I suppose you could use any rf backend you like but you will need to use the MySensors library to get the nonce exchange and such. Or manually port the signing specifics out from the MySensors library and integrate them into another library. It's all open source.
- The software emulated atsha signing backend (for MySensors) is compatible with any Arduino product.
- See 1.
Lastly, there are no dumb questions, only dumb answers :)
-
-
Hello,
firstly, I must say that you're doing a great job and this section about security is very interesting.
Sorry, but I want to ask a question: as regards the whitelisting system, how can I add more nodes to the list of the trusted nodes of the gateway?
The part of code is this:[...] #ifdef MY_SECURE_NODE_WHITELISTING whitelist_entry_t node_whitelist[] = { { //I want to add nodes HERE: .nodeId = 55, // Just some value, this need to be changed to the NodeId of the trusted node .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} } // This need to change to the serial of the trusted node }; MySigningAtsha204 signer(true, 1, node_whitelist); // Select ATSHA204A software signing backend with one entry in the whitelist [...]but the gateway continue to fail the verification of the trusted nodes that I inserted.
To sum up, how can I add more nodeIDs and serials in addition to the number "55" presented in the example of the code?Thank you very much in advance,
Silver978 -
Hello,
firstly, I must say that you're doing a great job and this section about security is very interesting.
Sorry, but I want to ask a question: as regards the whitelisting system, how can I add more nodes to the list of the trusted nodes of the gateway?
The part of code is this:[...] #ifdef MY_SECURE_NODE_WHITELISTING whitelist_entry_t node_whitelist[] = { { //I want to add nodes HERE: .nodeId = 55, // Just some value, this need to be changed to the NodeId of the trusted node .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} } // This need to change to the serial of the trusted node }; MySigningAtsha204 signer(true, 1, node_whitelist); // Select ATSHA204A software signing backend with one entry in the whitelist [...]but the gateway continue to fail the verification of the trusted nodes that I inserted.
To sum up, how can I add more nodeIDs and serials in addition to the number "55" presented in the example of the code?Thank you very much in advance,
Silver978@Silver978 Thanks!
Try something like this:whitelist_entry_t node_whitelist[] = { { .nodeId = 55, // Just some value, this need to be changed to the NodeId of the trusted node .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} // This need to change to the serial of the trusted node }, { .nodeId = 56, // Just some value, this need to be changed to the NodeId of the trusted node .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} // This need to change to the serial of the trusted node }, { .nodeId = 57, // Just some value, this need to be changed to the NodeId of the trusted node .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} // This need to change to the serial of the trusted node } }; MySigningAtsha204 signer(true, 3, node_whitelist); // Select ATSHA204A software signing backend with three entries in the whitelistNote the changed argument in the constructor (3 and not 1)
-
@Anticimex I tried also this syntax but I haven't changed the argument of the signer, so that number indicates how many nodes the gateway must trust?
Thank you! -
@Anticimex I tried also this syntax but I haven't changed the argument of the signer, so that number indicates how many nodes the gateway must trust?
Thank you!@Silver978 The number gives the number of entries in the whitelist the backend is expected to iterate over. Having a number for this allows the use of a potenitally very large whitelist but where "uninteresting" entries to this particular node can be ignored by having them last in the list and make sure the number does not cover those entries when searching the list.
-
@Anticimex Perfect, understood! Very good explanation and super-fast support, fantastic :)
Thank you very much again! -
@Anticimex Perfect, understood! Very good explanation and super-fast support, fantastic :)
Thank you very much again!@Silver978 :+1:
-
I would like to add security to my sensor network as well so I am very glad I found your thread. Your explanation are very detailed but I´m a guy who needs more practical examples. For example I would like to know, where exactly I have to activate this. I am using an arduino as an MQTT to Ethernet gateway and Mosquitto running on a raspberry pi. So all I have to do is activate the soft version in Myconfig.h, if not already activated, set a serial, re-upload to my arduino gateway and that´s it? I guess the Nodes have to get flashed again to get the serials as well, right?
-
I would like to add security to my sensor network as well so I am very glad I found your thread. Your explanation are very detailed but I´m a guy who needs more practical examples. For example I would like to know, where exactly I have to activate this. I am using an arduino as an MQTT to Ethernet gateway and Mosquitto running on a raspberry pi. So all I have to do is activate the soft version in Myconfig.h, if not already activated, set a serial, re-upload to my arduino gateway and that´s it? I guess the Nodes have to get flashed again to get the serials as well, right?
@siod correct. You have to activate signing in both ends. The serial numbers you only need of you want to use whitelisting which is a bit more complex to set up. At the very least, for software signing, you need to enable it, have an unconnected analog pin on your boards, and set a hmac key.
-
EDIT: Topic post updates with a documentation link for those using the development branch.
-
Great topic as usual. I have a question please.
You mentioned "Because it is pure-software however, it does not provide as good nonces (it uses the Arduino pseudo-random generator) and the HMAC key is stored in SW and is therefore readable if the memory is dumped. "
Isn't this case also dangerous if the node which contains ATSHA chip was stolen ? The attacker will use the chip to be on the network ?
Thanks.
-
Great topic as usual. I have a question please.
You mentioned "Because it is pure-software however, it does not provide as good nonces (it uses the Arduino pseudo-random generator) and the HMAC key is stored in SW and is therefore readable if the memory is dumped. "
Isn't this case also dangerous if the node which contains ATSHA chip was stolen ? The attacker will use the chip to be on the network ?
Thanks.
@ahmedadelhosni thanks!
Correct. That is why I also implemented whitelisting and node revocation. It's all described in the topic (and for development branch in doxygen, linked in the topic). -
@ahmedadelhosni thanks!
Correct. That is why I also implemented whitelisting and node revocation. It's all described in the topic (and for development branch in doxygen, linked in the topic).@Anticimex Thanks.
So this gets me to my next question :)
What I understood is that if I use whitelisting, I need to know the node ID of my sensor door to define it in the GW, correct ?
I guess the below code is in the GW.whitelist_entry_t node_whitelist[] = { { .nodeId = 55, // Just some value, this need to be changed to the NodeId of the trusted node .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} } // This need to change to the serial of the trusted node };another question, If I want to remove this node, do I have to reflash the GW and remove it ?
-
Yes.
-
@Anticimex mmmm
Can't it be implemented in a way so that whitelist is to be defined by the controller ?
For example, an internal message to be used to set the data.My concern is that auto assignation of nodes is flexible but at the same time you may need to choose which sensor node to be added to your whitelist. Thus if a Controller can show you all your nodes, like vera or domoticz, I guess this option can be added to the plugin to send an internal message to the GW to choose which sensor node to be added.
Am I saying something logic ? :)
-
Possibly. But that would mean that security features is dictaded by the controller plugins and I do not like that at all.
For months I have been trying to convince the Domoticz people that their ACK timeout is way to short and needs to be configurable for signing to work with Domoticz, but they do not even reply to me.
And I do not trust controllers at all and want to have full control over all configuration aspects of the signing solution. So I do not think it is good to move that logic off the nodes (whitelisting can also be used by a node, communicating with another node).
It is not only a GW that can have a whitelist. So although it might have been flexible to have it configurable, I think it compromises security (who knows, your controller could be hacked to inject a whitelist that permits a rogue node in your network).
Of course, security is at some level compromised anyway if the controller is hacked. But it is not the signing solution that is compromised in this case.
And ultimately, that feature would mean that the level of signing security and signing features for MySensors, becomes controller specific. And that I do not think is a good idea. If I want to change or improve the feature, the controller plugins all also have to be updated. It just becomes a too big turnaround for something as important as this in my opinion.
-
Yeah I got your point of view and convinced me. The only solution to implement this is that other communities works together to improve flexibility and security. This is not that easy of course as you have said.
Thanks a lot for your time.
-
Thanks for understanding :)
-
Also in all cases I see that if your controller is being hacked there will be no use to play with the whitelist :) The attacker has full control already to blow my house if he wants to :)
Anyway maybe I need to reflash using signing to understand things more.
Keep it up :)