Trusted Execution Environment: What It is, and What

It is Not
Mohamed Sabt, Mohammed Achemlal, Abdelmadjid Bouabdallah

To cite this version:

Mohamed Sabt, Mohammed Achemlal, Abdelmadjid Bouabdallah. Trusted Execution Environment:
What It is, and What It is Not. 14th IEEE International Conference on Trust, Security and Privacy
in Computing and Communications, Aug 2015, Helsinki, Finland. �10.1109/Trustcom.2015.357�. �hal-
01246364�

HAL Id: hal-01246364

https://hal.science/hal-01246364
Submitted on 18 Dec 2015

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Trusted Execution Environment:
What It Is, and What It Is Not
Mohamed Sabt∗‡ , Mohammed Achemlal∗† and Abdelmadjid Bouabdallah‡
∗ Orange Labs, 42 rue des coutures, 14066 Caen, France

{mohamed.sabt, mohammed.achemlal}@orange.com
† Greyc ENSICAEN, 6 Bd Maréchal Juin, 14050 Caen, France
‡ Sorbonne universités, Université de technologie de Compiègne,

Heudiasyc, Centre de recherche Royallieu, 60203 Compiègne, France

{mohamed.sabt, madjid.bouabdallah}@hds.utc.fr

Abstract—Nowadays, there is a trend to design complex, yet to refer to this environment using the term coined by Glob-
secure systems. In this context, the Trusted Execution Environ- alPlatform in [7], that is trusted execution environment (TEE).
ment (TEE) was designed to enrich the previously defined trusted
platforms. TEE is commonly known as an isolated processing A TEE is a secure, integrity-protected processing envi-
environment in which applications can be securely executed ronment, consisting of memory and storage capabilities [8].
irrespective of the rest of the system. However, TEE still lacks a For marketing purposes, the term TEE is heavily used in
precise definition as well as representative building blocks that advertisements of chip vendors and platform providers [9],
systematize its design. Existing definitions of TEE are largely [10]. The first deployed system with TEE appeared almost a
inconsistent and unspecific, which leads to confusion in the use
of the term and its differentiation from related concepts, such as decade ago demonstrated by a joint venture of Orange, Trusted
secure execution environment (SEE). In this paper, we propose Logic and STMicroelectronics [11]. Nevertheless, no common
a precise definition of TEE and analyze its core properties. and precise understanding for this term has been established
Furthermore, we discuss important concepts related to TEE, so far, and no framework has been proposed to evaluate and
such as trust and formal verification. We give a short survey compare TEE solutions. To underline this observation, we cite,
on the existing academic and industrial ARM TrustZone-based
TEE, and compare them using our proposed definition. Finally, in a chronological order, four definitions of TEE demonstrating
we discuss some known attacks on deployed TEE as well as its the inconsistent use and understanding of the term:
wide use to guarantee security in diverse applications.
1) Ben Pfaff, Terra, 2003 [3] The TEE is a “dedicated
closed virtual machine that is isolated from the rest of
I. I NTRODUCTION the platform. Through hardware memory protection and
User requirements for security are increasingly becoming cryptographic protection of storage, its contents are pro-
demanding. New challenges arise, since modern systems are tected from observation and tampering by unauthorized
becoming more and more complex, open and connected. Tra- parties.”
ditional security technologies can no longer meet the security 2) OMTP, Advanced Trusted Environment, 2009 [12] “The
requirements of such architectures. This explains the recent TEE resists against a set of defined threats and satisfies
trend to integrate trusted computing concepts into different a number of requirements related to isolation properties,
systems, such as embedded systems [1]. lifecycle management, secure storage, cryptographic
keys and protection of applications code.”
Trusted Computing was defined to help systems to achieve
3) GlobalPlatform, TEE System Architecture, 2011 [7] “The
secure computation, privacy and data protection. Originally,
TEE is an execution environment that runs alongside
trusted computing relies on a separate hardware module that
but isolated from the device main operating system. It
offers a functional interface for platform security. The trusted
protects its assets against general software attacks. It
platform module (TPM) [2] allows a system to provide evi-
can be implemented using multiple technologies, and
dence of its integrity and to protect cryptographic keys inside
its level of security varies accordingly.”
a tamper-evident hardware module. The main shortcoming of
4) Jonathan M. McCune, Trustworthy Execution on Mo-
the TPM is that it does not provide an isolated execution
bile Devices, 2013 [13] “The set of features intended
environment for third-party, thereby reducing its functionality
to enable trusted execution are the following: isolated
to a predefined set of APIs. A new approach to address trusted
execution, secure storage, remote attestation, secure pro-
computing is to allow the execution of arbitrary code within a
visioning and trusted path.”
confined environment that provides tamper-resistant execution
to its applications. In the literature, many names exist to All definitions somehow mention isolated execution and
this environment. Examples are closed-box VM [3], operator secure storage. In these two points there appears to be some
virtual machine (OVM) [4], TrustZone software (TZSW) [5], consent. However, definitions (1) and (3) are less explicit
and trusted language runtime [6]. In this paper, we are going about secure storage. Definition (1) specifically states crypto-
graphic protection as the only means to achieve secure storage, The security requirements for separation kernels are
whereas definition (3) tries to capture secure storage in a described in the Separation Kernel Protection Profile
generic way as a ‘protection of assets’. In addition, defini- (SKPP) [17]. The SKPP defines separation kernel as “hardware
tion (1) describes isolation as the protection of the integrity and/or firmware and/or software mechanisms whose primary
and confidentiality of the TEE runtime states. Regarding the function is to establish, isolate and control information flow
required security level, definitions largely differ from each between [...] those partitions.”. Unlike traditional security
others. Definitions (1) and (4) do not specify a threat model for kernels, such as operating systems, micro-kernels and hyper-
the TEE. Definition (3) vaguely includes all software attacks visors, the separation kernel is quite simple, providing both
in the threat model, while definition (2) clearly specifies the time and space partitioning.
threats against which the TEE must resist. Definition (1) The security requirements are composed of four main
describes the TEE as a ‘dedicated closed virtual machine’, security policies:
while the other definitions do not provide any detail about • Data (spatial) separation. Data within one partition can-
the nature of the execution environment. Some definitions not be read or modified by other partitions;
are concerned by particular properties. For instance, definition • Sanitization (temporal separation). Shared resources can-
(2) and McCune’s definition (4) involve content management not be used to leak information into other partitions;
by indicating that TEE should remotely manage and update • Control of information flow. Communication between
its data in a secure way (secure provisioning). Furthermore, partitions cannot occur unless explicitly permitted;
the McCune’s definition is specific to the context of human- • Fault isolation. Security breach in one partition cannot
interface devices, and therefore it includes the requirement of spread to other partitions.
interaction between the TEE and end-users (trusted path).
We argue that existing definitions of TEE fail to capture the B. Definition
core aspects of this term in a clear and unambiguous manner Trusted Execution Environment (TEE) is a tamper-
and are even contradictory in some parts. To address this issue, resistant processing environment that runs on a separation
in this paper, we propose a new refined definition of TEE kernel. It guarantees the authenticity of the executed code, the
considering its core aspects and the ‘separation kernel’ trusted integrity of the runtime states (e.g. CPU registers, memory
model (Section II). Thereby, we differentiate TEE from some and sensitive I/O), and the confidentiality of its code, data
related concepts. In Section III, we present the building blocks and runtime states stored on a persistent memory. In addition,
that capture the TEE design, followed by Section IV, in which it shall be able to provide remote attestation that proves its
we review the principal formal methods used in the context of trustworthiness for third-parties. The content of TEE is not
TEE. Section V gives a brief survey on the existing industrial static; it can be securely updated. The TEE resists against
and academic TEE, and compares them using our proposed all software attacks as well as the physical attacks performed
definition. In Section VI, we discuss some known attacks on on the main memory of the system. Attacks performed by
deployed TEE, and classify the research propositions defined exploiting backdoor security flaws are not possible.
in the literature that rely on TEE to guarantee security. We
end with a brief summary. C. Discussion
We define TEE as an execution environment which protects
II. T RUSTED E XECUTION E NVIRONMENT both its runtime states and stored assets, hence the need
In this section, we first describe the model of ‘separation for isolation and secure storage. Unlike dedicated hardware
kernel’, which is a fundamental concept related to the dual- coprocessors, TEE is able to easily manage its content by
execution-environment approach [14], and thus to the TEE. installing or updating its code and data. In addition, it must
We then present a new refined and comprehensive definition, define mechanisms to securely attest its trustworthiness to
as well as analyze its core aspects. Finally, we distinguish the third-parties. The threat model includes all software attacks
TEE from some related terms: secure execution environment and the physical attacks performed on the main memory and
(SEE) and dynamic root of trust measurement (DRTM). its non-volatile memory by a powerful adversary.
We argue that our definition is more general and includes
A. Prerequisite: Separation Kernel all the previously presented definitions of TEE. Secure exe-
The separation kernel is a foundation component of the cution, openness and trust are its main parts. Conceptually,
TEE. It is the element that assures the property of isolated our definition means that no untrusted code should be able
execution. The separation kernel, firstly introduced in [15], is to cause, enable, or prevent any event in the TEE. Events
a security kernel [16] used to simulate a distributed system. include not only the execution of instructions, but also traps,
Its main design purpose is to enable the coexistence of exceptions and interruptions. ‘Trust’ is discussed further in the
different systems requiring different levels of security on the next subsection.
same platform. Basically, it divides the system into several
partitions, and guarantees a strong isolation between them, D. How Trust Can Be Measured
except for the carefully controlled interface for inter-partition As mentioned in the above definition, and as its name
communication. indicates, the concept of trust is crucial to the TEE. Thus,
a direct comparison between two systems in terms of TEE trust score is a boolean that indicates the integrity state of the
is only possible if trust can be quantified. The main problem code. The TEE is trusted when its trust score is true, untrusted
is that trust is a subjective property, hence non-measurable. otherwise. The quality of the trust score depends on the defined
In English, trust is the “belief in honesty and goodness of a measurements for integrity.
person or thing.”. A belief is hard to capture in a quantified To evaluate the actual trust, as a first step, we define a trust
way. The notion of trust is more subtle in the field of computer function f (TEE, protection profile, RoT, measurements) as
systems. In the real world, an entity is trusted if it has behaved a function that returns the trust level of a given TEE depending
and/will behave as expected. In the computing world, trust on three parameters: the certificating protection profile, the
follows the same assumption. reliability of RoT, and the integrity measurements. The precise
In computing, trust is either static or dynamic. A static definition of this function is beyond the scope of this paper.
trust is a trust based on a comprehensive evaluation against
a specific set of security requirements. The Common Criteria E. Related Concepts
(CC) [18] are an international standard that provides assurance In this section, we highlight the conceptual differences
measures for the security evaluation. The CC specify seven between TEE and the related terms SEE and DRTM.
evaluation assurance levels (EAL1–EAL7), where levels with Secure Execution Environment (SEE) is a prerequisite for
higher numbers include all requirements of the preceding TEE, but it does not consider trust aspects. SEE is a process-
levels. In static trust, the trustworthiness of a system is ing environment that guarantees the following properties: (1)
measured only once and before its deployment. Dynamic trust authenticity: the code under execution should not have been
is quite different. It is based on the state of the running system, changed; (2) integrity: runtime states should not have been
and thus it varies accordingly. A system continuously changes tampered with; and (3) confidentiality: code, data and runtime
its “trust status”. In dynamic trust, the trustworthiness of a states should not have been observable by unauthorized ap-
system is constantly measured throughout its lifecycle. plications, or even by the main OS of the system. In contrast
The concept of dynamic trust is based on the existence of a to TEE, the design of SEE does not involve RoT to assert
secure and reliable means that provides evidence of the trust the integrity and authenticity of the loaded code. Moreover, it
status of a given system. Trust, in this context, can be defined does not define secure mechanisms to update its applications
as an expectation that the system state is as it is considered to and confidential data. In fact, in our definition, TEE is an open
be: secure. This definition requires a trusted entity called Root SEE that guarantees trust.
of Trust (RoT) to provide trustworthy evidence regarding the Dynamic Root of Trust Measurement (DRTM) is a group
state of a system. The role of RoT is divided into two parts. of techniques that enables some pieces of code to be executed
First is the trusted measurement and second is the function in an isolated environment, without trusting the previously
that computes the trust score. The trustworthiness of the sys- loaded software. This technology has been used to securely
tem, namely the generated score, depends on the reliability of execute critical software applications. Unlike TEE, the trusted
the trust measurement. If a malicious entity can influence the computing base (TCB) of DRTM is not limited to the code
trust measurement, then the generated score of trustworthiness running in the isolated environment, but it also includes a
is of no value. Therefore, RoT is necessarily a tamper-resistant small part of the main OS. Moreover, DRTM does not provide
hardware module. RoT, sometimes called trust anchor, can secure storage or include trusted mechanisms, such as remote
be implemented using various technologies. This depends on attestation and integrity measurement, in its core design.
the hardware platform that is used to guarantee the isolation In contrast to the TEE definition stated above, the isolated
properties in the separation kernel. For instance, TrustZone- execution environment needs to use the main memory as its
based systems [19] rely on secureROM or eFuse technology runtime memory, and hence is vulnerable to attacks on main
as trust anchor. PUF, Physically Unclonable Function, is a memory. TEE is supposed to resist against physical attacks on
promising RoT technology for TEE [20]. main memory by executing its code in a protected memory. It
Trust in TEE is a hybrid trust; it is both static and semi- is worth noting that DRTM does not allow concurrency. All
dynamic. Before deployment, a TEE must be certified by software is frozen until the end of the isolated environment
thoroughly verifying its security level in accordance of a execution. Therefore, DRTM is not suitable for systems which
protection profile, a document that contains a predefined set execute non-secure applications with real-time constraints.
of security requirements. For instance, GlobalPlatform defines
a protection profile that conforms to EAL2 [21]. In addition, III. TEE B UILDING B LOCKS
during each boot, the RoT assures that the loaded TEE is To capture the core design aspects of TEE, we propose the
the one certified by the platform provider. Strictly speaking, following definitions which are illustrated in the figure 1.
RoT protects the integrity of the TEE code. Once running, the • Secure Boot assures that only code of a certain property
integrity is protected by the underlying separation kernel. The can be loaded. If a modification is detected, the bootstrap
trust in TEE is considered semi-dynamic because the TEE is process is interrupted. An example implementation of secure
not supposed to change its trust level while running because boot, as proposed by Arbaugh et al., is to verify the integrity
it is protected by the separation kernel. In this model of trust, of a succeeding component according to a given reference
the trust measurements are integrity measurements, and the value [22]. Generally speaking, the design of secure boot
 Fig. 1. An Overview of TEE Building Blocks

consists of various stages, and therefore, a chain of trust is • Secure Storage is storage where confidentiality, integrity
established. This chain can be represented by the recurrence: and freshness (i.e., to protect against replay attacks and to
enforce state continuity [29]) of stored data are guaranteed,
I0 = True;
and where only authorized entities can access the data [30]. A
Ii+1 = Ii ∧ Vi (Li+1 ) common way to implement secure storage is sealed storage.
where Ii denotes the integrity of layer i and Vi is the Sealed storage is based on three components: (1) integrity-
corresponding verification function. The verification function protected secret key that can be accessed only by the TEE; (2)
performs cryptographic hash of the ith layer, and compares the cryptographic mechanisms, such as authenticated encryption
result to the reference value. We note that without the integrity algorithms; and (3) data rollback protection mechanism, such
of the initial boot code, represented by the I0 , any further as replay-protected memory blocks (RPMB) (see [31]).
integrity verification becomes pointless. Thus, the initial boot • Trusted I/O Path protects authenticity, and optionally con-
code is protected by a tamper-evident hardware module. fidentiality, of communication between TEE and peripherals
• Secure Scheduling assures a “balanced” and “efficient” (e.g., keyboard or sensors) [32]. Thus, input and output data
coordination between the TEE and the rest of the system. are protected from being sniffed or tampered with by malicious
Indeed, it should assure that the tasks running in the TEE applications. To be more precise, trusted I/O path protects
do not affect the responsiveness of the main OS. Thus, against four classes of attacks: screen-capture attack, key
the scheduler is often designed preemptive. Furthermore, the logging attack, overlaying attack, and phishing attack. Trusted
scheduler should take real-time constraints into consideration. path to user-interface devices enables broader functionality
Authors in [23] propose a secure scheduler that enhances the within TEE. It allows a human user to directly interact with
responsiveness of the main OS without compromising the real- applications running inside TEE. Examples of trusted user-
time performance of the system. interface can be found in [33]–[35].
• Inter-Environment Communication defines an interface
IV. F ORMAL M ETHODS
allowing TEE to communicate with the rest of the system.
Despite its numerous benefits, it introduces new threats: (1) The design of TEE, or any piece of software, consists of
message overload attacks [24]; (2) user and control data cor- two aspects: requirements specification and implementation. A
ruption attacks [25]; (3) memory faults caused by shared pages TEE is said to be correct if its implementation is verified to
being removed; and (4) unbound waits caused by the non- satisfy all the defined requirements. Formal methods, which
cooperation of the untrusted part of system. There exist vari- are mathematically based languages and techniques, are used
ous methods and implementations of inter-environment com- to prove correctness. Although formal methods do not neces-
munication. However, each mechanism should satisfy three sarily guarantee correctness, they provide insights which prove
key attributes: reliability (memory/time isolation), minimum useful in constructing better systems.
overhead (unnecessary data copies and context switches), and There are two goals for formal methods: specification
protection of communication structures. In the literature, we and verification. Formal specifications aim at describing the
identify three models of communication: (1) GlobalPlatform requirements of a system in a syntax-based language. They
TEE Client API [26]; (2) secure RPC (Remote Procedure are a necessary condition to perform proof-based verification
Call) of Trusted Language Runtime [6]; and (3) real-time on implementation. A set of formal specifications, combined
RPC of SafeG [27]. Secure inter-environment communication with a formal language produce a formal model. In literature,
is proposed in [28]. there are several formal models for separation kernel. The most
 Author
TEE License TCB Size Supported Normal World Supported Hardware Platform
laboratory/company
ObC Nokia Close 10kB Symbian OS 300 MHz OMAP 2420
<t-base Trustonic Close Unknown Android Samsung Exynos platforms
Andix OS TU Graz University of Technology Open-source Unknown Linux iMX53 QSB
TLK NVidia Open-source 128kB Android Tegra SoCs
TLR Microsoft Close 152.7 KLOC .NET CLR Tegra 250 Dev Kit
SafeG Nagoya University Open-source 1.96 kB TOPPERS/ASP PB 1176 JZF-S board
TABLE I
A N OVERVIEW OF THE C OMPARED TEE S

widely used formal specifications for separation kernel are core to provide an abstraction of two virtual cores (VCPUs):
those proposed by Greve, Wilding and Vanfleet (GWV) [36]. secure VCPU and non-secure VCPU. The monitor is seen
Concerning formal languages, the mainly used are Z notation, as a minimal hypervisor whose main role is the control of
B method [37], HOL4 (a variation of High Order Logic) [38], information flow between the two virtual cores.
and ACL2 (A Computational Logic for Applicative Common A short survey on the existing TrustZone-based TEE solu-
Lisp) [39]. Formal verification is used to analyze the formal tions in both the academic and industrial worlds is presented.
model for the desired properties. Two general approaches to
formal verification exist in practice today. The first, model A. Industrial TEEs
checking, is a technique in which systems are modeled as Established companies have invested to define their own
finite state systems. The second, theorem proving, proves that TEE and integrate them in their devices. Some companies
a system satisfies the specifications by deductive reasoning. have published their architecture, while some have preferred
Although proofs can be constructed by hand, machine-assisted secrecy over openness. Companies which open their TEE
theorem provers are used in most cases. Theorem proving is include Nokia and Samsung. Nokia, currently Microsoft in-
used more often than model checking because it can efficiently tegrate their TEE called ObC [43] into Nokia Lumia devices.
deal with complex properties. Samsung define TZ-RKP [44] that is deployed on the latest
We illustrate with two formally verified separation kernels. Samsung Galaxy series. Closed-architecture TEEs include <t-
INTEGRITY-178B [40] is a separation kernel of Green Hills base of Trustonic [9], SecuriTEE of Solacia [10], and QSEE
Software that is certified EAL6+. It uses GWV as formal of Qualcomm. Sierraware [45] propose two versions of TEE:
specifications, ACL2 as formal language, theorem proving open-source TEE that is called SierraTEE and a licensed TEE.
as formal verification method, and ACL2 theorem prover. Trusted Foundation and Mobiore, defined by Trust Logic and
SeL4 [41] is developed by NICTA and was formally verified G&D respectively, are disappearing from the market because
for security critical domain. It uses information flow security the two companies joined their efforts and formed Trustonic.
as formal specifications, HOL as formal language, theorem We also consider as industrial TEEs those which are defined
proving as formal verification method, and Isabelle/HOL the- by companies, but there is no public information about their
orem prover. deployment on commercial devices. STMicroelectronics, in
Formal methods play an important role in computing the collaboration with Linaro make their TEE called OP-TEE
‘trust level’ defined by the trust function (II-D), since the available on GitHub [46]. Nvidia proposes an open-source
protection profile could be defined using formal specifications implementation of TEE called TLK.
and proved using formal verification. This could highly im-
prove the trust level. However, formal methods are not a silver B. Academic TEEs
bullet. The trust function has other parameters and they could In the academic world, many prototypes of TEE exist. We
negatively impact the global trust level, even though formal only mention seven of them: (1) Genode TEE defined by Gen-
methods are employed. For the best of our knowledge, there ode Labs [35]; (2) Open TEE defined by Intel Collaborative
is no TEE that is formally verified. We believe that formal Research Institute for Secure Computing [47]; (3) Andix OS
characterization of TEE specifications will be regarded as a defined at TU Graz University of Technology; (4) ARMithril
considerable contribution. The most difficult part will be to defined at North Carolina State University; (5) SafeG defined
include all the components and building blocks in a single at Nagoya University [48]; (6) ViMoExpress defined by Elec-
model, despite their heterogeneity. Any formal model must at tronics and Telecommunication Research Institute [49]; and
least comprise the underlying separation kernel, the root of (7) TLR defined by Microsoft Research [6].
trust and the secure execution environment.
C. Comparative Study
V. ARM T RUST Z ONE - BASED TEE
We compare six TEE solutions using our proposed building
ARM TrustZone technology can be seen as a special kind blocks. An overview of these TEEs are presented in table I. We
of virtualization with hardware support for memory, I/O and decided to compare only these TEEs because they represent
interrupt virtualization [42]. This virtualization enables ARM well the wide spectrum of the different solutions. We do not
 TEE Provisioning Secure storage Secure UI Inter-world communication
Sealing storage using AES-EAX
Open provisioning, which means
authenticated encryption. The root
that the content management
ObC key is derived from a one-time Defined Proprietary interface
does not need the approval of
programmable (e-Fuse) persistent
any trusted-party.
on-chip key.
Sealing storage which is not
Owner-centric provisioning based on file systems. Instead,
model in which an application the unit of storage is an object.
GlobalPlatform TEE
<t-base to be installed on TEE needs to Objects are organized into a Defined
Client API
be encrypted using a key derived tree-like structure. Containers are
from the platform secret key. protected by the secret key of
their parent.
GlobalPlatform TEE
Andix OS Not defined Sealing storage Not defined
Client API
TLK Not defined Sealing storage Not defined Proprietary interface
Sealing storage with mechanisms
TLR Not defined Not defined .NET Remoting
to protect against rollback attack.
SafeG Not defined Unknown Defined Secure RPC
TABLE II
A C OMPARISON S TUDY OF THE SIX R EPRESENTATIVE TEE S OLUTIONS

include secure boot in our comparison criteria, since Non- physical address. Disassemblers are used to gain insight into
disclosure agreements (NDA) prevent authors from providing QSEE implementation. In [50], authors present an exploit that
details about their secure boot. is caused by code added by HTC. The exploit enables the
As illustrated in table II, only the two TEE widely de- execution of an arbitrary code within TrustZone in the secure
ployed, namely ObC and <t-base, provide secure provisioning. region of the memory. D. Rosenberg unlocks the bootloader
Trustonic attempts to control the content management of its of Motorola Android phones using two different exploits. The
TEE, while ObC opens their TEE for any party to install secure first exploit is about overwriting part of the secure region of
applications. Similarly, due to its high complexity, secure UI is the memory with certain values [51]. This is used to bypass the
not defined for all TEE. Concerning secure storage, it is often check of the function that unlocks the bootloader. The exploit
accomplished using sealing storage with AES encryption. works only on Qualcomm-based Motorola Android phones.
Our comparative table shows that there is no clear standard The second exploit affects all Android phones that utilize
for inter-environment communication. The use of proprietary Qualcomm Snapdragon SoC [52]. By issuing specially crafted
interface is common. SMC requests, an attacker can execute an arbitrary code inside
the QSEE. This vulnerability may be used to compromise any
VI. ATTACKS AND A PPLICATIONS applications relying on TEE for security.
We first discuss the attacks conducted on TEE deployed Besides exploiting SMC calls, the shared memory can
on mobile devices. We then provide a classification of the be manipulated to find vulnerabilities. In [53], a module
proposed applications that rely on TEE to guarantee security. intercepting exchanged data between the normal world and
the secure world is implemented. This module is integrated
A. Attacks inside the kernel driver which interacts with the TEE. The
TEE has been heavily promoted as the silver bullet solution targeted TEE by this attack is MobiCore and its goal is to
that provides secure processing in mobiles and embedded better understand the internal workings of MobiCore trustlets.
systems. However, far from speculative bubbles and market-
ing claims, security experts have not put TEE to the test, B. Applications
especially because of non-disclosure agreement (NDA). The The use of TEE paves the way for offering services requir-
attack surface of TrustZone-based TEE is: software exceptions ing a high level of security in a complex and connected system.
(e.g. SMC call), hardware exceptions (e.g. interrupts), shared Most of TEE applications defined in the literature are designed
memory interface, peripherals, and TEE-specific calls. The for smartphones. It is used to provide a wide range of secure
threat model includes a powerful attacker who is able to services: ticketing [54], [55], privacy-friendly public transport
execute an arbitrary code in the kernel privileges. ticketing [56], online transaction confirmation [57], privacy-
To the best of our knowledge, three attacks have been friendly online prepaid mobile payment [58], [59], media
published against QSEE or a manufacturer-customized version content protection [60], [61], authentication to access cloud
of QSEE. QSEE is an enticing target for attackers, since storage services [62], [63], two factor authentication [64], [65],
Qualcomm controls the majority of the market of Android and trusted sensors [66].
devices. In addition, it is easier to exploit security flaws, as TEE is also used to implement TPM (Trusted Platform
the memory layout of QSEE is known. In fact, the QSEE Module) on a software-only basis, without the need for ad-
resides unencrypted on eMMC flash and loaded at known ditional special purpose hardware [67]–[69]. There is a trend
to use TEE to secure various embedded system platforms, such [8] N. Asokan, J. E. Ekberg, K. Kostiainen, A. Rajan, C. Rozas, A. R.
as sensors and Internet of Things [70]. Sadeghi, S. Schulz, and C. Wachsmann, “Mobile trusted computing,”
Proceedings of the IEEE, vol. 102, no. 8, pp. 1189–1206, Aug. 2014.
TEE was used recently to provide self-protection to auto- [9] “Trustonic,” 2014. [Online]. Available: https://www.trustonic.com/
nomic systems. Azab et.al perform real-time protection for [10] Solacia, “SecuriTEE.” [Online]. Available: http://www.sola-cia.com/en/
kernels of mobile devices [44], while authors of [71] pro- securiTee/product.asp
[11] “STMicroelectronics, orange, and trusted logic to demonstrate secure
pose introspection mechanisms for operating systems using mobile phone and payment application,” 2005. [Online]. Available: http:
TrustZone-based trusted execution environment. //phys.org/news3041.html
[12] OMTP limited, “Advanced trusted environment: omtp tr1 v1.1,” 2009.
VII. R ELATED W ORK [13] A. Vasudevan, J. M. McCune, and J. Newsome, Trustworthy execution
This paper could be considered as a survey on the domain of on mobile devices. Springer Publishing Company, Incorporated, 2013.
[14] M. Sabt, M. Achemlal, and A. Bouabdallah, “The dual-execution-
trusted execution environment. Our approach is distinguished environment approach: analysis and comparative evaluation,” in ICT Sys-
from existing surveys. The closest work to ours are [8], [72]. tems Security and Privacy Protection, ser. IFIP Advances in Information
In [8], authors discuss trust computing in mobile devices. They and Communication Technology. Springer International Publishing,
2015, vol. 455, pp. 557–570.
focus on existing technologies and fail to provide a theoretical [15] J. M. Rushby, “Design and verification of secure systems,” SIGOPS
framework for TEE. Arfaoui et al. [72] present TEE uniquely Oper. Syst. Rev., vol. 15, no. 5, pp. 12–21, Dec. 1981.
according to GlobalPlatform standards. [16] J. Ames, Stanley R., M. Gasser, and R. R. Schell, “Security kernel
design and implementation: an introduction,” Computer, vol. 16, no. 7,
The particularity of our work is that we present a refined pp. 14–22, Jul. 1983.
definition of TEE. Its core properties are clearly defined. [17] “U.S. government protection profile for separation kernels in environ-
Other important related topics are discussed, such as formal ments requiring high robustness,” National Security Agency, Tech. Rep.,
Jun. 2007, version 1.03. [Online]. Available: https://www.niap-ccevs.org/
verification, known attacks, and a classification of the proposed pp/pp skpp hr v1.03.pdf
applications in the literature using TEE to guarantee security. [18] “The common criteria,” 2014. [Online]. Available: https:
//www.commoncriteriaportal.org/
VIII. C ONCLUSION [19] P. Wilson, A. Frey, T. Mihm, D. Kershaw, and T. Alves, “Implementing
TEE has practical interests and can be used to construct embedded security on dual-virtual-cpu systems,” IEEE Des. Test, vol. 24,
no. 6, pp. 582–591, Nov. 2007.
complex systems. Thus, we believe that deeper understanding [20] S. Zhao, Q. Zhang, G. Hu, Y. Qin, and D. Feng, “Providing toot of trust
of TEE is required in order to design better and more trust- for arm trustzone using sram pufs,” IACR Cryptology ePrint Archive, vol.
worthy systems. 2014, p. 464, 2014.
[21] GlobalPlatform Device Committee, “Tee protection profile,” 2014,
In this paper, we proposed a refined definition of TEE to version 1.2. [Online]. Available: http://www.globalplatform.org/
contribute in establishing a common understanding of this specificationsdevice.asp
term in the context of trusted computing. Furthermore, we [22] W. A. Arbaugh, D. J. Farber, and J. M. Smith, “A secure and reliable
bootstrap architecture,” in Proceedings of the 1997 IEEE Symposium
examined the building blocks of TEE explicitly differentiating on Security and Privacy, ser. SP ’97. Washington, DC, USA: IEEE
it conceptually from the classical notions of SEE and DRTM. Computer Society, 1997, pp. 65–71.
Moreover, we discussed how trust can be measured as well as [23] D. Sangorrı́n, S. Honda, and H. Takada, “Integrated scheduling for a
reliable dual-os monitor,” IPSJ Transactions on Advanced Computing
formal verification for TEE. Finally, we discussed TrustZone- Systems (ACS), vol. 5, no. 2, pp. 99–110, mar 2012.
based TEE, by providing a short survey using our proposed [24] J. Regehr and U. Duongsaa, “Preventing interrupt overload,” SIGPLAN
definition, presenting the known attacks and classifying the Not., vol. 40, no. 7, pp. 50–58, Jun. 2005.
proposed applications of TEE in the literature. [25] S. Chen, J. Xu, E. C. Sezer, P. Gauriar, and R. K. Iyer, “Non-control-
data attacks are realistic threats,” in Proceedings of the 14th Conference
Many challenges exist. Our future work will focus on on USENIX Security Symposium - Volume 14, ser. SSYM’05. Berkeley,
providing a formal definition for TEE, as well as explicitly CA, USA: USENIX Association, 2005, pp. 12–12.
defining the trust function in order to compute the trust level [26] GlobalPlatform Device Technology, “Tee client api specification,”
2010, version 1.0. [Online]. Available: http://www.globalplatform.org/
for the different TEE platforms. specificationsdevice.asp
[27] D. Sangorrı́n, S. Honda, and H. Takada, “Reliable and efficient dual-os
R EFERENCES communications for real-time embedded virtualization,” Information and
[1] N. Anciaux, L. Bouganim, B. Nquyen, I. S. Popa, P. Pucheral, and Media Technologies, vol. 8, no. 1, pp. 1–17, 2013.
P. Bonnet, Trusted cells: a sea change for personal data services, ser. [28] J. Jang, S. Kong, M. Kim, D. Kim, and B. B. Kang, “Secret: secure
ITU Technical Report Series. IT-Universitetet i København, 2012. channel between rich execution environment and trusted execution envi-
[2] “Trusted platform module (tpm) specifications.” [Online]. Available: ronment,” in Proceedings of 2015 Annual Network and Distributed System
https://www.trustedcomputinggroup.org/specs/TPM Security Symposium (NDSS’15), February 2015.
[3] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh, “Terra: [29] B. Parno, J. R. Lorch, J. R. Douceur, J. Mickens, and J. M. McCune,
a virtual machine-based platform for trusted computing,” SIGOPS Oper. “memoir: practical state continuity for protected modules,” in Proceedings
Syst. Rev., vol. 37, no. 5, pp. 193–206, Oct. 2003. of the 2011 IEEE Symposium on Security and Privacy, ser. SP ’11.
[4] “Secure payment via mobiles,” Card Technology Today, vol. 17, no. 3, Washington, DC, USA: IEEE Computer Society, 2011, pp. 379–394.
p. 5, 2005. [30] H. Löhr, A. R. Sadeghi, and M. Winandy, “Patterns for secure boot
[5] P. Wilson, A. Frey, T. Mihm, D. Kershaw, and T. Alves, “Implementing and secure storage in computer systems,” in Proceedings of the 2010
embedded security on dual-virtual-cpu systems,” IEEE Des. Test, vol. 24, International Conference on Availability, Reliability, and Security, ser.
no. 6, pp. 582–591, Nov. 2007. ARES ’10. IEEE Computer Society, Feb. 2010, pp. 569–573.
[6] N. Santos, H. Raj, S. Saroiu, and A. Wolman, “Using arm trustzone [31] V. Tsai, “emmc v4.41 and v4.5. architecture for high speed functions and
to build a trusted language runtime for mobile applications,” SIGARCH features,” 2010. [Online]. Available: http://www.jedec.org/sites/default/
Comput. Archit. News, vol. 42, no. 1, pp. 67–80, Feb. 2014. files/Victor Tsai.pdf
[7] GlobalPlatform, “TEE system architecture,” 2011. [Online]. Available: [32] “Trusted computer system evaluation criteria,” U.S. Department of
http://www.globalplatform.org/specificationsdevice.asp Defense, Tech. Rep. DoD 5200.28-STD, Dec. 1985.
[33] W. Li, M. Ma, J. Han, Y. Xia, B. Zang, C.-K. Chu, and T. Li, [57] L. Li, D. Huang, Z. Shen, and S. Bouzefrane, “A cloud based dual-root
“Building trusted path on untrusted device drivers for mobile devices,” trust model for secure mobile online transactions,” in WCNC’13, 2013,
in Proceedings of 5th Asia-Pacific Workshop on Systems, ser. APSys ’14. pp. 4404–4409.
New York, NY, USA: ACM, 2014, pp. 8:1–8:7. [58] M. Pirker and D. Slamanig, “A framework for privacy-preserving mobile
[34] D. Liu and L. P. Cox, “Veriui: attested login for mobile devices,” in payment on security enhanced arm trustzone platforms,” in Proceedings
Proceedings of the 15th Workshop on Mobile Computing Systems and of the 2012 IEEE 11th International Conference on Trust, Security
Applications, ser. HotMobile ’14. New York, NY, USA: ACM, 2014, and Privacy in Computing and Communications, ser. TRUSTCOM ’12.
pp. 7:1–7:6. Washington, DC, USA: IEEE Computer Society, 2012, pp. 1155–1160.
[35] GENODE Operating System Framework, “An exploration of arm [59] M. Pirker, D. Slamanig, and J. Winter, “practical privacy preserving
trustZone technology,” 2014. [Online]. Available: http://genode.org/ cloud resource-payment for constrained clients,” in Proceedings of the
documentation/articles/trustzone 12th International Conference on Privacy Enhancing Technologies, ser.
[36] D. Greve, M. Wilding, and M. Vanfleet, “A separation kernel formal PETS’12. Berlin, Heidelberg: Springer-Verlag, 2012, pp. 201–220.
security policy,” in Fourth International Workshop on the ACL2 Prover [60] R. Tögl, J. Winter, and M. Pirker, “A path towards ubiquitous protection
and Its Applications (ACL2-2003), 2003. of media,” in Proceedings Workshop on Web Applications and Secure
[37] K. Kawamorita, R. Kasahara, Y. Mochizuki, and K. Noguchi, “Applica- Hardware, ser. CEUR Workshop Proceedings, vol. 1011. Technical
tion of formal methods for designing a separation kernel for embedded University of Aachen, 2013, pp. 32–38.
systems,” vol. 4, no. 8, pp. 1076–1084, 2010. [61] Z. Ahmad, L. Francis, T. Ahmed, C. Lobodzinski, D. Audsin, and
[38] “HOL4,” 2014. [Online]. Available: http://hol.sourceforge.net/ P. Jiang, “enhancing the security of mobile applications by using tee
[39] “ACL2,” 2015. [Online]. Available: http://www.cs.utexas.edu/users/ and (u)sim,” in Proceedings of the 2013 IEEE 10th International Con-
moore/acl2/ ference on Ubiquitous Intelligence & Computing and 2013 IEEE 10th
[40] R. J. Richards, “Modeling and security analysis of a commercial real- International Conference on Autonomic & Trusted Computing, ser. UIC-
time operating system kernel,” in Design and Verification of Microproces- ATC ’13. Washington, DC, USA: IEEE Computer Society, 2013, pp.
sor Systems for High-Assurance Applications, D. S. Hardin, Ed. Springer 575–582.
US, 2010, pp. 301–322. [62] Y. Kim, J. Shin, C. Park, and W. Park, “Dfcloud: a tpm-based secure
[41] T. Murray, D. Matichuk, M. Brassil, P. Gammie, T. Bourke, S. Seefried, data access control method of cloud storage in mobile devices,” in
C. Lewis, X. Gao, and G. Klein, “Sel4: from general purpose to a proof Proceedings of the 2012 IEEE 4th International Conference on Cloud
of information flow enforcement,” in Proceedings of the 2013 IEEE Computing Technology and Science (CloudCom), ser. CLOUDCOM ’12.
Symposium on Security and Privacy, ser. SP ’13. Washington, DC, Washington, DC, USA: IEEE Computer Society, 2012, pp. 551–556.
USA: IEEE Computer Society, 2013, pp. 415–429. [63] J.-E. Ekberg, A. Afanasyeva, and N. Asokan, “Authenticated encryption
[42] ARMLtd, “Arm security technology - building a secure system using primitives for size-constrained trusted computing,” in Proceedings of the
trustzone technology,” 2009. 5th International Conference on Trust and Trustworthy Computing, ser.
[43] K. Kostiainen, J.-E. Ekberg, N. Asokan, and A. Rantala, “On-board cre- TRUST’12. Berlin, Heidelberg: Springer-Verlag, 2012, pp. 1–18.
dentials with open provisioning,” in Proceedings of the 4th International [64] R. van Rijswijk-Deij and E. Poll, “Using trusted execution environments
Symposium on Information, Computer, and Communications Security, ser. in two-factor authentication: comparing approaches,” in Open Identity
ASIACCS ’09. New York, NY, USA: ACM, 2009, pp. 104–115. Summit 2013, OID 2013. Springer, 2013, pp. 20–31.
[44] A. M. Azab, P. Ning, J. Shah, Q. Chen, R. Bhutkar, G. Ganesh, J. Ma, [65] C. Marforio, N. Karapanos, C. Soriente, K. Kostiainen, and S. C̆apkun,
and W. Shen, “Hypervision across worlds: real-time kernel protection “smartphones as practical and secure location verification tokens for
from the arm trustzone secure world,” in Proceedings of the 2014 ACM payments,” in The Network and Distributed System Security Symposium
SIGSAC Conference on Computer and Communications Security, ser. (NDSS), 2014.
CCS ’14. New York, NY, USA: ACM, 2014, pp. 90–102. [66] H. Liu, S. Saroiu, A. Wolman, and H. Raj, “Software abstractions for
[45] SierraWare, “Sierratee for arm trustzone.” [Online]. Available: http:// trusted sensors,” in Proceedings of the 10th International Conference on
www.sierraware.com/open-source-ARM-TrustZone.html Mobile Systems, Applications, and Services, ser. MobiSys ’12. New
[46] P. Brand, “Op-tee.” [Online]. Available: https://github.com/OP-TEE York, NY, USA: ACM, 2012, pp. 365–378.
[47] “Open-tee.” [Online]. Available: https://github.com/Open-TEE [67] K. Dietrich and J. Winter, “Implementation aspects of mobile and
[48] D. Sangorı́n, S. Honda, and H. Takada, “Dual operating system ar- embedded trusted computing,” in Proceedings of the 2nd International
chitecture for real-time embedded systems,” in Proceedings of the 6th Conference on Trusted Computing, ser. Trust ’09. Berlin, Heidelberg:
International Workshop on Operating Systems Platforms for Embedded Springer-Verlag, 2009, pp. 29–44.
Real-Time Applications (OSPERT), 2010, pp. 6–15. [68] J. Winter, “Trusted computing building blocks for embedded linux-based
[49] S.-C. Oh, K. Koh, C.-Y. Kim, K. Kim, and S. Kim, “Acceleration of arm trustzone platforms,” in Proceedings of the 3rd ACM Workshop on
dual os virtualization in embedded systems,” in 2012 7th International Scalable Trusted Computing, ser. STC ’08. New York, NY, USA: ACM,
Conference on Computing and Convergence Technology (ICCCT), Dec 2008.
2012, pp. 1098–1101. [69] S. Thom, J. Cox, D. Linsley, M. Nystrom, H. Raj, D. Robinson,
[50] N. Keltner and C. Holmes, “Here be dragons: vulnerabilities in trust- S. Saroiu, R. Spiger, and A. Wolman, “Firmware-based trusted platform
zone,” 2014. [Online]. Available: http://atredispartners.blogspot.jp/2014/ module for arm processor architectures and trustzone security exten-
08/here-be-dragons-vulnerabilities-in.html sions,” January 2013, uS Patent App. 13/193,945. [Online]. Available:
[51] D. Rosenberg, “Unlocking the motorola bootloader,” 2013. http://www.google.com/patents/US20130031374
[Online]. Available: http://blog.azimuthsecurity.com/2013/04/ [70] J. González and P. Bonnet, “Towards an open framework leveraging a
unlocking-motorola-bootloader.html trusted execution environment,” in Cyberspace Safety and Security, ser.
[52] ——, “Reflections on trusting trustzone,” Presented at Black Hat 2014. Lecture Notes in Computer Science. Springer International Publishing,
[53] S. Blog, “A software level analysis of trustzone os and 2013, vol. 8300, pp. 458–467.
trustlets in samsung galaxy phone,” 2013. [Online]. Available: [71] X. Ge, H. Vijayakumar, and T. Jaeger, “Sprobes: enforcing kernel code
http://www.sensepost.com/blog/9114.html integrity on the trustzone architecture,” in Proceedings of the 3rd IEEE
[54] W. H. W. Hussin, P. Coulton, and R. Edwards, “Mobile ticketing system Mobile Security Technologies Workshop (MoST), May 2014.
employing trustzone technology,” in Proceedings of the International [72] G. Arfaoui, S. Gharout, and J. Traoré, “Trusted execution environments:
Conference on Mobile Business, ser. ICMB ’05. Washington, DC, USA: A look under the hood,” in Mobile Cloud Computing, Services, and
IEEE Computer Society, 2005, pp. 651–654. Engineering (MobileCloud), 2014 2nd IEEE International Conference on,
[55] W. H. Wan Hussin, R. Edwards, and P. Coulton, “E-pass using drm in April 2014, pp. 259–266.
symbian V8 os and trustzone: securing vital data on mobile devices,”
in Proceedings of the International Conference on Mobile Business, ser.
ICMB ’06. Washington, DC, USA: IEEE Computer Society, 2006.
[56] S. Tamrakar, J.-E. Ekberg, and N. Asokan, “Identity verification schemes
for public transport ticketing with nfc phones,” in Proceedings of the Sixth
ACM Workshop on Scalable Trusted Computing, ser. STC ’11. New York,
NY, USA: ACM, 2011, pp. 37–48.