ARM TrustZone, connecting peripherals?

Question

I'm currently doing some research about ARM's TrustZone, e.g. here: ARM information center. As far as I understand, with TrustZone a secure environment based on the AMBA AXI bus can be created.

On ARM website it says: "This concept of secure and non-secure worlds extends beyond the processor to encompass memory, software, bus transactions, interrupts and peripherals within an SoC." I read that peripherals can be connected to TrustZone via the NonSecure-bit of the AMBA AXI bus (The extra signal is used to differentiate between trusted and non-trusted requests).

1) What, except the extra pin of AMBA AXI bus, is the TrustZone specific hardware in a SoC with TrustZone?

2) Is it possible to connect an external non-volatile memory (e.g. Flash) or a partition of it to TrustZone with access to secure world (via external memory interface and -then internal- the AXI bus)? If no, how are secrets (as keys) stored to be used in the secure world (with help of fuses??)? If yes, how is it prevented that a Flash including malicious code is connected?

3) Is it possible to implement code to the secure world as a customer of a chip vendor (e.g. TI or NXP), either before or after the chip left the factory?

Thank you for your answers.

Answer 1

TrustZone is a set of standards released by ARM. It gives OEM (embedded software programmers) and SOC vendors some tools to make a secure solution. These have different needs depending on what needs to be secured. So each SOC will be different. Some SOC manufacturers will try to compete on the same security application, but they will still differentiate.

1) What, except the extra pin of AMBA AXI bus, is the TrustZone specific hardware in a SoC with TrustZone?

Anything that the vendor wants. The GIC (ARMv7-A) interrupt controller, the L1 and L2 controllers, and MMU are all TrustZone aware peripherals in most Cortex-A CPUs. These are designed by ARM and implemented in the SOC. As well, there are various memory partitioning/exclusion devices which can be placed in between a peripheral and the SOC. Examples are the NIC301 and various proprietary BUS interconnect technology.

Other hardware may include physical tampers, voltage and temperature monitoring, clock monitoring and cryptography accelerators.

2) Is it possible to connect an external non-volatile memory (e.g. Flash) or a partition of it to TrustZone with access to secure world (via external memory interface and -then internal- the AXI bus)? If no, how are secrets (as keys) stored to be used in the secure world (with help of fuses??)? If yes, how is it prevented that a Flash including malicious code is connected?

As the above alludes, chips like the NIC301 can physically partition AXI peripherals.^{See image below} Part of any TrustZone solution is some secure boot mechanism. All CPU will boot in the secure world. The secure boot mechanism may vary. For instance, a one time programmable ROM might be appropriate for some applications. Many have programmable fuses with a public/private key mechanism implemented in SOC ROM. The SOC ROM boot software will verify that the image in flash is properly signed by whoever burned the one time fuses.

This OEM image can set-up many TrustZone peripherals, most of which will have a lock bit. Once set, registers in the peripherals can not be changed until the next hard boot.

3) Is it possible to implement code to the secure world as a customer of a chip vendor (e.g. TI or NXP), either before or after the chip left the factory?

Yes, this is the secure boot mechanism. It is not specified in the ARM TrustZone documents on how code will be secured. If you manufacture the chip and have on-chip ROM with a MESH layer protecting it maybe sufficient for secure boot. However, TI and NXP will implement a public/private key mechanism and verify that only software signed by an OEM can be loaded. This OEM software can have bugs (and possibly the ROM loader by the SOC vendor), but at least it is possible to create a secure boot chain.

With public key, even complete access to the chip will only allow an attacker to load previously released software from the OEM. Some solutions may have revocation mechanisms as well to prevent previously released software from being used.

---

See: trust-zone

• Typical ARM bus
• ARM partition checker
• Handling ARM TrustZone