Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 8051

General • Re: RP2350-E16: Can debug key installation compensate for CRIT1.DEBUG_DISABLE = 0?

$
0
0
OK, so you'd like (in the bootrom)

1) a way to mark a page of OTP for "device secret" (such that it can be locked down) - possibly allowing for >1 even with FIB readout mitigation
2) This page would be locked down before entering PC/SP reboot, BOOTSEL (as you can do today with permissions) etc. or indeed any user code (even via a valid signed image)
Yes.
3) possibly under control of new metadata in the IMAGE_DEF (both to enable possibly, but also to select device secret index perhaps), the derived secret could be stored somewhere (possibly BOOTRAM) when booting a signed image
There's no point in storing more than the 2 secrets described in the OTP, the derived secret given to user code is already keyed with the hash of said code, so everything already gets a different key by design. The 2nd secret only helps in the non-personalized (image is encrypted with a common key shared by every device) use-case, when stage1 is compromised/needs to be changed for some reason. It makes sense to include it since locking is page-level, so we have free space there that would otherwise sit unused, but anything beyond that doesn't help.
I don't think having a enable/disable thing in the IMAGE_DEF metadata is worth it, deriving both secrets for the user code is just 4 sha256 blocks operations, so a couple hundred cycles at most.

---

I also noticed another issue, DEBUGEN apparently survives resets that the SW_LOCK registers don't, which means any user code can just enable debugging again in DEBUGEN, reset the chip and then skip the ROM code that would lock the page. The bootrom could set DEBUGEN_LOCK to avoid this but that really sucks. So ideally the SW_LOCK of the OTP secret page would also reset only when DEBUGEN is also reset. I'm guessing this isn't done for SW_LOCK registers in general because of power limitations, but for one page it should be fine. Obviously this needs more then a bootrom change though.

This seems to have been missed in the enc_bootloader example as well.

Statistics: Posted by Tharre — Sat May 03, 2025 8:19 pm



Viewing all articles
Browse latest Browse all 8051

Trending Articles