💬 Ikea Molgan Hack

[Anticimex]

@LastSamurai I am not sure what you mean by hmac keys in the log? Hmac key is never shown in the log. Where is this hmac key you mention? I only see nonce data and that is (or should be) random.
Edit: the log from the GW shows the resulting hmac signature. Not the key. I guess your personalized keys differ between gw and node.

[LastSamurai]

@Anticimex What's a hmac signature? And personalized keys = serial number? So this is working as intended?
Any idea where the error could be? Software setup should be right and the power supply is big enough (its actually an old pc power supply), so why is the signing not working with this one node?

Sketch settings:

#define MY_NODE_ID 8
#define MY_RADIO_NRF24
#define MY_DEBUG    // Enables debug messages in the serial log
#define MY_BAUD_RATE  9600 // Sets the serial baud rate for console and serial gateway
#define MY_SIGNING_SOFT // Enables software signing
#define MY_SIGNING_REQUEST_SIGNATURES // Always request signing from gateway
#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // floating pin for randomness

[Anticimex]

@LastSamurai hmac signature is just that, the signature. The concepts are described in the documentation for signing.
And I don't understand what you mean with key = serial. Key and serial are two different things. One needs to be identical on all nodes and the other should be unique and is only used for whitelisting. This is also described in detail in the documentation.

[LastSamurai]

Yes the HMAC key has to be the same on all nodes. I did use the same HMAC key on all nodes.
So you mean that the logs indicate that the HMAC keys on gw and node aren't the same?

[Anticimex]

@LastSamurai no, I am saying that the hmac key is never shown in the log. The hmac signature is. Hmac key and hmac signature are two different things.
The log say that verification fails which means the hmac signature is calculated differently at sender vs receiver. That means one of these options:

1. Hmac key is different at sender and receiver
2. Message has been tampered during transit
3. Sender and/or receiver are using whitelisting but it is incorrectly configured. I recommend you only enable whitelisting if you are sure you know what you are doing, and I see no such indication from the snippets that you have provided.

You can enable verbose signing debug on the node to see what hmac signature is calculated at that end. Most likely it will be different compared to the hmac signature printed on the GW (for the same message).

[Anticimex]

There is also a fourth option, one I have only seen on gateways, only when memory is near full and with verbose prints active and only on a feature branch based on the development where I have seen the hmac key getting corrupted (this case is only for soft signing). I believe it is due to the stack growing into the heap. So you could try to disable verbose logging, or logging altogether on the GW and see if that affects things. It is a long short but worth a try if you are 110% sure you use identical hmac keys on node and gw.

[LastSamurai]

I just tested everything again. Enabled/disabled any debugging on the gw side and reuploaded HMAC and serial keys to both the molgan and the gw (using the same sketch with unchanged HMAC and changed serial). Whitelisting isn't used here (although I am using it with some of my RGBW controller nodes and its working just fine there).
Sadly it did not work .

The molgan node is using slightly different fuse settings only running at 8 Mhz and with 1.8V BOD (fuses: L 0xE2, H 0xDA, E0x06). Could this impact the software signing process? Also are different baudrates for the personalizer sketch supported? When I ran it I only got rubbish on the 115200 baud console (though the rough outline of the normal output). So I searched around in the code and finally added this at the beginning:

...
#define MY_BAUD_RATE 9600
#define MY_CORE_ONLY
#include <MySensors.h>
...

redefining the baud rate. Afterwards the 9600 baud console printed out the expected values. This has only be done on the molgan, not the gateway. Could this somehow have interfered with signing?

@Yveaux , @AWI and others did you (successfully) use signing with the molgan?

[Anticimex]

@LastSamurai baud rate has no impact on the signing, it's only for serial log.
Clock frequency should not have impact on soft signing, it can have on atsha204a as it uses bit banging. But I have run successfully both soft and atsha signing on 8 and 16 MHz. What arch is used? AVR? That is what I use for my development, although it should work on all supported archs.

[LastSamurai]

Its an Atmega328P, so an AVR processor if thats what you mean.

[Anticimex]

@LastSamurai ok, and what about memory? Do you have a percentage of how much ram there is left after programming?

[Anticimex]

@LastSamurai I find it slightly disturbing that you say 115200 baudrate does not work. That would suggest the clock is not running as it should. I can run 115200 just fine on my Nano (16MHz) and Pro mini (8Mhz).
The personalizer on the development branch uses the baudrate set by the MyConfig.h setting (MY_BAUD_RATE) so you define it using that flag (as you found out).

[Yveaux]

@Anticimex the Molgan Hack uses the internal oscillator, not an external crystal like the nano and pro mini.
The internal oscillator is less accurate, hence the lower baud rate.

[Anticimex]

@Yveaux ah, ok. That explains that then. But to my knowledge there is no timing dependency for software signing, except the signing timeout. But I think there is a debug message if that fires. If not, perhaps @LastSamurai could try to increase the timeout (currently at 5000 ms).

[LastSamurai]

Ok for the molgan sketch the arduino IDE spits this out:

• list item22.602 Bytes (73%) of memory
• list itemglobal variables 56% of dynamic memory

How do you change the timeout? Quick googling only turned up requests to make it configurable...

[Anticimex]

@LastSamurai it is configurable, and clearly visible where all signing configuration parameters are located in MyConfig.h. Look for MY_VERIFICATION_TIMEOUT_MS.

[LastSamurai]

Thanks, haven't really looked in that file since the upgrade to mysensors 2. Doing it all in the sketches now. I'll test it and get back to you.

[Anticimex]

@LastSamurai I do not think the timeout is the issue here, but worth a try anyway. The memory usage is in the red zone if over 70% I'd say so I suspect the hmac key gets corrupted by a stack that grows into the heap. You can test that by adding a debug print in the soft signing backend that dumps your hmac key before it is set. Assuming you run the latest stable release you'd want to place the print just before this line. You can copy this line and replace _signing_hmac with _signing_hmac_key. Also change the HMAC text to HMAC KEY to tell them apart (and don't post your printed key here ;))
This to verify that the key used is the key you personalized and that it has not been corrupted.

[LastSamurai]

@Anticimex So adding this around the line 325 should do the trick, right?

// Feed "message" to HMAC calculator
	DEBUG_SIGNING_PRINTBUF(F("HMAC key debug: "), _signing_hmac_key, 32);
	_signing_sha256.initHmac(_signing_hmac_key,32); // Set the key to use

The output of that is

HMAC key debug: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

which is definitly not my HMAC key!

PS Changing the timeout did not change this.

[Anticimex]

@LastSamurai alright, so there are now three options:

1. Your device is not properly personalized
2. Your key has been overwritten in eeprom by some other part of your sketch during runtime
3. Your key has been erased by stack growth (unlikely since it very much look like eeprom reset value)

You can test the various scenarios by moving your newly added print to various places in the backend. For instance, adding it just after the value is fetched from eeprom in the init function of the backend would tell you if the value is bad in eeprom or is erased in ram at a later stage.

[LastSamurai]

The HMAC key seems to already have been FFFFF.... when read from EPROM. While testing some more I somehow seem to have bricked the atmega328 though :( I just soldered a new board and will to some more testing tomorrow.