[security] Introducing signing support to MySensors

[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

[Anticimex]

@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 whitelist

Note the changed argument in the constructor (3 and not 1)

[Silver978]

@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]

@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.

[Silver978]

@Anticimex Perfect, understood! Very good explanation and super-fast support, fantastic :)
Thank you very much again!

[Anticimex]

@Silver978 :+1:

[siod]

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?

[Anticimex]

@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.

[Anticimex]

EDIT: Topic post updates with a documentation link for those using the development branch.

[ahmedadelhosni]

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.

[Anticimex]

@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]

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

[Anticimex]

Yes.

[ahmedadelhosni]

@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 ? :)

[Anticimex]

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.

[ahmedadelhosni]

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.

[Anticimex]

Thanks for understanding :)

[ahmedadelhosni]

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 :)

[ahmedadelhosni]

Hi again.

I managed to set run the softsign and everything seems fine till now. I just want to understand the system much more if you please.

Now my Gateway sends this data when I turn on Light.
( I am using GatewayW5100 with Domoticz ) Development branch

0;0;3;0;9;Eth: 0;0;3;0;18;PING
0;0;3;0;9;Eth: 2;7;1;0;2;1
0;0;3;0;9;send: 0-0-2-2 s=7,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 2-2-0 s=255,c=3,t=17,pt=6,l=25,sg=0:01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACAC
0;0;3;0;9;Signing backend: ATSHA204Soft
0;0;3;0;9;Message to process: 00020E01020731
0;0;3;0;9;Current nonce: 01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACACAAAAAAAAAAAAAA
0;0;3;0;9;HMAC: 135DBD85528E869ECC86C9C53679795D7FDA7B789DB7A0A74053C94FE8D668F0
0;0;3;0;9;Signature in message: 015DBD85528E869ECC86C9C53679795D7FDA7B789DB7A0A7
0;0;3;0;9;send: 0-0-2-2 s=7,c=1,t=2,pt=0,l=1,sg=1,st=ok:1

I want to know how was the following data calculated please:

• sg=0:01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACAC
• Message to process: 00020E01020731
• Current nonce: 01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACACAAAAAAAAAAAAAA
• HMAC: 135DBD85528E869ECC86C9C53679795D7FDA7B789DB7A0A74053C94FE8D668F0
• Signature in message: 015DBD85528E869ECC86C9C53679795D7FDA7B789DB7A0A7

So how was sg= calculated ?
What is message to process ?
The nonce is depending on analogue signal + what ? to get this value ?
I have already defined a random HMAC, but this one is different. It is a combination of what ?
Finally what is signature in message ?

On the other side I am trying to sniff the data by a serialgateway which is trying to hack the network. It only read the following data:

0;0;3;0;9;read: 2-2-0 s=255,c=3,t=17,pt=6,l=25,sg=0:01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACAC                      
2;255;3;0;17;01F470C061A0B9FF3DE248835736E2B85E31C8D6D1844AACAC

It is the sg only which it succeeded to read. Also I do understood form the topic that the attacker can read values sent between nodes unencrypted, but here I can't figure out where is the unencrypted data which can be sniffed by the attacker but we don't bother ourselves with cas we protect our network by using signing.

Lots of questions but I am trying to understand the logic and architecture in details to understand what I am doing :)

Thanks a lot.

[Anticimex]

Hi,
I suggest you read the doxygen documentation for signing carefully as it answers the questions you have. Signing does not in any way prevent anyone from reading your messages. As I have described in the documentation, it provides authenticity. That is, you can trust the sender of a signed message to be yours and not someone else's.