Signature verification failing.

[cgrf]

Hi,
For a few days now I've been trying to get my test-setup to work. I am using a NodeMCU Wifi MQTT gateway connected to my Mosquitto server and a single Arduino pro mini node, both with NRF24 radios. The node is supposed to be updated over the air later on, so I installed the latest MYSBootloader.

I had almost everything up an running 2 days ago including message signing. The only problem remaining was, that while FOTA updates were working, serial firmware uploads through the Arduino IDE were failing. I was able to solve this by compiling the bootloader for a reduced upload speed and at the same time upgraded gateway and node from library version 2.1.1 to 2.2. As it turned out, with version 2.2 over-the-air updates were no longer working. So I downgraded both nodes to version 2.1.1 which fixed FOTA for me.

Unfortunately, message signing seems to be broken now. This is the debug output from the node:

5656 MCO:SLP:WUP=-1
+++ request 
5660 Will not sign message for destination 0 as it does not require it
5668 TSF:MSG:SEND,4-4-0-0,s=1,c=2,t=36,pt=0,l=0,sg=0,ft=0,st=OK:
5677 MCO:SLP:MS=3000,SMS=1,I1=255,M1=255,I2=255,M2=255
5683 Will not sign message for destination 0 as it does not require it
5691 TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=22,pt=5,l=4,sg=0,ft=0,st=OK:1520
5937 TSF:MSG:READ,0-0-4,s=1,c=3,t=16,pt=0,l=0,sg=1:
5943 Skipping security for command 3 type 16
SHA256: 118E8C33213D6E353FDF26D2B28D84A5D745CFE2F099D3B2B4AAAAAAAAAAAAAA
5976 Will not sign message for destination 0 as it does not require it
5992 TSF:MSG:SEND,4-4-0-0,s=255,c=3,t=17,pt=6,l=25,sg=0,ft=0,st=OK:118E8C33213D6E353FDF26D2B28D84A5D745CFE2F099D3B2B4
6004 Transmitted nonce
6141 TSF:MSG:READ,0-0-4,s=1,c=1,t=36,pt=0,l=1,sg=1:1
Signature in message: 019753BF095A75BF7ED5A2A7CAE4ECDEBC916EFDF06B044A
Message to process: 00040E01240131
Current nonce: 118E8C33213D6E353FDF26D2B28D84A5D745CFE2F099D3B2B4AAAAAAAAAAAAAA
HMAC: 215BD88BE0543189561A6FCE26ADFAB61E8CF6C6EB2E16BBD514BD506C55082D
Signature bad: 015BD88BE0543189561A6FCE26ADFAB61E8CF6C6EB2E16BB
6324 Signature verification failed!
6334 !TSF:MSG:SIGN VERIFY FAIL
6400 MCO:SLP:TPD

This is the corresponding output on the gateway:

0;255;3;0;9;TSF:MSG:READ,4-4-0,s=1,c=2,t=36,pt=0,l=0,sg=0:
0;255;3;0;9;Sending message on topic: gateway1-out/4/1/2/0/36
0;255;3;0;9;TSF:MSG:READ,4-4-0,s=255,c=3,t=22,pt=5,l=4,sg=0:1520
0;255;3;0;9;Sending message on topic: gateway1-out/4/255/3/0/22
0;255;3;0;9;Message arrived on topic: gateway1-in/4/1/1/0/36
0;255;3;0;9;Skipping security for command 3 type 16
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=1,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
0;255;3;0;9;Nonce requested from 4. Waiting...
0;255;3;0;9;TSF:MSG:READ,4-4-0,s=255,c=3,t=17,pt=6,l=25,sg=0:118E8C33213D6E353FDF26D2B28D84A5D745CFE2F099D3B2B4
0;255;3;0;9;Nonce received from 4.
0;255;3;0;9;Proceeding with signing...
0;255;3;0;9;Message to process: 00040E01240131
0;255;3;0;9;Current nonce: 118E8C33213D6E353FDF26D2B28D84A5D745CFE2F099D3B2B4AAAAAAAAAAAAAA
0;255;3;0;9;HMAC: 959753BF095A75BF7ED5A2A7CAE4ECDEBC916EFDF06B044ACD49D19B741939C4
0;255;3;0;9;Signature in message: 019753BF095A75BF7ED5A2A7CAE4ECDEBC916EFDF06B044A
0;255;3;0;9;Message signed
0;255;3;0;9;Message to send has been signed
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=1,c=1,t=36,pt=0,l=1,sg=1,ft=0,st=OK:1

Config on the node:

#define MY_SMART_SLEEP_WAIT_DURATION_MS (700ul)
#define MY_DEBUG_VERBOSE_SIGNING //!< Enable signing related debug prints to serial monitor
#define MY_SIGNING_SOFT //!< Software signing
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 //!< Unconnected analog pin for random seed
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SIMPLE_PASSWD "mysecretpw"

Config on the gateway:

#define MY_DEBUG_VERBOSE_SIGNING //!< Enable signing related debug prints to serial monitor
#define MY_SIGNING_SOFT //!< Software signing
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 //!< Unconnected analog pin for random seed
#define MY_SIGNING_SIMPLE_PASSWD "mysecretpw"

Any hint or help would be greatly appreciated!

Best regards,
Christian

[cgrf]

Oh, I forgot to add that I already tried erasing the EEPROM on both devices but that didn't help either.

[Anticimex]

@cgrf the obvious question here is that, did you validate that your personalization is intact, and since you erased eeprom, it isn't. So you must redo personalization, and then the question still stands: are you sure you have the same hmac key at both ends?

Edit: I see that you use the simple password flag, so personalization is not needed. However, if you use that flag, you should not set signing backend. The simple password flag sets everything you need to set with respect to signing.

[Anticimex]

@cgrf another thing is that you don't have the simple password option for version 2.1.1. It was only available as beta prior to 2.2.0.

[cgrf]

@anticimex Thank you very much for your quick response! I didn't realize that the simple password option was not supported in version 2.1.1. Since FOTA doesn't seem to work for me in version 2.2.0 I'll try personalizing my nodes instead, tonight.

[Anticimex]

@cgrf If something is broken in 2.2.0, please report a bug on it.

[cgrf]

@anticimex I will. Right now I'm not sure though, what is actually causing the problem. It might be the library, the bootloader, the controller (MyController), or my general lack of expertise on the topic...

[sindrome73]

But then if I understand correctly, with the current stable version 2.2.0 you can also use:
  #define MY_SIGNING_SIMPLE_PASSWD "mysecretpw"

And it is no longer necessary to customize the nodes and the Gateway ??

If it is so!! Is it safer or less secure ???

[Anticimex]

@sindrome73 it is obviously less secure to use the key directly in your software. It is not protected in any way this is also clearly stated in the documentation (if anyone bothered to actually read it). But many have requested a simpler way of getting "security" so this is the answer. If you want better security, you use the atsha204a and personalize it as documented.

[cgrf]

@anticimex I have configured both devices using the personalization sketch now, and message signing is working perfectly with version 2.1.1! Unfortunately though, this seems to break FOTA again for me. Do you know if this could that actually be related to using message signing?

These are the first lines I see on the gateway after I reset the node that I would expect to get a new firmware over the air:

0;255;3;0;9;TSF:MSG:READ,4-4-255,s=255,c=3,t=7,pt=1,l=1,sg=0:0
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=4
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;Skipping security for command 3 type 8
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=8,pt=1,l=1,sg=1,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,4-4-255,s=255,c=3,t=7,pt=1,l=1,sg=0:0
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=4
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;Skipping security for command 3 type 8
0;255;3;0;9;TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=8,pt=1,l=1,sg=1,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,4-4-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=4
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;Skipping security for command 3 type 8

And I'd like to say that I appreciate the awesome work you are doing here very much! I really try to read and understand the documentation, but in some places it is not that easy to follow.

[Anticimex]

@cgrf Thank you. Regarding FOTA, I am no expert, but signing should not interfere. And I see nothing in the log that suggests it does.
Regarding the documentation, I would love to know what parts are unclear. I hear this a lot, but I have still not received constructive feedback so that I can improve it.

[cgrf]

@anticimex I would say you are right, signing does not seem to have anything to do with the FOTA problems I'm having. I've kept on try the last few hours and all I can say by now is that the firmware upload over the air works ... sometimes. Also rebooting the gateway seems to increase the probability for success. This is getting a little frustrating right now. Anyway, thanks again for your help with signing!

As for the documentation, I'm not very good at that myself. One thing I would suggest is breaking it up into smaller chunks. For example, separate the theoretical background from the technical documentation. Create smaller how-tos for single use cases, e.g. cover soft and ATSHA204 based signing separately. It could also help to state the library version explicitly that each part of the documentation is referring to.

That's probably not much help, but hopefully at least a little constructive.

[Anticimex]

@cgrf well, thanks for the feedback anyway. As for structure, I do have it in chapters. So the technical stuff is separated from other things, and the whole thing starts with how to actually use it, and the theory goes last for those interested. I could split it into separate pages but I feel that just fragments it.
As for the use cases, they are also split and I am not sure how to simplify them further.
As for what version they work with, the current setup is that there are always two versions. One for the most current release here: https://www.mysensors.org/apidocs/index.html
The other is for the beta releases (development branch), which is always bleeding edge here: https://www.mysensors.org/apidocs-beta/index.html

The version is currently to the git sha. But I have a pull request open that will make further releases show a version number instead which better link the documentation to a human readable version.
It will also update the security part of the "library customization" chapter a bit.