-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider using SHA2-256 for RoT FWID measurements #1548
Comments
I'd like to save some flash and RAM and I don't think that the differences in algorithm strength apply to this case given that there is also a signature check and image format tests. |
Closing, we're all tooled up for SHA3-256 for Firmware ID (FWID) and there doesn't seem to be a compelling reason to move to the HW-supported SHA2-256. Upcoming PR does make the FWID an enum with one SHA3-256 variant to make it easier to change this in the future. |
This PR has four commits to simplify reviewing. - The first is Laura's macro to manipulate the HASHCRYPT interrupt vector. - 2nd is pre-main kernel changes to create a staging area for Bootleby update and to validate the (now) four RoT flash banks and record those results for use by update_server. - 3rd are the API changes to support stage0 update including treating the bootloader as a separate component with A (active) and B (stage0next) banks. - last is the code in the RoT update_server to actually update stage0 Before merging this PR, Cargo.toml needs to be edited to reference the gateway-message-service main branch. Merging needs to be coordinated with an MGS merge. Closes #1043, #1404, #1548, #1353,
The software implementation of SHA3-256 adds to flash and RAM requirements more than using the hardware implementation of SHA2-256 that is available from the LPC55 ROM.
TODO:
The text was updated successfully, but these errors were encountered: