1) Base profile (signature checking with pinned public keys)
2) Extension for key revocation + certificate handling
3) Extension for attestation (DICE++)
UDS + hash of the next boot stage image + device state (e-fuses for debug/production/return for testing)
UDS -> use a set of CSRs that can be read only once during boot ?
4) Extension support encrypted images (be able to decrypt next boot stage)
5) Extension for secure update
6) Two way authentication ?
symmetric encryption for secure update / encrypted images: AES256-CBC GCM mode (GCM mode was the prefered one)
backwards certificate chain verification ?
UDS only readable from BootROM and a single hart (not accessible from other devices)
A CSR field for the device's state (to indicate if the device is under manufacture/debug/production etc stage -> check Google doc on OpenTitan)
Secure boot process runs on a single hart, the rest of the system remains on reset
Hardware debug interfaces are disabled on production
SRAM only available to the boot hart ?
Bootrom only available to boot hart ?
Lock mtvec CSR (through a bit on mseccfg) ?
State during reset
Hiding the bootrom
Hiding the UDS after bootrom access (e.g. acessing it through CSRs)
Non-leaky crypto primiitves (for hashing etc), not vulnerable to timing / dpa attacks -> For secure update / image encryption support (optional)