26.5.8 Security Bit and Chip Erase Hard Lock Bit
The Security Bit (SB) allows the entire chip to be locked from external access for code security (The debugger can only access the DSU register external address space and available commands are limited. Refer to the Intellectual Property Protection chapter). The security bit can be written by a dedicated command, Set Security Bit (SSB). The protection will only apply after the next chip reset, and will be visible in the DSU STATUSB.PROT bit and the NVMCTRL STATUS.SB bit. Once set, the only way to clear the security bit is through a debugger Chip Erase command. After issuing the SSB command, the STATUS.PROGE error bit can be checked.
In order to increase the security level it is recommended to enable the internal BODVDD when the security bit is set.
The CEHL bit allows to permanently disable the debugger chip erase feature. It can be written by a dedicated command, Set Chip Erase Hard Lock (SCEHL). CEHL can only be set after the Security Bit is effective, which implies issuing the Set Security Bit command, resetting the device, and issuing the SCEHL command through software. The CEHL status is then visible in the DSU STATUB.CEHL bit. . This is a permanent fuse, meaning that once it is set, it is set forever and cannot be reset anymore, therefore removing any possibility to perform a chip erase, reprogram or debug the chip.
In the rest of the chapter, "SB"="Security Bit" refers to NVMCTRL STATUS.SB (or DSU STATUSB.PROT) and CEHL to DSU STATUSB.CEHL.
The four possible combinations of both bits and their implications are summarized in the next table and described in detail in the following sections:
| BOOTPROT | SB | CEHL | Programming | Debugging | BOOTPROT updatable in UROW | Access rights to/from boot code section (boot) and Application code section (main) | Immutable boot | |||
|---|---|---|---|---|---|---|---|---|---|---|
| boot => boot | main => boot | boot => main | main => main | |||||||
| 0xF (disabled) | 0 | 0 | Yes | Yes | Yes | NA, boot section does not exist | Yes (self update) | No | ||
| 1 | 0 | No | No (chip erase only) | No | ||||||
| 1 | 1 | No | No | |||||||
| !0xF (enabled) | 0 | 0 | Yes (rest of Flash only) | Yes | Yes | Yes (read only) | Yes | |||
| 1 | 0 | No | No (chip erase only) | No | ||||||
| 1 | 1 | No | No | Yes | ||||||
Security Bit = 0 and CEHL = 0
- Full debug access is allowed.
- If a boot section has been defined in
the user row BOOTPROT bit field, then this section is write and erase protected (from
the debugger and from the application code running on the target). Changes to
BOOTPROT are considered only after the next reset. Consequently, if a boot code was
previously programmed and secured with a BOOTPROT value, then in order to reprogram
it and secure it again, the user must follow these steps:
- Disable the boot section protection(BOOTPROT = 0xF) and reset the potentially related region lock bits.
- Reset the chip for the new BOOTPROT value to be taken into account.
- Reprogram the boot section, protect it again by setting BOOTPROT to the appropriate value depending on the boot code size.
- Reset again.
- The application code (outside of the boot section) can be reprogrammed.
- A debugger chip erase is possible. It
will erase the main array (even the potentially protected boot section), the Data
Flash, the volatile memory, and the Security Bit. Note: The user row containing the BOOTPROT parameter is not reset by a debugger chip erase.
Security Bit = 0 and CEHL = 1
Security Bit = 0 and CEHL = 1: This combination is not possible, CEHL cannot be set when Security Bit = 0 (This will result in STATUS.PROGE being set).
Security Bit = 1 and CEHL = 0
- After the Set Security Bit command has been issued and a chip reset has occurred, the Security Bit will be set
- Once the Security bit is set, the user can only clear it through a debugger chip erase
- The debug access and actions are
restricted in this mode, For additional information, refer to the 13.9 Intellectual
Property Protection chapter and Table 13-6:
- After the Set Security Bit command has been issued and a chip reset has occurred, the Security Bit will be set
- The debugger chip erase is possible
- The debugger is not allowed to read and dump the code and data contained in the Flash memory
- Programming (write/erase) of the Flash (boot code, application code, Data Flash section, Configuration Rows (in particular BOOTPROT in the user row)) is not allowed. It will only be possible after a debugger chip erase, when Security Bit is back to 0.
- The boot and application codes running on the target have full read/write/erase access to the main array, Data Flash section and Configuration Rows, except if a boot section is defined with BOOTPROT, in which case, the boot section becomes write/erase protected from the boot code itself and from the application code
Security Bit = 1 and CEHL = 1
- After the Set Security Bit command has been issued and a chip reset has occurred, the Security Bit will be set
- It is then possible to issue the Set CEHL command (only with software)
- Once CEHL is set, it is not possible to reset it. This is a permanent fuse. The part is locked forever and there is no way to come back.
- The same as above still applies, except that chip erase functionality is disabled forever.
- CEHL status is visible in DSU STATUSB:CEHL
Defining a protected boot section by setting the Security Bit and the CEHL bit, allows for a global secure boot solution with an immutable boot loader section. The boot loader may for example embed public keys or certificates for supporting secure boot loading algorithms or secure update of the main application code.