Hi everyone! I am working with a client that is concerned about security on the STM32 - specifically the ability to attach a debugger and get heightened access to the flash. RDP level 1 prevents a debugger from reading out the flash, but the bit flags used to indicate level 2 is only one bit-flip away from a level that allows debugger access - and intentional perturbations of the chip (heat, etc) can induce that bit flip.
Specifically: TM32 RDP at level 1 prevents a debugger from reading out flash but still allows debugging and at level 2 disables all debug. Level 0 is 0xAA, Level 2 is 0xCC and Level 1 is any other number. The problem with this is any single bit flip from level 2 makes it level 1, which re-enables debug. This has been shown with lasers and UV exposure but the most dangerous is voltage or clockscrew attacks as these are becoming very cheap.
Although not foolproof, one effective mitigation of the effects of this attack is to stop the application from running early in the boot. So, what we have is a modification to RIOT OS to check the STM32 RDP level early in boot. We not only check it but do it in a way which is itself resistant to voltage/clockscrew attacks. The layout of the code is important, it’s written exactly to force the compiler to produce useful patterns. The two biggest issues we are worried about in glitch resistance is 1) bitflip on read or 2) a skipped instruction. To address 1, when reading RDP, we do so 3 times and make sure all reads were consistent. Whenever we do compare it against the reference value, we do so twice in hopes a skipped instruction will lead the attack straight into the second check. Glitch attacks are inconsistent, so even if the attacker could pass these mitigations once, we do this combo 3 times.
The total effect is a strong mitigation against UV/laser/glitch attacks for all products based on RIOT OS with a supported STM32 chip, an assurance that the designer’s choice in RDP will not be easily circumvented.
We created an issue (https://github.com/RIOT-OS/RIOT/issues/16925) and a PR (https://github.com/RIOT-OS/RIOT/pull/16979) but are blocked as needing review from one of @aabadie, @DipSwitch, fjmolinas, or vincent-d. (Only two mentioned due to new poster restrictions.)
Any suggestions on the patch or issue?
Thanks, Van
(Working for an OSPOCO client)