4 Device protections
Security protections described in this section are controlled by hardware mechanisms. They are set either
by configuring the device through option bytes, or dynamically by hardware component settings:
• Memory protection: main security feature, used to protect code and data from internal (software) and
external attacks
• Software isolation: inter-processes protection to avoid internal attacks
• Interface protection: used to protect device entry points like serial or debug ports
• System monitoring: detects device external tampering attempts or abnormal behaviors
4.1 Configuration protection
Any persistent security configuration is stored in a dedicated area of the non-volatile memory, called option bytes
(OB). The option bytes are protected with redundancy, and, in case of perceived vulnerability, they are stored as a
“magic value”. Besides rules imposed by security logic (OB can only be changed under specific conditions), there
are rules to determine the default value in case of OB corruption.
Note: Magic value is a pattern of usually 8 bits that must be exactly matched for the value to be recognized as valid,
common examples are 0xB4 or 0xC3 for TRUE or FALSE.
Details about rules to modify the option bytes are detailed in each reference manual. The configuration is
generally frozen by raising the RDP level. Additional rules apply case-by-case.
Each OB value is preconfigured to a reset value in production. This value is usually the least secure, open option.
In case of an error detected in OB loading (OBL, happens on every POR or request), the configuration is set to
a default value. This default value usually sets the highest possible security level to prevent leaking information
from damaged microcontroller.
It is useful to analyze the impact of a configuration error on an application, and to plan for potential recovery.
Highest number of corrupted option bytes however result of errors in programming. If the OB are modified in
controlled environment, the threat of unintentional device locked-up is very low.
4.2
TrustZone
®
for Armv8-M architecture
Microcontrollers based on Armv6 or Armv7 architecture (Cortex-M0, M3, M4, and M7) rely mostly on software
implementations for firmware and resource isolation. These mechanisms, described later in the document, are
robust but not that flexible to allow the concurrent execution of secure firmware together with nonsecure firmware.
The Armv8-M architecture brings a new security paradigm in Arm microcontrollers. It implements the TrustZone®
technology at microcontroller system level, allowing the development of trusted firmware through a robust
isolation at runtime.
The TrustZone® technology relies on a processor (Cortex-M23 or Cortex-M33) separation for secure and
nonsecure domains and on a bus infrastructure (AMBA®) propagating secure attribute throughout the whole
system (peripherals and memories).
The TrustZone is made for robust and flexible security control at runtime. Switching from secure to nonsecure
domain and vice versa is straightforward with few cycle penalties. There is no need for a Secure monitor as in
TrustZone® for application processors Cortex‑A.
AN5156
Device protections
AN5156 - Rev 8
page 16/56
To Next Page
Loading...
Need help?
General
