I have secure boot working and I understand roughly what Uboot is doing using esbc_validate. However, I'm trying to create an upgrade utility that verifies that a specific header file, generated with cst 2.x, is associated with a specific fit (kernel, dtbs, rootfs) image.
Placing the csf security header at its correct offset, and placing the fit image at its offset works just fine for booting. However I want to verify those PRIOR to placing them in their respective locations.
I understand the public key is embedded in the csf so I have to extract that. I'm a little confused after that. I think I need to extract the RSA signature and use the extracted public key on that to get a hash, and somehow that hash is tied to the fit image, but its not simply a hash of the fit image?
I've already managed to pull the SRKH from the blown fuses so I can compare that.
At the moment Google/Gemini isn't being much help.
Thoughts?
The signature is not just a hash of the FIT . For this secure-boot flow, it authenticates a SHA-256 digest of the CSF header, the image bytes specified by that header, the public key material, and the SG table if used. Validation also checks the key against the fused SRKH.
So, before installing either file , your utility must parse the candidate header, use its size and offset fields to select the correct bytes from the candidate FIT, calculate the digest over the complete signed data, and verify the extracted RSA signature with the validated public key. If verification passes, that header is associated with those authenticated FIT bytes. A FIT-only SHA-256 comparison will not work.