7 Guidelines
Secure systems can take advantage of many security supporting hardware feature. Some are useful for any
system, and need little change in the application code to be activated and fully functional. It is the case of the
RDP feature, that prevents basic access to the flash memory by disabling the debug port. Other features must be
selected depending on user application and the required security level.
This section helps defining the adapted set of security features, depending on the system use-cases. The
use-cases are gathered in four main groups: protection against external (1) and internal (2) threats, security
maintenance (3), and other use-cases related to cryptography (4) (see the table below).
Table 15. Security use cases
1 Device protection against external threats: RDP protection, tamper detection, device monitoring
-
1.1 Device configuration (option bytes, not supposed to be modified ever)
• Use RDP level 2. This closes the device from any external access.
1.2 Remove debug capability for the device.
• Use RDP level 2 for permanently disabling the debug.
1.3 Protect a device against a loss of external clock source (crystal).
• Enable clock security system (CSS).
1.4 Detect a system-level intrusion.
• Use tamper detection capability of the RTC.
1.5 Protect a device from code injection.
• Use the RDP.
• Isolate communication port protocol with the MPU, firewall, or HDP.
• Limit communication port protocol access range.
• Use write protection on empty memory areas (flash memory and SRAM).
2. Code protection against internal threats: TrustZone, PCROP, MPU, firewall, and HDP
-
2.1 Protect the code against cloning.
• Use RDP level 1 or 2 against external access.
• Use PCROP on most sensitive parts of the code against internal read access.
• Use OTFDEC to secure code stored in the external memory.
2.2 Protect secret data from other processes.
• Use firewall to protect both code and data.
• Use MPU to protect secret data area from being read.
• Use HDP in case data must only be used at reset.
• Use secure domain of TrustZone, if available.
2.3 Protect code and data when not fully verified or trusted libraries are used.
• Use PCROP to protect user most sensitive code.
• Use firewall to protect user sensitive application (code, data and execution).
• Use MPU and de-privilege the untrusted library.
• Use IWDG to avoid any deadlock.
• Use secure domain of TrustZone, if available.
3. Device security check and maintenance: integrity checks, SB, SFU
-
3.1 Check code integrity.
• Hash firmware code at reset and compare to expected value.
• Enable ECC on the flash memory and parity check on the SRAM.
3.2 Security checks or embedded firmware authentication
• Implement SB application with cryptography.
• Protect SB application secret data (refer to previous sections).
AN5156
Guidelines
AN5156 - Rev 8
page 42/56