Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

TrustZone Is an Architectural Feature

The first thing to understand about TrustZone is that it's an architectural feature of ARM. And to understand that, you need to remember how the ARM partner ecosystem works.

ARM (the company) doesn't make chips itself: it designs processors and subsystems and controls an architecture specification that other companies take as the blueprint for their own chips. An architectural feature is something that is baked into the architecture specification and is implemented through standard mechanisms and signals (not as software or an auxiliary module/IP block) and is promised to be compatible on any ARM-based SoC regardless of any differentiating features they may implement.

ARM-based SoCs are required to conform to the architecture specification (and pass a conformance test), so by specifying it in the architecture, it's assured that all such SoCs[1] have TrustZone. [2]

Another principal driver for implementing TrustZone as an architectural feature is that the security separation is then enforced by the chip hardware and doesn't rely on software or logical access control systems (which always fall to bugs in the end). This benefit is realized in ideal conditions and makes TrustZone extremely elegant and robust, although there are practical limitations on how much device makers can rely on this in the real world.

Protection Target

TrustZone is designed primarily to defeat software-borne attacks[3] such as those coming from rogue websites, errant downloads, root kits, and the like. It isn't designed to protect against concerted, targeted hardware penetration or lab attacks (like a smartcard might be). This makes sense when we consider the evolution of computing devices over the past decade or so: they have become increasingly networked, connected, and dynamic. Bulk data transfer is the norm, and data and applications flow seamlessly from one device to another with limited checks and balances. In such an environment, the growth in potential for scalable indiscriminate software attacks far outstrips those for targeted physical intrusion.

To be clear, in the TrustZone threat model, all software in the NWd is considered potentially hostile (either by rootkit infection or by deliberate replacement of kernel or similar). So while the SWd and NWd kernel often work together to provide overall device and application security, the SWd should never rely on information it receives from the NWd when making security decisions. This is important when considering TPM-like use cases.

  • [1] Specifically Cortex™-A class (or application) processors. ARM also designs R (realtime) and M (microcontroller) class processors, which don't have the kind of TrustZone feature described here.
  • [2] As you'll see later, simply having TrustZone isn't necessarily useful. It does have to be implemented correctly, something that requires skill and care.
  • [3] The term shack attack is sometimes used in association with TrustZone to describe a low-value, low-skill type of physical attack somewhere between the all-software hack attack and the high-end, skilled, and expensive lab attack. An example of a shack attack might be nondestructive bus probing on exposed wires. The degree to which an SoC can protect against shack attacks depends on the chip hardware design and isn't inherent to the TrustZone system.
< Prev   CONTENTS   Next >

Related topics