A Comprehensive Survey of Hardware-assisted Security: from the Edge to the Cloud

Abstract

Sensitive data processing occurs more and more on machines or devices out of users control. In the Internet of Things world, for example, the security of data could be posed at risk regardless the adopted deployment is oriented on Cloud or Edge Computing. In these systems different categories of attacks — such as physical bus sniffing, cold boot, cache side-channel, buffer overflow, code-reuse, or Iago — can be realized. Software-based countermeasures have been proposed. However, the severity and complexity of these attacks require a level of security that only the hardware support can ensure. In the last years, major companies released a number of architectural extensions aiming at provide hardware-assisted security to software. In this paper, we realize a comprehensive survey of HW-assisted technological solutions produced by vendors like Intel, AMD, and ARM for both embedded edge-devices and hosting machines such as cloud servers. The different approaches are classified based on the type of attacks prevented and the enforced techniques. An analysis on their mechanisms, issues, and market adoption is provided to support investigations of researchers approaching to this field of systems security.

Full text

A Comprehensive Survey of Hardware-assisted Security:
from the Edge to the Cloud
Luigi Coppolinoa, Salvatore D’Antonioa, Giovanni Mazzeoa,∗
, Luigi Romanoa
aUniversity of Naples ’Parthenope’
Centro Direzionale, Isola C4, 80133 Napoli
Abstract
Sensitive data processing occurs more and more on machines or devices out of users control. In the Internet of Things
world, for example, the security of data could be posed at risk regardless the adopted deployment is oriented on Cloud
or Edge Computing. In these systems different categories of attacks — such as physical bus sniffing, cold boot, cache
side-channel, buffer overflow, code-reuse, or Iago — can be realized. Software-based countermeasures have been proposed.
However, the severity and complexity of these attacks require a level of security that only the hardware support can ensure.
In the last years, major companies released a number of architectural extensions aiming at provide hardware-assisted
security to software. In this paper, we realize a comprehensive survey of HW-assisted technological solutions produced
by vendors like Intel, AMD, and ARM for both embedded edge-devices and hosting machines such as cloud servers. The
different approaches are classified based on the type of attacks prevented and the enforced techniques. An analysis on
their mechanisms, issues, and market adoption is provided to support investigations of researchers approaching to this
field of systems security.
Keywords: Hardware-assisted Security, IoT Security, Cloud Security, Edge Computing, Trusted Computing
1. Introduction
As more computing solutions increasingly pervade our
lives and move in non-secure environments, the security
of sensitive data and systems are emerging as extremely
important issues. Remarkable examples are Internet of
Things (IoT) architectures, spanning from traditional
deployments where collected sensor data is processed
in a central repository — e.g., a Cloud host — to
more advanced solutions such as those of the emerging
Edge Computing field where a distributed processing
occurs in end-devices. In both cases, the data is out
of user control and particularly exposed to integrity or
confidentiality attacks when is processed. The solely
software-based security is inadequate to protect such
systems since advanced attacks exploiting bugs can lead to
undesired user software modification or corruption, thus
overcoming restrictions of software security. Moreover,
the performance overhead introduced by software-based
security in certain cases is non-negligible and the hardware
support could improve it.
For this reason, over the last decade, we have seen
the proliferation of hardware-assisted security solutions
∗Corresponding author
Email addresses: luigi.coppolino@uniparthenope.it (Luigi
Coppolino), salvatore.dantonio@uniparthenope.it (Salvatore
D’Antonio), giovanni.mazzeo@uniparthenope.it (Giovanni
Mazzeo), luigi.romano@uniparthenope.it (Luigi Romano)
(also known as hardware-enhanced or hardware-enabled
security), which leverage mechanisms of hardware to
support software security, thus enabling trustworthy
computing. It is different from hardware security, which
aims at protecting physical devices/machines rather than
software that is installed on the hardware of a computer
systems. In hardware security, solutions are specifically
designed for the sole hardware layer, unlike HW-assisted
security that focuses on protecting higher layers (e.g.,
hypervisor, operating system) of machines architectures.
As reported in Figure 2, major vendors — i.e.,
AMD, ARM, Intel — released several architectural
implementations of HW-assisted solutions for a variety of
uses, such as technologies for accelerated security-related
processing, secure random number generation, memory
bounds protection, isolated execution, video protection,
or trusted computing. In this regard, a comprehensive
overview of most relevant and promising HW-assisted
security solutions is still missing. Few works exist [1][2][3]
but some lack a proper level of detail, others are only
focused on specific fields of application, others more
are only centered on specific categories of HW-assisted
technologies.
In this paper, we provide a survey of the different
categories of HW-assisted solutions currently available
for either increasing the performance of security-related
processing or, most importantly, for actually hardening
data-in-use in untrusted environments. In this regard,
we present a number of technologies enabling intra-host
Preprint submitted to Internet of Things May 7, 2019

protection, which are for the majority internal to CPUs.
The architectures taken into consideration are exploitable
in both sides of typical IoT deployments: the end devices
and cloud hosts. The selected technologies are nowadays
considered as the best approaches for countering the most
critical attacks — such as bus sniffing, hyperjacking, cold
boot, code-injection, iago, side-channel, code-reuse, buffer
overflow — against data processed in environments like
IoT end-devices or cloud hosting servers. The focus will be
on HW-assisted technologies of Trusted Platform Module
(TPM) (i.e., Intel TXT, AMD PSP), Trusted Execution
Environment (TEE) (i.e., Intel SGX, AMD SEV, ARM
TrustZone), Virtual Machine Isolation (i.e., Intel VT,
AMD SVM), Pointers Violation Prevention (i.e., Intel
MPX, ARM PA, Intel CET), Random Number Generation
(RNG) (i.e., SRAM PUF, Intel Secure Key), Video
Protection (i.e., Intel PAVP), Cryptographic Acceleration
(i.e., Intel AES-NI, and ARM Crypto Ext.) and Malware
Detection (Intel TDT). For each selected technology, we
describe the type of attacks addressed, the underlying
security techniques, the critical issues posing at risk their
usage, and the typical fields of application.
This work is organized as follows. Section 2 reports
and discusses related works that surveyed the field of
HW-assisted security. Section 3 provides basic concepts
of HW-assisted security, their possible classification,
and overviews typical usages scenarios such as IoT
devices and Cloud hosting machines. Afterwards,
Sections 4, 5, 6 describe solutions where hardware
is leveraged to support and improve performance of
security-related processing. Then, Section 7 reports
HW-assisted technologies that provide secure random
numbers to cryptographic algorithms using underlying
hardware. Section 8, instead, is dedicated to HW-assisted
approaches for preventing violations of memory pointers.
Section 9 overviews technologies of trusted computing
spanning from TPM to TEE. Finally, Section 10 concludes
the document.
2. Related Work
To the best of our knowledge, this is the first survey
that provides an entire overview of HW-assisted security
focused on different categories of mechanisms for a
diversity of application scenarios.
Zhang et al. [1] present a study where six technologies
of HW-assisted isolated execution environments are
compared. They presented main features from the security
perspective and also discussed their vulnerabilities.
Authors explored technologies included in current
processors, which enable trusted computing (e.g., ARM
TrustZone and Intel SGX) and virtualization (e.g.,
System Management Mode) for defensive and offensive use
scenarios. Unlike this survey, our work is centered on a
wider set of solutions that also include environments for
isolated execution.
Al-Omary et al. [2] provide a survey on HW-assisted
security in the context of IoT. In this work, the attention
is mainly on trusted computing and more precisely
on technologies able to ensure Hardware Root of Trust
(HRoT). In this regard, they also consider and emphasize
the adoption of FPGA re-programmable devices for IoT
able to guarantee HRoT. In our work, we do not consider
external devices such as FPGA since our focus is on
much more features of HW-assisted security whose covered
attack set is larger.
Adams et al. [3] compared the architectural extensions of
Intel and AMD CPUs for supporting virtualization. They
compared, from performance and security perspectives,
existing software VMM with the VMM designed with
the emerging hardware support. In our paper, these
extensions, i.e., Intel VT and AMD SVM, are also
deepened in the dedicated category of technologies able
to ensure isolated execution of virtual machines.
Another survey paper on specific HW-assisted solutions
is the one of de Clercq et al. [4], which overviewed
HW-assisted for Control-Flow Integrity (CFI) protection,
where hardware monitors are used to check the behavior
(i.e., calls) of the software. Authors found that most
architectures protect backward edges with a Shadow Call
Stack (SCS), and a large body of work discusses the
intricacies of enforcing an SCS. Even our work covers
such a typology of defense mechanisms when HW-assisted
memory protection is discussed.
Unlike previous works, the goal of this paper is to cover
a broader range of HW-assisted security solutions that
focus on both IoT edge devices and Cloud nodes. In the
above-referenced papers, instead, the focus is narrowed
to certain aspects, mainly related to IoT usages. The
scope on the sole IoT edge world cannot provide a wide
view of HW-assisted security and the provided benefit.
In fact, a number of IoT scenarios leverage cloud hosts
to store, process, or show sensors’ data. Such a data
can be safely acquired but questions could be raised
regarding its security on the cloud. Preventing attacks
with HW-assisted mechanisms even on that layer of data
flow is certainly important. This is the main motivation
behind this work.
3. Promises of HW-assisted Security:
Concepts, Scenarios, and Classification
Concepts. HW-assisted security comprises technologies
that use hardware components or extensions to support
the security of higher machine layers such as firmware
or software, thus including BIOS, operating systems,
hypervisors, or any other user-level application.
HW-assisted security must not be confused with hardware
security, which aims at protecting physical device rather
than software that is installed on the hardware of a
computer system.
A number of technological HW-assisted solutions have
been released by major vendors like Intel, ARM, AMD
to either improve the performance of security processing
2

MCU
MCU
MCU Gateway
Code-Reuse
Buffer-Overflow
Bus Sniffing
Cryptanalytic on RNG
Kernel Malware
IagoCold Boot
Code-Injection Cache Side-channel
DMA Attacks
Cloud Provider
(e.g. Google IoT, AWS IoT)
Edge Devices
Sensors
Data
Control
Core
Pub/sub
Cloud
Functions
Cloud
Dataflow
VMM Rootkits
Figure 1: Threats in a Typical IoT Cloud-based Deployment
or specifically enhancing the level of firmware/software
security against a wide range of attacks. Some of these
technologies reside in the same motherboard but are
external to the CPU, even though their trend is to move
inside it. Others like HW-assisted trusted computing
started to be external but nowadays they have become
internal CPU extensions. In this work, for completeness,
we will briefly survey them. Even though the main
focus is on CPU internal extensions as these are the
only ones capable of hardening applications against
extremely powerful attacks like those perpetrated by
privileged users. Other HW-assisted technologies, such as
re-programmable FPGAs, which are completely external
devices, are not taken into account.
Usage Scenarios. Over the years, a number of Internet
of Things systems have been released by companies and
research institutions [5][6][7]. Examples like smart homes,
smart cities, or smart grids are different implementations
of the same reference architecture. In these architectures
(Figure 1), local complex processing of data generated by
end-devices is theoretically possible. The proof is the
emergence of Edge Computing — i.e., the architecture
where computation is largely or completely performed on
distributed device nodes — whose success is still to be
verified and depends on the technological evolution.
Nowadays, the reasonable approach for use cases where
low latency is required is to rely on cloud-based platforms
for processing, analyzing, and storing data sets. Major
vendors such as Google, Amazon, IBM, and Microsoft
released their cloud platforms supporting IoT. Examples
are Google IoT Core, AWS IoT, IBM Watson, Azure IoT
HUB. In these typical deployments, data is at risk on
the two end-points sides. That is, when it gets collected
on the end-devices and is subjected to a pre-processing
procedure, and when is elaborated on the cloud host.
Overall, the technologies reported in this work can be
either used on embedded end-devices — i.e., at the Edge —
or on more general-purpose machines, e.g., a cloud server,
to protect data against intra host/devices attacks and so
enable defence-in-depth. We do not consider HW-assisted
solutions whose main objective is to counter network-level
attacks such as Man-In-The-Middle (MITM), Denial of
Service, IP Spoofing.
Classification. Figure 2 presents the technological
solutions overviewed in this paper. We divide them
in two macro-groups, i.e., technologies whose main
purpose is the Performance Boost and technologies for
Security Enhancement. In the first group, we considered
categories of solutions that use hardware to increase the
performance of security processing or to increase security
as a side effect, specifically: i)Malware Detection, which
embraces techniques for boosting anomaly detection
scanning activities; ii)Cryptographic Acceleration, that
is HW-assisted solutions for performance enhancement
of cryptographic processing; iii)Virtual Machine (VM)
Isolation, that includes technologies useful to improve
performances in virtualized environments and, at the
same time, protect against attacks such as hyperjacking
[8], side-channel [9] or DMA [10] attacks.
In the second group, we selected technologies where
hardware is used to actually support security, whose
techniques can be basically categorized as follows: i)
Trusted Computing useful to protect against a subset of
physical attacks like bus sniffing, or software ones like
code-injection [11] or run-time attacks such as Iago [12],
ii)Pointers Violation Prevention that hardens the system
against Code-Reuse Attacks (CRA) such as ROP [13] or
JOP [14], control flow hijack, or buffer overflow attacks
[15], iii)Random Number Generation able to shield the
host against attacks to the cryptographic schemes [16],
iv) and Video Protection that use hardware to securely
display frames and play audio to the user.
For each of the reported technologies, we will describe use
case scenarios including a discussion on the current status
of adoption in commercial products. Finally, the majority
of them will be accompanied by a summary on issues and
3

HW-assisted
Technologies
Intel
TDT
Security
Enhancement
Performance
Boost
Intel
AES-NI
HW-assisted
Trusted Computing
Intel
SGX
ARM
TrustZone
AMD
MET
Intel
VT
AMD
SVM
IntrinsicID
SRAM
PUF
Intel
MPX
HW-assisted
VM
Isolation
TEE
TPM
HW-assisted
Pointers Violation
Prevention
HW-assisted
Random Number
Generation
Intel
CET
ARM
Crypto
Ext.
HW-assisted
Crypto Acceleration
HW-assisted
Malware
Detection
ARM
PA
Intel
TXT
AMD
PSP
Intel
Secure
Key
Embed
TPMs
Figure 2: Technological Solutions of HW-assisted Security
known attacks exploiting vulnerabilities in the hardware
implementations. In some cases — e.g., Intel TDT or
Intel CET which have been recently released and CPUs
embedding them are still not available — there is not
much material except the one produced by companies that
obviously only highlight positive features, thus discussions
on their issues are inevitably poor and qualitative. In
other cases, instead, the discussion is enriched by research
works that evaluated the technologies on an objective
basis.
4. HW-assisted Malware Detection
4.1. Intel TDT – Threat Detection Technology
The most used technique for detecting malwares or
anomalies in a host machine is the scan of systems’
memory. Unfortunately, the continuous scanning
operation for malware has a high cost both in system
performance and power consumption. As a result,
final users are frustrated entailing that memory scanning
capabilities becomes rarely used and even when they used
them, the throughput of operations becomes very low
thus reducing the probability of detection. Hence, Intel
proposed a work around for this problem. More precisely,
in 2018 they released Intel Threat Detection Technology
(TDT) [17] where the scanning for memory-based malware
is offloaded from CPU to Intel Integrated graphics
processor (GPU). Intel uses functionality built-in at the
silicon-level to help defeat exploits via an Accelerated
Memory Scanning (AMS). Moving the main processing
burden from the CPU to the Intel integrated graphics
enables more frequent scanning, with only negligible
impact on CPU performance. Lower CPU usage means
lower power consumption, even while delivering more
frequent and consistent memory scanning. Intel TDT
enables independent software vendors (ISVs) to collect and
analyze data that continually the local picture of what is
normal for each system and each machine. This enables
system operators, over time, to get better and better at
recognizing suspicious activity. As a result, when some
advanced new type of malware strikes, Intel TDT can help
them identify it quickly by observing its behavior, rather
than relying on signature identification only. Benchmarks
realized by Intel showed that CPU utilization dropped
from 20% to 2%. Such a result must be taken with care
since Intel TDT was still not benchmarked by independent
researchers and third-parties.
The announcement of Intel TDT is very recent (2018).
Intel promised that its solution will be available for
computers with 6th, 7th, and 8th generation Intel
processors. Nowadays, there is still not enough material,
which could help to delineate its issues and adoption.
5. HW-assisted Crypto Acceleration
5.1. Intel AES-NI
The notorious Advanced Encryption Standard (AES),
also known by its original name Rijndael, is a specification
for the symmetric block cipher established by the U.S.
National Institute of Standards and Technology (NIST)
in 2001. In 2010, Intel released an extension to x86
instruction set architecture, namely AES New Instruction
(AES-NI)[18], which allows specific Intel CPUs to do
extremely fast hardware encryption and decryption with
the AES scheme. Several server and laptop vendors
have shipped BIOS configurations supporting the AES-NI
4

extension for increasing the speed of software performing
encryption and decryption using AES (e.g., OpenSSL).
According to Intel’s whitepaper [18], besides increasing
performance. AES-NI also allows to increase security.
It is one of those technologies able to jointly increase
performance and enhance security. Particularly, AES-NI is
designed to mitigate timing and cache side-channel leakage
of sensitive data (from ring3 processes) usually performed
on software implementations of AES [19]. Their latency
is data-independent, and since all the computations are
performed internally by the hardware, no lookup tables
are required. Therefore, if the AES instructions are used
properly the AES encryption/decryption, as well as the
Key Expansion, would have data-independent timing and
would involve only data-independent memory access.
5.2. ARM Cryptographic Extension
The cryptographic extension to ARM processors
adds new A64, A32, and T32 instructions [20] to
Advanced SIMD that accelerate Advanced Encryption
Standard (AES) encryption and decryption. This
includes instructions useful to implement the Secure
Hash Algorithm (SHA) functions SHA-1, SHA-224, and
SHA-256.
5.3. Issues
It is worth saying that AES-NI highly reduced the
risk of attacks compared to the initial AES software
implementation. Nevertheless, advanced firmware-level
attacks could compromise the cryptographic scheme. For
example, in the last years, researchers discussed some
side-channels obtained via microcode vulnerabilities. The
most notorious example is Spectre [21] where authors
demonstrated the exploitation of a vulnerability in the
speculative execution microcode to create hardware-based
side-channels, thus posing at risk the security of AES-NI.
An additional example is LazyFP [22] where authors
exploit Floating Point Unit (FPU), particularly its context
switching, to recover the FPU and SIMD register set of
arbitrary processes or VMs. As authors claim, all round
keys of AES-NI that are required to decrypt the particular
data block are kept in SSE registers. SSE registers are part
of the FPU register set and thus the LazyFP vulnerability
puts these into reach of an adversary with the ability to
execute code on the same system, regardless of privileges.
5.4. Adoption
A number of recent desktop and server Intel’s CPUs
are nowadays equipped with the AES-NI extension.
The Xeon,Skylake,Kaby Lake product lines are the
most affected ones. Intel AES-NI is mainly used to
strengthen the security in cloud hosting machines [23].
The majority of cloud providers such as Amazon, Google,
IBM, Microsoft started in the last 5 years to offer instances
equipped with this Intel extension and propose it as
security feature in their portfolio. This was possible
through the support provided in firmware (e.g., UEFI),
hypervisors (e.g., Hyper-V, Xen), development tools (e.g.,
gcc/g++), and application software (e.g., OpenSSL).
6. HW-assisted VM Isolation
The rapid adoption of virtualization in cloud
environments has pushed the design of new hardware
technologies, whose primary goal is to optimize the
performance and scalability of processor and network I/O
virtualization. HW-assisted virtualization technologies are
available in a number of Intel and AMD CPUs, namely VT
and SVM, respectively. ARM also introduced hardware
support for virtualization as well. Besides performance,
such HW-assisted solutions can be leveraged to design
advanced mechanisms of protection against hyperjacking
[8]. They can provide isolation and so protection against
DMA, VMM rootkits [24], or memory re-use attacks. An
example is the Input/Output Memory Management Unit
(IOMMU), which enables computer systems to protect
against peripheral device DMA attacks. IOMMU imposes
CPU-controlled address-space virtualization on peripheral
devices similarly to how MMUs impose it on processes.
It is used to protect against DMA attacks that would
violate guest OS isolation in a virtualized environment,
thus providing inter-OS protection.
6.1. Intel VT
Intel Virtualization Technology (VT) [25] is a suite of
technologies containing VT-x and VT-d. The former
is the actual technology that provides HW-assisted
virtualization, whereas VT-d is the extension that enables
direct passthrough of devices, such as PCI devices, that
is the IOMMU mechanism. VT-x is characterized by
two modes of operation for CPUs: VMX root mode
and VMX non-root mode. The first is dedicated to the
hypervisor (the VMM), while the latter is reserved to
guest VMs. This means that applications running in both
modes can operate in any of the four ring levels, which
are typically supported by CPUs, eliminating the need for
ring deprivileging techniques.
The execution switches contexts back and forth between
non-root and root mode. In VT-x, such transitions
are realized via VMEXIT and VMENTRY. The hypervisor
is executed only when particular events in the guest
trigger an exit transition. The exit-triggering events are
fine grained and can be configured by the hypervisor.
Main exiting events include exceptions, interrupts, I/O
operations, and the execution of privileged instructions
(e.g., accesses to control registers). Every exit is handled
by a dispatch function in the hypervisor that eventually
performs an entry to give the control back to the guest.
VT-x includes the Intel Extended Page Tables (EPT) that
support memory virtualization, and reduce the source
of overhead due to memory management. It basically
consists in a paging structure for a full 64 bit address space
5

that keeps a mapping between guest and host physical
addresses.
VT-d [26] stands for Intel VT for Directed I/O. The overall
concept behind VT-d is hardware support for isolating and
restricting device accesses to the owner of the partition
managing the device. A VMM may support various
models for I/O virtualization, including emulating the
device API, assigning physical I/O devices to VMs, or
permitting I/O device sharing in various manners. VT-d
includes four key capabilities:
•I/O device assignment, which allows an administrator
to assign I/O devices to VMs.
•DMA remapping. Supports address translations for
device DMA data transfers.
•Interrupt remapping. Provides VM routing and
isolation of device interrupts.
•Reliability features. Reports and records system
software DMA and interrupt erros that may otherwise
corrupt memory of impact VM isolation.
VT-d is not dependent on VT-x. That is, a VT-x
enabled system can operate without VT-d, or without
VT-d enabled or configured. You simply miss the benefits
of the feature. Many people have asked about this point.
6.2. AMD SVM
AMD Secure Virtual Machine (SVM) [27] is very
similar to Intel VT. They mostly differ in terminologies.
AMD-V is the correspondent of Intel VT-x, which creates
hardware privileged separation between guest VMs and
the hypervisor. AMD-Vi, Intel VT-d. The AMD Nested
Page tables (NPT) brings performance improvement in
memory management similarly to Intel EPT. Finally, the
IOMMU mechanism, included in Intel VT-d, is part of
AMD-Vi.
6.3. Issues
During the years, vulnerabilities of Intel VT and AMD
SVM were demonstrated. On one hand, HW-assisted
VM isolation can ensure protection against a set of
rootkits. However, on the other hand, there were new
advanced rootkits like BluePill [28] and Vitriol, which
were specifically designed for HW-assisted virtualization.
BluePill relies on AMD SVM technology and is installed
without modifications to the BIOS or other boot sectors.
BluePill manipulates kernel mode memory paging and
the VMRUN and related SVM instructions that control
the interaction between the hypervisor and guest. This
permits undetected, on-the-fly placement of the host
operating system in its own secure virtual machine
allowing for complete control of the system including
manipulation by other malware. Attacks like BluePill
and Vitriol motivated the creation of new mechanisms
of hypervisor detection on Intel VT and AMD SVM
such as signature-based, behavior-based, detection based
techniques.
Moreover, Wojtczuk et al. [29] demonstrated that Intel
VT-d can be attacked when Interrupt Remapping is
disabled. The attacks they describe work by forcing
the corresponding device to generate a so called Message
Signaled Interrupt (MSI), i.e., in-bound mechanism for
interrupt signaling. What makes the MSI-based attacks
especially interesting, is that in most cases it is possible
to mount such an attack without cooperating hardware
(malicious device), using entirely innocent and regular
device. An additional attack to IOMMU came from
Morgan et al. [30] who showed that it can be violated
exploiting a weakness in the typical design of Intel VT-d
and AMD-Vi. The weakness is related to the configuration
tables of the IOMMU, which are initialized in a DRAM
region which is not protected from DMA accesses. A
malicious peripheral may benefit from this weakness to
modify these tables in memory just before the hardware
setup of the IOMMU.
6.4. Adoption
Intel VT and AMD SVM are consolidated technologies
equipping almost all general-purpose machines, from
servers to personal computers. The extensions are disabled
by default and must be enabled by users from the
BIOS. Hypervisors also were made compatible with the
HW-assisted virtualization. In the last decade software
companies released their extensions to hypervisors like
Xen, Hyper-V, ESXi, KVM able to leverage the
HW-assisted technologies. These are nowadays the
supporting software for the majority of cloud providers.
7. HW-assisted Random Number Generation
It is well known that in cryptography the quality of
random numbers directly determines the security strength
of the system. Functions for randomness extraction have
hidden states, so that repeated calls to the function
generate new numbers that appear randomly. If the
state is known, all future outcomes of Random Number
Generators (RNGs) can be predicted. RNGs are at the
core of cryptographic applications. They are used for
generating session keys, digital signatures, masks and
challenges in authentication protocols. Cryptographic
applications rely on the unpredictability of random
numbers, which makes implementations of RNGs crucial
for security. All RNGs have to produce output numbers
that are uniformly distributed and unpredictable. Two
types of RNG exist: True Random Number Generator
(TRNG) and Pseudo-random number generator (PRNG).
The first use an unpredictable physical means to generate
numbers, while the second use mathematical algorithms,
completely computer-generated.
A number of attacks exist against PRNG [31][32], which
make the use of stronger TRNG necessary.
6

7.1. IntrinsicID SRAM PUF
Physically Unclonable Functions (PUF) have been
increasingly proposed as TRNG in cryptographic protocols
and security architectures [33][34]. PUF leverages
the physical property of hardware devices to extract
randomness.
At high level, the PUF is a noisy function that is embedded
into a physical object, such as an integrated circuit (IC),
receiving challenges xfrom a stimulator (that could be
a signal generator) to provide a final response ythat is
a unique hardware fingerprint. The majority of PUFs
exploit variability in CMOS circuits by taking advantage
of imperfections in manufacturing processes that lead
to intrinsic and random variations in the physical and
electrical characteristic of integrated circuits, such as
the metal resistivity and the effective channel lengths
of transistors. The response yis always different since
PUFs are subject to noise induced by variations of their
operating conditions, such as supply voltage and ambient
temperature variations.
Overall PUFs ensure the following security properties:
•Inherently unclonable - a PUF cannot be copied
since two device chips of same type provides always
different responses
•Infeasible to predict - it is impossible to predict the
next response when challenges are sent to the PUF.
•Tamper-evident - if an attacker wants to perform
a physical attack to the PUF, then the resulting
fingerprint and so keys will change
The physical system used by the PUF to obtain
randomness gave birth to different categories of PUF.
For example, Optical PUFs [35] rely on the random
interference pattern (speckle) created when a coherent
light (laser beam) propagates through an inhomogeneous
material. Or, Arbiter PUFs [36] that exploit the random
variations in delays of wires and gates on silicon. Given
an input challenge, a condition is set up in the circuit, and
two transitions that propagate along different paths are
compared to see which comes first. An arbiter, typically
implemented as a latch, produces a ‘1’ or a ‘0’, depending
on which transition comes first. Finally, another notable
example are SRAM PUFs, which use static random-access
memory (SRAM) to obtain randomness. The challenge
to an SRAM PUF [37] is a memory address, while
the corresponding PUF response is the content of the
uninitialized memory cells at this address. When an
SRAM cell is powered without applying a data signal,
the state the cell enters depends on the threshold voltage
differences of its transistors. SRAM cells with large
threshold voltage differences always enter either the ’0’ or
the ’1’ state on each power-up.
7.2. Intel Secure Key
Intel introduced Secure Key [38], with their integrated
RNG, called Digital Random Number Generator (DRNG)
in aiming at providing high-quality entropy. New
instructions are provided in the architecture of Intel’s
CPUs, i.e., RDRAND and RDSEED besides the underlying
DRNG hardware implementation. The DRNG follows
aCascade RNG construction model. A common
approach used in modern operating systems (e.g.,
Linux) and cryptographic libraries is to take input
from an entropy source in order to supply a buffer
or pool of entropy. This entropy pool is then
used to provide nondeterministic random numbers that
periodically seed a Cryptographically Secure PRNG
(CSPRNG). Intel uses processor resident entropy source
to repeatedly seed a hardware-implemented CSPRNG.
Unlike software approaches, it includes a better entropy
source implementation that can be sampled to repeatedly
seed the CSPRNG. As Intel states the hardware module
for RNG is self-contained and isolated from software
attacks on its internal state.
7.3. Issues
A first limitation of certain PUF systems (e.g., optical)
lays in the difficulty of implementing the acquisition
infrastructure, which could be physically large, and costly
both in terms of effort and money. PUF could suffer
in terms of reliability with respect to the long term
application in devices related to aging, environmental
conditions as temperature and other similar factors.
Besides that, PUF systems can be subjected to attacks.
An example are Modeling Attacks [39], in which an
adversary collects a subset of all Challenge-Response
Pair (CRP) of the PUF. Then, she tries to derive a
numerical model from this CRP data, i.e., an algorithm
which correctly predicts the PUF’s responses to arbitrary
challenges with high probability. In this regard, techniques
of Machine Learning (ML) are usually preferred. The
typical trend is to distinguish PUFs between Strong and
Weak. Strong PUFs are more susceptible to modeling
attacks. Strong PUFs are disordered physical systems with
a complex challenge-response behavior and very many
possible challenges. They usually have no protection
mechanisms that restrict in freely applying challenges
and reading out their responses. In fact, a Strong PUF
is characterized from a response, which is usually not
post-processed on-chip in a protected environment. Weak
PUFs have few, fixed challenges, and in the extreme case
with just one challenge. It is usually assumed that their
responses remain inside the PUF-carrying hardware, for
example for the derivation of a secret key, but are not
easily accessible for external parties. Weak PUFs are the
PUF class that is the least susceptible to modeling attacks.
Moreover, PUFs could be also target of Side-channel
Attacks. For example, Becker et al. [40] demonstrated
that an Arbiter PUF suffers side-channel attacks like
traditional cryptography. By combining machine learning
with two different side-channels for showing the attacks: a
passive power side-channel and an active fault attack based
on altering the supply voltage of the controlled PUF.
7

Shrimpton et al. [41] provided an academic,
provable-security treatment of Intel Secure Key by
determining its weaknesses. More precisely, they
found that RDRAND delivers pseudorandom bits with a
comfortable security margin. On the other hand, RDSEED
delivers truly random bits but with a security margin
that becomes worrisome if an adversary can see a large
number of outputs from either interface. If she controls
an unprivileged process on the same physical machine,
this could happen very easily.
They prove that RDRAND to be secure under a reasonable
set of assumptions regarding the quality of the entropy
source and a reasonable but heuristic assumption
regarding AES-128: namely that it can be modeled
as a random permutation when used with a specific
fixed, publicly known key. The situation with RDSEED is
more complicated, because the security bounds become
quantitatively quite weak in this context. They believe
that this does not correspond to a practical attack.
The assumption would require the adversary to have a
precise physical model of the entropy source (the exact
parameters of which appear to change from chip to chip),
and compute, by brute force, the distribution induced
by processing streams from this entropy source using
CBC-MAC under the previously mentioned AES key.
7.4. Adoption
Nowadays, some implementations of PUF are still
prototypical and belong more to the research world
than industrial. Others have started of being used in
commercial solutions in the context of IoT for both
end-devices and hosting machines, which could be cloud
hosts. There are companies investing in this area and
providing products, typically based on SRAM PUFs.
For example, the company Maxim Integrated released
ChipDNA [42], which uses a SRAM PUF for providing
secure keys to IoT devices. Or more, ST Microelectronics
sponsors the product of IntrinsicID, namely Citadel [43],
another SRAM PUF-based key provisioning system IoT
oriented.
The characteristics of Intel’s CPUs embedding the
Secure Key technology entail that this can be typically
used in hosting machines. In fact, the last releases of Ivy
Bridge processors containing such an extension are at the
core of cloud platforms like the Google Compute Engine
cloud computing service, or Amazon AWS, or others like
IBM Cloud.
8. HW-assisted Pointers Violation Prevention
In this category we considered examples of HW-assisted
technologies aiming at protecting the system against
attacks that leverage memory errors, i.e., software bugs
caused by invalid pointer operations, use of uninitialized
variables, or memory leaks. A significant part of software,
in fact, is written in languages such as C/C++, which are
unsafe in terms of memory controls and risk to introduce
memory corruption bugs. There are other languages such
as Rust which are considered safe, but are not yet very
adopted. The majority of software is therefore highly
vulnerable to attacks, where these memory bugs could be
exploited to make the software misbehave.
The most notorious examples of attacks in this sense
are Buffer Overflow (BO) [15] and Code-Reuse Attacks
(CRA) [44]. In the first case, more data is written to a
buffer than the allocated size, leading to the overwrite
of adjacent memory locations and causing items like
local variables, pointer addresses, return addresses, and
other data structures, to be overwritten. In the second
case, protection techniques of code-injection attacks are
circumvented by using and recombining pieces of existing
software for malicious purposes. A glorious example is the
return-to-libc attack [45].
OSs are usually equipped with software security
mechanisms to protect against memory-related attacks [46]
and researchers also investigated in this sense [47][48][49].
However, some mechanisms can be weak against certain
classes of attacks and the support of hardware could help
in this sense.
8.1. Intel CET – Control-flow Enforcement Technology
Intel recently announced a new hardware support
for providing CFI, namely Control-flow Enforcement
Technology (CET) [50]. It protects against CRA via
two known mechanisms of CFI, which in this case
become hardware-enabled: Shadow Stacks (SS) and
Indirect-Branch Tracking (IBT) [51]. A SS is a second
stack for the program that is used exclusively for control
transfer operations. This stack is separate from the data
stack and can be enabled for operation individually in
user mode or supervisor mode. When shadow stacks are
enabled, the CALL instruction pushes the return address on
both the data and shadow stack. The RET instruction pops
the return address from both stacks and compares them.
If the return addresses from the two stacks do not match,
the processor signals a control protection exception. The
shadow stack only holds the return addresses and not
parameters passed to the call instruction. The shadow
stack is protected from tamper through a page table
protection enforced by CET. To provide this protection
the page table protections are extended to support an
additional attribute for pages to mark them as Shadow
Stack pages.
Moreover, with CET, a new instruction is introduced,
ENDBRANCH, that marks valid indirect call/jmp targets
in the program. On processors that support CET the
ENDBRANCH is primarily used as a marker instruction by
the in-order part of the processor pipeline to detect control
flow violations. The CPU implements a state machine
that tracks indirect jmp and call instructions. When one
of these instructions is seen, the state machine moves
from IDLE to WAIT_FOR_ENDBRANCH state. From this state
the next instruction in the program stream must be an
8

ENDBRANCH. If an ENDBRANCH is not seen the processor
causes a control protection fault else the state machine
moves back to IDLE state.
Overall, with CET-enabled CPUs, Intel will introduce
new instructions and at the same time will change
traditional control transfer instructions to support the
such as RET, JMP, INT, CALL.
The reported overview is based off Intel’s published
technology preview documents. As no processor with
the claimed technology are still not available, the details
are not complete and may change in small ways prior
to production. For example, Intel still do not explain
the interaction of CET with other technologies such as
SGX. Furthermore, it is still not possible to delineate CET
drawbacks as well as define the adoption trend.
8.2. Intel MPX – Memory Protection Extension
Intel Memory Protection Extension (MPX) was first
announced in 2013 and introduced as part of the Skylake
microarchitecture in late 2015. The sole purpose of
Intel MPX is to transparently add bounds checking to
legacy C/C++ programs, thus facing attacks performed
via Buffer Overflow.
A significant feature of Intel MPX is its compatibility
and interoperability with legacy code. According to the
empirical study of Oleksenko [52], for developers familiar
with the capabilities of Pointer Checker in the Intel
compiler, moving to Intel MPX will be an easy progression
as there is only one new compiler switch, a handful of new
intrinsics and an Intel MPX enabled C runtime library.
Intel MPX provides 7 new instructions and a set of
128-bit bounds registers. Such registers store pointers’
lower bound and upper bound limits. Whenever the
pointer is used, the requested reference is checked against
the pointer’s associated bounds, thereby preventing
out-of-bound memory access (such as buffer overflows and
overruns). Out-of-bounds memory references initiate an
exception which can then be handled in an appropriate
manner. More precisely, The new MPX instructions are:
bndmk to create new bounds, bndcl and bndcu/bndcn to
compare the pointer value against the lower and upper
bounds in bnd respectively, bndmov to move bounds from
one bnd register to another and to spill them to stack,
and bndldx and bndstx to load and store pointer bounds
in special Bound Tables (BT). Moreover, the current
version of Intel MPX has only 4 bounds registers, which is
considered quite low for real-world programs
Unlike software-based protections such as SoftBound [47],
Intel MPX introduces separate bounds registers to lower
register pressure on the general-purpose register (GPR)
file, something that software-only approaches suffer from.
Second, software-based approaches cannot modify the
calling convention and resort to function cloning, when
a set of function arguments is extended to include pointer
bounds.
8.3. ARM PA – Pointer Authentication
In 2016, ARM announced the addition of a security
feature to the ARMv8-A architecture, namely Pointer
Authentication (PA) [53][54]. Its purpose is to detect
pointers created by an external entity. In essence, it
attaches a cryptographic signature to pointer values; those
signatures can be verified before a pointer is used. An
attacker, lacking the key used to create the signatures,
is unlikely to be able to create valid pointers for use in
an exploit. The idea behind ARM PA is that the actual
address space in 64-bit architectures is less than 64-bits.
There are unused bits in pointer values that we can use
to place a Pointer Authentication Code (PAC) for this
pointer. We could insert a PAC into each pointer we
want to protect before writing it to memory, and verify
its integrity before using it. An attacker who wants to
modify a protected pointer would have to find/guess the
correct PAC to be able to control the program flow. Not
every pointer has the same purpose in a program. We
want the pointers to be valid only in a specific context.
In Pointer Authentication, this is achieved in two ways:
having separate keys for major use cases and by computing
the PAC over both the pointer and a 64-bit context. The
pointer authentication specification defines five keys: two
for instruction pointers, two for data pointers and one
for a separate general-purpose instruction for computing
a MAC over longer sequences of data. The instruction
encoding determines which key to use. The context is
useful for isolating different types of pointers used with
the same key. The context is specified as an additional
argument together with the pointer when computing and
verifying the PAC.
8.4. Issues
Intel MPX has been proven very difficult to leverage.
Authors [52] conclude that Intel MPX is a promising
technique that is not yet practical for widespread adoption.
Particularly, they claim after running a number of
micro-benchmarks that performance overheads are still
high (50% on average), and the supporting infrastructure
has bugs which may cause compilation or runtime errors.
It cannot detect temporal errors, entailing risks for false
positives and false negatives in multithreaded code, and
its restrictions on memory layout require substantial code
changes for some programs. It puts at risk the availability
of applications when interacting with other ISA extension
such as Intel SGX and TSX.
Intel MPX support is available for GCC and ICC
compilers. At the compiler level, GCC-MPX has severe
performance issues (≈150%) whereas ICC-MPX has a
number of compiler bugs. At the runtime-support level,
both GCC and ICC provide only a small subset of function
wrappers for the C standard library, thus not detecting
bugs in many libc functions.
There are also potential issues affecting ARM PA. More
precisely, an attacker can forge pointers if she can guess
9

the key or gains control of a process that has the same
key as the target process. The quality of the randomness
used to generate the key is important and must not
be underestimated since the ARM architecture does not
include an entropy source. Another issue is related to
UNIX-like systems, where the fork() system call creates a
complete duplicate of a process. This means that the child
processes must now have the same keys as its parent for it
to continue running. It must be noticed that such an issue
exists for other software-based countermeasures against
CRA including such Address Space Layout Randomization
(ASLR).
In a privilege separation design where one of the processes
remain privileged while the other drops privileges,
compromising the unprivileged process would allow an
attacker to create authenticated pointers that would work
in the privileged process. In a worker process model
where several worker processes are spawned as needed by a
master process to service requests, a remote attacker can
gain multiple, potentially unlimited, tries to brute-force
PAC values since all workers will have the same key,
including the ones that are forked to replace the ones
that die due to address faults. In both cases, using the
fork+exec model where the child process reloads itself
right after fork makes sure the all processes start fresh
with a new key.
8.5. Adoption
While Intel MPX at the beginning seemed a promising
HW-assisted solution in the IoT world for both host or
edge devices collecting interest of the community, now it
seems that it is loosing ground. As proof of this, recent
news of GNU community reported that starting from
GCC v9.1 the support of Intel MPX will be removed [55].
Without the upstream GCC compiler support in place and
the kernel code not seeing much attention, most probably
Intel will remove this functionality in the future.
On the other hand, companies are starting to adopt
the ARM PA HW-assisted solution. Being an extension
to ARM processors, it is clear that its usage will be in
embedded systems spanning from Smatphones to more
generic IoT micro-controllers.
Notably, in September 2018, Apple announced that
the new generation of iPhones is equipped with
the new version of the ARM architecture [56], i.e.,
ARMv8.3, and that started to use the PA functionality.
This complicated jailbreakers’ life whose most used
techniques involved buffer overflows, integer overflows,
return-oriented programming (ROP) [57].
9. HW-assisted Trusted Computing
One of the widest usage of HW-assisted security regards
Trusted Computing (TC), in particular for ensuring
protection of data-in-use. The idea of trust is somewhat
orthogonal to that of security. Trusted components may
be used to build secure systems but trust on its own
does not entail security, merely predictable behavior. For
example, if a piece of software has been tainted by the
introduction of a virus, normal good behavior can easily
turn bad. According to the consortium of companies,
i.e., the Trusted Computing Group (TCG), “an entity can
be considered trusted if it always behaves in the expected
manner for the intended purpose”. With HW-assisted
TC, the machine will consistently behave in expected
ways, and that behavior is enforced bycomputer hardware
and software. This is achieved by loading the hardware
with unique encryption keys inaccessible to the rest of
the system. Trusted computing is based on the concept
of Chain-of-Trust (CoT). Achain-of-trust is established
by validating each component ofhardwareandsoftwarefrom
the end entity up to the Root-of-Trust (RoT). In
HW-assisted TC, the trust anchor usually lays in a piece of
HW. It could also be in SW components but then security
would be lower. In fact, unlike software-based solutions
of TEE [58][59], HW-assisted TC is able to guarantee
security against powerful attackers such as those having
full control over the system, e.g., a malevolent user who
escalated root privileges of the hosting OS. The user’s trust
is rooted in the silicon and it is harder for the attacker to
modify the hardware functionality. Usually
Overall, TC is based on the following generally agreed
upon features:
•Trusted Boot, allows the system to boot into a defined
and trusted configuration.
•Sealed Storage, allows software to keep
cryptographically secure secrets.
•Curtained Memory, will provide strong memory
isolation; memory that cannot be read by other
processes including operating systems and debuggers.
•Attestation, allows a trusted device to present reliable
evidence to remote parties about the software it is
running.
•Integrity Measurement, the ability to compute hashes
of executable code, configuration data, and other
system state information.
TC is nowadays used for different security-related purposes
spanning from run-time attacks enforced by privileged
malwares (e.g., the Iago Attack [12]) up to protection of
Digital Rights Management (DRM).
As reported by Maene et al. [60], over the years many
HTEE implementations were released which include either
a subset or all the features listed above. The most
important difference is the adoption or not of an external
piece of hardware. The Trusted Platfom Module (TPM),
for example, is physically separated from the CPU, while
in the case of Trusted Execution Environment (TEE)
everything is integrated in the CPU.
10

App 1
OS
Peripherals CPU Memory I/O TPM
SW
HW
App 2App 3App 4
Trusted Boot and
Attestation
Figure 3: TPM Security
9.1. TPM – Trusted Platorm Module
The TCG created the Trusted Platform Module (TPM)
specifications to enable access to trusted computing
resources and make them more ubiquitous. Since
the TPM specification is implemented by different
manufacturers in different ways, in the rest of this work
we will use the term TPM to generically mean a typical
implementation of the TPM specification.
A TPM is a dedicated chip external to CPU, designed
to provide a subset of the TC features defined before
(see Figure 3). Particularly, the TPM carries out
cryptographic operations, such as key or random number
generation; ensure platform integrity by taking and
storing security measurements; perform attestation
of software; store artifacts used for authentication or
integrity purposes, such as passwords, certificates, or
encryption keys. A TPM acts as trust anchor for the
chain-of-trust established during the measurement of
software that is realized during booting procedures. More
specifically, the TPM provides three types of RoT. i) A
RoT for measurement, i.e., a trusted implementation of
a hash algorithm, responsible for the first measurement
on the platform whether at boot time, or in order to
put the platform into a special, trusted state; ii ) a RoT
for storage, i.e., a trusted implementation of a shielded
location for one or more secret keys probably, the Storage
Root Key (SRK); iii ) a RoT for reporting, i.e., a trusted
implementation of shielded location to hold a secret key
representing a unique platform identity, the Endorsement
Key (EK). Both SRK and EK are 2048-bit RSA public
and private key pairs, which are created randomly on the
chip at manufacture time. These keys cannot be migrated
or removed.
Manufacturers implemented their own technologies
integrating a TPM. The most important are reported in
the following.
Intel TXT – Trusted eXecution Technology. The
Trusted eXecution Technology (TXT) [61] is Intel’s
implementation of the TCG’s specification for TPM.
With TXT, Intel chipset, designed to work with,
include: special TXT registers, an enhanced architecture,
controlled access to the TPM. Intel TXT incorporates
most of the TCG concepts. Most importantly, it includes
astatic and a dynamic RoT measurement. The static
chain of trust measures the platform configuration, and
the dynamic chain of trust measures the system software,
software configuration, and software policies. Intel TXT
comes with software support for the TXT hardware,
called Trusted Boot (tboot). This is a package which can
be added to a Linux distribution to enable the various
TXT features.
AMD PSP. The Platform Security coProcessor (PSP) is
the TPM-based solution of AMD. The PSP uses the ARM
TrustZone extension – explained in the following – as
a TPM hardware. PSP is a physically separate core
integrated into the AMD SoC having a dedicated SRAM
and dedicated access to the Cryptographic Co-Processor
(CCP). The PSP provides the immutable hardware RoT
that can be used as the basis for optionally providing the
chain of trust from the hardware up to the OS. The CCP
brings in a RNG, several cryptographic engines such as
AES, RSA, and others, and a key storage block. The
key storage block contains two key storage areas: one
dedicated to storing system keys that can be used by
privileged software but that are never readable; and the
other into which keys can be loaded, used, and evicted
during normal operation by software running either on the
PSP or on the main OS. During boot, SoC-unique keys are
distributed to the CCP system key storage block.
9.2. TEE – Trusted Execution Environment
The concept of Trusted Execution Environment (TEE)
can be seen as an extension of TPMs. The TEE is a secure
area of the main processor of a connected device that
ensures sensitive data is stored, processed and protected
in an isolated and trusted environment. As such, it
offers protection against software attacks generated in the
privileged OS ring0. Hence, a TEEis an area on the
CPU chipset that works like a TPM, but is not physically
isolated from the rest of the chip. It is embedded within
the CPU, thus ensures higher protection against physical
attacks (e.g., bus sniffing or cold boot). Furthermore,
compared to a TPM, a TEE offers a wider set of TC
features. Notably, the provision of an isolated execution
area for sensitive code with curtained memory ensures
protection against run-time attacks such as CRA.
Three main technological implementations of TEE have
been released in the last years, which are presented in the
following.
ARM TrustZone. TrustZone [62] is a flexible
hardware-assisted security technology proposed by
ARM, which partitions the hard- and software- resources
of a System-on-a-Chip, by distinguishing the context of
execution in secure and normal world. The latter is also
referred to as non-secure world. The separation is achieved
by an extended system bus design, adding the so-called
non-secure bit to bus addresses. This bit is propagated
with each resource access and so prevents a non-secure
11

Secure World
App 1
OS
Peripherals CPU Memory I/O
SW
HW
App 2Trustlet 1 Tru stlet 2
TEE
OS
Figure 4: ARM TrustZone Security
Normal world
privileged modes
Secure worldNormal world
Monitor mode
Normal world
user mode
Secure world
privileged modes
Secure world
user mode
Figure 5: ARM TrustZone Execution Modes
processor from accessing as secure sdeclared resources.
The TrustZone Protection Controller is used to configure
resources as secure or non-secure, whereas the TrustZone
Address Space Controller assigns memory regions to the
secure or non-secure side. From secure world, the monitor
mode can be entered additionally by directly writing to
the CPSR1. Altogether, a TrustZone-enabled processor
can switch between five modes, as illustrated in Figures
4 5. When switching worlds, the context of the world
switching from must be saved; the one of the switching to
must be restored.
The so-called monitor mode is a mechanism that allows
to context-switch or better world-switch between the
virtual processor cores. From the normal world, the
monitor mode can be entered by three exceptions: normal
interrupts, triggered e.g.by timers, input devices and
similar; external aborts, usually memory errors; call of
the dedicated SMC instruction.
Intel SGX – Software Guard eXtension. The 7th
generation of Intel’s CPUs has been equipped with
an innovative secure extension to the Instruction Set
Architecture (ISA), namely Software Guard eXtension
(SGX) [63]: a TEE based on a mechanism of “reverse
sandbox” in which sensitive processes’ address space is
protected – at CPU level – even against OS. The idea
behind is to protect selected code and data from disclosure
or modification through the use of secure enclaves, i.e.,
address regions whose content is protected – via encryption
and hashing – from any software outside the enclave,
included privileged ones. Only the enclave code can access
any part of the address space, except those areas belonging
to other enclaves. The boundary between enclave and
non-enclave sections is governed by the processor who
1Current Program Status Register
App 1
OS
SW
App 2App 3App 4
Peripherals CPU Memory I/O
HW
TEE
Enclav e
1
Enclav e
2
Enclav e
3
Enclav e
4
Figure 6: Intel SGX Security
blocks any access attempt from unauthorized processes.
An interface – defined in a domain-specific C language – is
declared by the programmer to establish entry points, i.e.,
calls to/from an enclave (namely ECALLS and OCALLS).
SGX enhances security of data processed, e.g., in the
cloud. However, this sensitive content arrives at the cloud
over the Internet. SGX therefore provides a mechanism,
namely Remote Attestation (RA), which enables service
providers to provision applications, and to know with
confidence that their secrets are properly protected [64].
The idea of RA is to prove – via a third remote entity –
the goodness of a software running in a specific enclave.
Such enclave must convince the other enclave – with which
it is communicating – that it has a valid measurement
hash, is running in a secure environment and has not been
tampered. The mutual verification is performed using a
processor key, which is accessible only by a special enclave
known as Quoting Enclave.
SGX allows both intra-attestation and inter-attestation
services, i.e., the procedure of RA performed between
two enclaves residing on the same host or in different
hosts, respectively. The remote attestation service builds
a secure channel between the two enclaves by performing
aDiffie-Hellman key exchange.
AMD MET – Memory Encryption Technology. The
Memory Encryption Technology (MET) [65] is the
HW-assisted TEE solution recently released by AMD
that encrypts and protects system memory. AMD
MET brings in a AES-128 encryption engine inside the
SoC that transparently encrypts and decrypts the data
when it crosses the SoC. Within MET, AMD released
two main security features, namely Secure Memory
Encryption (SME) and Secure Encrypted Virtualization
(SEV) [66]. Both SEM and SEV are managed by the
OS or hypervisor, and no application software changes are
needed. Encryption key management such as generating,
storing, and delivering the keys are carried out by the
AMD secure processor and the encryption keys are kept
hidden from untrusted parts of the platform.
SME is the security mechanism useful to face physical
attacks. It uses an encryption key that is randomly
generated by the AMD secure processor and is loaded
into the memory controller at boot time to encrypt the
memory. Access to sensitive memory page is directed to
the AMD Memory Encryption Engine. In the SME design,
12

all devices can access the encrypted memory pages through
DMA.
SEV is thought to face privileged attacks by providing
encrypted VM isolation. It encrypts the VM’s memory
space with the VM’s specific key from the hypervisor
or other VMs on the same platform. SEV does
not require changes to user legacy software, i.e., the
memory encryption is transparent. SEV leverages the
Memory Encryption Engine, responsible of encrypting
and decrypting different VM memory spaces on the same
platform. In SEV, a unique encryption key is associated
with each guest VM. When code and data arrives into the
SoC, SEV tags all of the code and data associated with
the guest VM in the cache and limits access only to the
owner. When a guest is launched, its memory must first
be encrypted before SEV can be enabled in hardware for
this guest.
9.3. Issues
Over the years, TC has been demonstrated vulnerable
to different attacks. For what regards the TPM, it must
be said that this is not designed to provide run-time
protection but only launch-time protection. That is, it
can defend against attacks like code-injection. In this case,
in fact, the hash of the binary changes and the system
detects that it. The TPM is not able able to protect
against runtime attacks such as CRAs where the attacker,
at run-time, changes the code that is already available
in memory. This weakness leaves the door opened to a
number of attacks that nowadays are realized against IoT
devices or Cloud hosts. Furthermore, the TPM is external
to the CPU, thus subjected to hardware attacks such as
bus sniffing attacks.
There are also examples of attacks against the TPM itself.
Just recently South Korean researchers demonstrated two
attacks against TPMs [67]. These were possible thanks
to power interrupts. Since machines do not feed power to
all their components all the time and at the same time.
They use special APIs to send power to a component only
when it needs it to perform an operation, putting it in a
suspended (sleep) state between use states. Researchers
discovered two issues affecting the way TPMs enter and
recover from these suspended power states, which allow
an attacker to reset TPMs and then create a fake boot-up
chain of trust for a targeted device. The attacks allow
an adversary to reset and forge platform configuration
registers which are designed to securely hold measurements
of software that are used for bootstrapping a computer.
One attack is exploiting a design flaw in the TPM 2.0
specification for the static root of trust for measurement.
The other attack is exploiting an implementation flaw in
tboot, the most popular measured launched environment
used with Intel’s TXT.
Another example of attack against TXT was realized by
Wo jtczuk et al. [68]. They demonstrated the assumption
of SMM being always trusted is incorrect since the SMM
can bypass security protections imposed by the late launch
process on a newly loaded VMM. In other words the
attacks completely bypass all the security functionality
that is supposed to be provided by the TXT for the
purpose of trusted boot.
Regarding TEE, instead, technological solutions such
as AMD SEV and Intel SGX have proven to be
vulnerable to micro architectural attacks that could create
side-channels to steal protected data. For example,
in 2018, a group of researchers revealed one of the
most impressive vulnerabilities that affects nearly every
computer chip manufactured in the last 20 years, namely:
Spectre and Meltdown [21]. These two names represent
different variants of the same technique, that exploits
the speculative execution of modern CPUs to perform a
side-channel attack and steal sensitive data. Both AMD
and Intel CPUs suffer from Spectre/Meltdown, which
can be leveraged to obtain data protected in their TEE.
Despite the media attention, it is not surprising that
TEE can be target of side channel attacks since these are
out of their threat model. For example Intel explicitly
states in the SGX threat model that they do not protect
against attacks at cache line or higher granularity, like
L1-L2 cache attacks. It is up to the developer to enforce
specific security checks within the TEE to verify possible
intrusions.
Besides attacks risks, TEEs such as SGX or TrustZone also
suffer from usability issues. These often requires several
software changes making their adoption difficult. Legacy
applications do not easily migrate to Intel SGX without
applying specific code modifications. Intel SGX provides
robust security protections, making it a suitable TEE for
applications that require an enhanced-degree of security
protection. Contrariwise, AMD MET enables transparent
protection. It is suited for securing more complex and
legacy applications than SGX.
9.4. Adoption
TC is already used in devices, such as smartphones or
tablets, and also by manufacturers of constrained chipsets
and IoT devices in different fields such as industrial
automation, automotive and healthcare, who are now
recognizing its benefit in protecting connected things.
Even Cloud Providers leverage technologies of TC for
increasing security of customers’ data and improve their
Service Level Agreement (SLA). The threat model of
TC-based solutions fits particularly well in contexts of
IoT where the application and its sensitive data reside in
untrusted environments, from the field up to the cloud.
TPMs such as Intel TXT or AMD PSP are mostly adopted
in cloud hosts or gateways. This is due to their intrinsic
characteristics, i.e., CPUs which are mainly adopted in
general purpose systems. As an example, IBM announced
some years ago that brought Intel TXT to its Softlayer
cloud service. Even Amazon AWS provides TXT in its
cloud offerings as security add-on. To protect data on edge
devices, instead, there are silicon companies producing
13

Intel
TXT
Intel
VT
Intel
MPX
Code-Reuse
Buffer-Overflow
Cloud Host/
Gateway
Edge-Device
Cold Boot
Code-Injection
Intel
SGX
Cold Boot
Code-Injection
Iago
Kernel Malware
Bus Sniffing
ARM
TrustZone
AMD
MET
AMD
PSP
ARM
PA
Intel
CET
VMM Rootkits
DMA Attacks
AMD
SVM
Cryptanalytic
on RNG
SRAM
PUF
Intel
SecureKey
Attacks HW-assisted
Solutions Target
Malware
Detection
Intel
AES-NI
Code-Reuse
Intel
TDT
Cache
Side-channel
ARM
Crypto Ext.
VMM Rootkits
Embed
TPMs
Figure 7: Attacks covered with HW-assisted security solutions
HW-assisted Solution
Cloud Host/
Gateway Edge-Device
Malware Detection Intel TDT
Crypto Acceleration Intel AES-NI
ARM Crypto Ext.
VM Isolation Intel VT
AMD SVM
RNG SRAM PUF
Secure Key
Pointers Violation
Prevention
ARM PA
Intel CET
Intel MPX
Trusted Computing
TPM
(TXT, PSP, Embed)
TEE
(SGX, MET, TrustZone)
Table 1: Adoption summary of HW-assisted solutions
embedded solutions such as OPTIGA of Infineon or
STSafe of STMicroelectronics.
For what concerns HW-assisted technologies of TEE,
these are also of interest for the different entities of typical
IoT deployments. SGX was initially designed to secure
small applications but then several research works and
companies have started to use Intel SGX for more complex
workloads such as enterprise-level services or even public
cloud applications [69][70][71][72]. Just recently IBM
announced in its cloud offerings the possibility of deploying
Intel SGX bare metal servers across all regions on IBM
Cloud [73] for protecting data-in-use. Or more, Microsoft
Azure presented Azure Confidential Computing [74] that
uses Intel SGX to protect in a transparent fashion data
processed in the cloud. Even, Alibaba cloud is proposing
a cloud offering where SGX is used to ensure data-in-use
security [75]. AMD MET, instead, was born specifically
for public cloud environments. A number of providers in
the last years such as Amazon [76], Oracle [77], Google
have started to adopt the EPYC processors containing the
AMD MET technology.
Finally, there are a number of applications of the
TrustZone extension in edge devices [78] [?] [79].
The ARMv8-M architecture is used in different embedded
devices and its TEE is of interest for Intellectual Property
protection. Device makers can use TrustZone for
ARMv8-M to store intellectual property in secure memory
while still allowing non-secure applications to access it
via APIs. They also use it for secure storage of critical
information such as user data, identity information,
and security keys. Or even to secure the end-to-end
communication with the IoT gateway. TrustZone
for ARMv8-M supports energy-conscious devices like
wearables or battery-operated edge nodes in markets such
as smart utilities and smart cities.
10. Conclusion
This paper reported a wide survey on several
HW-assisted solutions supporting the security of data
managed in either host machines such as cloud servers or
in end devices. We analyzed technologies that accelerate
the performance of security-related processing and, most
importantly, those that actually enhance systems’ security.
Figure 7 and Table 1 summarize the technologies seen
in this work, their covered attacks, and the target of
adoption. Overall, AMD, ARM and especially Intel have
released a number of products where hardware support
14

security mechanisms. We noticed that in the last years
companies have pushed on two categories of solutions, i.e.,
HW-assisted trusted computing and HW-assisted pointers
violation prevention. These also seem the main tracks for
the next years.
Acknowledgements
This project received funding from the European
Union’s Horizon 2020 Framework Programme for
Research and Innovation under grant agreement No
727528 (KONFIDO). Furthermore, authors acknowledge
the “Aziende e tecnologie smart: modelli, misurazione
delle performance, gestione della conoscenza e soluzioni
tecnologiche” project under the “Ricerca Competitiva”
programme funded by University of Naples ‘Parthenope’.
References
[1] F. Zhang, H. Zhang, Sok: A study of using hardware-assisted
isolated execution environments for security, in: Proceedings
of the Hardware and Architectural Support for Security and
Privacy 2016, HASP 2016, ACM, New York, NY, USA, 2016,
pp. 3:1–3:8. doi:10.1145/2948618.2948621.
URL http://doi.acm.org/10.1145/2948618.2948621
[2] A. Al-Omary, H. Alsabbagh, H. Al-Rizzo, Survey of
hardware-based security support for iot/cps systems, KnE
Engineering 3 (2018) 52. doi:10.18502/keg.v3i7.3072.
[3] K. Adams, O. Agesen, A comparison of software and hardware
techniques for x86 virtualization, SIGARCH Comput. Archit.
News 34 (5) (2006) 2–13. doi:10.1145/1168919.1168860.
URL http://doi.acm.org/10.1145/1168919.1168860
[4] R. de Clercq, I. Verbauwhede, A survey of hardware-based
control flow integrity (CFI), CoRR abs/1706.07257. arXiv:
1706.07257.
URL http://arxiv.org/abs/1706.07257
[5] G. Cerullo, G. Mazzeo, G. Papale, B. Ragucci, L. Sgaglione,
Chapter 4 - iot and sensor networks security, in: M. Ficco,
F. Palmieri (Eds.), Security and Resilience in Intelligent
Data-Centric Systems and Communication Networks,
Intelligent Data-Centric Systems, Academic Press, 2018, pp. 77
– 101. doi:https://doi.org/10.1016/B978- 0-12-811373- 8.
00004-5.
URL http://www.sciencedirect.com/science/article/pii/
B9780128113738000045
[6] V. Casola, A. De Benedictis, A. Mazzeo, N. Mazzocca,
Sensim-sec: Security in heterogeneous sensor networks, in: 2011
Conference on Network and Information Systems Security, 2011,
pp. 1–8. doi:10.1109/SAR-SSI.2011.5931360.
[7] V. Casola, A. De Benedictis, A. Drago, N. Mazzocca,
Analysis and comparison of security protocols in wireless
sensor networks, in: 2011 IEEE 30th Symposium on Reliable
Distributed Systems Workshops, 2011, pp. 52–56. doi:10.1109/
SRDSW.2011.27.
[8] N. Rakotondravony, B. Taubmann, W. Mandarawi,
E. Weish¨aupl, P. Xu, B. Kolosnjaji, M. Protsenko, H. de Meer,
H. P. Reiser, Classifying malware attacks in iaas cloud
environments, Journal of Cloud Computing 6 (1) (2017) 26.
doi:10.1186/s13677-017- 0098-8.
URL https://doi.org/10.1186/s13677-017- 0098-8
[9] Z. Wu, Z. Xu, H. Wang, Whispers in the hyper-space:
High-speed covert channel attacks in the cloud, in: Presented
as part of the 21st USENIX Security Symposium (USENIX
Security 12), USENIX, Bellevue, WA, 2012, pp. 159–173.
URL https://www.usenix.org/conference/
usenixsecurity12/technical-sessions/presentation/wu
[10] P. Stewin, I. Bystrov, Understanding dma malware, in:
U. Flegel, E. Markatos, W. Robertson (Eds.), Detection
of Intrusions and Malware, and Vulnerability Assessment,
Springer Berlin Heidelberg, Berlin, Heidelberg, 2013, pp. 21–41.
[11] A. Francillon, C. Castelluccia, Code injection attacks on
harvard-architecture devices, in: Proceedings of the 15th ACM
Conference on Computer and Communications Security, CCS
’08, ACM, New York, NY, USA, 2008, pp. 15–26. doi:10.
1145/1455770.1455775.
URL http://doi.acm.org/10.1145/1455770.1455775
[12] S. Checkoway, H. Shacham, Iago attacks: Why the system call
api is a bad untrusted rpc interface, SIGPLAN Not. 48 (4)
(2013) 253–264. doi:10.1145/2499368.2451145.
URL http://doi.acm.org/10.1145/2499368.2451145
[13] R. Roemer, E. Buchanan, H. Shacham, S. Savage,
Return-oriented programming: Systems, languages, and
applications, ACM Trans. Inf. Syst. Secur. 15 (1) (2012)
2:1–2:34. doi:10.1145/2133375.2133377.
URL http://doi.acm.org/10.1145/2133375.2133377
[14] T. K. Bletsch, X. Jiang, V. W. Freeh, Z. Liang, Jump-oriented
programming: a new class of code-reuse attack, in: AsiaCCS,
2011.
[15] C. Cowan, P. Wagle, C. Pu, S. Beattie, J. Walpole, Buffer
overflows: attacks and defenses for the vulnerability of the
decade, in: Foundations of Intrusion Tolerant Systems, 2003
[Organically Assured and Survivable Information Systems],
2003, pp. 227–237. doi:10.1109/FITS.2003.1264935.
[16] J. Kelsey, B. Schneier, D. Wagner, C. Hall, Cryptanalytic
attacks on pseudorandom number generators, in: S. Vaudenay
(Ed.), Fast Software Encryption, Springer Berlin Heidelberg,
Berlin, Heidelberg, 1998, pp. 168–188.
[17] Intel threat detection technology, https://www.intel.com/
content/dam/www/public/us/en/documents/product-briefs/
tdt-product- brief.pdf, accessed: 2018-12-10 (2018).
[18] S. Gueron, Intel advanced encryption standard (aes)
instructions set (rev 3.01), Intel Software Network.
[19] J. Bonneau, I. Mironov, Cache-collision timing attacks against
aes, in: L. Goubin, M. Matsui (Eds.), Cryptographic
Hardware and Embedded Systems - CHES 2006, Springer Berlin
Heidelberg, Berlin, Heidelberg, 2006, pp. 201–215.
[20] Arm cryptography extension, https://static.docs.arm.com/
ddi0501/f/DDI0501.pdf, accessed: 2018-12-11 (2014).
[21] P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg,
M. Lipp, S. Mangard, T. Prescher, M. Schwarz, Y. Yarom,
Spectre attacks: Exploiting speculative execution, CoRR
abs/1801.01203. arXiv:1801.01203.
URL http://arxiv.org/abs/1801.01203
[22] J. Stecklina, T. Prescher, Lazyfp: Leaking FPU register state
using microarchitectural side-channels, CoRR abs/1806.07480.
arXiv:1806.07480.
URL http://arxiv.org/abs/1806.07480
[23] L. Coppolino, S. DAntonio, G. Mazzeo, L. Romano, Cloud
security: Emerging threats and current solutions, Computers
& Electrical Engineering 59 (2017) 126 – 140. doi:https:
//doi.org/10.1016/j.compeleceng.2016.03.004.
URL http://www.sciencedirect.com/science/article/pii/
S0045790616300544
[24] S. T. King, P. M. Chen, Subvirt: implementing malware with
virtual machines, in: 2006 IEEE Symposium on Security and
Privacy (S P’06), 2006, pp. 14 pp.–327. doi:10.1109/SP.2006.
38.
[25] J. Fisher-ogden, Hardware support for efficient virtualization
(2006).
[26] David ott, understanding vt-d: Intel
virtualization technology for directed i/o, https:
//software.intel.com/en-us/blogs/2009/06/25/
understanding-vt- d-intel- virtualization- technology-for- directed-io,
accessed: 2018-12-14 (2016).
[27] Amd, inc. amd virtualization., https://www.amd.com/en/
technologies/virtualization, accessed: 2019-01-08 (2019).
[28] J. rutkowska, introducing blue pill, http:
15

//theinvisiblethings.blogspot.com/2006/06/
introducing-blue- pill.html, accessed: 2018-12-14 (2006).
[29] R. Wojtczuk, J. Rutkowska, Following the White Rabbit:
Software attacks against Intel(R) VT-d technology,
http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
(Apr. 2011).
[30] B. Morgan, . Alata, V. Nicomette, M. Kaniche, Bypassing
iommu protection against i/o attacks, in: 2016 Seventh
Latin-American Symposium on Dependable Computing
(LADC), 2016, pp. 145–150. doi:10.1109/LADC.2016.31.
[31] J. Kelsey, B. Schneier, D. Wagner, C. Hall, Cryptanalytic
attacks on pseudorandom number generators, in: S. Vaudenay
(Ed.), Fast Software Encryption, Springer Berlin Heidelberg,
Berlin, Heidelberg, 1998, pp. 168–188.
[32] G. Argyros, A. Kiayias, I forgot your password: Randomness
attacks against PHP applications, in: Presented as part of
the 21st USENIX Security Symposium (USENIX Security 12),
USENIX, Bellevue, WA, 2012, pp. 81–96.
URL https://www.usenix.org/conference/
usenixsecurity12/technical-sessions/presentation/
argyros
[33] C. Wachsmann, A.-R. Sadeghi, Physically unclonable functions
(pufs): Applications, models, and future directions, Synthesis
Lectures on Information Security, Privacy, and Trust 9 (2014)
1–91. doi:10.2200/S00622ED1V01Y201412SPT012.
[34] M. Barbareschi, A. D. Benedictis, N. Mazzocca, A puf-based
hardware mutual authentication protocol, Journal of Parallel
and Distributed Computing 119 (2018) 107 – 120. doi:https:
//doi.org/10.1016/j.jpdc.2018.04.007.
URL http://www.sciencedirect.com/science/article/pii/
S0743731518302582
[35] C. Mesaritakis, M. Akriotou, A. Kapsalis, E. Grivas,
C. Chaintoutis, T. Nikas, D. Syvridis, Physical unclonable
function based on a multi-mode optical waveguide, Scientific
Reports 8. doi:10.1038/s41598-018- 28008-6.
[36] U. Chatterjee, R. S. Chakraborty, H. Kapoor,
D. Mukhopadhyay, Theory and application of delay constraints
in arbiter puf, ACM Trans. Embedded Comput. Syst. 15 (2016)
10:1–10:20.
[37] C. Bhm, M. Hofer, W. Pribyl, A microcontroller sram-puf,
in: 2011 5th International Conference on Network and System
Security, 2011, pp. 269–273. doi:10.1109/ICNSS.2011.6060013.
[38] Intel digital random number generator
(drng) software implementation guide,
https://software.intel.com/en-us/articles/
intel-digital- random-number- generator- drng-software- implementation-guide,
accessed: 2018-11-22 (2018).
[39] U. R¨uhrmair, F. Sehnke, J. S¨olter, G. Dror, S. Devadas,
J. Schmidhuber, Modeling attacks on physical unclonable
functions, in: Proceedings of the 17th ACM Conference on
Computer and Communications Security, CCS ’10, ACM, New
York, NY, USA, 2010, pp. 237–249. doi:10.1145/1866307.
1866335.
URL http://doi.acm.org/10.1145/1866307.1866335
[40] B. Georg T, R. Kumar, Active and passive side-channel attacks
on delay based puf designs, Cryptology ePrint Archive, Report
2014/287, https://eprint.iacr.org/2014/287 (2014).
[41] T. Shrimpton, R. S. Terashima, A provable-security analysis
of intel’s secure key rng, in: E. Oswald, M. Fischlin (Eds.),
Advances in Cryptology – EUROCRYPT 2015, Springer Berlin
Heidelberg, Berlin, Heidelberg, 2015, pp. 77–100.
[42] Chipdna puf security overview, https://www.
maximintegrated.com/en/design/partners-and- technology/
design-technology/chipdna- puf-technology.html#_anc1,
accessed: 2018-11-20 (2018).
[43] Citadel - key provisioning system for iot security based on sram
puf, https://www.intrinsic-id.com/products/citadel/,
accessed: 2018-11-20 (2018).
[44] T. Bletsch, Code-reuse attacks: New frontiers and defenses,
Ph.D. thesis, aAI3463747 (2011).
[45] Bypassing non-executable-stack during exploitation
(return-to-libc), https://www.exploit-db.com/papers/13204,
accessed: 2018-11-22 (2006).
[46] E. Leon, S. D. Bruda, Counter-measures against stack buffer
overflows in gnu/linux operating systems, Procedia Computer
Science 83 (2016) 1301 – 1306, the 7th International Conference
on Ambient Systems, Networks and Technologies (ANT 2016)
/ The 6th International Conference on Sustainable Energy
Information Technology (SEIT-2016) / Affiliated Workshops.
doi:https://doi.org/10.1016/j.procs.2016.04.270.
URL http://www.sciencedirect.com/science/article/pii/
S1877050916303039
[47] S. Nagarakatte, J. Zhao, M. M. Martin, S. Zdancewic,
Softbound: Highly compatible and complete spatial memory
safety for c, SIGPLAN Not. 44 (6) (2009) 245–258. doi:
10.1145/1543135.1542504.
URL http://doi.acm.org/10.1145/1543135.1542504
[48] V. P. Kemerlis, G. Portokalidis, A. D. Keromytis, kguard:
Lightweight kernel protection against return-to-user attacks,
in: Presented as part of the 21st USENIX Security Symposium
(USENIX Security 12), USENIX, Bellevue, WA, 2012, pp.
459–474.
URL https://www.usenix.org/conference/
usenixsecurity12/technical-sessions/presentation/
kemerlis
[49] V. Moula, S. Niksefat, Ropk++: An enhanced rop attack
detection framework for linux operating system, 2017, p. 16.
doi:10.1109/CyberSecPODS.2017.8074849.
[50] Intel control-flow enforcement technology, https:
//software.intel.com/sites/default/files/managed/4d/
2a/control-flow- enforcement-technology- preview.pdf,
accessed: 2018-11-28 (2017).
[51] N. Carlini, A. Barresi, M. Payer, D. A. Wagner, T. R.
Gross, Control-flow bending: on the effectiveness of control-flow
integrity, in: USENIX Security Symposium, 2015.
[52] O. Oleksenko, D. Kuvaiskii, P. Bhatotia, P. Felber, C. Fetzer,
Intel MPX explained: An empirical study of intel MPX
and software-based bounds checking approaches, CoRR
abs/1702.00719. arXiv:1702.00719.
URL http://arxiv.org/abs/1702.00719
[53] Arm pointer authentication extension, https:
//www.qualcomm.com/media/documents/files/
whitepaper-pointer- authentication-on- armv8- 3.pdf,
accessed: 2018-12-12 (2017).
[54] H. Liljestrand, T. Nyman, K. Wang, C. C. Perez, J.-E. Ekberg,
N. Asokan, Pac it up: Towards pointer integrity using arm
pointer authentication, arXiv preprint arXiv:1811.09189.
[55] Intel mpx removed support, https://gcc.gnu.org/wiki/
Intel%20MPX%20support%20in%20the%20GCC%20compiler,
accessed: 2018-12-08 (2018).
[56] Examining Pointer Authentication on the iPhone XS,
https://googleprojectzero.blogspot.com/2019/02/
examining-pointer- authentication-on.html, last accessed
10/03/2019 (2019).
[57] Apple - arm pointer authentication, https://ivrodriguez.com/
pointer-authentication- on-armv8- 3/, accessed: 2018-12-11
(2018).
[58] R. Jayaram Masti, C. Marforio, S. Capkun, An architecture
for concurrent execution of secure environments in clouds, in:
Proceedings of the 2013 ACM Workshop on Cloud Computing
Security Workshop, CCSW ’13, ACM, New York, NY, USA,
2013, pp. 11–22. doi:10.1145/2517488.2517489.
URL http://doi.acm.org/10.1145/2517488.2517489
[59] L. Martignoni, R. Paleari, D. Bruschi, Conqueror:
Tamper-proof code execution on legacy systems, in:
Proceedings of the 7th International Conference on Detection
of Intrusions and Malware, and Vulnerability Assessment,
DIMVA’10, Springer-Verlag, Berlin, Heidelberg, 2010, pp.
21–40.
URL http://dl.acm.org/citation.cfm?id=1884848.1884851
[60] P. Maene, J. Gotzfried, R. de Clercq, T. Muller,
F. Freiling, I. Verbauwhede, Hardware-based trusted
16

computing architectures for isolation and attestation,
IEEE Transactions on Computers PP (99) (2017) 1–1.
doi:10.1109/TC.2017.2647955.
[61] W. Futral, J. Greene, Introduction to Trust and Intel Trusted
Execution Technology, Apress, Berkeley, CA, 2013, pp. 1–14.
doi:10.1007/978-1- 4302-6149- 0_1.
URL https://doi.org/10.1007/978-1- 4302-6149- 0_1
[62] T. R. ARM, Security technology building a secure system using
trustzone technology (2009).
[63] F. McKeen, I. Alexandrovich, A. Berenzon, C. V. Rozas,
H. Shafi, V. Shanbhogue, U. R. Savagaonkar, Innovative
Instructions and Software Model for Isolated Execution, in:
Proceedings of the 2nd International Workshop on Hardware
and Architectural Support for Security and Privacy, HASP,
2013.
[64] I. Anati, S. Gueron, S. P. Johnson, V. R. Scarlata, Innovative
technology for cpu based attestation and sealing (2013).
[65] D. Kaplan, AMD x86 memory encryption technologies,
USENIX Association, Austin, TX, 2016.
[66] S. Mofrad, F. Zhang, S. Lu, W. Shi, A comparison study of
sgx and amd memory encryption technology, 2018, pp. 1–8. doi:
10.1145/3214292.3214301.
[67] S. Han, W. Shin, J.-H. Park, H. Kim, A bad dream: Subverting
trusted platform module while you are sleeping, in: 27th
USENIX Security Symposium (USENIX Security 18), USENIX
Association, Baltimore, MD, 2018, pp. 1229–1246.
URL https://www.usenix.org/conference/
usenixsecurity18/presentation/han
[68] R. Wojtczuk, J. Rutkowska, Attacking intel trusted execution
technology.
[69] C. che Tsai, D. E. Porter, M. Vij, Graphene-sgx: A practical
library OS for unmodified applications on SGX, in: 2017
USENIX Annual Technical Conference (USENIX ATC 17),
USENIX Association, Santa Clara, CA, 2017, pp. 645–658.
URL https://www.usenix.org/conference/atc17/
technical-sessions/presentation/tsai
[70] S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin,
C. Priebe, J. Lind, D. Muthukumaran, D. O’Keeffe, M. L.
Stillwell, D. Goltzsche, D. Eyers, R. Kapitza, P. Pietzuch,
C. Fetzer, Scone: Secure linux containers with intel sgx, in:
12th USENIX Symposium on Operating Systems Design and
Implementation (OSDI 16), USENIX Association, GA, 2016,
pp. 689–703.
URL https://www.usenix.org/conference/osdi16/
technical-sessions/presentation/arnautov
[71] L. Coppolino, S. D’Antonio, G. Mazzeo, L. Romano, A
comparative analysis of emerging approaches for securing java
software with intel sgx, Future Generation Computer Systems
97 (2019) 620 – 633. doi:https://doi.org/10.1016/j.future.
2019.03.018.
URL http://www.sciencedirect.com/science/article/pii/
S0167739X18315942
[72] L. Coppolino, S. DAntonio, G. Mazzeo, L. Romano,
L. Sgaglione, Exploiting new cpu extensions for secure exchange
of ehealth data at the eu level, in: 2018 14th European
Dependable Computing Conference (EDCC), 2018, pp. 17–24.
doi:10.1109/EDCC.2018.00015.
[73] Data-in-use protection on ibm cloud using intel
sgx, https://www.ibm.com/blogs/bluemix/2018/05/
data-use- protection-ibm- cloud- using-intel- sgx/,
accessed: 2019-01-01 (2018).
[74] Microsoft azure confidential computing with intel sgx,
https://software.intel.com/en-us/blogs/2018/11/08/
microsoft-azure- confidential-computing- with- intel-sgx,
accessed: 2018-12-20 (2018).
[75] SGX-protected Alibaba Cloud Offering, https://www.
alibabacloud.com/blog/fortanix-provides- intel%C2%
AE-sgx- protected-kms- with- alibaba-cloud_594075, last
accessed 10/03/2019 (2018).
[76] Aws announcing the partnership with amd, https://aws.
amazon.com/it/ec2/amd/, accessed: 2019-01-06 (2018).
[77] Oracle announcing the launch of amd epyc instances,
https://blogs.oracle.com/cloud-infrastructure/
announcing-the- launch-of- amd- epyc-instances, accessed:
2019-01-06 (2018).
[78] SierraTEE Trusted Execution Environment, https://www.
sierraware.com/open-source- ARM-TrustZone.html (2018).
[79] M. Staffa, G. Mazzeo, L. Sgaglione, Hardening ros via
hardware-assisted trusted execution environment, in: 2018
27th IEEE International Symposium on Robot and Human
Interactive Communication (RO-MAN), 2018, pp. 491–494.
doi:10.1109/ROMAN.2018.8525696.
17