What is TrustZone?

Arm® TrustZone® technology provides a cost-effective methodology to isolate security critical components in a system, by hardware separating a rich operating system, from a much smaller, secure operating system.

Not K.I.S.S, K.I.I.S.!

I hope we have all heard of KISS, that stands for Keep It Simple Stupid. It’s a great design philosophy. Well in Security, we can misspell it KIIS, Keep It ISOLATED Stupid.

• Security is all about controlling access to assets (code, data, key data, secret data, peripherals).
• Access control can only be instigated with isolation and gatekeepers.

In fact, good security design is KISS and KIIS ?

5 Levels of Isolation

Yes, I know we could define more but let’s keep it simple, this is a blog post, not a university course! There are typically 5 levels of isolation found in devices today. We have categorized these as:

• Software logic-based isolation
• Traditional MMU based isolation
• Obfuscated Isolation
• System Hardware based Isolation
• Discrete Sub-System Isolation

Do not misread the order of these to imply better or worse security. Typically they are one or more deployed together to try and meet the needs in a given scenario.

Software logic-based isolation

An example of this is a browser keeping one web page isolated from another (you don’t want a web game seeing your online bank account login). So that isolator (the browser in this case) can make decisions as to whether Page A can access assets of Page B. But not just the isolator… all software the isolator depends on (such as the underlying operating system) can potentially also interfere with that isolation. That’s a huge pool of potential areas for mistakes and hence security attacks.

Pros

• Doesn’t require system specific hardware features.
• The “Applications” (webpages in this case) are easy to write as they have no forced separation of security and non-security aspects.
• Can use the full power of the main cores (GHz processor speeds).
• Can securely use the significant memory resources available to a standard application.
• Potentially many GB of Flash and RAM.

Cons

• Isolation managed by something designed to do a lot more than isolate: Feature creep adds functionality to the isolator that has nothing to do with isolation.
• Large “attack surface”- i.e. lots of places things can go wrong.
• The “Applications” (webpages in this case) have no forced separation of security and non-security aspects. This leads to security impacting errors in the non-security focused parts.
• Software generally functionality slowed by the heavily integrated software firewall.
• Fewer options when it comes to development languages.
• Being based on software, it is more vulnerable to changes and flaws than hardware-based isolations.
  • Hardware can have flaws
  • But software can have flaws as well as being impacted by any hardware flaws.

(It is worth noting that web browsers, have generally moved on from this and now leverage MMU isolation by requesting the OS to run pages in different processes.)

Traditional MMU based isolation

To remove the strain on a piece of software performing the isolation and lot of other tasks, a piece of hardware was introduced that isolated software inside a system. This meant a special piece of software could manage the isolation enforcement via this hardware, while the rest of the system got on with playing movies or whatever.

Larger pre-TrustZone technology systems mainly used one piece of hardware to enforce the isolation policies of the system, the Memory Management Unit (MMU). The MMU splits memory up into isolation regions based on tables which are also held in isolated memory. In a simple system with one processor core, or cluster of cores, or supercluster of cores… then this is fine if there is one OS managing the functionality.

Unfortunately, mobile devices are not so simple. Effectively they are 10’s of cores, each potentially with its own independent OS/RTOS/firmware/software and MMU, but with potential access to a common pool of memory and peripherals.

What are the pros and cons of MMU isolation?

Pros

• Well known technology to implement, a privileged piece of code (call it the Kernel or the Hypervisor) controls who can see what.
• Can use the full power of the main cores (GHz processor speeds).
• Can securely use the significant memory resources of the main SOC.
• Potentially the overall system has access to many GB of Flash and RAM.

Cons

• Only simple on simple devices. Not simple on a device with multiple bus masters.
• The isolation control is part of the privileged code.
  • In traditional OSes, the privileged code has other uses… such as driver interfacing and process management.
  • This leads to the size of the privileged code size increasing, and we are back to a large attack surface.
• In a complex device with many bus masters, it becomes a difficult mix of multiple … single points of failure
  • It fails the KISS test.

Obfuscated Isolation

So, the problem with even the Rich OS using an MPU is that for some use cases, you may not be able or willing to trust the Rich OS. Why? Because it has probably been designed with performance and feature richness in mind, not just security.

In the ideal world, the application wouldn’t have to rely on the OS to isolate it from “everything else”, it would do it itself.

Using a technique called obfuscation we try and enable the app to do this by hiding its secrets, even when someone has broken the OS security (and hence the MPU isolation). What follows is a very crude example which is NOT how it is done in the real world but shows a little of why it helps.

These two pieces of C code produce identical results.

Obfuscation isn’t perfect but then no security technique is perfect. The main issue with obfuscation is that it is potentially vulnerable to reverse engineering. Reverse engineering good obfuscation takes time and specialist knowledge and that obfuscation doesn’t stand on its own but adds to the other security defenses of the system. If the overall reverse engineering effort can be shown to be higher than the value of the material the system is guarding then it has useful security. Obfuscation adds significantly to the more standard defenses and can be enough to tip that “attack cost vs potential reward” balance away from the attacker.

Interestingly, many operating systems make use of a limited form of obfuscation called ALSR. ASLR is used to prevent an attacker from making unauthorized function calls inside the code.

TrustZone Technology Based Isolation

Let’s take it up a notch. There are two issues with MMU isolation:

One – Rich operating systems are BIG

The point of a rich operating system is not to provide security. It is to provide a massive range of features while trying to keep the environment secure. Feature richness is the driving goal.
The feature pressure leads to operating systems requiring massive amounts of codes and even when the MMU provides isolation, that code still needs to communicate.

More code = more communication = more likelihood of errors in the layers of gatekeepers. Errors that will unintentionally bypass the isolation.

Two – Hardware Systems are not simple anymore.

One way of looking at the problem with MMU’s is that the access control (stopping access to assets like code/secret data/key data) occurs near the Core. This means OTHER Cores and Bus Masters may be used to bypass the isolation and access control.

To solve these issues, Arm introduced Arm® TrustZone® technology:

• Starting in 2004 with their Arm1176JZ-S™ processor.
• Included in all their A-Class (apps) designs since then.
• Arm recently started introducing it in their M-Class, IoT focused cores.

TrustZone TEE

TrustZone + TEE techniques put the access control at the peripheral or memory and separate its management form system design and software not focused on security.

This isolation barrier separates assets, giving two execution environments which prevail throughout the general assets of the SoC:

• A “Secure World” for running Trusted Code (originally named after the state of the security bit on the Arm bus)
  • The Secure world hosts the Trusted Execution Environment (TEE).
• A “Normal” World for running general code.
  • The Normal World hosts the Rich OS Execution Environment (REE).
  • From the TEE point of view, the REE and the Rich OS do not have to be “Rich” in functionality, they just have to be outside the isolation boundary.
  • With the introduction of Hypervisors inside this class of device, the Normal World can potentially host many of these Rich OS.

Generally, a TEE doesn’t distinguish between different REE or Rich OS in a device except for message routing. From the TEE’s point of view, Rich OS are all untrusted by the TEE, and so any distinction would be based on untrusted data. For this reason, you may find all the Rich OS lumped together under one REE.

Pros

• In a chip with 20 or 30 independent bus masters, many of which might be running their own OS with their own kernel, placing the isolation decision at the peripheral prevents the “oh I forgot the DMA or Video Processor is not covered by MMU isolation”.
• General purpose OSes do not need their designs changed for the overall system security to improve.
• More efficient in hardware resources and overall design effort than implementing a dedicated security sub-system.
• Encourages separation of applications into security-critical aspects from general purpose aspects: reducing the attack surface.
• Can use the full power of the main cores (Typically GHz processor speeds).

Cons

• Takes thought to use: you can’t just move your whole app into the TEE, you need to separate the security bits from the rest (that’s just good security practice anyway!).
• Another programming environment to deal with: generally developed in C, though this is because of common use and there is no technical restriction.

For more detail on how a TrustZone Technology-based system is designed, and how it produces isolation in the core as well as for the memory and peripherals, see the excellent Arm overview document, “Building a Secure System using TrustZone Technology”

Discrete System Isolation

And finally, we can have a totally separate component with its own memory, processor, power management and peripherals.

Consider a UICC / SIM card in a mobile phone:

Pros

• Lovely isolation qualities
• Encourages separation of applications into security-critical aspects from general purpose aspects: reducing the attack surface

Cons

• In the UICC, can be painful to use
  • Typically, limited RAM/FLASH
    • In 2007 you were looking at 500KB ROM,512KB EEPROM, 16KB RAM
    • But if anything, these have gone DOWN to save costs.
  • Another programming environment to deal with
    • Generally developed in JavaCard.
  • Slow interface
    • Originally 9600 bps
    • The high speed 12 Mbps USB standard isn’t commonly implemented through lack of use cases.
  • And slow
    • Processors running at low Mhz speeds.
      • Generally, too slow to do asymmetric cryptography.
  • Takes thought to use
    • You typically can’t just move your whole app into the SE, you need to separate the security bits from the rest (that’s just good security practice anyway!).
  • And expensive to provide extra discrete systems like this
    • Not wallet breaking expensive but when you make a million devices even a cent extra cost is painful.

The UICC/SIM/SE is not the only example of this sort of platform but it is the most common when associated with mobile devices. Other alternatives go as far as Hardware Security Modules (HSM) which have far superior performance, retain (or improve on) the security isolation properties of a UICC, but at increased financial and practicality costs.

Conclusion

Arm® TrustZone® technology provides a cost-effective methodology to isolate security critical components in a system while not complicating life for the developers of all those other components that make the modern system on a chip (SoC) such a capable component.

… and it’s a great place to build a Trusted Execution Environment (TEE).

Terms & Abbreviations – Trusted Execution Environment & TrustZone