[Solved] 'Verify fail' when enabling whitelist in signing function

[carlierd]

Hello,

I tried to enable the white_list function between a serial gateway and a node.

Code for the gateway:

MyTransportRFM69 transport;
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
MySigningAtsha204Soft signer(true, 0, NULL, soft_serial);

Code for the node:

whitelist_entry_t node_whitelist[] = {
  { .nodeId = 0,
    .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} }};
MySigningAtsha204Soft signer(true, 1, node_whitelist);

I got following information in MYSController (example):

30/11/2015 20:57:21	RX	0;0;3;0;9;read: 1-1-0 s=0,c=3,t=16,pt=0,l=0,sg=0:
30/11/2015 20:57:21	RX	0;0;3;0;9;send: 0-0-1-1 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:01B9A97B9
30/11/2015 20:57:22	RX	0;0;3;0;9;verify fail

If I simply use MySigningAtsha204Soft signer; in the node everything is normal (data messages are signed).

Any idea ?

[carlierd]

Hello,

I also tried the following constructor on the node and get the same result:

MySigningAtsha204Soft signer(true, 1, node_whitelist, soft_serial);

Result in MYSController:

It seems that sign message are rejected by the gateway, no ?

[Anticimex]

@carlierd
Hi,
well from the logs, the messages received are not signed at all (sg=0) so there is probably something dodgy with your node.
What is the direction of the messages? Is your node supposed to send signed messages to your gw, then it is your gw that should have a whitelist as it is the gw that does the verification. And your node should specify a serial to salt the signatures with that matches the whitelist the gw has. Obviously, the complete opposite holds if it is in the other direction the signed messages are supposed to go.

Edit: the sg flags are correct. The message supposed to be signed is signed but also salted with a serial which the receiver (the gw) has no whitelist to match against. So verification fails.

[carlierd]

Hello @Anticimex !

I enabled signing on both gateway and node. This is perhaps not correct ?
I understood that I can only enable signing on one direction ? I misunderstood this point.

[Anticimex]

@carlierd both the sender and the receiver have to have signing enabled. Both do not have to require signing though.

[carlierd]

I just saw your edit in the previous post !
So the gateway need a whitelist if I want to add soft_serial in the constructor ?

I use this constructor (from your initial post):

MyTransportRFM69 transport;
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
MySigningAtsha204Soft signer(true, 0, NULL, soft_serial);

I understood that use NULL will avoid the verification in the whitelist for the node ?

[Anticimex]

@carlierd said:

use NULL will avoid the verification in the whitelist for the node ?

Well, sort of. However, if the transmitter uses whitelisting, the receiver will not be able to verify the signature if the transmitter is not listed in a whitelist at the receiving side. The sender does not know that the receiver has or has not the sender in its whitelist, so the sender will always salt its signature with its serial number when whitelisting is enabled for the sender. But the sender will only do the signing if the receiver has registered that it require it.

If I understand your usecase correctly, you want your node to only accept signed messages from your gw and use whitelisting so only your gw is accepted.
That means that your node have to have a whitelist with the gw nodeId and serial. Your node must also require signatures.
Your gw does not have to require signed messages from your node, but if your gw does require signed messages, it also has to have a whitelist with an entry for your node in order to verify messages from that particular node since the node has whitelisting enabled.
If we turn around things and have a gw that require whitelisted messages from a node, then the same holds true. However, the gw receives messages from potentially many nodes. But some might not require whitelisting. The GW will accept none-salted messages from nodes that are not present in the whitelist@gw. But, the gw will transmit salted signatures to all nodes that require signing (including the nodes that don't "want" whitelisting) per the same rules as above (the gw does not "know" which nodes support whitelisting and which don't but since one does, it salts everything). So for this reason, it is suggested to have whitelisting on all nodes that are involved in signed message exchange (unless you only send messages in one direction from them, node->gw in this case).

I would suggest if you want to secure data going into the GW, to use encryption (you don't want people snooping in on your sensor data) and you want to sign data going out from the GW (you don't want anyone taking over the control over your actuators). The GW does support requiring signing (and will only require signatures from nodes that in turn require signatures) but with whitelisting the setup can get a bit more complicated as a GW that salts messages to one node, does it to all who require signatures. This is no problem as long as you understand that the whitelists may need to be maintained.

Hope my long rambling made things a bit clearer. In the not too distant future, this will be better documented using Doxygen.

[carlierd]

I start to understand the problem. The node I use is a temperature node. The node you are using in your example is an actuator so the communication is in the other way.
Like I do, I have to set the whitelist in the gateway, it makes sense now !

I already use encryption with RFM69. So with signing I think the security is enough !

Really thanks for your help !!

[Anticimex]

Then you are thoroughly settled on security
Actually, your problem has gotten me to think a bit about how whitelisting is handled, and I think I will make improvements so that any node/gw capable of creating signatures will automatically salt signatures to nodes that has a whitelist. That way you can mix whitelist-enabled nodes with non-whitelist-enabled nodes.
So that you could have a GW that don't have whitelisting, and a node that does. But the GW would still know to salt messages to that particular node. It will cost some EEPROM but it can be done, and will be much more intuitive for people to use. So eventually, that support will be implemented. But I make no promises on it being done before the end of this year (and it will in any case target the development branch so it might not make it to the next release).

[carlierd]

Security is important for temperature nodes
When I start in the MySensors world I discover the signing functionality and as it was ready and really simple to use I decided to use it.
As soon as my network will be ready I will test the development branch and will be happy to test your modifications when ready !

[Anticimex]

That's great! I am always on the lookout for people interested in testing and using the signing framework. There are really great things in the pipe for the next (1.6.0 I believe) release.