• Home

Extra

Proceedings on Privacy Enhancing Technologies ; 2016 (3):96–116

Chad Spensky, Jeffrey Stewart, Arkady Yerukhimovich, Richard Shay, Ari Trachtenberg, Rick
Housley, and Robert K. Cunningham
SoK: Privacy on Mobile Devices – It’s Complicated
Abstract: Modern mobile devices place a wide variety
of sensors and services within the personal space of their
users. As a result, these devices are capable of transpar-
ently monitoring many sensitive aspects of these users’
lives (e.g., location, health, or correspondences). Users
typically trade access to this data for convenient appli-
cations and features, in many cases without a full appre-
ciation of the nature and extent of the information that
they are exposing to a variety of third parties. Never-
theless, studies show that users remain concerned about
their privacy and vendors have similarly been increas-
ing their utilization of privacy-preserving technologies
in these devices. Still, despite significant efforts, these
technologies continue to fail in fundamental ways, leav-
ing users’ private data exposed.
In this work, we survey the numerous components of
mobile devices, giving particular attention to those that
collect, process, or protect users’ private data. Whereas
the individual components have been generally well
studied and understood, examining the entire mobile de-
vice ecosystem provides significant insights into its over-
whelming complexity. The numerous components of this
complex ecosystem are frequently built and controlled
by different parties with varying interests and incen-
tives. Moreover, most of these parties are unknown to
the typical user. The technologies that are employed to
protect the users’ privacy typically only do so within
a small slice of this ecosystem, abstracting away the
greater complexity of the system. Our analysis suggests
that this abstracted complexity is the major cause of
many privacy-related vulnerabilities, and that a funda-
mentally new, holistic, approach to privacy is needed
going forward. We thus highlight various existing tech-
nology gaps and propose several promising research di-
rections for addressing and reducing this complexity.

Keywords: privacy-preserving technologies, mobile, An-
droid, iOS

DOI 10.1515/popets-2016-0018
Received 2015-11-30; revised 2016-03-01; accepted 2016-03-02.

Chad Spensky: University of California, Santa Barbara,
cspensky@cs.ucsb.edu
Jeffrey Stewart: MIT Lincoln Laboratory,
jeffrey.stewart@ll.mit.edu

1 Introduction
The rapid proliferation of mobile devices has seen them
become integral parts of many users’ lives. Indeed, these
devices provide their users with a variety of increasingly
essential services (e.g., navigation, communication, and
Internet connectivity), as well as useful functionality
(e.g., entertainment and photography). To accommo-
date these services, modern mobile devices are equipped
with various sensors, capable of collecting extremely rich
information about their users and their surroundings.
Users and developers alike have embraced these data-
collection technologies with open arms, in exchange for
the rich set of high-tech features that they enable. In
fact, many of the apps offering these services are pro-
vided for “free,” with an implicit exchange for access to
portions of this collected data, which is typically used
for advertising [1].

Unfortunately, there is also evidence that users do
not understand the extent of information being collected
about them or the personal details that can be inferred
from this information. For example, a recent study on
behavioral advertising showed that users did not un-
derstand how such advertising worked and found the
information that the advertisers had about them to
be “scary” and “creepy” [2]. Even when the users are
aware of the data collection, one cannot expect them
to fully realize the non-intuitive implications of sharing
their data. Researchers have shown that the sensors on
these devices can be used to covertly capture key presses
(taps) on the phone [3, 4] or a nearby keyboard [5], leak
the users’ location [6–9], record speech [10], or infer the
users’ daily activities [11].

Predictably, having millions of users carrying these
data-collection technologies presents numerous privacy

Arkady Yerukhimovich: MIT Lincoln Laboratory,
arkady@ll.mit.edu
Richard Shay: MIT Lincoln Laboratory,
richard.shay@ll.mit.edu
Ari Trachtenberg: Boston University, trachten@bu.edu
Rick Housley: Stevens Institute of Technology,
rhousley@stevens.edu
Robert K. Cunningham: MIT Lincoln Laboratory,
rkc@ll.mit.edu

Unauthenticated
Download Date | 7/11/17 1:00 AM

SoK: Privacy on Mobile Devices 97

concerns. The collected data may be accessible to a va-
riety of parties, often without the explicit permission of
the user. For example, companies that provide trusted
kernels [12–14], which are relatively unknown to the
user market, have the technical means to access most
of the private user data that flows through their de-
vices. Similarly, companies that advertise in mobile ap-
plications are able to learn a large amount of private
information about the user (e.g., gender, age, or home
address [15]), and some location-based applications have
been shown to expose the users’ fine-grained physical lo-
cation not only to the application provider, but to the
world [16, 17].

Recent high-profile data leaks have publicized com-
promising photographs [18], large numbers of credit
cards [19], and National Security Agency (NSA) docu-
ments [20]. Leaks of financial, authentication, or medical
data can be used to access costly services (such as medi-
cal operations [21]) and could result in damages that are
extremely difficult to fix [22]. In this climate, it is not
surprising that many users are concerned about their
privacy [23] and have strong incentives to keep at least
some of their data private. One survey, conducted in
2015, found that many Americans believed it to be “very
important” to “be able to maintain privacy and confi-
dentiality in [their] commonplace activities” [24], while
another found that 57% of users avoided or uninstalled
a mobile application because of privacy concerns [25].

In an attempt to address these concerns, numerous
privacy-preserving technologies (PPTs) already exist at
every level of the device stack (e.g., hardware, operating
system, application), and some companies even high-
light these privacy features as part of their marketing
campaigns [26]. However, the complexity of the modern
mobile-device environments, both hardware and soft-
ware, and the piecemeal solutions offered by the indi-
vidual components make security difficult to implement
correctly and privacy difficult to achieve. In fact, the
numerous components are produced and provisioned by
disjoint entities with differing interests and incentives.
In effect, complexity can be the enemy of both security
and privacy, and the current on-device mobile ecosys-
tem is especially complex.

In this work, we shed light on this complex system
by surveying the numerous existing privacy-preserving
technologies, the components that each relies upon, the
parties involved, and the overall ecosystem they all co-
habit. Our findings suggest that existing approaches
have had marginal successes, but are likely going to con-
tinue to fall short of users’ realistic privacy desires unless
they are accompanied with fundamental changes to the

ways that these devices are produced, provisioned, and
regulated.

We scope our analysis to on-device technologies,
which we consider the users’ first line of defense. Still,
we recognize that a lot of private data may also leave
the device and enter a “cloud” infrastructure, introduc-
ing additional privacy concerns that we leave for fu-
ture work. We also focus on identifying gaps in today’s
systems and, rather than providing concrete solutions,
provide high-level and speculative suggestions for future
research. Finally, whereas other studies have analyzed
privacy on mobile devices (e.g., [3, 27–34]), we believe
our work is the first to examine the entire ecosystem
(i.e., hardware, software, human).

Mobile differentiators The problems that we have
outlined underscore the unique challenges of the mobile
device ecosystem with respect to privacy. These chal-
lenges arise from the very nature of the devices, which
are 1) extremely sensor-rich, 2) continually proximate
to their users, 3) often accessed in public and through a
limited interface, and 4) produced in a rapidly-changing
commercial environment. Neither laptops, with their
limited sensors, nor desktops, with their limited user
proximity, nor appliances, with their limited function-
ality and tightly controlled supply chain, provide the
same level of deep-seated risks to the user’s privacy.

Contributions Our work includes the following pri-
mary contributions, with the goal of painting a holistic
picture of the overwhelming complexity in the mobile
privacy space:
– We inventory critical privacy-related components

on modern mobile devices, highlighting interactions
that are likely unintended or unexpected.

– We identify the commercial entities currently re-
sponsible for deploying each technology.

– We itemize the various privacy-preserving technolo-
gies currently in use, calling attention to existing
and historical flaws and gaps.

– We enumerate the types of private data that are
currently accessible to the various parties.

– We describe several novel experiments that we per-
formed to verify privacy-related claims.

– We highlight promising proposals that could help
alleviate some of the existing problems.

Indeed, we conjecture that achieving privacy in the cur-
rent ecosystem is unlikely without fundamentally novel
technical and regulatory approaches.

Unauthenticated
Download Date | 7/11/17 1:00 AM

SoK: Privacy on Mobile Devices 98

2 Mobile Privacy Ecosystem
We begin our analysis by examining the components
that comprise the mobile ecosystem (see Figure 1 for
a brief summary). While mobile devices contain many
of the same components as traditional computing plat-
forms, and face many of the same privacy-related prob-
lems, there are fundamental differences at each layer
that can impact user privacy.

The first differentiator between mobile and tradi-
tional computing platforms is the users’ relationship
with the devices, and the interfaces that they use to in-
teract with them. More precisely, users typically carry
their mobile devices, in a powered-on state, with them at
all times, which is significantly different from the more
stationary use-cases of both laptops and desktops. Sub-
sequently, many user’s have developed a unique psycho-
logical connection with their mobile device, in extreme
cases developing an addiction [35]. Furthermore, while
having a small form-factor is convenient for mobility, it
also restricts potential user interactions. For example,
while computers use separate input and output devices
(e.g., keyboard, mouse, screen), these interfaces are fre-
quently integrated and overlapping in mobile devices
(e.g., touch screen), leading to various alternative in-
terfaces (e.g., audio, vibration, motion). Moreover, this
smaller, integrated, interface also restricts the amount
of information that can be conveyed to or received from
the user, which can lead to sub-optimal privacy imple-
mentations (e.g., omission of security indicators [36]).

The applications and operating systems that users
interact with on mobile devices are also fundamentally
different from traditional platforms. Historically, com-
puters have provided relatively open environments, per-
mitting developers essentially unfettered access to the
system and similarly allowing users to install any ap-
plication and modify their system in any way that they
desired. However, mobile-device providers have adopted
a more closed ecosystem, typically restricting the device
to a single, pre-installed operating system, which is de-
signed to only run applications written in a specific lan-
guage (e.g., Java, Objective-C). These applications sub-
sequently have very limited access to the system, using
pre-defined application program interfaces (APIs), and
are cryptographically attributed to an author. Mobile
devices have also attracted a significant amount of at-
tention from advertisers, due to the rich data available
on these devices that can be used to perform targeted
advertising [37]. This advertising-focused profit model
has led to a significantly different economic model from

User Input/Output Interfaces

Applications Application Code,Third-party Libraries

Operating System
Kernel, Drivers, Application APIs,

Cryptographic Libraries,
Sandboxing, App Verification

Firmware
FSBL, Bootloader, TEE Kernel,

Baseband RTOS, Cryptographic Keys,
SE & SIM OS

Hardware
AP, BP, SIM, SE, Sensors, Touchscreen,

Radios, Power Controller,
Cryptographic Chipset(s)

Fig. 1. High-level abstraction of the components that constitute
modern mobile devices.

that of traditional computers, as the users’ private data
has become the primary currency for most developers.

Finally, mobile devices include a diverse medley of
hardware components to provide the rich experience
that users have come to expect. Due to the relative com-
plexity of each component, they are typically produced
by individual manufactures and then later combined
into one unified device. Most of these hardware compo-
nents have access to a lot of private information, which is
not necessarily managed by the higher-level components
on the device. Moreover, these hardware providers typi-
cally provide their own firmware and drivers to interact
with their component, introducing even more complex-
ity into the software environment.

2.1 Hardware Components

Mobile devices contain a plethora of individual hard-
ware components that interact using various protocols.
In some cases, the components can interact and ex-
pose sensitive user data in ways that were not intended.
While the general hardware architecture of these sys-
tems has become extremely complex and varies wildly
between devices, there are still some overarching simi-
larities in both the included technologies and their in-
terconnections. Figure 2 diagrams the typical hardware
configuration found in modern smartphones.

Application Processor (AP) The application pro-
cessors (APs) on mobile devices are very similar to cen-
tral processing units (CPUs) found in traditional com-
puters, with a few caveats. First, because of the strin-
gent power requirements of mobile devices, many of the

Unauthenticated
Download Date | 7/11/17 1:00 AM

SoK: Privacy on Mobile Devices 99

Application
Processor
(AP)

TEE Coprocessors

Main
Memory

Baseband
Processor

(BP)

SIM
Flash

Memory

RF
Tranceiver

Touchscreen CameraSensors

Flash
Memory

USB
Controller

Power
Controller

Secure
Element

Audio Codec
(Microphone & Speaker)

WiFi/BT NFC GPS

Indicates that the connection is architecture dependent, and not a common configuration.

Wireless Modules

Fig. 2. Typical hardware configuration for a modern mobile device.

APs are designed with specialized low-power compo-
nents and employ aggressive power-saving techniques
(e.g., halting cores). Second, unlike legacy CPUs, many
mobile devices utilize the system on a chip (SoC) model,
wherein various sub-components (e.g., connectivity, me-
dia, location) are all included in a single silicon chip.
Components within the SoC frequently share resources
(e.g., memory), which can potentially leak private data.
Finally, many of the newer APs include a trusted ex-
ecution environment (TEE), which provides hardware-
enforced isolation for “trusted” code, as well as the abil-
ity to arbitrate access to hardware components. These
TEEs can be leveraged to enhance both security and
privacy, but also present another layer of complexity.

Mobile Coprocessors In addition to the main AP,
modern devices are equipped with additional coproces-
sors (e.g., Motorola’s X8 [38] and Apple’s M7 [39]) that
assist the AP with various functions, each accompanied
with their own firmware. More specifically, devices have
recently been incorporating a natural language proces-
sor (NLP) for audio processing, and a contextual com-
puting processor (CCP) for processing environmental
information (e.g., motion, light). These coprocessors are
typically used to offload computation from the AP and
enable “always on” applications (i.e., the device can
still be aware of it’s surroundings while the AP and
screen are in a power-saving state), which only wake
the AP when a trigger event happens (e.g., saying “OK,
Google,” or handling the device). This always-on state
could have serious privacy implications, as the users’
devices are likely collecting data about them even when
they believe the device to be “off.”

Baseband Processor (BP) The baseband proces-
sors (BP) are typically multi-core processors that run
a propriety real-time operating system (RTOS) as their
firmware, which is provided by the BP vendor. Their
sole purpose is to handle cellular communications, and
they are thus typically isolated from the rest of the hard-
ware on the device, with the exception of the micro-
phone, speaker, and subscriber identity module (SIM).
This permits the BP to remain performant when han-
dling voice calls, regardless of the load on the other com-
ponents. While the ideal implementation would enforce
hardware isolation, it is typically cost effective to in-
clude the AP and BP on the same SoC, which could
allow the BP to access main memory [40], and subse-
quently a lot of private user data, in addition to the
cellular communications that it inherently controls.

Universal Integrated Circuit Cards (UICCs) A
typical mobile device will contain at least two UICCs,
a SIM card for authentication to a mobile carrier, and
a secure element (SE) for handling user credentials on
the device itself. Both of these units contain yet another
completely self-contained processing unit in a security-
hardened environment [41]. These components can be
leveraged to protect user data and credentials by pro-
viding an isolated environment for cryptographic oper-
ations, which is typically leveraged for authentication
and encryption. However, modern SIM cards can also
perform other actions on the device (e.g., send short
message service (SMS) messages, open a web browser,
and send messages over the network [42, 43]), which
could be used to violate the users’ privacy.

Unauthenticated
Download Date | 7/11/17 1:00 AM

SoK: Privacy on Mobile Devices 100

Cryptographic Hardware In addition to SEs, some
manufacturers have recently begun including dedicated
cryptographic hardware for data encryption and au-
thentication. For example, modern Apple devices have
a dedicated module for encryption, using keys that are
fused into the application processor during manufactur-
ing to make them inaccessible from software [44]. These
cryptographic modules can be utilized to protect the
user’s private data when the device is “locked.”

Sensors Modern mobile devices are far more sensor-
rich than traditional computers, and are equipped with
a wide variety of sensing capabilities (e.g., movement,
location, light). Additionally, numerous peripherals, or
wearables, also enable access to pedometers, heart rate
monitors, and even sensors to detect blood oxygen lev-
els. These sensors are the source of much of the private
data collected by mobile devices, as even access to a
few of these sensors can provide incredible insights into
the user’s private life. For example, with just location
and accelerometer data, Google is able to provide users
with a complete log of their travels, including the mode
of transportation [45].

2.2 Software Components

While the general software architecture of mobile de-
vices is similar to that of traditional computers, there
are a few key differences, which we briefly highlight.

Trusted Kernel Unlike historic computers, which only
contained a single operating system, mobile devices fre-
quently contain a separate, feature-rich, trusted kernel
which is used inside the TEE. This trusted kernel is the
most trusted code on the device. Its job is to create an
isolated “non-secure,” or “normal,” world for the main
operating system (e.g., Android, iOS) to execute within.
The trusted kernel and the main operating system inter-
act using very limited interfaces (e.g., shared memory
regions), and the trusted kernel always maintains con-
trol of the non-secure world and has access to its entire
memory space. Thus, the trusted kernel can undermine
any data protections or privacy-preserving technology
deployed by the OS provider.

Operating Systems The major differentiator between
mobile OSs and their ancestors is primarily their closed
nature. They are typically more restrictive in both polic-
ing which apps are allowed to be installed, and subse-
quently restricting the app’s access once it is installed
and executed. In order to restrict this access, mobile

OSs employ sophisticated permissions models and ap-
plication sandboxing techniques.

Mobile Applications In addition to the closed envi-
ronment and advertising-focused economic model, the
types of applications available on mobile devices are
also significantly different from traditional computers.
Specifically, mobile applications are very likely to make
heavy use of their access to the various sensors. For ex-
ample, numerous popular social applications leverage
the users’ precise location, and health-related applica-
tions collect intimate details about the users’ personal
lives. However, many of these applications are devel-
oped quickly with functionality as their primary focus
and little thought given to user privacy, which can lead
to this personal data being mishandled (e.g., users’ in-
timate encounters appearing on search engines [46]).

Third-Party Libraries Many of the applications
available for mobile devices make use of third-party li-
braries, such as targeted advertising libraries [33], for
both functionality and profit. However, users are often
unaware of the existence of these third-party libraries
in the apps. What’s worse, because there is currently
no hard isolation between the components of an appli-
cation, these libraries have the same access to data and
sensors as their parent application, which is frequently
leveraged to collect sensitive user data [15, 47].

2.3 Parties Involved

Numerous parties are typically involved in the deploy-
ment and provisioning of mobile devices, each respon-
sible for different components. This significantly com-
plicates privacy protection as the different parties may
have varying incentives. Moreover, these parties often
retain control of their components after deployment
through over-the-air (OTA) updates. Understanding the
parties involved, and their access to, and control of, the
device is critical when analyzing the privacy assurances
that are provided for mobile device data.

Chip Vendors Unlike the AP, which typically runs
software that was provided by the device provider, both
the BP and UICCs typically come with pre-installed
software from their respective manufacturers. Because
of these hardware components’ privileged access in the
device, a vulnerability or backdoor could provide access
to private user data. In fact, Gemalto, a popular UICC
manufacturer, recently made allegations that the United
States’ and Britain’s intelligence agencies attempted to
compromise their devices [48]. Furthermore, the area

Unauthenticated
Download Date | 7/11/17 1:00 AM

SoK: Privacy on Mobile Devices 101

of malicious hardware has been gaining attention re-
cently with recent publications showing just how practi-
cal these attacks are [49]. Detecting malicious hardware,
if it exists, has been shown to be extremely difficult [50].

OS Provider The operating system (OS), and thus
its provider, generally has access to a great deal of sen-
sitive data. The OS is also responsible for ensuring ad-
equate software-based segregation of applications and
data sources. Most mobile OS vendors also employ re-
mote administration capabilities, permitting them to
provide updates post-deployment, as well as install and
remove applications [51, 52]. This could enable them
to change their protections or the amount of private
data they collect, without informing users. More inter-
estingly, many of the OS providers (e.g., Google, Apple)
also have a strong incentive to collect private user data
to leverage for advertising or their own services [53].

Trusted Kernel Manufacturers Recently, the desire
to use the TEE has led to the advent of “trusted ker-
nels,” which come pre-installed on our mobile devices.
Companies like Trustonic [54] and TrustKernel [13] pro-
vide this kernel to the device vendor, which then al-
low developers to install trusted applications within the
TEE. Trustonic claims to have their kernel installed on
more than 400 million devices, and permits over-the-air
(OTA) updates of “Trusted Services”[14]. These parties
have considerable power over mobile devices and an ex-
ploit in their firmware could be leveraged to completely
compromise most security and privacy protections.

OEMs and ODMs The vendor that assembles the in-
dividual components into a mobile device for end users
is called the Original Equipment Manufacturer (OEM)
or Original Design Manufacturers (ODM) (e.g., Apple,
Samsung, HTC, LG). These vendors design the hard-
ware system architecture, the connections between the
individual components, and often provide the first-stage
boot loader (FSBL). In the case of the Android, OEMs
typically modify the OS to incorporate specific hard-
ware functionality, pre-install applications, add or re-
move features, and add services to ensure continued
control over the device once it is deployed. Recently,
OEM vendors have also started including their own in-
terfaces and functionalities (e.g., Samsung’s Knox[55])
in the TEEs of their devices. Even when the OEMs have
the best of intentions, they are still capable of intro-
ducing severe vulnerabilities [56] as they are frequently
increasing the complexity and attack surface of the OS.

Mobile Internet Service Providers (MISPs) Most
modern devices rely heavily on Internet access provided

by mobile Internet service providers (MISPs). In fact,
many of the mobile devices on the market today are
sold directly by MISPs. These MISPs inherently can ob-
serve all unencrypted traffic, and can trivially ascertain
the rough physical location of devices using triangula-
tion with their broadcast towers. The 3GPP, a partner-
ship of communications interests, outlines the specifi-
cations for lawful interception of communications [57].
Many MISPs have far more access on devices than their
role of providing Internet access would suggest. In many
cases, they can remotely update the functionality of the
SIM [58], which has access to numerous functions on the
device enabling it to obtain global positioning system
(GPS) coordinates, open a browser, and communicate
with the BP and the AP.

Application Developers Mobile application devel-
opers inherently have the least-privileged access to the
private data. However, most of the device’s functionality
to users is provided through these applications. Thus,
exposing hardware sensors and other data sources to
these applications is typically necessary. While most of
these queries for data (e.g., GPS coordinates) will alert
the user, it has been shown that most users will blindly
accept these requests without much concern for how the
data will be used [29].

Third-party Library Providers Instead of develop-
ing entire applications, some developers focus on creat-
ing libraries that can be included in other applications
to provide specific functionality (e.g., cryptography, ad-
vertising, or graphics). Many developers use these li-
braries, exposing their data to the library provider.
In particular, in exchange for monetary compensation,
numerous applications include advertisement libraries.
Researchers found that as many as 52.1% of appli-
cations utilize ad libraries [33]. Therefore, these ad-
library providers can access a vast amount of user data
spanning numerous applications and operating systems.
Zang et al. found that 73% of Android apps shared per-
sonal information (e.g., name and email) and that 47%
of iOS apps shared location data with third parties [59].

Mobile Device Management Many employers ei-
ther provide mobile devices to their employees, or en-
courage them to bring your own device (BYOD), al-
lowing employees to use their personal devices for busi-
ness purposes. In both cases, the employer typically re-
quires a mobile device management (MDM) solution to
be installed, which provides the employer with a great
deal of control over the device (e.g., install/blacklist ap-
plications, modify security settings, and location track-

Unauthenticated
Download Date | 7/11/17 1:00 AM

SoK: Privacy on Mobile Devices 102

ing). Employees storing personal data on MDM-enabled
phones, and carrying them during off-business hours,
presents some interesting privacy concerns that, to the
best of our knowledge, have been left mostly unexplored.

2.4 Summary

The mobile-device ecosystem is a unique environment
with numerous perils for user privacy. Unlike most desk-
top and laptop computers, mobile devices are filled with
sensors that can collect a vast amount of sensitive data
since the devices are typically always on and always with
their user. Complicating things further, the hardware
components of the mobile-device ecosystem, and their
associated drivers, are provided by multiple vendors and
potentially give these providers access to sensitive user
data. Furthermore, software developers are allowed to
distribute their own code to these devices in the form
of apps with many of these monetizing the available
user data through third-party advertisement libraries.
The result is an ecosystem with multiple agents that
have access to private user data and a clear incentive to
gather, exploit, and share this private data.

3 Protecting Private Data
In this section, we review the numerous privacy-
preserving technologies and techniques employed on
modern mobile devices, across all levels of the stack.
These protections are deployed in an effort to add secu-
rity and privacy to the various components of the mobile
ecosystem discussed in Section 2. In our presentation,
we highlight the aspects of the technologies that make
them particularly interesting on mobile devices. Addi-
tionally, we restrict our analysis to Google’s Android
and Apple’s iOS platforms, which account for 97.8% of
the smartphone market [60].

3.1 Hardware-based Mechanisms

Both Android and iOS leverage hardware-based features
for protecting the privacy and security of sensitive data.

3.1.1 Trusted Execution Environment (TEE)

TEEs provide a hardware-enforced isolated execution
environment for security-critical code, which can pro-

vide a safe haven for storing and processing sensitive
data. The general concept behind TEEs is that this
“trusted,” or “secure,” world, can be verified using tech-
niques like secure or authenticated boot [61] and can be
leveraged to maintain a root of trust on the device, even
when the “normal,” or “non-secure,” world is compro-
mised. The most popular of these, due to their market
dominance, is ARM’s TrustZone [62].

This functionality is available on all modern ARM
cores and has only recently started to be leveraged to
protect user data. For example, both Android [63] and
iOS [44] are using this technology to protect fingerprint
templates and Samsung has deployed Knox [55], which
is used to provide segregation between the user’s per-
sonal and work-related data on the device. Howe

Extra

1. Read the article: SoK_Privacy on Mobile Devices

2. Write a summary for the article. The summary should have 2 paragraphs and no more than

2 pages. The summary should cover all key points in the article. You just need to focus on

the article itself, and no citations needed.

3. After the summary, you should write 3 different opening questions that related to this article

(Those questions cannot be simply answered by yes or no). You don’t have to answer them

but they should be heuristic, discussible, and closely related to the topic of the article.