[type=editor, orcid=0000-0002-7366-9034]

# Physical Fault Injection and Side-Channel Attacks on Mobile Devices: A
Comprehensive Survey

Carlton Shepherd<EMAIL_ADDRESS>Information Security Group, Royal
Holloway, University of London, Egham, Surrey, United Kingdom  Netherlands
Forensic Institute, The Netherlands  Equipe Commune CEA Tech – Mines Saint-
Etienne, CEA Tech, Centre CMP, Gardanne, France  French National Gendarmerie
Research Center (CREOGN), France  Institut de Recherche Criminelle de la
Gendarmerie Nationale, France  École Normale Supérieure, Paris, France
Konstantinos Markantonakis<EMAIL_ADDRESS>Nico van Heijningen
Driss Aboulkassimi  Clément Gaine  Thibaut Heckmann  David Naccache

###### A B S T R A C T

Today’s mobile devices contain densely packaged system-on-chips (SoCs) with
multi-core, high-frequency CPUs and complex pipelines. In parallel,
sophisticated SoC-assisted security mechanisms have become commonplace for
protecting device data, such as trusted execution environments (TEEs), full-
disk and file-based encryption. Both advancements have dramatically
complicated the use of conventional physical attacks, which has required the
development of specialised attacks. In this survey, we consolidate recent
developments in physical fault injections (FIAs) and side-channel attacks
(SCAs) on modern mobile devices. In total, we comprehensively survey over 50
fault injection and side-channel attack papers published between 2009–2021. We
evaluate the prevailing methods, compare existing attacks using a common
framework, identify several challenges and shortcomings, and suggest future
directions of research.

###### keywords:

Fault Injection Attacks
Side Channel Attacks
System-on-Chips (SoCs)
Mobile Device Security
Embedded Systems Security

##  1 Introduction

Powerful personal mobile devices have become ubiquitous over the past decade,
which is coupled with a substantial decline in the use of personal computers
[147]. Current estimates show that 3.8 billion people will be active
smartphone users in 2021 [146]. 84% of US citizens use a smartphone regularly,
rising to 96% in the 18–29 year old category, while 52% are estimated to use a
tablet [117]. Today, mobile devices are used widely for security- and privacy-
sensitive applications, such as banking, instant messaging, navigation, social
media, corporate email, and accessing cloud-based media. Consequently, mobile
device data is often of major value to malicious adversaries and forensic
investigators.

In certain scenarios, such actors may attempt to mount physical attacks
against mobile devices. Physical attacks exploit weaknesses in their physical
implementation, potentially circumventing existing security mechanisms—trusted
execution environments (TEEs), full-disk and file-based encryption, and secure
boot chains—to recover personal data, cryptographic keys, and other secrets.
In this work, we analyse two well-known classes of physical attacks— _fault
injections_ and _side-channel attacks_ —and their application to mobile
devices. These attacks are well-understood in the smart card and secure
element (SE) domain [100, 64, 124, 77]. Indeed, they are usually employed
during the evaluation of smart cards and SEs under the Common Criteria
framework [93].

Fault injection attacks (FIAs) perturb the device’s physical conditions beyond
that which it was intended; for instance, the application of high
temperatures, under- or over-volting the supply voltage, and intense
electromagnetic (EM) pulses. This can induce errors in the operation of
components, which can be used to recover secret data. In comparison, physical
side-channel attacks (SCAs) exploit physical measurements produced by a device
while it is running. These side-effects, such as EM emissions and power
consumption, can reveal secret data if the side-effect is dependent on the
secret data being executed.

The complexity of today’s mobile devices has led to difficulties when applying
FIAs and SCAs used on smart cards and micro-controller units (MCUs). Mobile
device system-on-chips (SoCs) utilise high-frequency (1GHz+), multi-core CPUs
with complex pipelines; mixed analog and digital components; and support
sophisticated operating systems (OSs) with multiple applications and
virtualisation. Ultimately, this has changed the types of physical attacks
that have been successfully mounted against mobile devices.

In this work, we consolidate and extensively evaluate the state of the art in
physical fault injections and side-channel attacks on mobile devices. We
examine over 50 attack papers published between 2009 and 2021, which are
compared using criteria regarding the target platform, the attack goals, any
prerequisites, and their results. After this, we identify some significant
shortcomings and highlight potential future research directions from the
current literature. To our knowledge, this is the first comprehensive survey
paper on physical FIAs and SCAs on modern mobile devices.

###  1.1 Scope

This survey examines _physical_ fault injection and side-channel attacks on
SoC-based mobile devices. We define these SoCs as the primary integrated
circuit (IC) for executing a complex OS, e.g. Android, and a set of user
applications aboard a commercially available device. They incorporate single-
or multi-core CPUs with memory management units (MMUs); multiple memory
modules, e.g. dynamic and non-volatile RAM, and flash storage; external
peripheral interfaces, e.g. I2C and GPIO; and an optional dedicated GPU.

We focus on attacks that exploit physical properties of SoCs whether wholly or
in part, such as power consumption and electromagnetic and acoustic
measurements. The taxonomic scope of this paper is shown in Figure 1. Wholly
software attacks are, therefore, outside the scope of this survey, which
include but are not limited to: micro-architectural attacks that are
exploitable only in software, e.g. cache timings and side effects of
speculative execution, and software timing attacks on security protocols and
cryptosystems.

While the focus of our work is physical FIAs and SCAs on mobile SoCs, we
include important advances in the embedded systems literature where
appropriate. This is particularly the case where mobile SoCs have not been
successfully attacked using a particular FIA or SCA method, but where they
have successfully compromised related systems, such as Internet of Things
(IoT) SoCs and MCUs. These techniques may inspire future attacks on mobile
devices.

for tree=rounded corners, top color=white, bottom color=gray!10,
edge+=darkgray, line width=1pt, draw=darkgray, align=center, anchor=children,
before packing=where n children=3calign child=2, calign=child edge, before
typesetting nodes=where content=coordinate, [Physical Attacks, [Fault
Injection
Attacks (FIAs) [Invasive [Laser
Beam] [ [Light
Pulse] [Focussed
Ion Beam] ] [Heavy-Ion
Micro-Beam] ] [Non-Invasive [Clock
Glitches] [ [Electromagnetic
Fault Injections
(EMFIs)] [Heating
Attacks] ] [Voltage
Glitches] ] ] [Side-Channel
Attacks (SCAs) [Power
Analysis] [ [Acoustic
Analysis] [Electromagnetic
Analysis (EMA)] ] [Temperature
Analysis] ] ]

Figure 1: Taxonomic scope of this survey.

###  1.2 Related Surveys

Table 1: Summary of related surveys. Work | Year | Summary
---|---|---
Barenghi et al. [25] | 2012 | Fault injection attacks on cryptographic systems.
Shepherd et al. [140] | 2016 | Security properties of secure execution platforms and TEEs for embedded systems.
Fournaris et al. [46] | 2017 | Micro-architectural attacks for embedded systems.
Spreitzer et al. [143] | 2017 | Network, micro-architectural, software, and some hardware SCAs on mobile devices.
Mirzargar & Stojilović [106] | 2019 | Physical SCAs and covert channels for FPGAs and cryptographic ASICs.
Sayakkara et al. [131] | 2019 | Electromagnetic side-channel analysis of embedded systems.
Han et al. [65] | 2019 | Program analysis using side-channel analysis for embedded systems.

In existing work, Barenghi et al. [25] (2012) presented an early survey of
FIAs on cryptosystems, e.g. AES, RSA and elliptic curve cryptography (ECC), in
the context of traditional and embedded systems. This survey was published
before the proliferation of modern mobile SoCs and TEEs, full-disk encryption,
and other modern security mechanisms. In 2016, Shepherd et al. [140] reviewed
secure and trusted execution environments for IoT systems, which compared
their security features and briefly discussed their susceptibility to physical
attacks. However, no FIAs or SCAs are analysed in detail. Spreitzer et al.
[143] (2017) surveyed general SCAs on mobile devices. It briefly covers
physical attacks and network traffic analysis, cache timings, and other
software channels outside the scope of this work. In 2017, Fournaris et al.
[46] focused on X86 and ARM Rowhammer attacks, with a brief discussion of
electromagnetic analysis (EMA). In 2019, Mirzargar and Stojilović [106]
surveyed SCAs on field-programmable gate arrays (FPGAs) and cryptographic
application-specific ICs (ASICs). The use of power, electromagnetic, and
thermal side-channels are examined for creating covert channels. Sayakkara et
al. [131] (2019) presented a tutorial on using EMA for digital forensics.
Methods are described for EMA measurement acquisition, their analysis for
hardware and software profiling, and the related standards; it is unrelated to
attacks on mobile security mechanisms. Han et al. [65] (2019) presented a
tutorial of program analysis using EMA and power analysis; the work presents
methods for signal acquisition and statistical analysis, e.g. correlation
analysis and machine learning.

The above surveys are summarised in Table 1. We note that other surveys have
covered general mobile attacks [158], cryptographic analysis methods [32], and
attacks on simpler systems like smart cards [100]. To our knowledge, however,
no survey paper has extensively covered state-of-the-art physical fault
injection and side-channel attacks on mobile devices. This paper addresses
that gap.

###  1.3 Structure

We begin in §2 with background information on modern mobile SoCs, their high-
level system features, and their use in common mobile security mechanisms.
Following this, we present comprehensive surveys of physical fault injection
and side-channel attacks in §3 and §4 respectively. The surveyed works are
compared extensively in §5, where we also present existing shortcomings,
challenges, and potential future research directions. Lastly, §6 concludes
this work.

##  2 Background

This section provides background information for understanding recent fault
injection and side-channel attacks. We provide an overview of SoCs and common
mobile security mechanisms, including TEEs, secure boot, key management
systems, and full-disk and file-based encryption.

###  2.1 Mobile System-on-Chips (SoCs)

The SoC is the centrepiece of contemporary mobile device hardware: an IC with
the core components for establishing a computing system. SoCs are used
ubiquitously because of their compact physical footprint and superior energy
efficiency compared to traditional computing architectures. SoCs are designed
largely by configuring reusable intellectual property (IP) semiconductor
blocks. These designs are developed in-house or licensed from a third party,
such as ARM, which are then fabricated into a single IC by the SoC vendor.
Various commercial designs exist for application processors [17]; security
extensions and cryptographic accelerators, e.g. the ARM TrustZone and
CryptoCell families [18]; and graphics and multimedia units, e.g. the ARM Mali
series [16]. In particular, ARM-based SoC designs are used in 90% mobile
handsets, tablets, and IoT devices [145]. By 2028, 90% automotive infotainment
and driver assistance systems, and 65% networking equipment is expected to be
driven by ARM-based SoCs.

Today’s mobile SoC vendors integrate a large number of these designs as
individual interconnected subsystems. High-frequency multi-core application
processors (1GHz+ clock frequencies) with multi-level caches and MMUs serve as
the main CPU platform. Around this, numerous dedicated memory units are used,
such as dynamic and static RAM, read-only memory (ROM), and flash memory.
Other common subsystems are timers and clocks and co-processors for
accelerating cryptographic operations, including digital signatures and
symmetric and asymmetric encryption and decryption algorithms. Integrated GPUs
and audio DSP units are also found widely for video and audio processing.
These components inter-communicate using on-SoC system buses that control and
transfer data between SoC subsystems. The precise capabilities of mobile SoC
models varies between vendors. Currently, the Qualcomm Snapdragon, Hisilicon
Kirin, Samsung Exynos, Apple A and M1, and the MediaTek Helios series are some
widely deployed mobile SoCs used by original equipment manufacturers (OEMs),
such as Motorola, Apple, Samsung, Xiaomi, and Huawei.

###  2.2 Trusted Execution Environments (TEEs)

A TEE is an isolated environment that hosts sensitive code and data in
parallel to a native OS. Its aim is to protect sensitive assets from
privileged software attacks. On mobile devices, TEEs protect—among
others—cryptographic keys, biometric authentication, payment processing, and
digital rights management systems. At present, the prevailing commercial TEEs
are Intel Software Guard Extensions (SGX) and the AMD Platform Security
Processor (PSP) for non-mobile platforms. On mobile devices, ARM TrustZone and
the GlobalPlatform TEE—a suite of specifications governing the use of TEEs—are
the main TEE architectures, arising from the popularity of ARM-based mobile
SoCs [13, 41, 140]. We discuss these TEEs and their properties next.

####  2.2.1 GlobalPlatform TEE Specification

The GlobalPlatform TEE is the prevailing set of specifications for governing
the architecture, management and security goals of TEEs [53, 56, 57]. It
establishes two worlds of execution: the rich execution environment (REE, or
the _untrusted_ or _non-secure_ world) and the TEE (_trusted_ or _secure_
world). The GP TEE architecture is depicted in Figure 2. The REE contains the
mobile’s native OS, such as Android, its firmware and user-space applications.
The TEE contains an independent security kernel, known as the trusted OS, and
a set of security-sensitive trusted applications (TAs). The REE communicates
with the TEE via a tightly controlled interface at the platform’s highest
privilege level, known as the secure monitor.

The REE and TEE must execute with hardware-enforced isolation if they utilise
the same underlying platform. This isolation is critical to prevent REE
adversaries from accessing secure world memory regions and peripheral devices.
Upon launch, the GP TEE must be initialised from a root-of-trust (RoT) using a
secure boot process. This process is described further in §2.3 for ARM
TrustZone—the principal method by which GlobalPlatform TEEs are instantiated
on ARM-based mobile devices. Crucially, this initialisation process must be
performed without trusting or co-operating with the untrusted REE.

The GlobalPlatform TEE specifies the GlobalPlatform Internal API [54] by which
trusted world applications (TAs) communicate with the trusted OS.
GlobalPlatform also specifies the Client API [52], which standardises the
communication interfaces between REE applications and the TAs via the non-
secure and secure world OSs. For the full specifications, the reader is
referred to the GlobalPlatform Technology Document Library [55].

Figure 2: GlobalPlatform TEE system architecture [53].

The GP TEE Protection Profile (GP TEE PP) is used to evaluate a GP TEE target
of evaluation (TOE) under the Common Criteria framework. It addresses
_“threats to the TEE assets that arise during the end-usage phase and can be
achieved by software means…focuses on non destructive software attacks that
can be easily widespread…and constitute a privileged vector for getting undue
access to TEE assets without damaging the device itself”_ [57]. The secure
monitor, TEE kernel, and the TAs are considered trusted. Errors in any of
these components can compromise the services that a TEE provides.

From a hardware viewpoint, the GP TEE can have access to a secure clock,
cryptographic accelerators, and volatile and non-volatile memory. The TEE must
access these without cooperating with the REE; the GP TEE must be self-
sufficient from any software or firmware components in the untrusted REE [53,
57]. As a minimum requirement, the GP TEE PP stipulates that TEE assets should
be defended against two high-level REE adversary types:

  * •

Basic remote attacker:  _“Performs the attack on a remotely controlled device
or alternatively makes a dow-nloadable tool that is very convenient to end-
users. The attacker retrieves details of the vulnerability identified in the
identification phase and_ […]  _makes a remote tool or malware and uses
techniques such as phis-hing to have it downloaded and executed by a victim_
[into the untrusted world]_.”_

  * •

Basic on-device attacker:  _“Has physical access to the target device; it is
the end-user or someone on his behalf. The attacker is able to retrieve
exploit code, guidelines written on the internet on how to perform the attack,
and downloads and uses tools to jailbreak, root, reflash the device in order
to get privileged access to the REE allowing the execution of the exploit. The
attacker may be a layman or have some level of expertise but the attacks do
not require any specific equipment.”_ [57].

The minimum GP TEE compliance level is evaluation assurance level 2 (EAL2).
EAL2 is applicable where only low-to-moderate level of assured security is
required using structured testing. This is lower than smart cards and secure
elements that are typically evaluated to CC EAL4+—a higher cost of evaluation,
requiring methodical design, testing, and review—with moderate-to-high
assurance. In addition, these platforms consider expert adversaries possessing
specialist testing equipment in order to conduct physical attacks. These
threats are typically not within the protection scope of TEEs. As a result,
physical fault injection and side-channel attacks can provide a promising
avenue for subverting GP TEE implementations.

####  2.2.2 ARM TrustZone

ARM TrustZone is a set of extensions to the ARM architecture that creates a
secure world of execution; it is the primary way by which the GlobalPlatform
TEE is implemented on ARM platforms [13, 41, 140]. Similar to the GP TEE
specification, TrustZone divides execution into ‘secure’ and ‘non-secure’
worlds. Each world hosts its own OS and applications at different processor
exception levels that communicate over a secure monitor at the highest ARM
exception level (EL3), as shown in Figure 3. The secure world OS is a security
kernel with limited functions to reduce the scope for vulnerabilities. It
implements the internal APIs, e.g. GlobalPlatform TEE Internal API [54],
memory management and process scheduling of TAs, and any trusted world device
drivers. Commercial TrustZone-based TEEs include Huawei iTrustee [72], Samsung
TEEGRIS [129], Trustonic Kinibi [154], and the Qualcomm TEE [123].

Figure 3: The ARM v8.4-A exception model [14].

ARM TrustZone uses a control signal, the ‘non-secure’ (NS) bit, to reflect the
world of execution at run-time. The NS bit is propagated through all areas of
the SoC where non-secure world adversaries may attempt to access secure world
material. This includes page tables, cache lines, and bus transactions to
memory firewalls and peripheral controllers. Any unauthorised access attempts
to secure world-only resources are prevented by the corresponding on-SoC
controller. Such controllers are the TrustZone Peripheral Controller (TZPC)
for protecting secure world-only peripheral interfaces, and the TrustZone
Application Space Controller (TZASC) for partitioning dynamic memory regions.
Any SoC bus transactions that carry a non-zero NS bit are blockable by these
controllers.

For inter-world communication, data can be transmitted between the REE and TEE
over a secure monitor at EL3. Alternatively, shared memory regions can be
established between the REE and TEE. For the former, user-space applications
communicate with the TEE using a library from the TEE OS provider. Library
calls are passed to the REE kernel driver—also provided by the TEE OS
provider–that uses the ARM secure monitor call (SMC) interface to enter
TrustZone’s secure monitor mode for performing the world context switch. Data
is passed to the secure world kernel and then to a target TA; responses are
returned using the reverse process. A reference implementation of the secure
monitor code and bootloading process is provided as part of the Trusted
Firmware project [90], which manufacturers can tailor to their own SoCs.

TrustZone aims to principally defend against privileged non-secure world
software attacks. Laboratory physical attacks are outside the protection scope
provided by TrustZone.

####  2.2.3 Apple Secure Enclave Processor

The Apple Secure Enclave Processor (SEP) is a proprietary hardware co-
processor on Apple devices. Very few publicly available details exist besides
features provided in official marketing material and high-level security white
papers and presentations [10, 82]. However, some reverse engineering methods
have been made independently [98, 40]. The SEP is directly initialised during
the secure boot process by the boot ROM, the device’s root-of-trust.
Crucially, the SEP is a separate physical processor for hosting sensitive
applications. This assists with defending against same-core side-channel
attacks mounted by malicious software.

The SEP provides access to hardware cryptographic operations, such as
encryption and signing services. In particular, it makes use of a Public Key
Accelerator (PKA)—a hardware block for asymmetric cryptography, such as RSA
and ECC. The PKA is designed to resist timing and side-channel attacks such as
simple (SPA) and differential power analysis (DPA) [11]. The SEP also uses
memory encryption between internal memory and external RAM to protect data in
transit between itself and and main memory. The SEP can also access its own
set of peripherals, a bank of eFuses, and widely used input/output interfaces,
such as GPIO and SPI. Application-wise, the SEP supports general iOS key
management and the Apple iOS biometric authentication systems, including Touch
ID and Face ID [10].

####  2.2.4 Google Titan M

In 2017, Google announced the Titan M hardware security module for the Pixel 2
smartphone, which executes independently from the device’s primary SoC [60].
The Titan module contains flash memory, CPU, RAM and a true random number
generator (TRNG) in a single package, which is designed to resist physical
side-channel attacks including power and electromagnetic analysis. It is also
resilient against FIAs, such as voltage, clock and temperature faults. The
Titan M supports general key and credential management for the OS and
applications, and stores the last known safe Android version to prevent
rollback attacks.

###  2.3 Secure Boot

Attackers who can load unauthorised bootloaders and secure/non-secure world
binaries can easily disable critical security mechanisms, e.g. the TEE and
file-based encryption, and execute their own code. Secure boot is designed to
enforce the loading of authorised and authentic software components that
underpin the device’s security.

Mobile devices contain multiple bootloader stages of increasing complexity and
decreasing security privilege. After receiving a reset signal, the SoC’s ROM
(BL1) performs basic setup operations, including power-on self-test (POST) and
clock initialisation. The trusted world binary and secure monitor firmware
(BL2) are authenticated and loaded after SoC ROM, but _before_ loading the
non-secure world image with the native OS and its applications. A generic
overview of the ARM boot procedure is shown in Figure 4.

The prevailing technique is to verify a chain of signatures beginning with an
initial root of trust (RoT), such as immutable on-SoC ROM. The RoT contains a
hash of a public key certificate that is used to verify the signature of the
next bootloader. This hash may also be stored in on-SoC one-time programmable
(OTP) eFuses. Bootloaders are signed using the manufacturer’s private key; the
boot process is stopped if an unauthorised component is loaded that fails
signature verification. The RoT verifies and loads the following bootloader,
which itself contains a public key for authenticating the next bootloader.
This process is repeated until the non-secure world image is loaded and
executed (Figure 5).

Figure 4: Generic ARM boot procedure [15, 159]. Figure 5: High-level
authenticated secure boot process.

Publicly available information is scarce regarding the specific cryptographic
algorithms used by OEMs during secure boot processes. However, we note that
the ARM Trusted Board Boot requirements specifies the use of SHA-256 and
RSA-2048 or 256-bit ECDSA for bootloader certificates, and AES-128 for
hardware symmetric keys [15]. Some devices also contain eFuses that are
permanently set (‘blown’) if signature verification fails during the boot
process [130]. The state of these eFuses persists through device restarts and
resets. These are used to permanently signal to the main OS that unauthorised
firmware was previously used that may have compromised device assets.

###  2.4 Secure Storage and Key Management

TEEs can provide secure persistent storage of sensitive material, such as
cryptographic keys. At a specification level, the GP TEE provides functions
via the Internal Core API [54] for data ‘binding’, which generates encryption
keys from a hardware unique key (HUK) using a key derivation function (KDF)
within the TEE. These keys are used to encrypt TA and TEE key material and
data; TAs can also use these keys to encrypt non-secure world data. The keys
must never leave the TEE and, as a result, encrypted material cannot be
decrypted on another device. The GP TEE supports a variety of cryptographic
algorithms that an OEM may use for internal TEE operations. This includes
128/192/256-bit AES in various modes of operation, e.g. CBC, XTS, and CTR; up
to 2048-bit RSA; 160- to 521-bit ECC, including ECDSA and ECDH; and 128- or
196-bit triple DES. The GP Internal Core API [54] specifies a full list of
supported algorithms and modes of operation.

A widely used TEE-based key management system is the Android Keymaster, which
allows user-space applications to generate and containerise cryptographic keys
within a TEE [7]. Application key material is generated using a TEE-resident
secret and never exposed outside the secure world. The Android framework
provides interfaces to developers to use this material, such as encryption,
decryption, and signature verification and signing operations. Direct access
to these keys is purposefully not given to users or developers. Since the
introduction of the Google Titan module (§2.2.4), the StrongBox Keymaster can
be used where supported. This is a Keymaster implementation aboard a tamper-
resistant hardware security module, like the Titan M [62].

On Apple devices, the SEP (see §2.2.3) handles key management for Mac OS’s
secure boot, encrypting data at rest, and securely storing biometrics data.
Each SEP is built with a hardware-based unique ID (UID) from which
cryptographic keys are derived for device binding. Additional class keys are
derived from a user-inputted password and a hardware secret, which are used
for per-file and volume encryption. Encryption keys are never directly exposed
to the device CPU. Moreover, the Apple T2 security chip, which contains the
SEP, has a dedicated AES-256 engine that is built into the direct memory
access (DMA) path between the flash storage and main system memory. This is
used for fast file encryption from the naive OS using keys from the SEP [10,
11].

###  2.5 Full-Disk and File-Based Encryption

Full-disk encryption (FDE) is used to encrypt all user data on a device at a
block level using symmetric key encryption, namely AES. User data is encrypted
before saving to it to disk; when the data is read, the decryption procedure
is performed before returning it to the parent process. Android’s FDE
implementation encrypts data using a device disk encryption key (DEK), which
is encrypted by a key encryption key (KEK) that is derived from the user’s
PIN/password. Only following successful boot-time user authentication is the
key released in order to decrypt the device data. Without successful
authentication, the KEK and the DEK are not released, so device data cannot be
decrypted [6].

File-based encryption (FBE) encrypts data at a filesystem level, unlike FDE
which operates at a block or volume level. FBE is generally considered to be
FDE’s successor on mobile devices: it allows essential data to still be used
for critical device functions—accessibility services, emergency calls, and
alarm managers—while keeping sensitive data encrypted when the device is
locked [8]. FBE generates per-file AES encryption keys, which are used to
dynamically decrypt and encrypt data as it is read and written respectively to
persistent storage. FBE is supported by Apple SEP and by Android 7.0+, which
supports directory-level encryption using the Keymaster TA for key management.

##  3 Fault Injection Attacks

Fault injection attacks (FIAs) are active attacks that physically perturb the
device beyond its intended operating conditions. The goal is to generate and
observe the results of abnormal system behaviour that an attacker can leverage
to access restricted functionality and data. FIAs have a long-standing,
approximately 25 year history, and have been analysed in great depth in the
wider smart card literature [25, 5, 31, 164, 21, 115, 69]. FIAs are
categorised as _transient vs. permanent_ , and _invasive vs. non-invasive_.
Transient faults are temporary errors that the system eventually recovers from
following a reset or when the fault source stops. Their aim is to temporarily
disrupt the system’s control flow or corrupt the results of an instruction to
gain access to unauthorised functionality and data. Permanent faults
indefinitely change the target component’s state, which persists through
device restarts and resets.

A typical physical FI (and SCA) setup—shown in Figure 6—instruments code on
the target device, or device under test (DUT), to trigger an external
generator at run-time. For FIAs, the generator injects the DUT with a
precisely timed and calibrated fault using the desired method, such as an EM
burst over a particular SoC die location. A control machine (PC) is used to
analyse the resulting data from the DUT—register values, memory addresses, and
encryption and decryption results—to identify exploitable faults, such as
instruction fetch errors and encryption/decryption bit errors. We note that
instrumenting a device with triggers is often not possible in black-box
testing environments, which renders precise fault injections significantly
more difficult.

Figure 6: Generic trigger-based setup using an external generator. For FIAs,
the generator injects the fault after receiving the trigger. For SCAs, the
trigger starts the measurement process.

###  3.1 Invasive FIAs

Invasive FIAs involve significant alteration to the target under test. This
includes depackaging the SoC or IC under evaluation, removing protective
layers, and directly inducing faults into internal components. There is a
significant risk that components can be irreparably damaged, which can lead to
the irreversible loss of forensic evidence when a device is under examination.
High-energy light pulses, near-infrared lasers, and ion beam attacks are
popular techniques, which can flip the transistor states of memory cells and
other components using carefully calibrated beams [142, 155, 120, 132, 152,
87, 157]. Historically, invasive FIAs using visible light and ultraviolet
energy bursts have also been popular on smart cards [77, 25, 155]. However,
these attacks have not been successfully applied to mobile SoCs. Indeed, very
few invasive FIAs in general have been publicly disclosed on modern mobile
SoCs.

####  3.1.1 Focussed Ion FIAs

The costliest FIAs employ focused ion beams (FIB)—typically liquid metal ion
sources, e.g. gallium ions—and heavy-ion microbeams (HIMs) that operate with a
high degree of precision (2.5nm). In general, FIB and HIM attacks are
extremely expensive ($100,000+ USD) and require access to specialist
laboratories and restricted testing equipment. Torrance and James [152] (2009)
described the application of FIBs to perform IC microsurgery on a DES ASIC,
which enabled the read-out of encryption keys. In 2015, Li et al. [87]
presented a HIM attack against a CRT-RSA implementation on a SRAM-based FPGA.
The FPGA was irradiated using 1 GeV of carbon ions, which triggered bit errors
at a rate of 8 times per hour during RSA decryption operations. It is
theorised that the recovery of a 1024-bit CRT-RSA private key is achievable
after approximately 128 hours, but experimental results are not provided.

####  3.1.2 Laser FIAs

Vasselle et al. [157] (2017) described a laser FIA to bypass the secure boot
process of an undisclosed Android smartphone with a ARM Cortex A9-based
(1.4GHz) SoC. This was achieved after physical and software reverse
engineering, package decapsulation, and targeting the SoC with a 978nm
infrared laser. The value of the Secure Configuration Register (SCR) could be
modified, which is used to hold the TrustZone NS bit for denoting the current
world of execution (see §2.2.2). The authors could modify the register with
95% success, which may be used to gain non-secure access to secure world
assets.

On an IoT SoC, a laser FIA was recently presented by Colombier et al. [37]
(2019) that modified the bits of words fetched from flash memory on a 32-bit
MCU. The targeted device was a ChipWhisperer board with an ARM Cortex-M3 CPU
(7.4MHz). Similarly, the authors decapsulate the target MCU and use a
calibrated infrared laser (1,064 nm) to induce faults that modified move-word
instructions (movw) to movt. This is leveraged to perform 128-bit AES key
recovery with two faulty ciphertexts after 128 attempts using a reference
software implementation.

###  3.2 Non-Invasive FIAs

Non-invasive FIAs require little-to-no tampering; their effects usually
disappear when the stimulus is removed or the device is reset. Non-invasive
FIAs are performed by perturbing physically accessible components without
decapsulating the target SoC/IC, removing adjacent components, applying
corrosive chemicals, etc. In general, non-invasive FIAs are less costly,
require cheaper and commercially available equipment, and risk significantly
less damage to the target component than invasive FIAs [25]. Well-studied non-
invasive FIAs are:

  * •

Voltage-based glitch attacks that under- or over-volt the device’s intended
supply voltage [121, 24, 149, 151, 150, 23, 111] (§3.2.1).

  * •

Clock glitches that under- or over-clock the device to induce faults [30, 2,
148, 80] (§3.2.2).

  * •

Heating attacks that expose device components to temperatures beyond that
which it was intended [81, 83, 63] (§3.2.3).

  * •

Electromagnetic FIs (EMFIs) that expose components to strong, targeted EM
pulses [39, 125, 42] (§3.2.4).

A summary of FIAs, their relative complexity, precision and risk is provided
in Table 2.

Table 2: Summary of FIAs based on [25] and [87].

Technique | Precision (Space) | Precision (Time) | Cost | Skill | Damage Risk
---|---|---|---|---|---
Voltage Glitch | Low | Moderate | Low | Moderate | Low
EMFI | Moderate | Moderate | Moderate | Moderate | Low
Clock Glitch | Low | High | Low | Moderate | Moderate
Heating | Low | Low | Low | Low | Moderate
Light Pulse | Moderate | Moderate | Moderate | High | Moderate
Laser Beam | High | High | High | High | High
FIB | Very High | Very High | Very High | Very High | High
HIM | Very High | Very High | Highest | High | High

  * •

EMFI: Electromagnetic FI, FIB: Focussed ion beam, HIM: Heavy-ion micro-beam.

####  3.2.1 Voltage-based Glitch Attacks

Voltage-based glitch attacks manipulate the target device’s supply voltage. By
under- or over-volting this source, or redirecting it to ground to generate
brownouts, an attacker can generate single- or multi-bit faults during
execution. Consequently, the processor can be coerced into corrupting or
skipping instructions, including security-critical verification steps. These
attacks have been used to recover cryptographic key material, skip signature
verification checks, and bypass system access control measures.

One of the earliest voltage glitches on a mobile phone SoC was presented by in
2009 by Barenghi et al. [23] against a reference software RSA implementation
on a 32-bit ARM9 CPU (ARM926EJ-S). The attack concentrates on energy-intensive
load instructions, which were susceptible to execution errors when the device
was fed a low supply voltage (underfeeding). During the instruction fetch
phase, the authors were able to induce faults to change the binary encoding of
logical operations (AND to EOR), conditional additions (ADDNE to ADDEQ), and
conditional branches (BNE to BEQ). Using this, three attacks on OpenSSL 0.9.1i
were presented: (1), factoring the RSA modulus when using the Chinese
Remainder Theorem (CRT); (2), an e-th root attack to retrieve an input message
encrypted under a correct and faulted encryption; and (3), a theoretical
attack for recovering the secret key during message signing. The instruction
swaps occur only a small number of times and _“may be reduced up to a single
one in the whole computation of a target algorithm.”_ Due to this rate, the
key recovery attack was not practical. For the first attack, 6.6%–39% RSA-CRT
computations were faulted of which 3.0%–39% were exploitable. For the second,
36.42%–62.77% of 1000 faulted runs were exploitable. We note that the target
is a single-core, low-frequency (266 MHz) SoC that can be considered obsolete
nowadays.

Later, Barenghi et al. [24] used the same approach—exploiting corrupted LOAD
instructions—to recover round sub-keys in the AES cipher. The attack is
independent of the key length or the number of rounds, and requires a fault-
free ciphertext and a small number of faulty ciphertexts generated from the
same plaintext. The attack is demonstrated using the same SoC as [23] using
Linux 2.6 and an AES implementation based on OpenSSL. The authors show it is
possible to break AES using 100,000 encryptions with different plaintexts and
2,000,000 encryptions of the same plaintext.

In 2016, Timmers et al. [151] presented two attacks that use a voltage-based
glitch to alter the program counter of an ARM Cortex-A9 AP on a Xilinx
Zynq-7010 SoC. Both attacks use instruction corruption vulnerabilities with
two load instructions (LDR and LDMIA) when the device is under-volted, which
alter the program counter on the 32-bit ARM architecture (AArch32). The first
attack targets the first bootloader—BL1, see §2.3—to bypass the secure boot
process. It requires the BL1 image to be overwritten with a malicious payload
containing shellcode and pointers. The fault must be injected precisely after
the device has copied the shellcode into volatile memory and while it is
copying the pointers. The fault, if successful, corrupts the instruction so
the pointer is copied into the PC register, thus executing the shellcode and
transferring control to the attacker. The second attack uses the same approach
to compromise the TEE after it has booted; it exploits the scenario where the
REE copies data to the TEE using a shared memory buffer. The attacker loads
the shellcode into the buffer and induces the fault when the world switch
occurs. The fault overwrites the PC with a pointer to execute the shellcode,
therefore compromising the secure world. 10,000 fault attacks on the LDR and
LDMIA instructions were conducted. For LDR, only a single (0.01%) glitch was
successful; for LDMIA, 27 glitches were successful (0.27%). Attacks against a
TEE or secure boot process on a consumer device were not shown.

Figure 7: Voltage FIA parameters [149].

In 2017, Timmers and Mune [149] describe three voltage FIAs on an undisclosed
SoC with a ARM Cortex-A9 CPU to achieve user-space privilege escalation. The
attacks assume the ability to run arbitrary Linux applications in an
unprivileged context. Voltage glitches are performed after carefully
characterising the glitch parameters: normal voltage, glitch voltage, glitch
length, and glitch delay (see Figure 7). The first attack uses an FIA during
the open syscall when opening /dev/mem/ to allow an unprivileged application
to map arbitrary addresses into physical memory. This is performed using an
instrumented untrusted application and injecting the fault during the Linux
kernel’s access control check, causing it to be bypassed. Attack two uses the
same instruction corruption attack as [151] to change the PC register within
the Linux kernel, triggering system crashes as a proof of concept. The third
attack targets the setresuid syscall to set an unprivileged application’s
process ID to root. This FIA is performed during the kernel’s verification
process, also causing it to be bypassed. The fault success rate was 0.53%
(attack one), 0.63% (attack two), and 0.41% (attack three).

In 2019, Qiu et al. [121] presented the VoltJockey attack on TrustZone
systems, which exploits the SoC’s dynamic voltage and frequency scaling (DVFS)
framework. DVFS which regulates the frequency or operating voltage of a multi-
core processor to minimise its power consumption, using kernel drivers to
control the device’s power management integrated circuit (PMIC) in software.
This can be used to lower the processor voltage to generate cross-core faults;
the attack path is shown in Figure 8. The attack assumes root access, a multi-
core processor, and that the voltage of the target multi-core processor can be
modified in software. Because the secure and normal worlds use the same
physical processor, faults induced by the non-secure world could be used to
perform key recovery from the secure world using a reference software AES
implementation. The faults induce byte errors in the eighth round of the AES
algorithm during its execution in the secure world. Attacks on RSA signature
verification are also demonstrated using a reference software RSA
implementation. Here, the authors show that desired plaintexts can pass
signature verification after introducing byte faults into the RSA public
modulus. This was exploited to load an unsigned TEE applications by the
TrustZone secure OS. Proof-of-concept attacks are mounted on the Google Nexus
6 smartphone with a Qualcomm APQ8084AB SoC. A success rate of up to 2.2% for
AES and 4.6% for RSA is shown. The proof-of-concepts, however, have never been
released. On non-mobile systems, similar attacks have been mounted
subsequently against Intel SGX for X86-64 [36, 122, 111].

Figure 8: VoltJockey attack sequence [121].

The NCC Group [113] (2020) published a voltage glitch vulnerability on a
MediaTek MT8163V SoC (ARM Cortex-A53). The SoC contains a one-time
programmable (OTP) eFuse bank and boot ROM that serve as the secure boot’s
root of trust and a certificate store for bootloader verification (see §2.3).
A potential voltage glitch is discovered after the first bootloader is loaded
from eMMC into RAM, which caused a secure boot signature verification check to
be skipped. The glitch is exploited by implementing a trigger on eMMC activity
to insert and load an unauthorised boot component. This component is used to
perform code execution at the highest level of privilege (EL3). The glitch
success rate was 15.21%–23.44%. While not demonstrated, the authors posit that
the glitch could be exploited to load an unauthorised TEE image.

####  3.2.2 Clock Glitch Attacks

Clock glitches manipulate external device clocks, such as introducing
additional clock edges (Figure 9), that can result in instruction misses and
data misreads. Instruction misses are caused by the circuit executing an
instruction before the CPU has completed executing the previous instruction.
Data misreads are caused by attempting to read values from a data bus before
the memory latches out the requested value in time. Historically, clock
glitches have attracted significant attention in the smart card and secure
element literature [20, 100, 101].

Figure 9: Using an FIA to introduce an additional positive clock edge [80].

At the time of publication, clock glitch attacks have found limited
application on mobile devices. An exception is the CLKScrew attack presented
by Tang et al. [148] (2017). The attack uses privileged software-based power
management on the SoC to generate faults that can be exploited for cross-core
attacks on TrustZone. CLKScrew also exploits DVFS—see Qiu et al. [121] in
§3.2.1—where frequency and voltage management is controlled from the non-
secure world to influence secure world operations. Specifically, software
overclocking is used to generate faults in the secure world. This is leveraged
to mount two attacks: (1), software AES key recovery from a secure world
process; and (2), corrupting OEM software RSA signature verification used by
the secure world to verify TAs before they are loaded. CLKScrew has several
prerequisites: kernel access is required to control the power manager, the
core clock frequency must be modifiable, interrupts must be disabled, and the
TrustZone application must be repeatedly invoked from the non-secure world in
order to decrypt arbitrary ciphertexts. The attack is evaluated using a Google
Nexus 6 using a Qualcomm Krait-based SoC and a TEE OEM implementation. On
average, useful faults are generated at a 5% rate for inducing a one-byte
fault to a desired AES round for the AES key recovery attack, and at a 1.51%
rate for the RSA attack.

Besides CLKScrew, no other published attacks have used clock glitches against
mobile phone SoCs. They have, however, been used against MCUs. Korak and
Hoefler [80] present clock glitches on a 16-bit AVR ATxmega256 and 32-bit ARM
Cortex-M0. The authors can generate instruction skips with arithmetical
(adds), branch (beq and breq), and memory instructions (ldr and str). It was
initially found that solely using clock glitches against the Cortex-M0 were
ineffective, leading a combined approach of performing a clock glitch with
supply voltage underfeeding. The ARxmega256 did not require voltage
underfeeding to generate faults. The attacks affected the _fetch_ and
_execute_ parts of the MCU instruction pipeline, which could be generated with
high probability (up to 100%). The test hardware was a Xilinx Spartan-6
XC6SLX45 FPGA with a NXP LPC 1114 (ARM Cortex-M0) and ATxmega256A3 extension
board. No attacks were presented against security mechanisms or cryptosystems.

In 2014, Blömer et al. [30] demonstrated clock glitch attacks against an
implementation of pairing-based cryptography (PBC) from the RELIC toolkit [12]
on an Atmel AVR XMEGA A1. The authors discover and exploit a clock glitch
vulnerability that triggered the skipping of a jump instruction (rjmp) used in
the PBC implementation that led to the recovery of the secret key. At most,
4,000 experiments are required to launch the attack (0.025% success rate).

Figure 10: A microcontroller with and without a phase-locked loop (PLL)
circuit using an external clock input [136].

One difficulty of performing clock glitches is the use of internal phase-
locked loop (PLL) circuits (Figure 10). The PLL processes the external clock
into the system clock frequency thereby acting as a filter. As a result,
traditional (external) clock glitches do not straightforwardly influence the
internal clock on today’s devices. Selmke et al. [136] (2019) demonstrated an
attack against a PLL-equipped ARM Cortex-M0 processor on a STMicroelectronics
STM32F0308R. The authors perform an FIA that effectively overclocks the PLL to
deliver deterministic perturbations in the PLL’s output frequency. Using this,
full key recovery is achieved against a reference AES software implementation
in ECB mode. In total, 1000 faults were injected of which 16.4% were
exploitable.

####  3.2.3 Heating Attacks

No heating attacks have been successfully demonstrated on mobile phone SoCs.
However, extreme heating has been known for $>$15 years to generate multi-bit
errors in DRAM memory and read/write threshold mismatches in non-volatile
memory [77]. In 2003, Govindavajhala and Appel [63] presented a proof-of-
concept showing that temperature-induced bit errors can lead to security
vulnerabilities. A 50W light bulb was used to increase the DRAM working
temperature of a personal computer to 100∘C, which was able to generate up to
10 flipped bits per 32-bit word; successful faults could be used with a 71.4%
probability. Using these, the authors develop attacks based on these errors
that circumvent the Java type system and introduce security vulnerabilities in
two commercial Java virtual machine (JVM) implementations. A major risk of
heating attacks is that excessive temperatures can leave long-lasting damage
to the target component, including destruction of the target IC [25].

In the microcontroller literature, Hutter and Schmidt [73] (2013) present
heating-based FIAs on an AVR ATmega162 MCU. A low-cost laboratory heating
plate is used to heat the MCU to $>$150∘C, beyond its maximum intended
temperature specification of 125∘C. The authors discover that the IC begins to
exhibit faults between a critical heating window of 152–158∘C. RSA-CRT
decryptions are then performed using a reference software implementation at
650ms intervals over a 70 minute period. This resulted in 100 faults of which
31 were exploitable using the Boneh et al. [31] RSA-CRT fault attack to
recover one of the prime moduli.

In 2014, Korak et al. [81] applied a heating attack to an AVR ATmega162. The
MCU is exposed to temperatures of up to 100∘C that facilitates clock glitch
attacks presented in earlier work by Balasch et al. [20] on an 8-bit smart
card MCU. The authors demonstrate that the clock glitches could be applied
with greater success at high temperatures to cause instruction repetition,
instruction replacement, and changing destination registers of instructions.
Attacks against particular cryptosystems or security mechanisms were not
shown.

####  3.2.4 Electromagnetic FI (EMFI)

Another FIA vector is to expose device components to strong electromagnetic
pulses. One of the earliest fault models was described in 2002 by Quisquater
and Samyde [125], showing that Eddy currents induced in the circuit are
captured by latches in the target IC, thus generating bit faults. Subsequent
fault models have been developed since, such as Raoult et al. [126], who
examined the coupling of a near-field probe to a PCB microstrip line.
Electromagnetic FIs (EMFIs) have greater spatial precision by targeting
particular ICs and shielding other components, performed using a high-
precision probe connected to an EM pulse generator. EMFIs on embedded systems
have been widely studied since attacks on smart cards in the early-2000s [125,
100, 101].

##### EMFIs on Mobile Phone SoCs.

The first mobile phone SoC EMFI was presented by Cui and Housley [38] (2017).
Here, the authors describe the BADFET attack, which leverages second-order
effects of EMFIs. They showed that faults generated in one component can
trigger faults in dependent components. A test-bed ($300 USD) is presented for
generating EM pulses that corrupt the contents of target DRAM and NAND flash
memory. This causes a fault in the CPU’s instruction cache, where the
bootloader code is loaded. The authors describe an attack that faults the
secure boot procedure to cause the primary bootloader to skip into an
unreachable code region that contains a debugging command line interface
(CLI). Using this, the authors load a separate binary that exploits a pre-
existing vulnerability in the device’s TrustZone SMC implementation (see
§2.2.2) to execute code in the TEE. A Cisco 8861 IP Phone with a Broadcom
BCM11123 SoC is used as the target of evaluation. Following the initial proof-
of-concept, the authors were able to replicate the attack 72 out of 100
retries (72%) on the same device.

Trouchkine et al. [153] (2019) explore fault identification on modern CPUs
when using EMFIs. Software-based micro-architectural and instruction-level
methods are presented for identifying the fault locations on ARM and Intel
CPUs. That is, whether the fault perturbed data in CPU registers, the
pipeline, MMU, caches or external memory. Experimental results are presented
showing that faults on CPU registers, the CPU pipeline, or memory can be
identified on a Broadcom BCM2837 SoC (quad-core ARM Cortex-A53 at 1.2GHz) and
an undisclosed Intel Core i3 CPU with 95% and 80% accuracy respectively. No
specific attacks on security or cryptographic systems are presented.

EMFIs have focused heavily on non-PoP SoCs. In 2019, Aït El Mehdi [3]
presented the first public results on applying EMFIs against package-on-
package (PoP) designs. The goal was to disable the Android lock-screen’s
timeout countermeasure against brute force attacks. While this did not
succeed, the author shows that the target device’s PoP chip is vulnerable to
EMFIs. The upper DRAM package is particularly vulnerable, showing that
instructions located in the package can be corrupted to modify program control
flow. The advantage here is that the glitched instruction persisted in the CPU
cache as long as it was not replaced. However, the specific device and SoC
model are redacted.

Gaine et al. [48] (2020) presented an EMFI privilege escalation attack on a
64-bit (non-PoP) SoC with four embedded ARM Cortex-A53 (up to 1.2GHz) CPUs on
a mobile development board. The target uses Yocto Project (Sumo), a Linux
distribution for hand-held and embedded devices with version 4.14 of the Linux
kernel. EM pulses were generated using an injection probe, shown in Figure 11,
on an XYZ motorised stage. The authors characterised the temporal and spatial
EMFI requirements using a test program; only one CPU on the target SoC was
sensitive to EMFIs. An instruction skip vulnerability is discovered and
exploited on a conditional branch instruction (cbz) used in the string
comparison (strcmp) C function. This is used to bypass the password comparison
procedure used by the substitute user Linux command (su). After implementing
an artificial trigger in libpam (the pluggable authentication module), which
performs the password procedure, a successful EMFI is performed every two
minutes for the same CPU with a fixed frequency and fixed probe position
(overall success rate of 2%). The authors are also able to perform the EMFI
with DVFS activated; 21 of 6000 FIs were successful (0.35%), equivalent to a
success every 300 attempts (15 minutes).

Figure 11: EMFI probe used by Gaine et al. [48].

##### EMFIs on MCUs.

Dehbaoui et al. [39] (2013) demonstrated an EMFI on a reference software AES
implementation on a 32-bit ARM Cortex-M3 CPU. The authors target the AES round
counter to induce the execution of an additional round to enable feasible
cryptanalysis. An EM pulse generator is used to perform the EMFI on the ninth
and tenth AES rounds with a high success rate (up to 100%). An key recovery
attack was presented, showing that the encryption key could be recovered with
two correct and two faulty ciphertext pairs.

Also on an ARM Cortex-M3, Moro et al. [109] (2013) describe instruction and
data corruption vulnerabilities by targeting the device’s data and instruction
buses. EMFIs are performed that: (1) modify the values of LDR instructions to
alter data flow, (2) generate hardware exceptions to alter control flow, (3)
replace STR instructions, and (4) modify processor registers. Empirical
analyses of the effect of EM pulse amplitude on the number and relative
frequency of bitset faults on data fetched from flash memory are presented. No
attacks are demonstrated against cryptographic implementations or security
systems.

Riviere et al. [127] (2015) demonstrated an EMFI on the instruction cache of
an ARM Cortex-M4. The authors demonstrate an EMFI with 96% success rate that
targets the update of the target processor’s prefetch queue buffer. Using
custom assembly programs, four instructions could be skipped and the following
four could be replayed. Like [109], no attacks are demonstrated against actual
cryptographic or security systems. However, it is discussed that the fault
model may be applied to CRT-based RSA, AES, and providing privilege escalation
on ARMv7-M architectures.

A known issue with EMFIs is the laborious process in finding effective fault
parameters, such as fault location and time. In 2016, Majéric et al. [97]
showed that EM side-channel analysis can expedite this process for identifying
spacial and temporal fault parameters. This was possible as the authors
discovered that EM emissions corresponded to particular Hamming weights. EMFIs
are conducted on a 128-bit AES hardware implementation aboard a cryptographic
co-processor of an undisclosed SoC with an ARM Cortex-A9 CPU (1GHz). The ninth
round of the AES implementation is successfully faulted at a rate of 0.03%.
Faulted ciphertexts can then be used to disclose the key using the Piret and
Quisquater [119] attack. Unfortunately, neither the specific AES
implementation, e.g. mode of operation; the cryptographic co-processor; nor
the SoC model are disclosed, besides that it is used by IoT and automotive
systems.

Liao and Gebotys [89] (2019) combine EMFIs with overclocking for disrupting
the pre-fetch stage of an 8-bit MCU (Microchip PIC16F687). The attacks trigger
bit-level corruption of opcodes, causing instruction replacement faults within
specific programs under evaluation. An exclusive-or (xorwf) and move-literal
(movlw) instruction were particularly vulnerable, which could be replaced with
other instructions with a 1.8%–98.7% frequency, including go-to (goto),
inclusive-or (iorwf) and bit-clear (bcf). An attack on a reference AES
software implementation is presented where, on average, 222 EM pulses and 5.3
plaintexts were needed for full key recovery. The authors speculate that
successful instruction replacements with goto could be potentially exploited
to bypass authentication checks during a device’s secure boot process. No
experiments were conducted to this end. The PIC16F687 also required backside
decapsulation.

Menu et al. [103] (2019) present data corruption EMFIs on the transfer bus
from flash memory to the 128-bit data buffer of an Atmel SAM3X8E MCU with an
ARM Cortex-M3 CPU. The attack enables resetting between zero and 128 bits with
byte-level precision. It also allows the targeting of the device’s pre-fetch
mechanism without disturbing or corrupting the code execution. An EM pulse
generator is used that delivers square voltage pulse (200V maximum amplitude)
with a 6ns minimum width and 2ns transition time. Three components are shown
to be vulnerable: the flash memory, the 128-bit pre-fetch buffer, bus
interfaces, and the register file. The authors target a public software
implementation of AES and assume the key is stored in flash memory. In the
first attack, an EMFI directly sets or resets the whole key as it is fetched
from memory, which was shown to be 100% repeatable. The second study applies
an attack by Biham and Shamir [29], which assumes that the attacker can
collect ciphertexts of known plaintexts while progressively resetting one bit
of the secret key until a zeroed key is reached. This is leveraged to reduce
the key-space of the 128-bit AES key to $16\times 2^{8}$, which can be easily
brute-forced. The last study provides a fault attack that requires a
persistent fault in one or more S-box look-up table elements. Any encryption
with this corrupted S-box results in a faulty ciphertext if the corrupted
entry is accessed during the encryption. It is shown that the AES key entropy
can be reduced to 32-bits when four elements of the S-box are corrupted using
EMFIs.

Elmohr et al. [42] (2020) conducted EMFIs against an NXP LPC 1114 with an ARM
Cortex-M0, where an EMFI corruption fault was discovered in the MCU’s
instruction pipeline. This occurs during the execution stage of load
instructions (LDR), which can be exploited to access unauthorised data. Using
a small test program, this fault occurs in cases when a branch (BNE)
instruction is being fetched at the same time. The faults occur with a
frequency of 31%, 13%, 12% and 12% for faulting two, three, four, and five
instructions at once respectively. Like [89], the LPC1114 required
decapsulation due to its external shielding, rendering it destructive.

##  4 Side Channel Attacks

Rather than inducing abnormal conditions into components, side-channel attacks
(SCAs) exploit observable physical properties emitted during execution. The
disclosure of the NSA TEMPEST programme [47] (1972) discussed how vulnerable
cryptographic implementations can leak information depending on the key and
the input data. The exploitation of such side-effects has received tremendous
attention by the research community for over 20 years, and continue to plague
systems today [35, 58, 160, 161, 165, 99].

In the wider literature, a plethora of SCAs have been developed that exploit
timing differences and cache access patterns in cryptographic implementations
[95]. This survey is focussed on physical SCAs that exploit distinguishable
environmental or electrical properties. Here, sensitive data—for example, key
recovery from vulnerable AES, ECC and RSA implementations—can be disclosed
using:

  * •

Power analysis: exploits differences in the device’s power consumption during
particular operations [58, 118, 133, 71, 116, 110].

  * •

EM analysis: uses magnetic field variations of operations under execution [1,
76, 112, 107, 19, 59, 94, 26, 34, 35, 4, 161].

While power and EM analysis are the most studied physical side channels,
others have been explored in the embedded systems literature, namely:

  * •

Acoustic cryptanalysis: leverages differences in sound waves during execution
[50].

  * •

Temperature analysis: exploits temperature emission differences during
execution [73].

We emphasise that predominantly EM analysis has been successfully applied to
mobile phone SoCs. The others have been applied extensively on simpler SoCs
and MCUs, which we survey as supplementary information. The following sections
now review state-of-the-art physical SCAs.

###  4.1 Power Analysis

Power analysis is the study of power variations consumed by the device.
Components contained within today’s mobile devices contain millions of
transistors that act as voltage switches. During execution, these components
are switched on and off, causing measurable voltage fluctuations. This is
traditionally measured using the supply voltage of the device under test.
Power analysis has been covered extensively for smart card and embedded
systems [110, 100, 133].

Interestingly, we note that only two power analysis attacks have been
conducted on a mobile device. Genkin et al. [49] (2016) used a power tap on an
iPhone 4’s USB charging port, which involved a USB pass-through adapter with a
0.33$\Omega$ resistor in series with the ground line. The phone was connected
to a battery pack via the adapter and the voltage over the resistor was
measured. With this approach, five ECDSA scalar-by-point multiplication
operations (using the same point and four different scalar values) can be
distinguished using the NIST P-521 implementation from OpenSSL. Detailed
experimental evidence is not presented regarding the success rates for full
key recovery, or its effectiveness using other devices. The second instance,
published by Lisovets et al. [92] (2021), is an additional investigation of a
predominantly EM-based SCA on an Apple iPhone 4. We discuss this work in
detail in §4.2.

Using the power consumption from the device’s USB outlet has also been used
for identifying high-level mobile device activity, including browsing
behaviour [163]. In general, however, power analysis attacks on mobile phone
SoCs face a myriad of challenges. Firstly, the density of modern mobile phone
SoCs renders it difficult to capture reliable measurements, with different
power planes, voltage regulators, and landside decoupling capacitors compared
to MCUs. Modifying the target’s SoC or PCB to acquire such measurements is not
straightforward and puts the device at significant risk of irreparable damage;
we return to this challenge in §5.3.4. Secondly, mobile phone SoCs contain
multi-core CPUs that host complex OSs with multiple applications, whose
individual power consumptions must be distinguished. PoP also designs add
another layer of complexity where researchers must account for multiple
packages in a single IC. All of these complicate the acquisition and analysis
of exploitable power traces for discriminating between target and irrelevant
program execution.

In this section, we instead cover recent power analysis attacks on embedded
systems. Lower complexity SoCs for IoT devices have been recently analysed,
which may offer a gateway for analysing full mobile phone SoCs in the future.

####  4.1.1 Key Recovery

Key recovery attacks use several common techniques to statistically analyse
power consumption waveforms, or traces. _Simple power analysis_ (SPA) directly
uses waveforms to identify particular instructions under execution and their
corresponding cryptographic operation. These operations can be chained
together to determine the data and the secret key upon which the operation is
applied. _Differential power analysis_ (DPA) is a more advanced technique,
first presented by Kocher et al. [78]. DPA uses statistical analysis of
multiple traces and ciphertexts to infer secret keys under execution. It is
based on computing correlations between the Hamming distance of intermediate
cryptographic operations and the power trace to determine key bytes. _Template
analysis_ involves collecting a set of traces and labelling their
corresponding cryptographic operation. Newly measured traces are then
classified by mapping it to its closest related template from this set.

A wide body of work has examined SPAs, DPAs, and template analyses on smart
cards, FPGAs and other embedded systems in substantial detail over the past 20
years [100, 99, 44, 108]. Recent power analysis research has focused on the
application of machine and deep learning, which can offer better
discriminative power over traditional, manually tailored statistical models.
Heuser and Zohner [71] (2012) present the use of support vector machines
(SVMs) to perform profiled power analysis. The authors use an 8-bit AVR
ATMega-256-1 MCU (8MHz clock) that executed a reference software AES
implementation. The AES S-box is used as the profiling target and the SVM is
used to classify the Hamming weight of the S-box value against the power
consumption. The authors show that the AES key can be recovered within 20
traces in low-noise environments and up to 60 traces in high-noise
environments. Since 2012, a wide variety of work has been published on machine
learning-based SCAs in numerous application areas besides power analysis. The
reader is referred to surveys by Hettwer et al. [70] and Jin et al. [74] for
detailed treatments of these works.

Deep learning (DL) methods currently represent the state of the art in power
analysis research. Deep learning models—neural networks with multiple hidden
layers—enable the ability to capture complex, non-linear interactions between
these power trace features. Maghrebi et al. [96] (2016) presented some of the
first results of DL methods applied to AES key recovery. Similar to [71], the
authors target an intermediate value of the AES’s first-round S-box produced
as a function of the plaintext and the secret key. The authors first attack an
unprotected FPGA-based AES implementation, showing that key recovery can be
achieved with 200 traces using a deep convolutional neural network (CNN).
Secondly, an unprotected reference software AES implementation aboard a
Chipwhisperer is attacked—a development board for side-channel analysis using
an AVR ATMega328P MCU. Using an autoencoder neural network, the first four AES
key bytes could be recovered with 20 traces. In the final experiment, the
authors develop a masked AES implementation for the Chipwhisperer. In the best
case, an autoencoder and CNN was able to recover the secret key using 500 and
1000 traces respectively.

In 2018, Picek et al. [118] explored the use of CNNs and traditional machine
learning approaches, such as XGBoost and Random Forests. The authors attack
the Hamming weight power consumption of the first AES key byte in the first
S-box operation. Protected implementations of AES are also examined, which are
collected from a Atmel AVR MCU. The authors use the DPAcontestv2 dataset with
50,000 traces. Using this, a 91.2% test accuracy was achieved when using CNNs
to classify the correct Hamming weight. However, it is noted that simpler
methods were also used effectively. All evaluated methods—XGBoost, Naïve
Bayes, Random Forest, and CNNs—were able to recover the secret key in fewer
than 10 traces. A similar approach has been used by Wang [160] (2019), which
uses CNNs to perform key recovery against two AVR ATXmega128D4 MCU boards
using a 128-bit AES reference software implementation in ECB mode. Notably,
the average number of required attack traces for full key recovery differs
significantly between the boards during experimentation, requiring 160 and 400
traces on average for each evaluation board.

In other power-based SCAs, Schmidt et al. [133] (2010) exploit the small but
measurable power consumption of exposed IC input/output pins. This is an
alternative method for whenever the direct measurement of power supply lines
is not possible, which is often the case on modern mobile devices without
invasive intervention. The authors test five devices: 8-bit Atmel ATMega163
and AT89S2853 MCUs, an NXP LP2148 MCU with a 32-bit ARM ARM7TDMI-S CPU, a
Virtex-II Pro XC2VP7 FPGA, and an ASIC. Each device contained an
implementation of a 128-bit AES reference software implementation without
side-channel countermeasures. Plaintexts are sent to the device over a serial
interface with an oscilloscope measuring the voltage on the I/O pin. DPAs are
conducted successfully on all devices, but the necessary number of traces to
mount the attacks is not provided.

In 2019, Gnad et al. [58] successfully mounted correlation power analysis
attacks against AES-128 on mixed-signal SoCs aboard IoT devices: a
ESP32-devkitC, STMicroelectronics STM32L475 IoT Node, and the
STMicroelectronics STM32F407VG Discovery. The attack uses power analysis to
exploit voltage noise generated by digital subsystems that perturb the signals
of on-SoC analog-to-digital converters (ADCs). The threat model is a malicious
program aboard the device that wishes to recover the secrets being executed by
another. Software is developed for performing AES-128 for single encryptions
of 128-bit plaintext messages, where mbedTLS was used for the software AES
implementation. Using correlation analysis, ciphertext-based key recovery is
successfully performed on the last round of AES using a dataset of 10 million
ADC noise traces.

####  4.1.2 Instruction Profiling on MCUs

Another, less-studied use of power analysis is for individual instruction
profiling. This enables an attacker to identify particular instructions under
execution on a device. This has a multitude of applications like detecting
unauthorised software and reverse engineering black-box programs. In this
area, Msgna et al. [110] (2014) investigate the use of power consumption to
recognise individual instructions on an Atmel ATMega163. Power traces are
captured using the voltage drop across a shunt resister connecting the MCU’s
ground pin and the ground pin of the voltage source. Figure 12 shows a sample
one-cycle trace of four ATMega163 instructions. 11 instructions are profiled
using a templating approach upon which dimensionality reduction is applied as
a feature extraction technique. The authors then apply two statistical
models—k-Nearest Neighbour (kNN) and multi-variate Gaussian probability
distribution function—to classify instructions. 66.78–100% recognition
accuracy is achieved using these models depending on the method used. In 2018,
instruction recognition was performed similarly by Park et al. [116] on an AVR
ATMega328P MCU. A larger set of instructions was targeted for recognition in
this work (112 in total). The authors use a classification model based on
quadratic discriminant analysis trained on 2,500 power traces per instruction,
achieving a recognition rate of 99.03%.

Figure 12: Power consumption of the NOP, MOV, ADD, and SUB ATMega163
instructions [110].

###  4.2 Electromagnetic Emission (EM) Analysis

Using EM analysis to compromise security systems dates back to 1943 when a
Bell Telephone engineer discovered oscilloscope perturbations while using an
encrypted teletype: the Bell Telephone model 131-B2. The next landmark was the
publication of a partially de-classified 1972 NSA paper documenting the
beginning of the TEMPEST program, which described how cryptographic systems
can be susceptible to information leakage via EM emissions [162, 47]. Since
then, EM analysis has been researched extensively to break security and
cryptographic systems, from smart cards to modern high-frequency system-on-
chips. These observable side effects from charge movements through the circuit
to other transistor gates, wires etc. This produces measurable electromagnetic
radiation emissions that can reveal sensitive data under execution [78, 65,
114, 104, 105].

This section surveys the state-of-the-art EM-based SCAs. Unlike power
analysis, EM analysis has been successfully applied in several works to mobile
devices.

##### EM SCAs on Mobile Phone SoCs.

In 2011, Aboulkassimi et al. [1] presented results of the first EM-based SCA
on a modern mobile device. The authors target a reference software AES
implementation executing on the Java Platform, Micro Edition (Java ME). A
trigger signal is sent over the device’s microSD card interface, using a
commercially available EM probe and oscilloscope for signal acquisition (see
Figure 13). Two novel methods are proposed: a spectral density-based approach
(SDA) and a template-based resynchronisation approach (TRA). These overcome
the difficulties in performing EM-based correlation attacks due to the garbage
collector and just-in-time (JIT) compiler, which introduce temporal
distortions in the EM traces. Using the proposed template-based
resynchronisation approach, the authors recovered one byte of the AES key in
one-hour after analyzing 250 traces of an undisclosed device with a 32-bit
RISC processor and 370MHz clock frequency. This platform can be considered
obsolete nowadays, however.

Figure 13: Experimental setup used by Aboulkassimi et al. [1].

In 2012, Kenworthy and Rohatgi [76] demonstrated side-channel attacks on three
undisclosed mobile devices using elliptic curve cryptography (ECC), RSA and
AES. The first device—a _“4G LTE smart phone from a major manufacturer”_ —is
used to perform 2048-bit RSA-CRT encryption, which is a self-written
implementation using the square-and-multiply approach. From a single trace,
the secret RSA-CRT exponents could be recovered using using a Yagi antenna,
magnetic probe, an ICOM 7000 receiver, and an Ettus Research USRP digitizer
costing $1000 (USD) at the time of writing. The second device, _“a mobile
PDA,”_ is used to perform elliptic curve point multiplication over P-571 using
a self-written double-and-sometimes-add implementation. The authors are able
to perform full key recovery using a single trace with an EM probe located
approximately three meters (10 feet) away from the device. The third device,
_“another mobile phone from a major mobile manufacturer,”_ uses the platform’s
AES-128 library to perform AES-CBC encryption on a 200kB data buffer. In this
experiment, traces corresponding to 12,500 individual AES block operations
were required to perform key recovery using DPA. For all device targets, it is
not disclosed whether or how any triggers were used, if at all.

Nakano et al. [112] (2014) present SPA attacks on ECC and RSA implementations
on an undisclosed Android smartphone with a clock frequency of 832MHz. The
authors aim for key recovery on ECC and RSA implementations provided by
Android’s Java Cryptography Extension (JCE) library. The RSA implementation
uses a square-and-multiply approach, which has been shown in much previous
work, e.g. [76], to be vulnerable to side-channel analysis. Similarly, ECC
double-and-multiply operations are also exploited as in [76]. Analysis at the
10 MHz and 20 MHz frequencies yielded the best results for key recovery, which
was achieved in a single trace for both algorithms. The precise nature in
which triggers were implemented are not disclosed.

In 2015, Balasch et al. [19] presented EM-based DPA attacks on a 32-bit ARM
Cortex-A8 CPU (1GHz). The attacks focus on a customised bitsliced AES-128
software implementation from Könighofer [79] (2008), designed to thwart cache
timing attacks, which executed on a Texas Instruments AM3358 Sitara SoC aboard
a Beaglebone Black single-board computer (SBC). The target system uses a Linux
distribution based on Debian 7 with kernel v3.8.13-bone47. Interestingly, the
authors attack both unprotected and masked versions of the bitsliced AES
algorithm, the latter intended to thwart side-channel analysis. In total, 1.2
million measurements were needed at most to break the masked algorithm using
first-order DPA, while 400,000 were required to successfully mount a second-
order DPA. Using the unprotected algorithm, 10,000 traces were required for
key recovery.

Figure 14: Device under test used by Goller and Sigl [59]. The red cross
illustrates the optimal EM probe position. Figure 15: Average of 1063 RSA EM
traces. Grey regions show the key bits recovered by Goller and Sigl [59].

Goller and Sigl [59] (2015) attack an RSA implementation on five unnamed
smartphones; although, one PCB serial number disclosed in the paper
corresponds to a Samsung Galaxy S3 (Figure 14). The authors removed the
device’s shielding plate for stronger EM emanation and used probe connected to
a high-gain amplifier attached that was placed on a capacitor near the main
CPU. A C program was developed using the Android SDK with a reference software
square-and-multiply RSA implementation. The EM waveforms that emanated during
its execution were collected using a software-defined radio. The waveforms are
shown to clearly correspond to the bits of the processed key (Figure 15). With
the shielding plate installed, 276 traces were required to perform full key
recovery with high confidence (0.999 correlation), while 170 traces were
required without the shielding plate.

Longo et al. [94] (2015) conduct EM DPAs against an AES implementation on a
gigahertz CPU. The target is a BeagleBone Black with a Texas Instruments
AM3358 SoC and a ARM Cortex-A8 CPU (1GHz ), the same as Balasch et al. [19].
The target ciphers are a software implementation of AES-128 in CBC mode, taken
from OpenSSL, and an AES-256-CBC implementation on the SoC’s cryptographic co-
processor. DPAs were mounted successfully on both. For the software
implementation, 20,000 traces were required for the correct key hypothesis.
The analysis of the security co-processor required 500,000 sets of 1,000
averaged traces (500 million traces in total). Notably, it is stated that the
co-processor DPA may be useful against implementations of full-disk
encryption. While no experimental evidence is presented for this use case, it
is one of the few papers to attack a physical cryptographic co-processor. No
proof-of-concept code has been released for the co-processor.

In 2016, Belgarric et al. [26] discovered that ECDSA implementation in
Android’s Bouncy Castle cryptographic library was vulnerable to EM analysis,
whereby addition and multiplication operations are distinguishable. Full key
extraction is demonstrated by placing an EM probe within an open case of the
phone. Traces are triggered via the USB interface and subsequently measured
using an oscilloscope. A lattice attack is performed on an undisclosed
smartphone with a Qualcomm MSM7225 SoC. As a use case, the authors attack and
successfully compromise an Android-based Bitcoin wallet key. Experimental
evidence is presented showing that up to 39 ECDSA signature traces were
required for full key recovery, which took 102 seconds at most.

Similar results were presented concurrently by Genkin et al. [49] (2016). The
authors also demonstrate full key recovery on ECDSA using the OpenSSL
implementation on iOS and Android devices. The attack is less invasive than
[26], requiring only a magnetic probe placed in proximity of the device and
does not require any hardware or software triggers. In the work, ECDSA is
exploited experimentally using a Sony-Ericsson Xperia X10 and iPhone 3GS as
the devices under test. In total, 5000 signature traces were collected and
analysed across the devices, two of which (0.04%) could be exploited to
recover the key.

Bukasa et al. [34] (2017) present the first investigation into EM SCAs on ARM
TrustZone. The work analyses unprotected reference software implementations of
AES and a PIN verification algorithm. A Raspberry Pi 2 is used as the device
under test, which uses a Broadcom BCM2836 SoC with a quad-core ARM Cortex-A7
at 900MHz. The effect of multi-core versus single-core execution is examined
alongside secure-world versus non-secure world execution. A templating
approach is employed using 150,000 EM traces as the training set; a success
rate of 17.81%–38.30% is then demonstrated depending on the system
configuration. The scenario of multi-core execution in the secure world
produces the lowest success rate (17.81%), while single-core execution in the
non-secure world with the MMU disabled produces the best results (38.30%
success).

Alam et al. [4] (2018) present the One&Done attack, which is used to recover
RSA encryption keys from a single decryption trace using OpenSSL (version
1.1.0g). Interestingly, the attack is effective even against a 2048-bit fixed-
window constant-time RSA implementation, and when the plaintext message is
blinded. The attack, based on modelling potential control flow transitions of
Montgomery multiplications, examines frequencies at 40MHz around the target
device’s clock frequency. Two Android mobile phones are used for evaluation.
The first is a Samsung Galaxy Centura SCH-S738C with a 800MHz Qualcomm
MSM7625A SoC and an ARM Cortex-A5 CPU. The second device is an Alcatel Ideal
with a Qualcomm Snapdragon 210 MSM8909 and a quad-core ARM Cortex-A7 CPU. A
single-board computer is also evaluate with an Allwinner 13 Cortex-A7 CPU.
During experimental validation, 95.7%–99.6% of the target key’s bits are
successfully recovered depending on the platform.

Leignac et al. [86] (2019) further examined whether the effectiveness of EM-
based SCAs differed between TEE and REE execution. To this end, the authors
compared EM side-channel leakages on a reference software AES implementation
in the REE and TEE of a HiKey SBC. The SBC has an octo-core ARM Cortex-A53
(1.2GHz), Android Oreo as the REE OS, and Trustonic Kinibi as the TEE OS; the
same SoC is used by the Huawei P88 and Honor 5A smartphones. The work shows
that the TEE is still vulnerable, although attack synchronisation was more
complicated. Recovering the AES key was in the same order of magnitude as the
REE (6000 traces), demonstrating little difference between EMFIs conducted on
a REE or TEE.

Figure 16: Lock-in thermography of the SoC die used by Vasselle et al. [156]
showing heat maps of IR amplitudes (left) and in-phase AES emissions (right).

The first SCA on package-on-package (PoP) SoCs was presented by Vasselle et
al. [156] (2019). The attack recovers the key used by boot ROM for decrypting
BL1 firmware when it is loaded during the secure boot process (see §2.3). The
DRAM PoP package was shown to produce greater EM noise than the main SoC; to
counter this, the authors separated the main SoC from the DRAM package using a
hot air station. This process required practice on multiple PoP SoCs to
prevent irreparably damaging the target. This approach only worked for BL1, as
the absence of DRAM caused a fatal boot deadlock at BL2. EM measurements were
then collected by targeting the on-SoC cryptographic co-processor using a
Lecroy WaveRunner oscilloscope, a Langer H-Field probe and a low-noise
amplifier. Lock-in thermography was used to identify the co-processor using
infrared measurements during encryption and decryption operations (Figure 16),
which was used to position the EM probe. The authors then acquire 2,500 traces
and 5,000 encrypted firmware binaries to be decrypted (12.5 million AES-CBC
operations in total). Correlation analysis was used to recover the co-
processor’s AES key using two firmware encryptions and 2,500 averaged traces.
All details pertaining to the identity of the PoP, SoC and cryptographic co-
processor are redacted; information about the trigger implementation is also
not made public.

Figure 17: Partial PCB modifications made by Lisovets et al. [92] for
providing an artificial power supply to the Apple A4 via an external board
(modified: left; unmodified: right).

Recently, Lisovets et al. [92] (2021) presented the first physical SCA on an
Apple iPhone for extracting the 256-bit device-specific, hardware-based user
identifier (UID) key. The UID key is used as input with the user’s passcode to
a password-based key derivation function to generate a passcode key. This
passcode key is used subsequently to unwrap additional keys from the system
keybag, a system file in which per-file data encryption keys are stored by the
iPhone’s on-SoC AES encryption engine for FBE.111The work targets an Apple
iPhone 4, which does not include a Secure Enclave Processor found on modern
iPhone models (§2.2.3). The SEP prevents the application processor from
accessing the UID for ultimately unwrapping FBE keys. Exploiting vulnerable
boot ROM is, therefore, not enough to access the AES engine to mount the same
attack. A two-part attack is used for recovering the UID. The first part
requires exploiting a vulnerability in boot ROM to load an unauthorised
bootloader that can submit unlimited encryption queries to the AES engine. The
second part is then to use a chosen-plaintext SCA attack using EM-based
correlation power analysis of the AES engine. Traces are collected by placing
a probe on the Apple A4 SoC, which are triggered by the unauthorised
bootloader after re-configuring one of the device’s GPIO pins, e.g. volume
button. For the measurement equipment, a Langer EMV-Technik RF-B 0,3-3 EM
probe, a Langer EMV-Technik PA 303 SMA amplifier, and Teledyne LeCroy
WaveRunner 8254M with 2.5 GHz bandwidth (sampling at 40 GS/S) are used.
Successful key recovery was achieved after 300 million traces at most
collected over a two week period; less than three hours was needed to perform
the analysis using two Nvidia RTX 2080 TI GPUs. In addition to the EM-based
attack, a power-based SCA is mounted by measuring the voltage across a
$1\Omega$ shunt resistor on an external board connected between an external
power supply and the iPhone, which required modifying the PCB (Figure 17).
Using this approach, the authors are able to recover the UID key with 200
million traces using correlation power analysis. While experimental evidence
is not provided, the authors believe the attack can be extended to modern
models but SCA countermeasures might be present.

##### SCAs on MCUs and Related Systems.

In related work, Montminy et al. [107] (2013) demonstrate the extraction of an
AES encryption key running on a 32-bit processor with a 50MHz clock frequency.
The device under test is a Stellaris LM4F232H5QD MCU with an ARM Cortex-M4F,
which is used to run a reference software implementation of AES-128 in ECB
mode. The main acquisition equipment is a near-field probe and a software-
defined radio to collect EM waveforms, including a modified digital television
received costing $20 (USD) at the time of publication. Using this, the authors
successfully mount a correlation-based analysis attack to extract all AES key
bits using 100,000 traces.

Using an Intel single-board computer, Saab et al. [128] (2016) presented an
EM-based DPA attack on Intel’s AES-NI instruction set extensions to the Intel
Core i7 Ivy Bridge architecture. An Intel Core i7-3517UE was used as the
target of evaluation. A dedicated application was targeted in C that made
calls to Intel’s AES-NI sample library (version 1.2), which looped over a
group of AES-256 (CBC mode) calls to the assembly routine iEnc256_CBC. After
collecting 1.5 million traces over 17 days, statistically significant Hamming
distance leakage is discovered due to loading differences in a CPU cache. A
second attack is described that also uses Hamming distance information
leakage, but this time caused by the mixing of the round key between
successive rounds. For this attack, $\sim$1.3 million power measurement traces
are collected over 22 days. In short, it is shown that Intel’s AES-NI is not
well-protected against side-channel analysis. This was reinforced in the
PLATYPUS attack by Lipp et al. [91] (2021), who demonstrated a software-based
power analysis attack using the Intel Running Average Power Limit (RAPL)
interface, which allowed AES-NI key information used by Intel SGX enclaves to
be leaked.

In 2018, Camurati et al. [35] showed that mixed-signal SoCs (CPU and radio
transceiver on the same die) can exhibit EM-based information leakage. This
occurs when the CPU noise is modulated into the (analog) radio transceiver’s
emissions, generating an exploitable non-invasive attack vector. The authors
attack a Nordic Semiconductor nRF52832, a Bluetooth SoC with a 2.4GHz
transceiver and an ARM Cortex-M4 CPU; and a Qualcomm Atheros AR9271, a
wireless 802.11N SoC. 128-bit AES keys can be recovered at a 10 meter distance
by observing EM emissions produced by tinyAES and mbedTLS in the 2.4GHz
spectrum. Key recovery is demonstrated on tinyAES at a 10m distance using
70,000 traces for offline template creation and 428 traces to perform the
actual attack using template analysis. For mbedTLS, a successful attack is
mounted at a distance of 1 meter requiring 40,000 traces.

Two papers were presented in 2018 and 2020 by Benadjila et al. [27, 28] on
using deep learning for EM side-channel analysis. The authors comprehensively
analyse the application of convolutional neural networks to perform key
recovery by classifying the Hamming weights of intermediate cryptographic
operations. The targets are masked and unmasked reference software AES
implementations on an 8-bit AVR microcontroller (ATmega8515). A publicly
available dataset, the ASCAD dataset, is released to facilitate future
research in the domain. Surprisingly, it is found that the VGG-16 image
recognition network architecture can be used effectively for side-channel
analysis.

On an IoT SoC, Wang et al. [161] (2020) present a deep learning-based SCA on
AES from its EM emissions. Three neural networks are trained—two convolutional
neural networks (CNNs) with different layer configurations and one multi-layer
perceptron (MLP) network—on traces captured from five Bluetooth devices at
five distances from the target device. Like [35], the Nordic Semiconductor
nRF52832 SoC is used along with a reference software 128-bit AES
implementation provided by the tinyAES C library. 500,000 traces are
collected, which are distributed across various distances from the device
(wired connection, then 1m–8m) and in different locations (an office and
corridor environment). In the best case, 367 traces of the same encryption
were required to recover an AES subkey at a distance of 15m from the device.

###  4.3 Other Physical Side Channels

Another side-channel is _acoustic cryptanalysis_ , although it has not been
applied succesfully to mobile SoCs. This involves cryptanalysing sound waves
produced by a system whose emitted pitch is dependent on the current
operation. In 2014, Genkin et al. [50] showed that RSA key extraction using
acoustic cryptanalysis is feasible against a Lenovo laptop. The authors target
GnuPG’s RSA implementation and, using a laboratory microphone setup and a
Samsung Note II, show that a 4096-bit key can be recovered within one hour
using audible and ultrasonic sound emanations.

Temperature emissions are another side-channel; however, they have also not
been successfully applied to mobile phone SoCs for key recovery. However, on
MCUs, Hutter and Schmidt [73] (2013) demonstrate information leakage from an
8-bit AVR ATmega162 by monitoring its temperature using a PT100 sensor element
with a 100ms thermal response time. As a proof of concept, the authors use the
move (MOV) instruction to move all possible values of one input byte (i.e.
256) to 24 internal registers. This is measured for a period of 20 seconds in
a loop. It is shown that the temperature increases depending on the Hamming
weight of the processed value, but a full key recovery attack is not shown.
Crucially, the attack is appropriate only for single-purpose devices with
long-running operations that create low-frequency signatures. As such, it is
unlikely to be fruitful against today’s mobile SoCs.

##  5 Evaluation

This section evaluates state-of-the-art FIAs and SCAs; presents a common set
of criteria to compare the requirements, evaluated platforms, and attack goals
of each work; and examines their challenges and limitations.

###  5.1 Comparison Criteria

The previous two sections have showed that a large range of techniques, target
platforms, algorithms, and success rates are present in existing work. We thus
developed evaluation criteria to assist in the comparison of works across each
attack family. The aim is to provide the reader with a concise summary of the
requirements, security targets, and attack goals that apply to each work. This
criteria is as follows:

  * •

Work and year: the work under comparison and its year of publication. Older
attacks may have evaluated obsolete platforms which may generalise poorly to
modern devices.

  * •

Attack class: the type of SCA or FIA that was used, such as clock glitch,
EMFI, or power analysis.

  * •

SoC type: the type of SoC that was used, e.g. single-core, multi-core, mixed-
signal and/or high-frequency (1GHz+) SoC. If a non-mobile phone SoC was used,
such as an IoT SoC or MCU, then this is mentioned explicitly.

  * •

Trigger?: whether the device under test was instrumented with hardware or
software triggers to precisely generate faults or the activation of side-
channel analysis. Trigger-based approaches may struggle to generalise to
black-box scenarios where devices cannot be straightforwardly instrumented.
Furthermore, it is important to note that some triggers are artificial, e.g.
instrumented in reference software cryptographic implementations, which are
unlikely to be directly useful when analysing commercial devices.

  * •

Evaluation platform: the platform used as the target of attack; for example,
the device, SoC, MCU, or microprocessor model.

  * •

Attack prerequisites: any preconditions necessary for mounting the attack,
such as requiring kernel-space code execution, SoC decapsulation, or a
particular processor architecture.

  * •

Implementation: the cryptographic implementation targeted by the SCA or FIA.
This may be a proprietary OEM, an open-source, or a reference implementation.
We consider OEM versions to be the most likely to generalise when reproducing
the attack on other commercial mobile devices.

  * •

Success criteria: the reported number of faults/traces required to mount the
attack, or the accuracy of the proposed method (if applicable). Attacks with
low success rates may be economically unviable if a substantially large number
of attempts are needed to successfully perform the SCA or FIA.

  * •

Attack goals: the attack goals for each work, expanded upon in §5.2.

Table 3 provides a comprehensive comparative summary using the above criteria
for state-of-the-art fault injection attacks surveyed in §3. A separate
comparison is provided in Table 4 for side-channel attacks surveyed in §4.

###  5.2 Attack Goals

The existing FIA and SCA literature covers a multitude of attack scenarios,
such as software-based AES key recovery, privilege escalation, and subverting
the secure boot process. To assist practitioners and security researchers,
each work in Tables 3 and 4 has been mapped to one or more of the below attack
goals depending on their applicability.

  1. 1.

TEE code execution: gain control of the kernel space of the TEE secure world.
This enables privileged access to different TEE targets on the device,
including TEE secure world applications in lower protection levels, device
drivers to security-critical peripherals, and TEE memory management.

  2. 2.

TEE AES/RSA/ECC key recovery: perform key recovery attacks against security
services that use the AES, RSA or ECC cryptosystems in the TEE secure world.
Relevant works could be useful when attacking TEE-based key management
(keystore) systems and FDE and FBE implementations, as discussed in §2.4 and
§2.5.

  3. 3.

Load unauthorised TEE TAs: gain the ability to load unauthorised TEE trusted
applications. This can be used to further interrogate the TEE to understand
its internal operations or attempt secure world privilege escalation attacks.

  4. 4.

Bypass secure boot verification checks: circumvent boot-time procedures that
enforce the loading of authorised components, e.g. OEM-signed bootloader
binaries, in order to load unauthorised self-signed or unsigned images.

  5. 5.

REE code execution: gain control of the non-secure world’s kernel-space. This
enables privileged access to other system targets, including device drivers,
memory management, and applications in less privileged protection modes.

  6. 6.

AES/RSA/ECC key recovery: perform key recovery against an
encryption/decryption system outside a TEE. AES is used ubiquitously for
symmetric key data encryption, including full- and file-disk encryption, while
RSA and ECC cryptosystems are used widely for digital signatures and public-
key cryptography on mobile platforms.

  7. 7.

Bypass verification checks: bypass other run-time security verification steps,
such as RSA and ECC signature verification.

  8. 8.

Load unauthorised data into RAM: corrupt the device’s data flow integrity
protections to load unauthorised data items, such as a cryptographic keys,
into RAM during program execution.

  9. 9.

Key resetting: perform run-time bit reset attacks on part or all of a
cryptographic key to disrupt the device under test under investigation.

  10. 10.

Reverse engineering: learn instruction-level information of black-box software
being executed.

Work Year Class SoC Type Evaluation Platform Prerequisites Implementation
Trigger? Success Rate/Criteria Attack Goals Vasselle et al. [157] 2018 LFI
Multi-core ARM Cortex-A9 SoC decapsulation Reference Y Up to 95% Secure world
privileged access. Colombier et al. [37] 2019 MCU ARM Cortex-M3 Y Up to 100%
AES key recovery. Barenghi et al. [23] 2009 VFI Single-core ARM ARM926EJ-S —
OpenSSL (v0.9.1i) and Reference Y 6.6%–39% (RSA-CRT attack) 6.42%–62.77% (e-th
Root) RSA key recovery. Barenghi et al. [24] 2010 Y 100K ciphertexts
(different plaintexts) 2M ciphertexts (same plaintext) AES key recovery.
Timmers et al. [151] 2016 Multi-core ARM Cortex-A9 Xilinx Zynq-7010 SoC
AArch32 architecture Reference Y 0.01%–0.27% Bypass secure boot verification.
Load unauthorised bootloaders. Secure world privileged access. Timmers & Mune
[149] 2017 ARM Cortex-A9 AArch32 architecture User-space access Linux kernel Y
0.41%–0.63% Linux privileged access (REE). VoltJockey [121] 2019 Multi-core
1GHz+ Qualcomm APQ8084AB SoC Google Nexus 6 SW-controlled PMIC Kernel-space
access OEM TrustZone (AES and RSA) Y 2.2% (AES key recovery) 4.6% (RSA
decryption fault) Secure world AES key recovery. Load unauthorised TEE TAs.
NCC Group [113] 2020 ARM Cortex-A53 MediaTek MT8163V SoC — OEM N 15.21%–23.44%
Bypass secure boot verification. Load unauthorised bootloaders. Korak &
Hoefler [80] 2014 CFI MCU AVR ATxmega256 ARM Cortex-M0 NXP LPC 1114 Reference
Y Up to 100% Bypass verification checks. AES key recovery. Blömer et al. [30]
2014 Atmel XMEGA A1 RELIC toolkit [12] Y 0.025% ECC (PBC) key recovery.
CLKScrew [148] 2017 Multi-core 1GHz+ Qualcomm APQ8084AB SoC Google Nexus 6 SW-
controlled PMIC Kernel-space access Repeated TEE TA invocation OEM TrustZone
(AES and RSA) Y 5% (AES key recovery) 1.51% (RSA verification fault) Secure
world AES key recovery. Load unauthorised TEE TAs. Selmke et al. [136] 2019
MCU ARM Cortex-M0 STM STM32F0308R — Reference Y 16.4% AES key recovery. Glitch
PLL-equipped CPUs. Hutter & Schmidt [73] 2013 HFI + CFI AVR ATmega162I N 31%
RSA key recovery. Korak et al. [81] 2014 Y N/A† _Bypass security verification
checks._ _AES key recovery_ Dehbaoui et al. [39] 2013 EMFI ARM Cortex-M3 Y Two
correct and two faulty plaintext-ciphertext pairs. AES key recovery. Moro et
al. [109] 2013 Y N/A† Load unauthorised data into RAM. Bypass verification
checks. Riviere et al. [127] 2015 ARM Cortex-M4 Y Up to 96% _AES and RSA-CRT
key recovery_.† _Privilege escalation_.† BADFET [38] 2017 Single-core Cisco
8861 IP Phone Broadcom BCM11123 SoC Exploitable TrustZone SMC code OEM N 72%
Bypass secure boot verification. Load unauthorised bootloaders. Privileged TEE
access. Liao & Gebotys [89] 2019 MCU Microchip PIC16F687 — Reference Y Up to
222 faults required. 5.3 plaintexts for AES AES key recovery. _Bypass secure
boot verification._ † Menu et al. [103] 2019 Atmel SAM3X8E ARM Cortex-M3 AES
key resides in Flash memory. OSS Y Up to 100% AES key recovery. AES key
resetting. Elmohr et al. [42] 2020 NXP LPC1114 ARM Cortex-M0 E31 RISC-V SiFive
FE310-G002 NXP LPC1114 chip decapsulation Reference Y 12%–31% _Bypass
verification checks_.†. Load unauthorised data into RAM. Gaine et al. [48]
2020 Multi-core 1GHz+ ARM Cortex-A53 — Linux kernel (libpam) Y 0.35%–2% (DVFS
on–off) Linux privileged access (REE). • Gray-coloured works do not target
mobile SoCs. • *: Device model and manufacturer are not disclosed, †:
Discussed as a potential attack but not experimentally verified, Y: Yes, N:
No. • OEM: OEM implementation, OSS: Open-source software, Reference: Reference
implementation. • FI: Fault injection, LFI: Laser-based FI, VFI: Voltage-based
FI, CFI: Clock-based FI, HFI: Heating-based FI, EMFI: Electromagnetic FI, SW:
Software, PMIC: Power management integrated circuit, MCU: Microcontroller
unit, PBC: Pairing-based cryptography, PLL: Phase locked loop, SoC: System-on-
chip, DVFS: Dynamic voltage and frequency scaling.

Table 3: Summary of recent fault injection attacks on mobile and embedded
systems.

Work Year Class SoC Type Evaluation Platforms Prerequisites Implementation
Trigger? Success Rate/Criteria Attack Goals Aboulkassimi et al. [1] 2011 EM-
SCA Single-core Java ME phone* 32-bit RISC CPU (350MHz) MicroSD interface
Bouncy Castle and Reference Y 250 traces AES key recovery. Kenworthy & Rohatgi
[76] 2012 4G LTE smartphone* Mobile PDA* Square-and-multiply RSA Double-and-
sometimes-add ECC OEM, OSS and Reference ? Single trace (RSA and ECC) 12,500
AES block op. traces RSA, ECC and AES key recovery. Montminy et al. [107] 2013
MCU Stellaris LM4F232H5QD ARM Cortex-M4F (50MHz) — OEM N 100,000 traces AES
key recovery. Nakano et al. [112] 2014 Single-core Android smartphone*
(832MHz) Square-and-multiply RSA Android JCE N Single trace ECC and RSA key
recovery. Balasch et al. [19] 2015 Single-core 1GHz+ ARM Cortex-A8 (1GHz) TI
AM3358 Sitara SoC Beaglebone Black — Reference Y 400,000 traces (masked AES)
10,000 traces (unmasked AES) Masked AES key recovery. Goller & Sigl [59] 2015
? Four smartphones* _Samsung Galaxy S3_ (see text) Square-and-multiply RSA
External casing is opened Android JCE N 276 traces (EM shielding) 170 traces
(no EM shielding) RSA and AES key recovery. Longo et al. [94] 2015 Single-core
1GHz+ ARM Cortex-A8 (1GHz) TI AM3358 Sitara SoC Beaglebone Black SBC
Cryptographic co-processor OEM and OpenSSL (v1.0.1j) Y 20,000 traces (SW AES)
500M traces (co-processor AES) AES key recovery. Co-processor AES key
recovery. _FDE key recovery._ † Belgarric et al. [26] 2016 Android smartphone*
Qualcomm MSM7225 SoC External casing is opened Bouncy Castle (v1.5) Y 39
traces ECDSA key recovery. Genkin et al. [49] 2016 Sony-Ericsson Xperia X10
Apple iPhone 3GS — OpenSSL (v1.0.x) iOS 7.1.2–8.3 N 5000 traces ECDSA key
recovery. Saab et al. [128] 2016 Multi-core 1GHz+ Intel i7-3517UE Intel Ivy
Core architecture Intel AES-NI (Ivy Bridge) N 1.3–1.5 million traces AES key
recovery. Bukasa et al. [34] 2017 Multi-core Raspberry Pi 2 Broadcom BCM2836
SoC ARM Cortex-A7 (900MHz) — Reference Y 17.81%–38.30% with 150,000 traces
Secure world AES key recovery. Camurati et al. [35] 2018 Multi-signal IoT SoC
Nordic nRF52832 ARM Cortex-M4 Qualcomm Atheros AR9271 Mixed-signal SoC tinyAES
and mbedTLS✣ N 70,000 traces (tinyAES) 40,000 traces (mbedTLS) AES key
recovery. Alam et al. [4] 2018 Single-core Samsung Galaxy Centura Alcatel
Ideal — OpenSSL (v1.1.0g) N Single trace (95.7%–99.6% recovery) Constant-time
RSA key recovery. Leignac et al. [86] 2019 Multi-core 1GHz+ HiKey LeMaker SBC
ARM Cortex-A53 (1.2GHz) Undisclosed Y 6000 traces REE and TEE AES key
recovery. Vasselle et al. [157] 2019 ? Undisclosed Decomposable PoP SoC
Undisclosed N 2500 traces, two ciphertexts Co-processor AES key recovery.
Boot-time firmware decryption. Wang et al. [161] 2020 IoT SoC Nordic nRF52832
SoC — tinyAES✣ Y 367 traces AES key recovery. Lisovets et al. [92] 2021 EM-
SCA+ P-SCA Multi-core 1GHz+ Apple iPhone 4 Apple A4 SoC Exploitable boot ROM
Unlimited AES engine encryptions OEM Y 300M traces (EM-SCA) 200M traces
(P-SCA) AES key recovery. Schmidt et al. [133] 2010 P-SCA MCU NXP LP2148
(ARM7TDMI-S) AVR ATMega163 + AT89S2853 Exposed I/O pins Reference Y N/A† Key
recovery. Heuser & Zohner [71] 2012 AVR ATMega-256-1 Accessible power line Y
20–60 traces (low–high noise) AES key recovery. Msgna et al. [110] 2014 AVR
ATMega163 N 66.78–100% (11 instructions) Reverse engineering. Maghrebi et al.
[96] 2016 AVR ATMega328P N 20 traces (unprotected AES) 500 traces (masked AES)
Masked AES key recovery. Picek et al. [118] 2018 N 10 traces AES key recovery.
Park et al. [116] 2018 Y 99.03% (112 instructions) Reverse engineering. Wang
[160] 2019 AVR ATXmega128D4 N 160.3–400.2 traces AES key recovery. Gnad et al.
[58] 2019 Mixed-signal IoT SoC STM 32L475 and 32F407VG ESP32-devkitC Mixed-
signal SoC tinyAES and mbedTLS✣ Y 10M traces AES key recovery. Genkin et al.
[50] 2014 AC-SCA Multi-core 1GHz+ Lenovo laptop — GnuPG (v1.x) N One-hour
audio trace RSA key recovery. • Gray-coloured works do not target mobile SoCs.
• ?: Method not disclosed. *: Device model and manufacturer are not disclosed,
†: Discussed as a potential attack but not experimentally verified, Y: Yes, N:
No. • OEM: Proprietary OEM implementation, OSS: Open-source software
implementation, Reference: Reference implementation, ✣: Implementation and/or
version not disclosed. • SCA: Side-channel attack, EM-SCA: Electromagnetic
SCA, P-SCA: Power-analysis SCA, AC-SCA: Acoustic SCA, JVM: Java virtual
machine, Java ME: Java Platform – Micro Edition, JCE: Java cryptography
extensions library, ECC: Elliptic curve cryptography, SBC: Single-board
computer, SoC: System-on-chip, FDE: Full-disk encryption.

Table 4: Summary of recent physical side-channel attacks on mobile and
embedded systems.

###  5.3 Challenges and Limitations

In the following sections, challenges and limitations of existing SCA and FIA
research is identified and discussed.

####  5.3.1 Few Attacks Against Implementations with Known Countermeasures

In recent years, a range of hardware- and software-based countermeasures have
been developed for addressing many FIAs and SCAs. Hardware-based power filters
have effectively thwarted voltage-based FIAs for over 20 years since their
inclusion in commercial smart cards [77]. Similarly, phase-locked loop (PLL)
circuits, while not a dedicated security countermeasure, have significantly
increased the difficulty of mounting clock glitch attacks [136]. Frequency
detection circuits have also been developed for preventing clock glitches [22]
and hardware frequency locking can be used against software-assisted clock
glitch attacks, such as CLKScrew [148]. Tamper-resistant EM shielding can be
used to minimise EM emissions during execution in order to thwart EMFIs, while
on-board temperature sensors have been shown to effectively detect heating-
based FIAs [9].

Several software countermeasures are also widely known, including double or
multiple checks of security-critical procedures, e.g. signature verifications.
This forces the attacker to perform several FIAs to bypass a single step, thus
substantially increasing attack difficulty. Software- and hardware-based
redundancy has also been suggested where the same result is computed and
checked multiple times, as well as introducing randomness into program
execution, such as random timing waits [22].

The same discussion is applicable to SCAs. Introducing randomness into program
execution and clock frequencies are common software and hardware defences.
Constant-time operations, e.g. the ECC Montgomery ladder, that do not leak
secret-dependent information are a key software countermeasure. Masked
implementations of AES device are another countermeasure to defend against
differential power analysis attacks. While some work has shown that masked
implementations can still be attacked, it comes with dramatically increased
attack complexity [19]. Hardware countermeasures can also be used for SCAs: EM
shielding, e.g. Faraday cage packages [124], are a known method for
attenuating exploitable EM emissions.

While these countermeasures are widely known, existing research has still
focussed on evaluating unprotected implementations. The widespread evaluation
of custom or reference algorithms raises concerns that the presented success
rates represent the ‘best case’ only. In some work, researchers have targeted
cryptographic implementations that are widely known to be vulnerable to side-
channel attacks, such as double-and-sometimes-add ECC [76]. Unfortunately,
researchers will likely face difficulties when replicating these attacks
against hardened implementations. This could be partly why cryptographic co-
processors have been subjected to extremely few attacks ([94] and [156])
compared to custom or reference implementations. Indeed, there are no
published attacks on the Apple SEP (§2.2.3). We return to the move to secure
elements by OEMs in §5.4.

####  5.3.2 Practical Attack Viability

A significant limitation of some FIAs and SCAs is the viability of collecting
large numbers of exploitable traces and faulted ciphertexts required for
mounting an attack. In particular, voltage- and clock-based FIAs often
generate exploitable faults at an extremely low rate during experimental
analysis ($<$0.1% of all faults) [151, 149, 30]. The voltage FIA by Barenghi
et al. [24] requires up to two million faulted ciphertexts to achieve key
recovery using a reference AES implementation. Longo et al. [94] require 500
million traces for AES key recovery using EM SCA against a cryptographic co-
processor, while the power-based SCA by Gnad et al. [58] requires 10 million
traces for AES key recovery on a mixed-signal IoT SoC. Along similar lines,
the attack by Dehbaoui et al. [39] requires AES encryptions to be performed
multiple times under the same message and key.

An investigator may wish to use these attacks if measurement traces or fault
injections can be executed repeatedly and reliably. Otherwise, a practicality
concern arises for data-demanding attack methods. They may be economically
unviable if the cost of acquiring a trace or injecting a single fault is
substantial, and the process cannot be easily repeated or automated.

####  5.3.3 Inaccessible Hardware

Accessing hardware components to inject faults and acquire exploitable
measurements is a major challenge to certain FIAs and SCAs on today’s mobile
devices. For power-based SCAs, voltage supply pins are not easily accessible
on modern SoCs as the pins are occluded by the BGA package itself. Invasive
techniques are thus required just to evaluate the feasibility of an attack,
let alone execute one successfully. Moreover, conducting power analysis on BGA
packages requires specialist test equipment and expertise, significantly
increasing the attack’s complexity [19]. It is likely, for this reason, that
security researchers have tended to focus on power analysis attacks on
platforms with easily accessible supply pins and power planes, such as single-
board computers and MCUs. It also likely why EM SCAs have gained popularity on
mobile SoCs, due to their largely non-invasive means of signal acquisition.

####  5.3.4 Risk of Device Damage

An overarching issue with physical attacks is the risk of irreparably
destroying the device under test, thus permanently losing access to valuable
data. By definition, FIAs leverage unexpected behaviour when the device is
subjected to conditions beyond the manufacturer’s guidelines. This is likely
to occur during the search process of identifying effective glitch parameters
for fault characterisation, shown previously in Figure 9 in §3 for clock
glitch attacks. Over-glitching, e.g. extreme over- and under-volting, can
inflict permanent and unpredictable damage on device components, often in ways
that are not immediately observable.

Damaging components is not just confined to fault injections. Recent side-
channel attacks have required decapsulating ICs and disassembling PoPs to
enable the acquisition of exploitable measurements. This has required
researchers to refine these methods on spare components before mounting an
actual attack [156]. Consequently, researchers operating on a budget, or with
access to only a few PoPs/SoCs of interest, may struggle to reproduce these
attack techniques.

In some forensics cases, investigators may have to resort to laser or chemical
decapsulation to gain hardware access for reverse engineering and/or data
extraction [144]. Laser or chemical decapsulation increases the risk of
destroying the device, particularly the bonding wires [68]. This damage can
occur in two ways: (1), when the laser or chemical is used on the package to
expose the device [68]; and (2), when the investigator manipulates the probes
to contact the device during chip-on methods to read device memory or conduct
physical FIAs [67]. To address this, Staller [144] (2010) proposed a method
coupling electrically conductive adhesives (ECAs) and the precision of laser
ablation—also known as photoablation—for the repair of damaged bonding wires
and to minimise the risk of device damage.

####  5.3.5 Package-on-Package (PoP) Systems

We are not aware of any successful fault injection attacks on PoP systems
where multiple packages, e.g. memory units and SoC(s), are integrated into a
single IC. PoP SoCs are used widely by high-end mobile devices, such as the
Apple A14 on the iPhone 12 series. PoPs significantly increase attack
complexity as researchers must account for SoC activity _and_ side-effects
from other integrated packages. Aït El Mehdi [3] presented initial signs that
EMFIs may be possible on PoPs, but a full attack was not presented. Very few
SCAs has been published on PoP SoCs. Vasselle et al. [156] used EM analysis
for key recovery from an on-SoC cryptographic co-processor. However, the work
exploited a unique part of system initialisation—BL1 of the secure boot chain
(§2.3)—where disassembling the PoP, removing the DRAM, and analysing the SoC
directly was possible. This approach will not generalise to post-boot or late-
boot analysis where removing the DRAM would cause a catastrophic system
malfunction. Recent work by Lisovets et al. [92] demonstrated EM- and power-
based SCAs against an Apple A4 PoP SoC aboard an iPhone 4. While there are
difficulties in generalising the attack to modern Apple devices with SEPs (see
§2.2.3), the authors show that side-channel attacks against a complex PoP SoC
is a practical reality.

Recent research has demonstrated the possibility of desoldering PoP components
without altering them [66]. The use and combination of conductive and
insulating adhesives to stabilise PoP systems is a solution that can be used
for achieving fault injection attacks on PoP SoCs [45]. Polymeric adhesives
are of particular interest in the digital forensics domain. These can be used
to perform complex repairs or even to realise advanced man-in-the-middle
attacks to reverse engineer secure systems. Heckmann et al. [67] (2017)
illustrated this in a home-made memory man-in-the-middle attack platform. This
platform aims to provide (reading/writing) access to data exchanged between
the CPU and its volatile and non-volatile memory. This platform is a first
step for fault injection attacks on PoP SoCs.

####  5.3.6 Poor Reproducibility

One immediate limitation of FIAs and SCAs is the extent to which published
attacks and methods can be generalised to other evaluation platforms. This
includes platforms that are yet to be released. Published research is
typically constrained to a small set of evaluation platforms; often only a
single target is used, as is the case with $>$80% state-of-the-art FIA and
$>$60% SCA works. Differences in mobile SoC architectures, power management
systems, voltage regulators, power planes, land-side decoupling capacitors
(LDCs), and external clocks may significantly affect attack reproducibility to
the point of being ineffective. It is likely the case that the success rates
of published techniques—shown in Tables 3 and 4—are a significant overestimate
if an alternative platform is under evaluation.

Poor methodological transparency is also a source of reproducibility issues.
Crucially, we observe that many authors simply do not disclose the device
and/or the SoC under test [1, 59, 76, 112, 3, 156]. In many cases, only high-
level details are shared, e.g.  _“an Android smartphone”_ [112] or a _“4G LTE
smart phone from a major manufacturer”_ [76]. In other work, this information
is blatantly redacted [3, 156]. Obscuring platform information can
significantly hinder reproducibility if the attack approach does not
generalise. A related issue is the tendency for researchers to not open source
their proof-of-concept code. For elaborate attacks, e.g. [38] and [121], the
absence of easily available code can also hinder or even prevent
reproducibility altogether.

From an analysis perspective, Benadjila et al. [27] state that the data
analysis framework is often not published for some SCAs:
_“hyperparameterisation_[of machine learning models] _has often been kept
secret by the authors who only discussed the main design principles and on the
attack efficiencies”_. The disclosure of model hyperparameters is a key step
towards reproducing published results. Wang et al. [161] also showed that the
effectiveness of machine and deep learning-based SCAs can vary severely
between devices. They experimentally show that a model trained on power traces
from one board does not easily generalise to others, even those with the same
IC: a DL model with a purported 96% accuracy drops to only 2.45% when tested
on traces captured from another board with the same IC.

Another limitation is the heavy use of device triggers integrated in the
target implementation. The vast majority of FIAs—shown in Table 3—require a
custom trigger from the device to perform the fault injection, as do a large
number of SCA works. Useful triggers are unlikely to exist, or cannot be
easily integrated, into implementations on commercial devices. Researchers may
thus encounter great difficulty in replicating such attacks on off-the-shelf
devices.

The trend of increasingly faster, denser and noisier SoCs continue to pose
significant reproducibility issues. High-frequency, multi-core CPU
architectures with complex instruction pipelines and MMUs have dramatically
increased attack complexity in the past decade [1, 49, 112]. For FIAs, it
necessitates the injection of extremely precise faults during program
execution, which is limited by the precision of available testing equipment.
For SCAs, researchers must also account for context switching, garbage
collectors, virtualisation, and multi-stage pipelines that hinder the
collection of exploitable power and EM traces. The use of TEEs complicates
this further, which use the same physical CPU cores as the native OS in a
time-sliced fashion. The resulting temporal distortions must be overcome in
order to discriminate between secure and non-secure world operations.

####  5.3.7 Lack of Publicly Available Data Sheets

A major issue is the lack of publicly available data sheets provided by OEMs
and SoC vendors. This has forced researchers into evaluating devices under
test using black-box methods. This speaks to a security by obscurity concern:
the absence of attacks on a given SoC does not imply that it is secure against
SCAs and FIAs. Given the extremely large number of commercially available
SoCs, FIAs and/or SCAs may be possible if a previously unevaluated SoC
undergoes a dedicated investigation.

###  5.4 Future Directions

Deep learning-based approaches to side-channel analysis have rose to
prominence. These methods enable complex feature extraction and the ability to
model highly non-linear interactions for classification. This is in contrast
to traditional statistical methods that use carefully chosen parametric
models. At present, DL-based SCAs are attracting significant attention by
researchers, with promising results being presented in leading security
conferences and journals. It is likely that this trend will persist given the
new avenues it opens for EM- and power-based SCAs without defining highly
bespoke statistical models.

The growth of mixed-signal and multi-SoC architectures are an important
development in the development of fault injection and side-channel attacks on
mobile devices. Recent research, e.g. [35] and [58], has shown that these can
offer new attack vectors into recovering secret data. Given the economic
incentives to shrink device hardware into ever-more compact units, it is
likely that this trend will continue, and that new attack avenues may be
opened from the interaction between increasingly diverse on-SoC components. In
parallel, manufacturers continue to delegate long-running but low-complexity
device features, such as sensor hubs, to separate device SoCs. This allows the
primary SoC with the device’s application processor to remain in a low-powered
state while low-complexity processing is handled by a less energy-intensive
SoC. Similarly, the interaction between subsystem SoCs could offer new attack
vectors in future research.

Researchers should also be aware of emerging mobile TEE applications in recent
research. Examples include secure mobile deep learning [84], protecting
cryptocurrency wallets [51], authenticating adverts from mobile advertising
networks [88], preserving the integrity of system logs [137, 75], direct TEE-
to-TEE communication with remote attestation [138, 139], protecting healthcare
data [135], and confidential image processing [33]. Such proposals could
reflect possible commercial services and serve as future attack targets.
Moreover, new TEEs and security mechanisms continue to be developed using the
RISC-V open-source instruction set architecture [85, 102, 134, 141]. The
efficacy of SCAs and FIAs against these systems is another interesting future
research direction, especially if RISC-V becomes increasingly used by mobile
device OEMs.

Finally, we observe that manufacturers are increasingly returning to discrete
secure element (SE) hardware for protecting the most critical device assets,
such as cryptographic keys and user credentials, rather than TEEs. This is
highlighted by Google’s recent release of the Titan M module (§2.2.4) and the
formation of the Android Ready SE Alliance for accelerating the adoption of
SEs on Android devices [61]. The alliance identifies that using tamper-
resistant hardware for hosting digital keys for physical items, e.g. car keys;
ePassport and national identity credentials; and digital wallets _“offers the
best path for introducing these new consumer use cases in Android”_ [61].
These targets have significant protections against FIAs and SCAs, which
necessitates the development of fresh approaches.

##  6 Conclusion

The difficulty of data extraction and analysis methods has increased
significantly due to the growing complexity of mobile platforms and an
increased focus on their security. This is progress from a privacy viewpoint,
but it poses major challenges in forensic contexts; for instance, lawful
evidence recovery from mobile phones and tablets used in serious crimes.

This report presented an extensive survey of state-of-the-art physical fault
injection and side-channel attacks on mobile system-on-chips. These approaches
have been used to perform key recovery, disable critical security mechanisms,
perform privilege escalation, and more. For attack classes with no known works
against mobile SoCs, we surveyed research using simpler targets, e.g. MCUs and
IoT SoCs, which may inspire future attacks on mobile devices.

In total, over 50 research publications published between 2009 and 2021 were
examined from which 10 attack goals were drawn. Each publication was
individually mapped to the relevant attack scenario with any prerequisites,
limitations, the evaluated platforms, and their published success rates. We
also presented challenges and limitations pertaining to FIAs and SCAs.

In particular, we raised the issue of attack reproducibility: redacted
platform details, an extremely small number of evaluation devices,
increasingly complex SoCs, and poor analysis transparency may all lead to
generalisation issues on current and future targets. Furthermore, we
identified that the regular targeting of unprotected reference or custom
software implementations is a cause for concern. Most works do not evaluate
attacks on software and hardware platforms with widely known FIA or SCA
countermeasures. Consequently, it is likely that researchers will face
difficulties when applying many approaches to other platforms, particularly
OEM mobile phones.

Lastly, we discussed potential future developments in the state of the art.
Specifically, we see the growing use of deep learning to model complex feature
interactions as an increasingly fruitful method for side-channel analysis. We
showed earlier on that PoP architectures continue to pose major problems for
both side-channel and fault injection attacks. Recent work has shown they are
possible, but with substantially increased attack complexity. Importantly, we
discussed the growing use of tamper-resistant cryptographic co-processors by
leading OEMs, e.g. Apple’s SEP and Google’s Titan M. These modules contain