STM32U0 OEMiRoT RDP regression appnote?

[Hans_W]

I'm trying to find out the exact steps to regress an STM32U083 to an erased state after programming it with the OEMiRoT example project and and locking it to RDP2 by the accompanying provisioning.bat script.
Will be using STM32CubeProgrammerCLI (or the GUI version at first just to test the steps) for the regression.

Something like chapter 10 of the STM32U5 AN5347 would be nice (https://www.st.com/resource/en/application_note/dm00625692-stm32l5-series-trustzone-features-stmicroelectronics.pdf)

or like this forum post on U5: https://community.st.com/t5/stm32-mcus/how-to-regress-from-rdp-level-2-to-rdp-level-0-on-the-stm32u5/ta-p/568476

Especially the "Disable RDP regression with a password" action in the programmer GUI seems very counter-intuitive to do for an RDP2 level locked chip, as if you would deliberately brick it by disabling the regression (no password in level 2 = bricked). Is this always a safe step? Because as long as the level is 2, the password will be necessary to regress.

[Bubbles]

Hi @Hans_W ,

there's this wiki article: Security:RDP for STM32U0 - stm32mcu

Secondly, the Cube programmer alternatively has a command line parameters to work with. Look for regression.bat in the STM32U0Cube package for working example. 

Regarding the GUI, what exactly do you suggest to improve?

BR,

J

[Hans_W]

Hi Bubbles,

I know the flow between the RDP states, but the procedure in the STM32CubeProgrammer is a bit different from U5 I guess, and the steps are not that clear. What does "Disable password"' do for example? Its name suggest removing the OEM key, but wouldn't that brick the device? without that password you cannot unlock anymore.

An appnote describing the necessary steps in the correct order would clarify a lot.

Besides that, I didn't find regression.bat in the STM32Cube_FW_U0_V1.1.0 folder structure where I copied the OEMiRoT project from.

[Bubbles · Accepted solution]

hi @Hans_W ,

according to UM2237 the "Disable password" would indeed remove the OEM key. That does not brick the device, but it will burn the bridge and the device will be forever locked in RDP2. That's certainly something to avoid during development, but it's a valid product state when the product is deployed.

The regression batch was missing in v1.1.0 but version 1.2.0 was recently posted on our website.

I'm not sure if the decision to cover the regression with an appnote will be made, but at least I can try to clarify more on that security wiki page I linked in my first reply.

Thanks a lot for your feedback.

J

[Hans_W]

For me, it is essential that the possibility exists to reprogram devices (refurbish) by unlocking using the OEM2KEY. In that sense it would become bricked when the programming PC would issue the erase password in this stage when it hasn't confirmed that the unlock was complete. It then becomes e-waste.

On the other hand, I understand that leaving the OEM2KEY unchanged does not pose any problems, after unlocking to RDP 0 it can always be changed to something else in case we will be using random OEM keys for each device. Unfortunately you cannot read the chip unique ID while in RDP2 to link the OEM2KEY to that, unless an existing application can tell you that before reprogramming.

I just downloaded the V1.2.0 package, let's see what's new in there...