2023-04-17 09:29 AM
We deliver encrypted image to the customer-manufacturer. After image update is performed the image is stored opened in internal flash. With RDP level set to 2 it is possible protect from jtag debugging and access. But if hacker at manufacturer side, writes it's own application (both desktop and ST part, residing in SRAM, or even one of internal flash banks) to read internal flash, what kind of physical protection on ST MCU side can be applied at this stage?
Assume experienced hacker can write it's own "CubeProgrammer tool", which would read internal flash. How flash can be protected from that?
2023-04-17 10:02 AM
Perhaps have a roster of staff at least as smart as the hacker(s)?
Involve some of your own trusted staff at manufacture.
Have a method of delivery that uses root of trust, and sends a device unique firmware to each device, tied to things that the manufacturer doesn't know or control. ie server equipment you own/manage, private keys
2023-04-17 12:18 PM
ST offers a toolset named SFI which addresses this concern.
2023-04-18 12:55 AM
If a word 'hacker' confuses let's explain it as somebody at customer-manufacturer side, who wants illegally copy the firmware, which resides decrypted in internal flash. Since it is already decrypted manufacturer doesn't need to know the key at this moment. Is internal flash protected from that? By what means?
2023-04-18 01:11 AM
If I strictly follow the steps of using this tool, I will not be able to extract the encrypted image. But after I have finished flashing the firmware it resides decrypted in internal flash. ST offers SFI tool to write into internal flash. What means can guarantee, that similar tool, which reads decrypted internal flash instead of writing it, can' be created? And another side of this question if how verification, that firmware was flashed correctly and is bitwise with original one, is performed?