Posted on August 28, 2014 at 20:54Clive, you wrote:
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.
From the reference manual for the STM32L0x RDP level 1 means,
-
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.
So it seems to be the case that there is no way to circumvent RDP, even level 1, using a RAM program. Does this contradict your quote above? If not, what is the attack you believe is still available?
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.
RDP level 2 eliminates access to the system memory and SWI,
-
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.
That seems pretty reasonable to me.
There are certainly attacks on the physical die that are devilishly difficult to thwart. I've read that some secure MCUs include an extra conductive metal layer over the functional portions of the die to impede probing.
I think that the question most people are asking is this. Can we rely on the RDP (and now Firewall) protections of the STM32 microcontrollers to block attempts to read our code and data via the MCU pins?
This is in light of the documented failings in the MSP430 where clock glitching allows a modest hacking effort to circumvent memory protections of the MCU.
Cheers
