How code in internal flash of STM32U5 can be protected from copying, if it is stored decrypted?

[VTver.1]

Flash writing procedure has just finished. The next step, anyone can assume, is verification, that code has been written correctly, which involves reading the flashed memory. At this stage, if I trace the API calls, which Cube tool does to perform flash reading. Does this mean I can copy the firmware without having vendor keys? Please point me at which step I'm wrong.

[Aime]

Hi @VTver.1​ ,

If you want to verify that your code has been written correctly on your MCU, I would recommend to use STM32CubeProgrammer.

In the "Memory & File editing" tab click on "+" and "Compare memory with file" , then select your .hex or .bin file to compare with the internal memory  .

 

Best Regards,

A.MVE

[gbm]

Normally, during factory programing, the memory is written, then verified, THEN PROTECTED. After it's protected, it's no longer possible to debug or read the memory with a programmer/debug interface.

[VTver.1]

Thank you @Aime​ 

My actual concern is how Cube does this compare operation. It reads internal flash (by some portions) which is decrypted, and then compared with decrypted binary? So, if I have the tool, which would record the calls/messages Cube sends to do this, I can then repeat them in my own code and obtain the firmware in internal flash? How internal flash can be protected against that?

[VTver.1]

Thank you, @gbm​ 

But if I trace the calls Cube does to perform verification, I can repeat them in my own tool, and using another device I can get the firmware? Is there any protection against that?

Also please see the above picture, how memory comparison works, after memory is protected?

[Aime]

Hi @VTver.1​ ,

Sorry I misunderstood your concern, if you want to protect your internal code on U5 devices, you can used the key security features on U5 devices :

• Debug protection, depending on the RDP level
• Optional password-based RDP level regressions, including for RDP level 2
• Protected firmware distribution scheme, using TrustZone, on-the-fly decryption, and RDP level 0.5
• Active tamper and protection against temperature, voltage and frequency attacks

Please refer to the section 3 "System security" on the attached reference manual.

A.MVE

[Aime]

@VTver.1​ , once protected your firmware won't be accessible even by STMCubeProgrammer. The picture above works only if the device is not protected

[VTver.1]

Hi @Aime​ 

I have read this manual with other documents. And my question exists, because the documentation (as it seems to me now) doesn't address that particular case, I have specified in the question. And the case is the protection during verification operation after flashing. (RDP hasn't been set to protection level at this moment) If I record the communication protocol between Cube tool and target, and repeat it in my own tool, does it mean I can read the flash firmware from the next device being flashed?

I would be happy, if you navigate me, where this case is addressed in the documentation.

[VTver.1]

Thank you, @Aime​, for a good point. Could you please provide a bit more details on that? If the firmware is not accessible by STMCubeProgrammer, how verification is performed? How the user gets answer that everything has been flashed correctly?

[gbm]

Your question was already answered TWICE. Just read the answers.