Checksum documentation - Githubissues

dmitrystu / sboot_stm32

Secure USB DFU1.1 bootloader for STM32

Apache License 2.0

303 stars 63 forks source link

Checksum documentation #44

Open dzarda opened 2 years ago

dzarda commented 2 years ago

It's not entirely obvious how the firmware checksum validation works. I seem to have some idea but would like confirmation.

Encrypter appends checksum and verifies that remainder reaches zero only at the end of image
Bootloader verifies the whole flash region (_APP_START up until __romend)

Does this mean that the application image should be linked with the resultant size of __romend - _APP_START - 4 in order to guarantee correct checksum verification?

dmitrystu commented 2 years ago

No. This will work for CRC, but not for FNV1A
Not quite. Bootloader verifies flash memory until a checksum collision was found or __romend - sizeof(checksum) was reached.

Therefore, not necessary to get the resultant size of the full free ROM. The еncryptor checks firmware for the collisions after appending checksum and guarantee the only correct collision exist. Of course, there is a small probability to get a bad collision in the junked free space or in the broken firmware, but this is applicable to any type of hash or CRC. BTW. I have tested and compared CRC32 vs FNV1A32 on the random data and found that FNV is much better for this use case.

dzarda commented 2 years ago

Okay. I'm trying to figure out the probability of collision in the free space... Logic tells me that in case of 65k of free space, this amount would simply be subtracted from the 4 billion possible codes, only introducing a very slight probability, as you say.

Also when considering the remainder of flash memory - that's not really random data, is it. Perhaps would be better modeled as FFFF.

dzarda commented 2 years ago

Actually, after further thought, the probability is quite a bit more substantial IMHO. Introducing 65000 more OK-codes does not simply subtract, but rather divide the checksum codespace by that amount.

That's moving from 1 in 4B towards 65k in 4B. Therefore the resultant checksum would only have a strenght of 16 bits instead of 32. Again, that's when considering random distribution.

dmitrystu commented 2 years ago

Found an interesting article. So I think that 32-bit checksums are good for the small devices, but I prefer a 64-bit if it doesn't consume an extra flash page.