you may check developer guide, especially for the Security chapter.
moreover,
PKC for sign:
if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption:
if SBK is burned, then the SBKFILE users provide is for encrypting the images.
KEKs for encryption keys:
they are keys to encrypt your keys. KEK0, KEK1, KEK2 are 128-bit key files; KEK256 is 256-bit key file. please use the commands, --KEK* to determine which key encryption key you’re going to fused.
Thank you for your answer.
I have a follow up questions:
My goal is to see the different logs with and without secure boot (learning purposes).
from my understanding there are two paths for the secure boot:
bootROM → … → UEFI
UEFI → secured images (kernel/dtb/rootfs…)
Can I test or use the first path without actually blow a fuse? (I wish to do it to produce secure boot log and then revert the changes)
Can I test the second path without the first path? I mean that if I skip securing all the images until UEFI because I don’t want to blow fuses, can I secure the images loaded by UEFI and see different boot log?
I use the initrd tool to flash my devkit (external nvme). Should I use it to sign and flash the secured apps or still use the flash.sh as it appears in the instructions?
you’ll see bootloader logs (MB2) with… RSA PSS signature check if you’ve SecureBoot enabled.
please see-also Topic 158361, you may performing two steps approach to fuse a board, please review all those keys has created correctly, and also keep flashcmd.txt file for further confirmation.