Ian Hall from Renesas put a sample secure bootloader project ("YASB") on github. Ian's python program prepends a 0x100-byte signature header to the application image and then performs the hash calculation starting from inside the header, rather than from the start of the application image. It would seem the most straightforward way would be to calculate the hash based solely on the application image, generate the signature from it, and prepend the header to the image.
I'm sure there must be a good reason for including part of the header in the hash calculation so I'd appreciate understanding why it was done this way.
Thanks
tom
I think you are refering to imgtool.py from MCUBoot
https://github.com/mcu-tools/mcuboot/blob/master/docs/design.md
The hash covers both hdr and body
#define IMAGE_TLV_SHA256 0x10 /* SHA256 of image hdr and body */The hdr contains info such as version, load address, image size(exclude header) which must be integrity checked.e.g. I change version and a previous image with known vulnerability could be reloaded.Such info could have been embedded in application image. mcuboot would need to know where it is located, when itperform checks for downgrade prevention. It can be done but from mcuboot perspective, an external header is easier to manage. IMHO.
Hi,
It would be more straight forward to just hash the application but that would allow the length of the image and the more importantly the version of the image to be changed without detection. Being able to change the version number would allow a downgrade attack to be implemented by simply changing the image version of an old image to that of a higher one to be accepted by the bootloader. By including the version in the hash then this is prevented.
Ian.
Yes I see now. Thanks for the clarification and thanks to CS Yep for the response.