MPUs and MCUs
A holistic view on microcontroller security
By Giancarlo Parodi, principal engineer, Renesas Electronics S
ecurity is becoming increasingly important for embedded systems as these evolve from standalone applications into connected ones that store, receive, and
transmit data, update themselves with the latest software, get remotely monitored and so on. Such requirements propagate even into the tiniest implementations in spite of limited memory resources and computational power.
Most embedded developers might perceive all this as too complex to handle, starting from cryptography-related topics. But in fact, security-related aspects encompass many aspects of the software and chip architecture which must be designed specifically, and work together seamlessly, to achieve their goals. This article focuses on the most relevant aspects to consider in relation to microcontroller security implementations for such small embedded systems.
One of the first steps to secure access to a valuable asset, is to make it available under a specified usage policy while isolating it. Arm TrustZone separates the user application into a “secure” and “non- secure” environment. In case of violations, an exception is thrown (see Figure 1). To execute a secure function, the CPU can change its state to secure via a special instruction called ‘secure gateway’ (SG), paired with a ‘jump’ to the desired secure function address; when returning, the processor state is switched back to non- secure mode.
An example of resource allocation is provided in Figure 2.
Pairs of ‘SG + Branch address’ get allocated to a special area defined as non-secure callable; any parameters like memory pointers passed by the non-secure callable functions can use a specialized ‘test target’ instruction to make sure a memory buffer is in non-secure memory, and does not overlap over secure memory, to avoid data leakage.
38 April 2022 Components in Electronics
www.cieonline.co.uk Figure 1: TrustZone access policy
When a non-secure interrupt happens while in secure mode, the registers are pushed on the secure stack and their contents cleared out automatically, to prevent information leakage. Each environment supports a dedicated interrupt vector table, stack pointer, systick timer, and so on.
This all sounds great, but how are the secure areas defined? The SAU (security attribution unit) and the IDAU (implementation-defined attribution unit) are used. On each CPU access, both will respond with an associated security attribute. The most restrictive of the two responses ‘wins’ and gets evaluated against the policy in Figure 1. Illegitimate
Figure 2: Non-secure callable functions
accesses get blocked, and a secure exception raised.
The SAU (how many regions are supported, default settings, etc.) is defined at design time, and the implementation of the IDAU is left to the device manufacturer. Memory protection units (MPUs) within each domain will protect individual threads from each other, enhancing the overall robustness of the software. Figure 3 shows a partitioning example.
Have we achieved any security related goal so far? Actually, not yet. TrustZone can isolate application threads but cannot enforce the legitimacy of an access (rather prevents unintended or direct usage). A good candidate for isolation is
typically cryptographic operations; in any case the system shall apply the TrustZone settings from execution start, and prevent their tampering (i.e. storing those into memory not modifiable by the CPU). The amount of functionality implemented within TZ shall be minimal to reduce the possibility of bugs and runtime errors which could be exploited, while reducing validation and test efforts.
Which crypto related resources shall an MCU provide? It depends on the application complexity; from a pure software routine at entry level, to hardware accelerated algorithms for reducing power consumption and code size, at higher execution speeds.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64