9.4.10.5 IRT Isolation and Data Protection

IRT partition implementation is based on the principle of temporal isolation. Since IRT is the first firmware to execute after reset, it controls the execution of other firmware components. Sensitive IRT data is cleared from registers and RAM before executing any application (non-secure firmware). Likewise, IRT partition access is disabled (PLCK bit == ‘1’) before executing the application, preventing it from accessing or corrupting IRT Flash regions.

• If IRT firmware needs to be protected from access by non-secure firmware, the instruction cache should be invalidated and disabled before transferring control to the application firmware.
• The IVT base address should be set to application space before attempting to transfer control to the application firmware. This ensures that application firmware exceptions, starting with the first application code instruction, can be handled by application trap handlers.

Secure debug must be enabled, and external access must be disabled (EAA (IRTCTRL[0]) bit = ‘0’) for the IRT partition to be fully protected from external access. When secure debug is not enabled, or when it is enabled but external access is allowed (EAA bit = ‘1’), external access to internal registers and RAM values is possible via the ICSP interface. A properly timed Reset during IRT execution may reveal sensitive information in RAM and registers that retain their state through the Reset.

IRT partition access may be extended to updatable root of trust firmware components. One or more updatable components (stages) are authenticated directly by IRT firmware or indirectly through the chain of trust process previously described. The updatable root of trust components execute with the IRT partition enabled. The IRT partition is locked by the IRT or updatable root of trust firmware by setting the DONE bit before starting the execution of the application (non-secure code). Alternatively, updatable root of trust components may have an independent security partition. In this case, the IRT disables the IRT partition before transferring control to an updatable root of trust component in a non-IRT region. A separate (non-IRT) protection region can be set up for the updatable root of trust components to store cryptographic keys and configuration data. Access to this region is disabled before transferring control to the application (non-secure firmware). Unlike the IRT partition, this partition is erased on a chip erase and can be accessed by debug without specific authorization. IRT firmware may implement a security life cycle state using IRT region storage. This is separate from the higher-level device life cycle state controlled by the UCB write-protect word. Additionally, IRT firmware may implement nonvolatile secure debug Configuration options.

IRT partition memory is not erased on a chip erase, and debug access to IRT memory is controlled by IRT firmware.