On 09-04-2008 at 16:14, Anonymous wrote:
Protection, Is my code in Flash really secure?
I want my code in Flash to be secure from downloading by anybody else.
On 16-04-2008 at 19:20, Anonymous wrote:
Hi Lanchon,hholms,greg_stm,obtronix, renon,
Is the PM0042 not enought clear on this protection point ?
[ This message was edited by: STOne-32 on 01-05-2008 19:21 ]
On 28-05-2008 at 08:29, Anonymous wrote:
thanks. I see the protection section has been rewritten. however I believe only two phrases are really relevant to this discussion; it says:
"Main Flash memory read access is not allowed except for the user code (when booting from main Flash memory itself with the debug mode not active)."
where is the term "debug mode" defined, how and at what times can it be activated, and what does it mean to boot with the debug mode not active?
"[...] the memory can be programmed by the code executed from the main Flash memory (for IAP, constant storage, etc.), but it is protected against write/erase (but not against mass erase) in debug mode or when booting from the embedded SRAM."
what about booting into the bootloader with RDP enabled? does the bootloader have main flash read and/or write access (even though it doesn't use it)?
this is an improvement, but the security model is still not clear. it seems that coming out of reset a decision is made weather to permit or deny access to the main flash for both read and write, that won't be reviewed until next reset.
if this is true ST should clearly say so, and explain in exact non-ambiguous terms when and how the decision is taken, what the direct consequences of the decision are and how they are implemented. (also how the whole system works to protect code if this corollary is not completely obvious.) and ST could even take the opportunity to *sell the stm32* by explaining extras such as how the reset-time decision is cleverly protected from malicious reset and power glitches, how the protection cells are hardened to withstand certain physical attacks, etc.
as it stands, I'm afraid the unspecified security model continues to be a show-stopper for the STM32 in my application.
Once the protection byte has been programmed:
● Main Flash memory read access is not allowed except for the user code (when booting from main Flash memory itself with the debug mode not active).
I am not concerned about my code running in RAM (copied from my code in flash) and reading from flash. I am concerned about malicious code copied to my end product's RAM via JTAG (or any other method) and reading out my code in flash. As far as I understand it, it will be possible to copy code to RAM, but it will not have read access to flash. This can be used to clear Read-out protection and once this is done, a mass erase of the flash will occur. Again, I assume the spec's are correctly implemented ;-).
You can't remove/change the system loader whichstarts when BOOT0=High. On the F1 it's possible to boot into RAM, anduse JTAG to download into RAM regardless of the RDP state.
No access to the Flash program memory and data EEPROM (read both for fetch and data and write) and no backup register reading is performed if the debug features (single-wire), or the device boot in the RAM, or the System memory is connected. If the user tries to read the Flash memory or data EEPROM, a bus error is generated. No restriction is present on other areas: it is possible to read and write/erase the Option bytes area and to execute or read in the System Memory.
Evenif you replaced the system loader, or some how came up with some magicloader that you thought was more robust, it would still be vulnerable toseveral vectors of attack, especially the physical ones. ST once statedit would take >$1M of equipment, but I would suggest you only needaccess and expertise of such equipment, try any university campus, orany IC QA lab.
Level 2 is set when RDPROT is set to 0xCC. When this level is enabled, it is only possible to boot from the Flash program memory, and the debug features (single-wire) are disabled. The Option bytes are protected against write/erase and the protection level can no longer be changed. The application can write/erase to the Flash program memory and data EEPROM (it is only possible to boot from the Flash program memory and execute the customer code) and access the backup registers. When an Option bytes loading is executed and Level 2 is enabled, old information on debug or boot in the RAM or System memory are deleted.
Retrieving data ...