Contest Winner

@encrypt great news! Thanks for joining the community and for your troubleshooting. This information will be compiled into the docs for future reference. Happy signing

@encrypt ah, that would indeed explain a lot and especially the tampered indication.
If true, I'll see if I can add that to the troubleshooting section to the documentation.
I was not aware of this fuse.

@encrypt but I still do not get how the bootloader could cause you to get tampered eeprom data.
Unless the fuses also affect eeprom writes of course.

@encrypt sorry no. There is no direct dependency between the security functionality and avr fuses. Atsha communications and some timeouts do expect the clocks to be working at expected rates though so the concept of time is valid. If the core clock is not matching what the preprocessor flags specify (F_CPU) then there could be problems.
Perhaps your device is not really running @8Mhz?

Perhaps you could test running a simple sketch that prints something at a specific pace and match that with a "real" clock. For example printing something every 10s specified by some delay or wait function and measure that that is reasonably accurate.

I would expect that if the MCU is not executing at the speed F_CPU specifies, a thing like delay(10s) would not really delay for 10s.

@encrypt hm ok. Try to enable the MY_SIGNING_SOFT flag. I am on cell phone so I have a hard time reading the logic flow of the code.

@encrypt that sounds very strange to me. The sketch is written to do nothing when left unchanged from git. Just output the current status.

@encrypt you should be able to run it without any local modifications to get it to print the data.

@encrypt normally when this happens, it is the main sketch that writes something to eeprom without taking into consideration what parts of the eeprom the MySensors library reserves for internal use.
Could you try to run the personalizer to write the eeprom, then your main sketch, and after that the personalizer again, but this time, configured to not write any data, just print out what is already there?
Sara should be identical but I strongly suspect it will not be (as the main sketch consider data "tampered").

@encrypt
The key here is "!SGN:PER:Tampered".
The security backend checks a checksum of the eeprom data used for security. If it is not valid, it considers data tampered and will not use it. So your eeprom has been corrupted one way or another. Or you use either a really old personalizer or a really old library version.
Edit: not old library. And old library would not care about checksum.

@kimot AES key is stored in eeprom for all radios. It is fetched and loaded to the radio in runtime. Not compiletime.