8.4.7.1 Function

The TrustZone AES Bridge (TZAESB) performs encrypted memory accesses. It also offers the possibility for Secure and Non-secure worlds to perform encrypted memory accesses with different encryption keys. The memory space that can be encrypted by TZAESB include the NFC_RAM, EBI, SRAM, QSPI and DDR spaces.

In order to use the TZAESB (for on-the-fly encrypted accesses), the TrustZone AES Bridge Address Space Controller (TZAESBASC) must be configured. This block defines the regions in the memory map where encryption is needed, and their security level. Whenever the address of a memory access matches a region defined in TZAESBASC, the access is routed through the TZAESB instead of taking the direct unencrypted path.

When access is performed to a region configured as non-secure in TZAESBASC, the protection bit is modified on-the-fly as non-secure even if the access was initially marked as secure. The access is then routed to the non-secure AES core in TZAESB (as illustrated with access A3 in the following figure).

TZAESBASC, MATRIX and TZC-400 security settings must match.

The following schematic illustrates the behavior of the TZAESB when ID_TZAESB_S is secure and ID_TZAESB_NS is non-secure. This example shows five accesses (A1, A2, A3, A4, A5) coming either from the processor or the DMA with different securities, and targeting region 1 (secure), region 2 (non-secure) and a clear region (i.e., not defined in TZAESB) in the DDR space.

Figure 8-4. Example of Security Management with Different Access Types

Non-secure access A2 to region 1 (secure) is not immediately denied. The access is stopped when reaching TZC-400, leading to a bus error with corresponding denied access information, due to TZC-400 and TZAESBASC identical security settings.

Secure access A3 becomes non-secure when crossing TZAESBASC, leading TZAESB to select the non-secure AES core in order to use the correct encryption key. This access is not denied by TZC-400 because the target address is a non-secure region.

When the application does not require two different encryption keys, the encrypted access bandwidth can be increased by running the two cores in parallel when two different hosts from different matrixes access TZAESB, for example DMAC0 and DMAC2. To do so, the user must program the same security bit values (ID_TZAESB_S or ID_TZAESB_NS) and use identical encryption keys for both cores.