Thank you for the insight, I see where you are coming from. I am in somewhat of a unique situation where I pretty much lock down every other boot method, and use OTP for loading my own bootloader into ram, which handles loading and validating itself via uart from a host controller. I think in this special case, the debug key is a valid workaround, although I have yet to test to confirm.The issue is that even though, as far as I understand the related circuitry from the datasheet, installing debugs keys would actually disable debug access at first this doesn't gain you much. The bootrom is setup to only support secure boot under ARM (as the datasheet tells us), not RISC-V, and as far as I can see there's nothing that would abort boot in this case. This means that we are free to fill the flash chip with whatever attacker payload we desire, read the OTP registers and indeed turn debug access back on with the DEBUGEN register.
It may actually be possible to fix this if you disable every other boot option apart from OTP (in addition to installing debug keys), which contains a bootloader that aborts when this case is detected and otherwise just implements the normal flash-boot logic like the bootrom does. Not entirely sure if this would work, though even if it does it imposes significant restrictions on what you can do with the microcontroller.
Statistics: Posted by chack131 — Mon May 05, 2025 6:23 pm