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.
- 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.
- 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?
- 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.
- 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.
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 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.
- 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).
- 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:
- Lovely isolation qualities
- Encourages separation of applications into security-critical aspects from general purpose aspects: reducing the attack surface
- 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.
- Processors running at low Mhz speeds.
- 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.
- Typically, limited RAM/FLASH
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.
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
2 Factor Authentication—an extra layer of security that requires you to supply at least two proofs of identity when attempting to access an asset; for example, a password AND access to a mobile phone on a particular account.
Address Space Layout Randomisation—a form of obfuscation commonly employed to prevent an attacker making unauthorised function calls inside code.
A TEE that is under the control of the ODM or OEM such that no other parties can install TAs. A closed TEE provides only a restricted set of services, much like an HSM.
A combination of one or more platforms (and potentially one or more devices) in one discrete physical object. For example, a mobile SIM card is a SE platform in a device, and that device is inserted into the mobile phone device that may also contain the TEE platform and the REE platform(S).
Differential Fault Analysis—a “side channel” method to discover secrets by monitoring changes caused by induced faults in the electronic signals inside a device. For example, a fault causes a secret to be written to screen memory rather than its normal location.
Differential Power Analysis – A “side channel” method to discover secrets by monitoring changes in power usage of a device.
Dynamic Random Access Memory – A form of memory that can be written and read at high speed. It requires a periodic update to keep its contents valid.
Silicon-based, non-volatile memory (NVM) that has no moving parts. The technology behind this is typically 3 or 4 generations behind the technology for making processor cores and SoCs, so Flash cannot be integrated directly onto the same silicon as processing cores.
Keep It Simple Stupid—a design philosophy that recognises that with increased complexity comes more potential for bugs and security holes. From a security point of view, this results in putting the security critical pieces of code in a separate isolated silo to reduce this risk.
Memory Management Unit – A silicon component that restricts and maps the memory access of a process.
Near Field Communications. – A limited range radio technology that can be used as a method of indicating close presence as well as establishing data communication.
Non Volatile Memory – Memory that retains its contents when power is turned off.
Original Design Manufacturer – typically refers to a manufacturer that does not make a consumer product but produces something that other manufacturers use as a component in a product. This may include Whitebox manufacturers whose product is then “branded” by a retailer.
Original Equipment Manufacturer—typically refers to a manufacturer that produces final consumer products.
A TEE that is open to the installation of 3rd-party service provider TAs.
Operator Card Set
A set of chip (SE) containing cards with HSM-wrapped secrets and potentially keys, that allow the HSM to associate a specific card with a particular operation or operations that the HSM may provide. The use of an SE makes it harder to generate unauthorised copies.
One-time Programable—a form of memory that may be written to once, commonly used for small data assets including keys and hashes. Note that some forms of OTP should be considered OTP on a per bit basis. These start with a value 0xFF that can be written to become 0xF0. They cannot then be changed to 0xFF again but may be changed to 0x00. To prevent this, a second piece of OTP memory must be used to “”Lock values”” and prevent further changes.
A single execution environment that can be thought of as a single domain of trust isolated from any other domains. Examples of a platform in a mobile phone might be; • The REE running a Rich SO such as Android or IOS • The UICC running JavaCard applications • The TEE running GP-compliant Trusted Applications • The Base Band OS running dedicated telephony-related services Note this is the use defined in GlobalPlatform but other definitions exist.
Rich Operating System Execution Environment – Originally considered to hold the Rich OS(s). Now, due to the deployment of TEE technology in IoT environments where the “”other OS”” may not be consider feature-rich, the REE may also be described as holding the Device OS(s). In one sense, it should be considered “everything else” inside the device that is not part of the current TEE and hence capable of attacking the TEE. In terms of security, the REE should include components such as Secure Elements and other TEEs if present, but for simplicity, these are kept separate.
The “main” operating system inside a device. Such an OS is designed to provide the users access to the general software functionality of a device and is considered “feature rich”. Typical examples are Linux, Android, iOS, Windows. In a TEE-enabled device, this Rich OS runs in the REE, alongside the TEE and may make use of some services offered by TA’s. In IOT devices, this may not be an OS as such, but a set of generic services, such as an internet access stack.
Root of Trust
Root of Trust (RoT) – GlobalPlatform have a detailed document defining root Root of Trust [GP_RoT] which is the basis for our usage here. A Root of Trust is a combination of software, hardware and data, providing a service, for which no other combination of software, hardware and data is capable of attesting the initial state.
Secure Element – A Secure Element (SE) is a microprocessor chip that can store sensitive data and run secure apps such as payment. It is the secure computing device found in places such as UICC’s, microSD cards, HSM Operator Card Sets and Bank Cards.
A generic term in TEE and SE circles for the application developer or the entity that makes use of applications to provide a service. While often focused on the TA Developer, in the TEE case the service provider may be linking Cloud Services, Rich OS applications and/or Trusted Applications.
Silicon Provider – The organisation that fabricates and packages the silicon. It may also be defined as the organisation responsible for the hardware aspects of the chip security, along with (in some cases) the first layer of ROM RoT software to run on the chip. The SiP product is typically taken and used by ODM, if needed, and finally OEM to make a final product.
System On Chip—the technique of taking all the discrete components found in a traditional PC and integrating them into a single piece of silicon. This has advantages because the connection between those components can run much faster and/or at much lower power consumption. There is also a security advantage in that it becomes much harder to probe communications between those integrated components.
Static Random Access Memory—a form of memory that can be written and read at high speed. It does not require a periodic update to keep its contents valid, but takes up a larger amount of silicon space compared to DRAM.
Short Range Wireless—the generic term for low-power wireless communication definitions such as BlueTooth, ZigBee, or NFC. A method of indicating close presence as well as establishing communication.
Trusted Execution Environment—an environment that is isolated from other environments, has gone through a boot process that has signature-checked all loadable components of its boot- and run-time environment, and into which only signature-checked application software is loaded. Technically, a TEE can be instigated in something like a Secure Element but, typically, is implemented using technology such as ARM TrustZone Technology [ARM_TZ].
Trusted Platform Module—a hardware security module dedicated to recording the power-up boot state of a single platform in a series of registers called PCRs, and providing a signed attestation to that state to external parties.
A TEE is composed of software and hardware components. The Trusted OS is the component that exposes run-time capabilities to enable and manage Trusted Applications. In IOT devices, this may not be an OS as such, but a set of generic services, such as a TLS stack enabling secure communications to off-device entities.