💬 Ikea Molgan Hack

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

[Anticimex]

@LastSamurai alright. Perhaps the molgan sketch does some eeprom operations which inadvertently erases the key. You could try to read the key from eeprom early in the sketch after it was personalized just to confirm it had the key at some point at least.

[LastSamurai]

Hah success! Until now I was programming the chip directly via an USBasp (ignoring any bootloaders). I guess thats how I "bricked" the other chip (accidentally burning fuses that indicate an external clock...).

Today I burned a bootloader (with the right fuses) to the new board and uploaded the securityPersonalizer and the molgan sketch via serial... and everything is working! It takes some (re)tries to get the signing up and running but after ~2 seconds the molgan board showed up in the gateway log. Now I'll only have to connect the new board to the molgan pcb and hope that everything still works.

I still don't know why it wasn't working before though. I have some other chips that I programmed via ISP and they work well with signing too...

[Anticimex]

@LastSamurai nice. My best bet is that you somehow erased your eeprom after personalizing it. But anyway, nice that you are fully up and running now :)