Abstract
Millions of mobile devices are built around processors and systems-on-chip (SoCs) based on ARM®; processor designs. The success of the ARM architecture is due in no small part to the fact that ARM only designs and licenses the base IP for SoCs: the company does not make or sell finished chips. Device makers in search of SoCs for their designs generally benefit from this model as they have a wide choice of products and vendors to choose from while enjoying the efficiency and reliability of standardized tool chains, low-level compatibility and a broad developer ecosystem. However in the area of security ARM-based devices were not always consistent or compatible, so ARM created TrustZone to provide a portable architecture-level security feature for the ARM community to build upon.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
‘Application processor’ as distinct from ‘real-time processor’ or ‘micro-controller’. TrustZone as described in this text is only applicable on A class (recently referred to as Cortex-A) family processors, and not -R or -M class designs. Cortex-A is the type typically used in smartphones, tablets, smart TVs and the like, collectively referred to as ‘smart mobile devices’.
- 2.
TrustZone nomenclature has seen a number of refinements over the years and the ‘Secure World’ label has generally given way to ‘Trusted World’ in contemporary documents, partly to differentiate from ‘Secure Elements’, and partly in recognition of the unattainable nature of full security and better reflecting the combinatorial and subjective role TrustZone plays in the wider computer system. Nonetheless architectural descriptions often retain the original ‘Secure World’ naming. This usage is reinforced by the naming of various architectural features that support TrustZone.
- 3.
The notion of ‘roguishness’ is strictly subjective. For some, a user-built Linux kernel is the ultimate security breach, while for others it is the only acceptable environment for their usage. The design of TrustZone does not assume a particular semantic or detailed threat model in this regard: it is simply assumes that the entire NWd is untrustworthy from the perspective of the SWd.
- 4.
AHB and APB devices are not directly compatible with TrustZone – the signals are only properly preserved in AXI systems.
- 5.
The ‘33rd address bit’ analogy (all TrustZone-supporting ARM systems were 32-bit when the feature was introduced: the implication for 40- and 64-bit systems is obvious) is not uncontroversial among those with intimate knowledge of processor and memory architectures, but it is close enough as to be useful.
- 6.
Technically any code can run in any mode, but this should be the sole job of the Monitor. Adding additional complexity to this powerful software can be extremely risky.
- 7.
The scope of ‘firmware’ is, of course, somewhat subjective. In practice the monitor is often provided by the authors of the rest of the privileged SWd code.
- 8.
TrustZone was invented in an era when ARM SoCs were generally single processor, single core, and the design rationale reflects this. Modern SoCs have many cores, each of which has its own NWd and SWd, and many different configurations and control designs are possible. However since the complexity of shared resources, bus masters and power management control become much more complex in this scenario only the simple single processor case is addressed in this text.
- 9.
This is sometimes achieved, and has a number of benefits: additional tamper resistance/evidence on one hand, and additional isolation potential on another.
- 10.
Off-chip components are of course more open to invasive hardware attacks such as probing.
- 11.
This may refer to the obvious popular example of programs downloaded from the Internet but it is not intended to. At the level of TrustZone it is important to realize that system flash is untrustworthy since it can be modified by NWd.
- 12.
Time Of Check To Time Of Use – a common security error whereby input data is correctly validated when presented, but is changed before being operated on. Famously responsible for a number of security errors in unix file handling.
- 13.
Since the architectural concept of a driver depends on the operating stack it is difficult to go into too many details of the software level problems that might arise. However low-level access to the memory system is a very portable and relevant concept.
References
ARM: ARM cortex A9 technical reference manual: system boot sequence (2004). http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/Chdfjdgi.html
ARM: ARM trustzone security whitepaper (2005). http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
Smackall Games: Enhanced security for mobile devices: A Q & A with ARM’s Tiago Alves (2009). http://www.smackall.com/viewarticle.php?title=Enhanced-security-for-mobile-devices--Q-A-with-ARM-s-Tiago-Alves&article=816
GlobalPlatform: Truted execution environment (TEE) guide (2012). http://www.globalplatform.org/mediaguidetee.asp
IQ Magazine: TrustZone: integrated hardware and software security (2004). http://www.iqmagazineonline.com/magazine/pdf/v_3_4_pdf/Pg18_24_custZone_Secur.pdf
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2015 Springer International Publishing Switzerland
About this chapter
Cite this chapter
Geater, J. (2015). ARM® TrustZone® . In: Candaele, B., Soudris, D., Anagnostopoulos, I. (eds) Trusted Computing for Embedded Systems. Springer, Cham. https://doi.org/10.1007/978-3-319-09420-5_2
Download citation
DOI: https://doi.org/10.1007/978-3-319-09420-5_2
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-09419-9
Online ISBN: 978-3-319-09420-5
eBook Packages: EngineeringEngineering (R0)