[security] Introducing signing support to MySensors

[Anticimex]

@tbowmo We probably should conditionally include drivers/ATSHA204/ATSHA204.cpp based on the MY_SIGNING_ATSHA204 flag. Otherwise the ATSHA204.cpp file will be included in multiple places if ATSHA204 signing is enabled in the gw.

[alexsh1]

@Anticimex it says

0;255;3;0;9;156987 TSF:MSG:READ,4-4-0,s=2,c=1,t=1,pt=2,l=2,sg=1:45
4;2;1;0;1;45
0;255;3;0;9;169466 Verification timeout

Shall I try to increase timeout?

[Anticimex]

@alexsh1 First you have to resolve the NACKs. It will not help to increase the timeout if messages never arrive.

[alexsh1]

@Anticimex I think I have resolved it by changing this:

#define MY_RF24_PA_LEVEL RF24_PA_HIGH

to

#define MY_RF24_PA_LEVEL RF24_PA_LOW

0;255;3;0;9;44594 Signing backend: ATSHA204
0;255;3;0;9;44647 SHA256: CF003C2C5580A69303207910E37DA55E6A4B0C78B671218C3BEF40B895658B9D
0;255;3;0;9;44658 Will not sign message for destination 6 as it does not require it
0;255;3;0;9;44671 TSF:MSG:SEND,0-0-6-6,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=OK:CF003C2C5580A69303207910E37DA55E6A4B0C78B671218C3B
0;255;3;0;9;44681 Transmitted nonce
0;255;3;0;9;44951 TSF:MSG:READ,6-6-0,s=2,c=1,t=1,pt=7,l=5,sg=1:55.2

One node is still bad - I'll change the radio and test it again.

[Anticimex]

@alexsh1 :+1:

[alexsh1]

@Anticimex

Do you think that I may have verification timeout due to having a mixture 2.1.1 and 2.2.0?

0;255;3;0;9;124541 Signing backend: ATSHA204
0;255;3;0;9;124594 SHA256: 9CEF656D53F4C3722D72AE17346E310BD300161FAB992261DD5216C08D0D7950
0;255;3;0;9;124605 Will not sign message for destination 16 as it does not require it
0;255;3;0;9;124618 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=OK:9CEF656D53F4C3722D72AE17346E310BD300161FAB992261DD
0;255;3;0;9;124628 Transmitted nonce
0;255;3;0;9;124799 TSF:MSG:READ,16-16-0,s=255,c=3,t=0,pt=1,l=1,sg=1:76
16;255;3;0;0;76
0;255;3;0;9;124809 TSF:MSG:READ,16-16-0,s=0,c=3,t=16,pt=0,l=0,sg=1:
0;255;3;0;9;124819 Signing backend: ATSHA204
0;255;3;0;9;124872 SHA256: 326EB7828E5F02AB2F9FCE645FC5B7D2628DDD70FED64C78275AC1FA0D1C1AF5
0;255;3;0;9;124883 Will not sign message for destination 16 as it does not require it
0;255;3;0;9;124896 TSF:MSG:SEND,0-0-16-16,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=OK:326EB7828E5F02AB2F9FCE645FC5B7D2628DDD70FED64C7827
0;255;3;0;9;124906 Transmitted nonce
0;255;3;0;9;125176 TSF:MSG:READ,16-16-0,s=0,c=1,t=38,pt=7,l=5,sg=1:2.9
16;0;1;0;38;2.9
0;255;3;0;9;137796 Verification timeout

[Anticimex]

@alexsh1 Hm, it should not be a problem. Assuming your log snippet is from the GW, it basically says that it successfully transmit the nonce to your node as requested to, and then it expects the node to provide a signed message to the GW within a certain timeout. The node fails to do this within that time so the GW times out and will not accept the message if it arrives later on.
So there are two options;

1. The node takes too long to process the received nonce, sign the message and send it back (perhaps many repeater hops between node and gw, this can be resolved by increasing the signing timeout at the GW side).
2. The node does transmit the signed message but fails with a NACK. The GW will never see this message and therefore assumes the node did not send it and correctly times out.

[alexsh1]

@Anticimex On the node, changing nrf24l01+ orientation (I have two nrf24l01+ sockets) 90 degrees changed signing from

0;255;3;0;9;120620 Transmitted nonce
0;255;3;0;9;120630 TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=1:24.0
0;255;3;0;9;120644 Current nonce: 415DAB5FF6170E67F5B180ADC827C062D35CBF2DCE1B6B0264AAAAAAAAAAAAAA
0;255;3;0;9;120745 HMAC: 759A77B66BAC8F0AEA542685F4EA12DEB66B27FE15F57788F1D1022508984896
0;255;3;0;9;120756 Signature bad
0;255;3;0;9;120766 Signature verification failed!
0;255;3;0;9;120776 !TSF:MSG:SIGN VERIFY FAIL
0;255;3;0;9;120981 TSF:MSG:READ,4-4-0,s=2,c=1,t=1,pt=2,l=2,sg=1:70
0;255;3;0;9;120991 No active verification session
0;255;3;0;9;121001 Signature verification failed!
0;255;3;0;9;121011 !TSF:MSG:SIGN VERIFY FAIL

0;255;3;0;9;165728 Transmitted nonce
0;255;3;0;9;165944 TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=1:24.4
0;255;3;0;9;165958 Current nonce: BAC8828FEAAFB3A0C65DE6F8D4993E4D3D93F190B58AA3C737AAAAAAAAAAAAAA
0;255;3;0;9;166059 HMAC: 122222A7C324B3688BD98EC8EF9AD9557350B874CAB38F250A246EBB069805D3
0;255;3;0;9;166070 Signature OK

[Anticimex]

@alexsh1 Looks like RF performance was significantly improved by that change.

[alexsh1]

@Anticimex It seems to me that 90% of all issues is actually RF.
Very annoying!

Thanks for your help!

[alexsh1]

I am using latest beta (2.2.0b). Does anyone know what this means in the log:

!SGN:NCE:GEN

I think this is related to signing

[Anticimex]

@alexsh1 https://ci.mysensors.org/job/Verifiers/job/MySensors/job/development/Doxygen_HTML/group__MySigningDebugMessages.html

[Anticimex]

@alexsh1 to be more specific; the backend failed to generate a nonce. If you use the soft backed, it did not initialize properly (and you should have a log entry for that failure as well).
If using atsha204a, it either failed init like described above, or it failed to communicate properly (which should also be visible in other failures in the log)

[alexsh1]

@Anticimex Spot on -> there was a mistake :

#define MY_SIGNING_ATSHA204_PIN 3

and should have been

#define MY_SIGNING_ATSHA204_PIN 17

I was wondering why nonce was all zeros...

[Anticimex]

@alexsh1 excellent. Signing won't work well without proper communication with the chip :)
I considered just hanging if that happened but decided it was a bit too harsh and might disguise the problem in case UART debug isn't enabled.

[magpern]

I cannot get my china USB to Serial device to work with the arduino boards, so I cannot program the board to run the personalization. As a work around a use a Arduino Uno board as the "USB to Serial" and now I can upload the sketch and the personalizer writes to serial output fine at 115200 baud.
But, when it wants me to press SPACE, it responds with "Unexpected answer. Skipping lock."

I tried an other sketch that does Serial.read() and echos back the result. It does not work at 115200 but works at 9600 baud. At 9600 I get char 32 back as SPACE, but 160 or 130 or 254 at 115200. Maybe the Uno board cannot handle 115200?

So, question: Can the personalizer sketch be changed to use 9600 (or something slower than 115200)? I tried to change the Serial.begin(115200) to 9600, but it is still 115200.

(of course, I can alter the code to bypass the press SPACE to press any key, but I want to get to the bottom with the problem)

[Anticimex]

@Magnus-Pernemark
Question 1: so you run stable release or beta?
Answer 1: yes you can change baud rate but it is handled differently between stable and beta.

[Anticimex]

@Magnus-Pernemark there is a configuration switch to disable UART verification you can use

[mfalkvidd]

@Magnus-Pernemark which version are you using?
The development version from github supports

#define MY_BAUD_RATE 9600

at the start of the sketch.

The 2.1.1 version has

Serial.begin(115200);

in the sketch. Just change that.

[magpern]

@Anticimex I am so not familiar with the arduino/mysensors development yet, but I guess I use 2.1.1, since i used "Sketch / Include Library / Manage Library" and it had 2.1.1

@mfalkvidd Since I have the line Serial.begin(115200) I assume it is 2.1.1, but changing it to 9600 and uploading the sketch does nothing. I still need to open serial window with 115200, else I just see garbage as output from the mini pro.

I will try the development version and see if that helps.