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, @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]

@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]

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?

[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

[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.

[gbm]

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

[VTver.1]

Thank you, @gbm​ , quoting your answer, " Normally, during factory programing, the memory is written, then verified, THEN PROTECTED.", can I conclude that during verification the memory is NOT protected, and all my concerns about the security of this step are reasonable? I haven't found anything refuting my concerns in this discussion thread.

[Pavel A.]

Have you seen https://wiki.st.com/stm32mcu/wiki/Security:SFI ?

[VTver.1]

Thank you @Pavel A.​ My question refers exactly regarding the SFI procedure, described in the link you shared with me. The user needs to know the answer, if the device was flashed correctly or not. (This is quite obvious) Then, how the verification of the internal flash, being written with decrypted code is performed? The link you provided, and other documents I have searched, don't contain information about this step and it's security. It would be really helpful, if you could provide more details on this step.

[Pavel A.]

@JHOUD​ @Jocelyn RICARD​  @Aime​ could you help here, please?

[Jocelyn RICARD]

Hello @VTver.1​ ,

From your first question, I understand you are flashing a firmware in clear. So, no need to read it back from device because you already have it on the PC.

Now, regarding SFI, this addresses the installation of a firmware in an untrusted environment.

This requires specific tools and a HSM as described in the Wiki.

The firmware installation is actually done by the chip itself.

It receives the encrypted firmware from the programmer, decrypts it, write it to flash and then finally check is was properly written. When the whole firmware is flashed, the programmer sends the last block that contains the encrypted option bytes to setup. This is usually the last command send, after that, the device is closed and ready to go.

I hope it answers your question

Best regards

Jocelyn

[Pavel A.]

@Jocelyn RICARD​ What if [in untrusted environment] this last command is blocked so the firmware remains open to read out?

[Jocelyn RICARD]

Hello Pavel,

The SFI can only run with minimum security level enabled (RDP 0.5 on U5), with a boot forced on RSS.

If the SFI process is interrupted, by a reset for instance, at next boot, SFI process is still enabled and interruption is detected. Everything is then erased.

Best regards

Jocelyn

[VTver.1]

Thank you @Jocelyn RICARD​, The erase will occur in case and after next reset? The device itself will be erased, that is clear, but before the reset, the firmware remains open and could be read from PC side? And please confirm my 2nd question about the next version software update:

And if at untrusted site, we want to upgrade the firmware again, as soon as we boot from RSS with RDP set to 0.5 or above the flash gets erased?

[Jocelyn RICARD]

Hello @VTver.1​ ,

As I said, the process is secured. You cannot connect to a device that is running SFI. JTAG is disabled.

Once you have finished SFI, the firmware is installed an secure.

If you want to install another version of the firmware, you need to have a secure boot in your firmware that will install this new version of the application. SFI will not be involved anymore.

Best regards,

Jocelyn

[VTver.1]

Thank you @Jocelyn RICARD​. The SFI can be performed only once? Any version upgrade on external site can't be performed with it?

Then what I need to do, to get firmware protected/erased during following version update? Will it be erased automatically, if I boot from RSS?