Conference PaperPDF Available

Establishing Mutually Trusted Channels for Remote Sensing Devices with Trusted Execution Environments

Authors:

Abstract and Figures

Remote and largely unattended sensing devices are being deployed rapidly in sensitive environments, such as healthcare, in the home, and on corporate premises. A major challenge, however, is trusting data from such devices to inform critical decision-making using standardised trust mechanisms. Previous attempts have focused heavily on Trusted Platform Modules (TPMs) as a root of trust, but these forgo desirable features of recent developments, namely Trusted Execution Environments (TEEs), such as Intel SGX and the GlobalPlatform TEE. In this paper, we contrast the application of TEEs in trusted sensing devices with TPMs, and raise the challenge of secure TEE-to-TEE communication between remote devices with mutual trust assurances. To this end, we present a novel secure and trusted channel protocol that performs mutual remote attestation in a single run for small-scale devices with TEEs. This is evaluated on two ARM development boards hosting GlobalPlatform-compliant TEEs, yielding approximately four-times overhead versus untrusted world TLS and SSH. Our work provides strong resilience to integrity and confidentiality attacks from untrusted world adversaries, facilitates TEE interoperability, and is subjected to mechanical formal analysis using Scyther.
Content may be subject to copyright.
Establishing Mutually Trusted Channels for Remote Sensing
Devices with Trusted Execution Environments
Carlton Shepherd, Raja Naeem Akram, Konstantinos Markantonakis
{carlton.shepherd.2014,r.n.akram,k.markantonakis}@rhul.ac.uk
Information Security Group, Royal Holloway, University of London
Egham, Surrey, United Kingdom
ABSTRACT
Remote and largely unaended sensing devices are being deployed
rapidly in sensitive environments, such as healthcare, in the home,
and on corporate premises. A major challenge, however, is trusting
data from such devices to inform critical decision-making using
standardised trust mechanisms. Previous aempts have focused
heavily on Trusted Platform Modules (TPMs) as a root of trust,
but these forgo desirable features of recent developments, namely
Trusted Execution Environments (TEEs), such as Intel SGX and the
GlobalPlatform TEE. In this paper, we contrast the application of
TEEs in trusted sensing devices with TPMs, and raise the challenge
of secure TEE-to-TEE communication between remote devices with
mutual trust assurances. To this end, we present a novel secure and
trusted channel protocol that performs mutual remote aestation in
a single run for small-scale devices with TEEs. is is evaluated on
two ARM development boards hosting GlobalPlatform-compliant
TEEs, yielding approximately four-times overhead versus untrusted
world TLS and SSH. Our work provides strong resilience to integrity
and condentiality aacks from untrusted world adversaries, facili-
tates TEE interoperability, and is subjected to mechanical formal
analysis using Scyther.
CCS CONCEPTS
Security and privacy Trusted computing;
Embedded sys-
tems security; Domain-specic security and privacy architectures;
Networks Security protocols;
KEYWORDS
Trusted sensing, trusted execution environments, trusted comput-
ing, embedded device security, secure sensing architectures.
ACM Reference format:
Carlton Shepherd, Raja Naeem Akram, Konstantinos Markantonakis. 2017.
Establishing Mutually Trusted Channels for Remote Sensing Devices with
Trusted Execution Environments. In Proceedings of ARES ’17, Reggio Cal-
abria, Italy, Aug. 29–Sep. 01, 2017, 10 pages.
DOI: 10.1145/3098954.3098971
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permied. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specic permission
and/or a fee. Request permissions from permissions@acm.org.
ARES ’17, Reggio Calabria, Italy
©
2017 Copyright held by the owner/author(s). Publication rights licensed to ACM.
978-1-4503-5257-4/17/08. . . $15.00
DOI: 10.1145/3098954.3098971
1 INTRODUCTION
e advent of the Internet of ings (IoT) – the notion that in-
terconnected everyday objects will monitor and act upon their
surroundings – is enabling pervasive sensing applications to be-
come reality. Healthcare proposals have long existed that transmit
physiological data from wearable sensors for self-monitoring [
46
],
early detection of illness [
32
], and to inform insurance premiums
[
8
]. In the home, energy conservation systems using occupancy
data [
22
], task automation for the elderly and disabled [
34
], and
fall/injury detection [
31
] have been proposed. is extends to mon-
itoring transported goods, e.g. perishable foods [
5
] and livestock
[
29
], smart manufacturing [
24
], and various other domains. Across
sensor-driven domains, however, the challenge of data assurance
is presented: whether remote sensing devices can be trusted to
inform critical decision-making in which malicious data could yield
damaging consequences for end-users.
is has motivated past work using Trusted Computing Group
(TCG) concepts, namely the Trusted Platform Module (TPM), to
protect data and provide evidence of platform integrity. TPMs, how-
ever, are restricted relative to modern trust technologies: neither
arbitrary application execution nor secure input/output (I/O) are
realisable without additional processes, such as TPM-backed virtual
machines [
48
]. One solution is the Trusted Execution Environment
(TEE), which shares hardware with an untrusted Rich Execution
Environment (REE), e.g. Android, but executes independently with
hardware-enforced isolation. is allows critical applications to
execute with strong condentiality and integrity guarantees along-
side a potentially compromised REE, while providing TPM-like
features, such as secure storage and authenticated boot.
In this paper, we investigate TEE-based sensing to achieve certain
trust and security assurances, contrast these with TPMs (Sections 2
and 3), and identify the challenges facing their use. Particularly, the
issue of mutual trusted channels for TEEs – the notion of secure
TEE-to-TEE communication with trust assurances – has received
lile aention in past literature. To address this, we present a novel
protocol that provides secure and trusted channels between two
remote TEEs (Sections 4 and 5), where trust can be veried uni-
directionally or bi-directionally through one- and two-way remote
aestation respectively. is provides resilience to sophisticated
integrity and condentiality soware aacks from intermediate
components, i.e. REE or network-level adversary. Our work is ap-
plicable to sensing applications requiring stronger trust assurances,
and we discuss measures for facilitating interoperability between
competing TEEs, such as Intel SGX and the GlobalPlatform TEE.
e protocols are formalised and subjected to mechanical formal
analysis using Scyther (Section 5), before presenting a performance
evaluation using a GlobalPlatform-compliant TEE on two ARM
ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy C. Shepherd, R. N. Akram and K. Markantonakis
development boards (Sections 6 and 7). Lastly, we conclude our
ndings and identify future research directions (Section 8).
2 RELATED WORK
Sensing with standardised trust technologies has aracted notable
aention in past literature; we discuss relevant work and highlight
their contributions. Liu et al. [
26
] propose two abstractions for
providing trust in sensing platforms:
(1)
,sensor aestation, which
signs each reading with a TPM’s Aestation Identity Key (AIK)
and veried with its public key; platform integrity is preserved
using regular remote aestation (described in Section 3).
(2)
,Sensor
seal: encrypted secrets are bound to the TPM and released once
sensor readings satisfy a given policy. ese two concepts are
evaluated using ARM TrustZone with a TPM emulated in soware,
and Credo, a TPM-backed hypervisor, for X86 systems. Both are
evaluated yielding moderate overhead.
Gilbert et al. [
14
] examine TPMs to provide data assurance in
sensitive sensing applications. Similarly, the authors propose a
TPM-backed hypervisor to protect device drivers and sensing pro-
cessing applications from soware integrity aacks. Untrusted user
applications are executed in a separate guest domain to facilitate
isolated execution, with the hypervisor acting as a secure monitor.
It is proposed to sign sensing measurements with a signed TPM
quote, which includes the TPM Platform Conguration Register
(PCR) responsible for the sensing application.
Saroiu et al. [
40
] propose two sensing architectures using TPMs:
(1)
, a TPM-backed hypervisor that sandboxes users’ soware in a
guest Virtual Machine (VM), and a root VM with privileged access to
sensor drivers and the TPM. e root VM signs sensor readings with
the TPM to prevent modication once passed to the user VM. Design
(2)
proposes aaching a TPM to each sensing microcontroller to
protect against a malicious kernel. Here, the microcontroller signs
readings using the TPM independently of the OS. e authors note
that
(1)
is less costly – both performance-wise and economically –
but provides fewer security guarantees.
To our knowledge, the use of TEEs in trusted sensing has avoided
direct examination in light of recent developments, such as Intel
SGX and the GlobalPlatform TEE. Certain TEE features have already
been identied as desirable, e.g. secure I/O and isolated execution
[
14
,
26
]. In other work, these features have been developed in-
dependently with TPMs [
21
,
26
,
28
,
48
], but a unied TPM-based
system has not materialised as a deployable solution over time. e
shortfall of TPMs for such general-purpose trusted computing is
aributed to the large and ever-changing Trusted Computing Base
(TCB) necessary to maintain it [
38
]. A large TCB – the soware and
hardware components critical to a system’s security – increases the
aack surface available to an adversary. For sensing applications,
a compromise at any point would undermine data assurance, i.e.
whether it was modied or breached condentiality.
3 TRUSTED SENSING PLATFORMS
e lack of trust assurances in sensing platforms is a major chal-
lenge in deploying services that could signicantly benet users
[
40
]. One example is enabling healthcare clinicians to suggest treat-
ments via users’ physiological data reported from health wearables
[
39
]. Another is the use of sensor-driven authentication schemes to
Table 1: Comparison of TPM and TEE Features.
Feature Rich OS TPM SGX GP TEE
+TrustZone
HW Tamper-Resistance 7 3 ^ ^
Native Isolated App. Execution 7 7 3 3
No Additional Hardware 3 7 3 3
Remote Aestation 7 3 3 7
Native Secure I/O 7 7 7 3
Native Secure Storage 7^3 3
Authenticated Boot 7 3 7 3
^Limited functionality.
control access to remote assets based on location, application activ-
ity or other behavioural data [
42
,
44
]. In such examples, protecting
platform integrity is paramount to prevent data manipulation at
source, as well as protecting measurements at rest or in transit, e.g.
over Bluetooth or WiFi.
To complicate maers, reported measurements are oen sev-
eral steps removed from raw values. Feature extraction and pre-
processing algorithms, such as noise ltering and compression, are
applied regularly before transmission [
14
]. is places TPMs at a
disadvantage, which do not naturally provide isolated execution
to transform sensitive data securely. Moreover, data may be col-
lected o-line and stored persistently before transmission. is
is benecial where real-time streaming is prohibitive due to bat-
tery and network constraints, especially for detailed, high-volume
measurement streams. In such cases, measurements ought to be
stored securely (on-device) to preserve integrity and condential-
ity. is too is problematic with TPMs, however, which provide
limited on-board storage and processing capability for encrypting
potentially feature-rich measurements at high sampling rates. An
approach based on encrypting measurements, as in [
26
], neces-
sitates a trusted path with sensor hardware; a compromised I/O
driver, for example, may intercept data before it reaches a TPM.
TEEs oer promise by providing standardised secure I/O, se-
cure storage and isolated execution. is allows sensing nodes
to robustly store and process sensitive material while preserving
performance through hardware sharing. TEEs may also oer other
TPM-like mechanisms, such as authenticated boot and remote at-
testation. We provide a comparison of TPMs and TEEs in Table 1.
Next, we explore TEEs further and their challenges with respect to
trusted sensing.
3.1 Trusted Execution Environments (TEEs)
GlobalPlatform denes a TEE as an execution environment, iso-
lated from the REE, which “protects from general soware aacks,
denes rigid safeguards as to data and functions that a program
can access, and resists a set of dened threats” [
15
]. TEEs are used
to execute sensitive applications, such as ngerprint matching,
with hardware-enforced isolation via a trusted hardware element,
e.g. a CPU. Trusted applications (TAs) reside in their own mem-
ory regions and such isolation is used to prevent unauthorised
accesses from REE space; TAs may allocate shared memory space
with trusted world applications, or expose developer-dened func-
tions that are mediated by a high-privilege secure monitor. TEEs
are nding development on devices suitable for sensing platforms.
Mutually Trusted Channels for Remote Sensing Devices with TEEs ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy
Micro-controllers, such as the Atmel SMART
1
, and single-board
computers, including the Raspberry Pi 3
2
, contain ARM TrustZone
extensions. Intel SGX, meanwhile, is nding adoption on server-
side and larger portable devices, e.g. Intel-based laptops. A detailed
comparison of secure and trusted environments is found in [
43
].
We summarise these main TEEs below.
3.1.1 Intel Soware Guard eXtensions (SGX). An extension to
the x86-64 instruction set that allows the creation of independent
TEEs, or ‘enclaves’, per application on-demand. Enclaves reside
in isolated memory regions within RAM with accesses mediated
by a (trusted) CPU. Enclaves may access untrusted world memory
space directly, but not vice-versa; enclaves may also not access
other enclaves arbitrarily. Intel SGX oers secure storage using the
‘sealing’ abstraction in which enclave data is encrypted using a key
derived from the CPU-bound root seal key, where ‘sealed’ data is
accessible only to that enclave. SGX oers remote aestation for
third-party verication of enclave integrity using the Enhanced
Privacy ID (EPID) protocol [
7
] – a variant of Direct Anonymous
Aestation (DAA) that uses a group signature scheme with a CPU-
bound EPID key for preserving platform privacy. EPID bootstraps a
key for allowing remote operators to provision or retrieve sensitive
data from the target enclave. SGX is available from the Skylake
generation of Intel CPUs [9].
3.1.2 GlobalPlatform (GP) TEE and ARM TrustZone. Maintains
two worlds for all trusted and untrusted applications. e trusted
world contains a trusted OS that interfaces with TAs through the
GP TEE Internal API (see Figure 1 and [
18
]), while untrusted world
applications interface with the trusted world using the Client API
[
15
]. e GP TEE provides secure storage using the sealing ab-
straction, akin to SGX; a trusted user-interface API for establishing
secure paths between TAs and a touch display; a Sockets API for
initiating TEE network connections using POSIX-style sockets; and
a Secure Element API for communicating with on-board secure
elements [
19
]. ARM TrustZone is typically used to instantiate GP
TEEs in hardware, which uses two virtual cores for each world
per physical CPU core and an additional Non-Secure (NS) proces-
sor bit to indicate execution mode. Secure Monitor Call (SMC)
instructions are used to context switch between worlds. Moreover,
TrustZone uses secure ROM for performing authenticated boot of
the trusted world by measuring and computing a signature chain
of critical system components, e.g. a bootloader. Secure I/O is pro-
vided through which dedicated interrupts can be routed specically
to the trusted world – achieved via the TrustZone Protection Con-
troller (TZPC), responsible for securing on-chip peripherals, and
the TrustZone Address Space Controller (TZASC) for protecting
DRAM and memory-mapped devices.
3.2 TEE Challenges
TEEs currently face signicant standardisation challenges [
36
]. For
example, secure I/O remains the preserve of ARM TrustZone/GP
TEE, while the GP TEE is yet to dene a remote aestation mecha-
nism. TEEs oer potential in sensing, but the absence of a uniform
remote aestation solution impedes interoperability. We develop
1
Atmel SMART: hp://www.atmel.com/products/microcontrollers/ARM/default.aspx
2Raspberry Pi 3: hps://www.raspberrypi.org/products/raspberry- pi-3-model- b/
Figure 1: GlobalPlatform TEE Architecture.
the issues of remote aestation and TEE interoperability and inter-
communication forthwith.
3.2.1 Remote Aestation. Intel SGX’s EPID mechanism relies
on developers comparing the signature of enclave applications
known before deployment with the aestation result (known as
a ‘quote’). Aer receiving an aestation challenge, the untrusted
host application requests its enclave to produce an aestation, and
the enclave produces a report structure comprising the identity
and hash of the enclave, which is veried and signed by a special
quoting enclave. is is signed using a EPID key derived from a
hardware-bound key, which is certied by Intel, and accessible
only to the quoting enclave. e nal quote is transmied to the
challenger, who can use the Intel Verication Service to verify its
authenticity; this process is controlled stringently by Intel, which
functions as a trusted third-party. Comparatively, GlobalPlatform
is yet to standardise a remote aestation mechanism.
3.2.2 TEE Intercommunication. e issue of secure TEE-to-TEE
communication on distinct devices is pertinent to sensing applica-
tions. It is conceivable that diering TEE architectures may wish
to communicate with each other directly, e.g. an Intel-based server-
side analytics service receiving sensitive health measurements from
an ARM-based wearable. While EPID allows Intel SGX to bootstrap
a secure channel, this is a one-way mechanism that only veries
an SGX-enabled entity. Ideally, both end-points should undergo
trust verication to provide this assurance, i.e. each node remotely
aesting the other prior to further communications involving sensi-
tive data, and ought to be performed without trusting intermediate
components, such as either REE. We herein refer to this two-way
remote aestation as achieving bi-directional trust assurances.
To our knowledge, this remains unaddressed with remote TEEs.
A na
¨
ıve solution is to perform remote aestation twice – one per
party – but this adds the complexity of two protocol executions, nor
does it bootstrap a shared session key with two-way trust verica-
tion within a single run. Two-way remote aestation protocols have
been proposed previously with TPMs [
2
,
20
], and we aim to extend
this to TEEs by developing a single protocol that provides intercom-
munication with bi-directional trust assurances, while accounting
for potential interoperability issues.
ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy C. Shepherd, R. N. Akram and K. Markantonakis
Figure 2: High-level System Architecture.
4 PROTOCOL DESIGN
We refer to the high-level architecture in Figure 2 in our discussion.
e threat model assumes any component between the TEEs to be
untrusted, including the medium across which data is transmied,
such as the Internet, a short-range (e.g. Bluetooth), local area, or
peer-to-peer network. e TEE and its applications are considered
to be trusted; the TEE should also protect against threats dened in
the GlobalPlatform TEE Protection Prole [
15
]. We aim to defend
against a strong adversary that may:
(a)
, arbitrarily observe or
modify sensor measurements and other data, either in soware or
across a network, once it has departed either TEE;
(b)
, masquer-
ade as either end-point with using message replays;
(c)
, aempt
to use a past compromised session key in future runs; and
(d)
,
deny/repudiate that a protocol instance had occurred.
4.1 Security Requirements
We propose a series of requirements for establishing trusted chan-
nels between remote TAs, which serve as a minimum (but not
exhaustive) security baseline that should be supported natively:
(1) Mutual Key Establishment
: A shared secret key is es-
tablished for communication between the two entities.
(2) Mutual Entity Authentication
: Each entity shall au-
thenticate the other’s identity to counter masquerading.
(3) Mutual Non-Repudiation
: Neither entity may deny that
a protocol instance had occurred.
(4) Trust Assurance
: Entities shall be able to remotely aest
the application and platform integrity of the other.
(5) Mutual Trust Verication
: Both entities shall success-
fully aest the state of the other within the protocol.
(6) Freshness
: e session keys, including derivatives, must
be fresh in order to counter replay aacks.
(7) Forward Secrecy
: e compromise of a particular session
key should not aect past or subsequent protocol runs.
(8) Denial of Service (DoS) Prevention
: Resource alloca-
tion shall be minimised at both end-points to prevent DoS
conditions from arising.
4.2 Functional Requirements
(1) Avoid additional trust hardware
: For constrained em-
bedded devices, the protocol shall avoid the need for addi-
tional security hardware.
TEE
Attestation Authority
Verification
Server
Attestation
Server
TA Developer
User Device
Trusted Hardware
Trusted
Application (TA)
Untrusted World
Trusted
Measurer (TM)
Secure Storage
3) Registers
valid TA state
4) Attestation
challenge to TA
5) TA requests TM
to measure TA and
platform configuration,
and to sign quote
under AK
2) TA provisioned
into device
6) TA transmits
quote
7) Verifies
quote
1) Provider generates
certified, device-specific
attestation key-pair, AK,
and provisions into
secure storage
before deployment
Figure 3: Generic TEE Remote Attestation Architecture.
(2) TEE-agnostic
: e protocol shall avoid manufacturing
and verication processes specic to particular TEEs.
(3) Session resumption
: e ability to resume a session se-
curely without restarting the protocol completely.
4.3 Trust Assurance – Operational Perspective
TEEs and TPMs typically follow the ‘quote’ abstraction in remote
aestation. In SGX (Section 3.2.1), a separate trusted application
– a quoting enclave – functions as a verier and signatory of the
state of the requested enclave and the hardware TCB. is signed
state (the quote) is transmied back to the challenger for verica-
tion by an operator, through the Intel Verication Service, which
acts as a trusted authority. is abstraction is not specied in the
GlobalPlatform specications, but may be implemented similarly.
With OP-TEE [
25
], a GP-compliant TEE by Linaro, the TEE ver-
ies a TA’s binary signature when it is loaded into memory such
that only veried TAs are launched; TAs are signed by the devel-
oper before deployment. e fact that the device was booted and
the TA was launched implies a weak notion that they are inte-
gral, but this may not be fully convincing to remote challengers.
is process, however, provides limited application assurances, and
verifying platform integrity is more challenging. For stronger plat-
form assurances, proprietary remote aestation mechanisms have
emerged, but these remain largely undocumented publicly; Sam-
sung KNOX, which uses ARM TrustZone, is known to transmit boot
measurements as part of its aestation response, which is signed by
a device-unique aestation root key certied by Samsung [
37
]. is
is complicated by long-running TAs, like those collecting sensing
data over long periods of time, which may run for days without
being rebooted/reveried. A post-launch compromise by TA or TEE
OS aacks outside of a TEE protection prole [
15
], e.g. program-
ming errors, may not be detected except potentially by aestations
that generate both TA and platform measurements (assuming such
an aack does not compromise the measurer and signing keys).
We suggest the use of a separate GP TEE OS component, a
Trusted Measurer (TM), which is veried in authenticate boot, to
generate quotes based on the state information of the platform and
Mutually Trusted Channels for Remote Sensing Devices with TEEs ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy
Protocol 1 Proposed Bi-directional Trust Protocol (BTP)
1: TAS D T AR E :I DS D | | I DRE | | nS D | | дS D | | ARR E || Sco ok ie
Sco ok ie =H(дS D || nS D || IDS D || I DR E )
2: TAR E TAS D :IDR E || IDS D | | nR E || дR E | | σT ARE (XTAR E ) || σT AR E (VTAR E )KE
KMAC || ARS D
XT AR E =H(I DS D || I DR E | | дR E || дS D || nR E || nS D )
VTAR E =QT ARE || nR E || nS D
3: TAS D T AR E :[σT ASD (XTAS D ) || σT AS D (VT AS D )]KE
KMAC || Scoo ki e
XT AS D =H(I DS D | | I DRE | | дR E || дS D || nRE | | nS D )
VTAS D =QT ASD || nR E || nS D
Table 2: Protocol Notation
Notation Description
SD Sensing device, e.g. health wearable.
RE Remote entity, e.g. analytics service.
TAXTEE trusted application on device X.
U AXUntrusted application on device X.
nXRandom number (nonce) generated by X.
H(D)A secure one-way hash function, H, applied to D.
XYMessage transmission from Xto Y.
IDXIdentity of X.
A|| BConcatenation of Aand B.
дXDie-Hellman exponentiation of X.
ARXAestation request on target entity X.
QXote from TEE X.
σ(A)P
KSignature of A with private-public key-pair (K,P).
[D]Ke
KMAC
Message Dis encrypted using session encryption
and MAC keys Keand KMAC respectively, both
generated during the protocol.
target TA. e TM would sign the quote using an aestation key
provisioned by an operator before deployment. is could be in
soware using native TEE secure storage or, at the cost of addi-
tional hardware and Functional Requirement 1, within a secure
element accessible only to the TEE to provide greater hardware
tamper resistance (suggested by the GP specications [
15
]). TEE im-
plementations of TPMs (‘rmware’ TPMs, or fTPMs), as discussed
by Raj et al. [
33
], are another potential candidate to act as a TM. A
verication service, run by the service operator, may then verify
received quotes. Figure 3 depicts a generic aestation process.
5 PROPOSED PROTOCOL
We now formalise the proposal from the requirements in Section
4 and present the Bi-directional Trust Protocol (BTP), listed in
Protocol 1. In design, BTP is based on the Intel SGX aestation
architecture [
7
], and the Greveler et al. [
20
] and Akram et al. [
2
]
protocols that establish mutually trusted channels using TPMs. We
provide a detailed comparison in Section 5.4. Our proposal pro-
vides bi-directional trust on TEEs while promoting interoperability
through the quoting abstraction in Section 4.3. Next, we show how
BTP can be modied to provide one-way aestation for devices
incapable of hosting a TEE, but may still wish to transmit securely
with a remote TEE. We denote this as the Uni-directional Trust
Protocol (UTP); for this, the trust guarantees in Section 4 apply only
to the TEE device. ese dierences are highlighted throughout.
5.1 Setup and Assumptions
For BTP, it is assumed both TAs know the valid state of the other, i.e.
a certied signature of the TA binary, as specied in Section 3.2.1,
and a TM for generating and signing quotes from application and
platform state data. For UTP, only the TEE end-point must respond
to aestation requests and provide quotes. It is also assumed that
the TEE has a secure, preferably hardware-based, means of key
generation and derivation, and random number generation.
5.2 Post-protocol
Trusted sensing necessitates secure session resumption to alleviate
the overhead of re-executing the protocol. is is essential for low-
powered devices that transmit sensitive data frequently but not
necessarily constantly, e.g. a home monitoring system reporting oc-
cupancy data during the day. Resumption is not cost-free, however;
the longer a session exists, the greater the likelihood and impact of
a compromised session. As such, sessions should be re-established
at regular intervals to minimise this risk.
5.3 Analysis
An informal analysis of the protocol is now discussed – marking
dierences between BTP and UTP – alongside the results of formal
verication using Scyther.
5.3.1 Informal Discussion.
(1)
, e sensing device, which is
trusted in BTP (
TAS D
) or untrusted in UTP (
U AS D
), computes and
transmits its Die-Hellman (DH) exponential ‘
дS D
’, along with
an aestation request ‘
ARRE
’ for the remote entity to provide its
quote.
Sco ok ie
, comprising a hash of the nonce, IDs and chosen DH
exponentiation may be used for session resumption. is satises
the session resumption functional requirement (F3).
(2)
, Next,
TAR E
transmits its DH exponentiation,
дS E
; nonce,
nRE ; its quote, QT AR E ; and signatures of both the DH exponentia-
tions and the quote, which are signed using session-derived keys.
is satises the requirement S1 (mutual key establishment) and
S6 (freshness). In the BTP protocol,
TAR E
requests an aestation
from the sensing device. By design, this is not necessary with UTP.
(3)
Finally, the sensing device acknowledges with the nonces,
DH exponentiations and IDs, which are encrypted and signed, and
the session cookie. is satises S2 (mutual entity authentication),
S3 (mutual non-repudiation), S6 (freshness) and S7 (forward secrecy,
by generating an ephemeral key). S8 (DoS prevention) is largely
ensured by avoiding either party to perform overly-demanding
operations: two signatures, a single aestation, DH exponentiation,
ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy C. Shepherd, R. N. Akram and K. Markantonakis
Table 3: Requirements Comparison of Related Protocols.
Protocols
Req. STS AD ASPeCT JFK T2LS SCP81 MM SM P-STCP SSH TLS DTLS SGX+EPID GJL AMMBSC Proposal
S1 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
S2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
S3 3 7 7 3 3 3 3 3 3 3 3 3 3 3 3 3
S4 7 7 7 7 3 (3)7 7 3 7 7 7 3 3 3 3
S5 – – 7 7 – – 7– – 7 3 3 3
S6 3 3 3 3 3 3 3 (3)3 3 3 3 (3)3 3 3
S7 3 7 3 3 3 3 7 7 3 3 3 3 3 3 3 3
S8 7 7 7 3 3?7 7 7 3 7 3?3?3 3 3 3
F1 – – 7 3 – – 7– – 7 7 3
F2 – – 7– – 3
F3 7 7 7 7 3 7 7 7 3 3?3 3 7 7 3 3
3
— Supported.
7
— Unsupported. (
3
) — Supported implicitly by the architecture.
3?
— Supported aer modications. (–) — Not applicable due to
another requirement. — Keys provisioned into hardware fuses during manufacturing.
nonce generation and shared-key generation are required by each
party. Lastly, the sensing device responds with its respective quote,
thus satisfying S5 (bi-directional trust). For UTP, no responding
quote is generated and σT ASD (VT AS D )is not transmied.
5.3.2 Mechanical Formal Verification with Scyther. e Scyther
verication tool by Cremers et al. [
10
] was used to verify the cor-
rectness of both protocols. Given a security protocol description
wrien in the Scyther description language and desired properties
(claims), Scyther veries whether the protocol satises those claims.
We analyse both protocols using the Dolev-Yao adversarial model,
testing for the secrecy of quotes (
Secret, qre
), aliveness (
Alive
),
non-injective agreement (
Niagree
), non-injective synchronisation
(
Nisynch
), session key secrecy (
SKR, K
) and reachability of both
communicating entities (
TARE or UASD/TASD, Reachable
). e
full scripts for the bi-directional (BTP) and uni-directional (UTP)
protocols can be found in Appendices A.1 and A.2 respectively.
Scyther found no aacks on either protocol.
5.4 Comparison
A criteria comparison is made with protocols from related domains
in Table 3. ese include well-known transport-layer protocols
(TLS [
11
] and SSH [
47
]), and their variants (DTLS [
35
]), as well as
smart cards (the Markantonakis-Mayes [
27
], GP SCP81 [
16
] and
Sire-Mayes [
45
] protocols). We also include other key exchange
(Station-to-Station [
12
], Aziz-Die [
6
], ASPeCT [
23
] and Just Fast
Keying or JFK [
1
]) and trusted protocols (Trusted TLS or T2LS [
13
],
Akram et al. (AMMBSC) [
2
], Greveler et al. (GJL) [
20
], Enhanced
Privacy ID with SGX [
7
] and P-STCP [
3
]. e smart card domain
oers an unique perspective, with high security and performance
requirements, as well as its maturity, and we include such protocols
due to the similar requirements on limited devices.
As illustrated in Table 3, no protocol satises the requirements
motivating this work. Some are closely related, such as AMMBSC
[
2
], SGX+EPID [
7
] and GJL [
20
]. SGX+EPID is not considered due to
the tightly-controlled nature in which Intel provisions PSKs during
manufacturing and performs aestation (described in Section 3.2.1).
Naturally, AMMBSC is avoided for its reliance on TPM, the issues
of which we highlighted in Section 3. GJL, which is similar to
AMMBSC and uses TPMs, is avoided likewise. While widely used,
(D)TLS and SSH are avoided due to the absence of trust provisions,
alongside the diculty of engineering TEE-based aestation in
such protocols retroactively.
6 IMPLEMENTATION
Both BTP and UTP were implemented using OP-TEE [
25
] – an
open-source, GP-compliant TEE based on ARM TrustZone. Two
applications were developed that executed in the trusted and un-
trusted worlds independently, with communications mediated via
the GP secure monitor [
19
]. OP-TEE executes two execution en-
vironments simultaneously: the untrusted world OP-TEE Client,
running a bare-bones Linux system that implements the GP TEE
Client API [
17
]; and OP-TEE OS, running the TEE kernel that im-
plements the GP TEE Internal API [
18
]. e reader is referred back
to Section 3 and Figure 1 for an overview of the GP TEE.
Both protocols were implemented using the cryptographic oper-
ations dened in the GP Internal API, all of which occurred in the
trusted world application, while the untrusted world was used for
handling TCP/IP sockets and TA instantiation. In OP-TEE, crypto-
graphic operations are implemented by the LibTomCrypt library
and ARM Cryptography Extensions for providing instruction-level
AES and SHA [
4
]. Based on the NIST recommendations [
30
], we
used 2048-bit Die-Hellman, 128-bit AES in CBC mode, and SHA-
256 (including for HMACs). For quote signing and verication, we
used the Elliptic Curve Digital Signature Algorithm (ECDSA) using
the
secp256r1
curve, based on those recommendations. Currently,
only the NIST curves are specied in the GP TEE Internal API [
18
].
Each TA was preloaded with the known signature of the remote TA
and an associated 256-bit ECDSA public key, also using
secp256r1
.
Akin to Intel SGX enclave measurement, we emulated a TM that,
on request, returns an ECDSA-signed hash of the binary and mock
platform information. In practice, as per Section 3, this key would
be certied and provisioned by the developer, and the TM would
ideally form part of the TEE’s secure boot.
We used two HiKey LeMaker ARM development boards, hosting
an HiSilicon Kirin 620 SoC with an eight-core ARM Cortex-A53
processor (1.2GHz), 2GB DDR3 RAM and TrustZone extensions.
Such specications are typical of modern single-board platforms;
Mutually Trusted Channels for Remote Sensing Devices with TEEs ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy
Figure 4: High-level Implementation Information Flow for BTP.
the Raspberry Pi 3, for example, also uses an ARM Cortex-A53.
Notably, the board is supported and well-documented for use with
OP-TEE. e protocol was implemented in C – the only develop-
ment language supported fully by OP-TEE at the time of writing
– and cross-compiled for ARM 64-bit platforms using the GNU C
Compiler. In order to minimise overhead, world context switches
were kept to two per message for seing and retrieving messages
into and from the TA respectively. is is shown in Figure 4.
7 PERFORMANCE EVALUATION
We measured 1,000 runs of the BTP and UTP protocols, which were
benchmarked against the OpenSSL 1.0.1 implementation of TLS
v1.2 and SSH (via OpenSSH 6.7) running in the untrusted world.
For TLS, the modes DHE-RSA-AES128-SHA256,DHE-DSS-AES128-
SHA256
and
ECDHE-ECDSA-AES128-SHA256
were used. is selec-
tion stems from the similarities with our proposal: the use of
ephemeral Die-Hellman (DHE), 256-bit ECDSA and 128-bit AES,
in addition to RSA and DSS signatures for comparison. ese were
measured using
openssl s client
. For SSH, 128-bit AES in CBC
mode was used with SHA-256 HMACs, as per our implementation.
is was tested with RSA-, ECDSA- and DSA-based key pairs; the
ssh
utility was used with default seings except for specifying
AES and HMAC modes, and the desired key. e Die-Hellman
group sizes were set at 2048 bits (with pre-generated moduli) in
accordance with our implementation, as well as 256-bit ECDSA for
the relevant SSH and TLS modes; 3072-bit RSA was also used, in
line with the NIST recommendations. Note that 3072-bit DSS was
used for TLS, while OpenSSH imposes a 1024-bit limit for DSA;
OpenSSH aims to deprecate DSA, but we include it for comparison.
e protocols were measured using wall-clock time via the
time
UNIX utility and assisted by a shell script for initialisation, storing
the target IP address and port number, and result logging.
Message-specic times were measured for BTP and UTP using
the
<time.h>
library provided by OP-TEE. For these, the mean
wall-clock time was calculated from 100 measurements per mes-
sage. is includes client and server times to generate and verify
each message, and round-trip time to account for network latency
– comprising message generation, transmission, verication and
acknowledgement. For all experiments, the boards were connected
through an Ethernet hub with no other aached devices to minimise
network overhead. e boards were congured in a client-server
Figure 5: Test-bed Environment – HiKey Boards (circled)
Connected via Ethernet (blue) and UART (yellow).
architecture: one acting as
TAR E
and the other as
TAS D
. Both were
connected to a laptop via UART-to-USB for debugging purposes.
Figure 5 depicts our test-bed environment.
7.1 Results Discussion
e results are presented in Figure 6 (comparing BTP and UTP with
TLS and SSL), Table 4 (BTP and UTP message-specic times), and
Table 5 (total protocol round-trip time). As shown, our proposal
performs consistently at approximately
1.7
seconds to execute in
its entirety (round-trip) – yielding a
˜
4x overheard versus TLS with
ephemeral key Die-Hellman and RSA. is comprises the time to
open/close TCP/IP sockets, receive and parse messages from the
client/server, invoking the protocol TA functions and world context
switches. is is in addition to performing all of the cryptographic
algorithms including 2048-bit Die-Hellman key-pair generation,
HMAC and signature generation/verication (including for quotes).
Some overhead was expected due to the results from related
TPM and TEE work [
2
,
26
,
41
], and we aribute this to:
(1)
, the
dierence in cryptographic implementations between SSH and TLS,
both of which used OpenSSL, and the less widely-used LibTom-
Crypt provided by OP-TEE;
(2)
, the penalty imposed by two world
context switches per message and instantiation/destruction of the
TA;
(3)
, additional overhead of packing and unpacking message
ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy C. Shepherd, R. N. Akram and K. Markantonakis
Table 4: Mean Client, Server and Round-trip Wall-clock Times in Milliseconds (Std. Dev. in Brackets).
BTP UTP
Message Client (TAS D ) Server (TAR E ) Round-trip Client (UAS D ) Server (TAR E ) Round-trip
M1: TA/UAS D T ARE 302.7 (4.1) 21.5 (2.9) 347.1 (3.5) 305.9 (2.5) 20.8 (3.0) 350.2 (2.6)
M2: TAR E TA/UAS D 346.9 (6.6) 682.6 (6.9) 1192.0 (7.2) 350.3 (6.1) 689.4 (7.3) 1189.2 (10.3)
M3: TA/UAS D T ARE 61.6 (4.8) 39.7 (4.1) 117.2 (4.6) 39.2 (3.9) 26.7 (3.1) 73.8 (3.4)
Table 5: Mean Full Protocol Wall-clock Times in Milliseconds.
Proposal TLS SSH
BTP UTP DHE+RSA DHE+DSS ECDHE+ECDSA RSA DSA ECDSA
1692.3 (11.0) 1618.2 (9.6) 410.5 (3.9) 374.3 (4.1) 102.5 (2.2) 535.1 (13.6) 446.1 (11.8) 453.8 (15.0)
Figure 6: Protocol Performance Relative to TLS (DHE-RSA).
structures to adhere to GP-specic data structures in the Client [
15
]
and Internal APIs [18].
Further, our reference implementation could benet from optimi-
sations, which is usual with widely-used protocol implementations.
ere is an approximate 100ms overhead of the full protocol time
versus message totals. We aribute this specically to the initialisa-
tion and tear-down of the TA, i.e.
(1)
and
(2)
. Notably, a signicant
portion of the protocol time occurs where Die-Hellman opera-
tions are present. is occurs once on the client-side in message 1
and three times in message 2: twice server-side – once to compute
дRE
and the other to compute the shared secret – and another on
the client-side to compute its shared value. We refer back to
(3)
for
a potential explanation. While benchmarking GlobalPlatform prim-
itives and cryptographic suites is outside the scope of this paper,
we identied the above two as two major performance bolenecks.
7.2 Limitations
TEEs oer their own benets in trusted sensing, but avoiding TPMs
relinquishes extensive hardware tamper-resistance. TEEs do not
necessarily defend against sophisticated hardware aacks and side-
channel analyses, but are designed primarily to resist soware-
based vectors [
9
,
19
,
36
]. Consequently, we urge caution in using
our work where complex hardware aacks are a reasonable possi-
bility, e.g. military and government applications, where state-level
adversaries comprise part of a threat model. Secondly, GlobalPlat-
form recently dened the Sockets API for initiating TCP/IP connec-
tions from the trusted world; this provides an interesting avenue
of research, which, in the context of our protocol, would remove
a context switch between the secure and trusted world. Mature
implementations of the Sockets API are not widely available for
development boards; with OP-TEE, for example, GP Sockets API
remains in its infancy, and we aim to revisit this in the future upon
maturity. Finally, defending against availability aacks is currently
an open challenge in TEE research [
36
]. TEEs rely implicitly upon
co-operation between untrusted and trusted world, and a compro-
mised untrusted world that simply drops messages from the TEE
would prevent the protocol from running, thus raising availability
concerns; this issue, however, is inherent across TEEs.
8 CONCLUSION
In this work, we investigated the application of TEEs to trusted
sensing applications, and identied current challenges facing their
deployment, namely secure TEE intercommunication. We con-
tribute to this by presenting the development and evaluation of a
secure and trusted channel protocol that, unlike past work, pro-
vides one- or two-way remote aestation for trust assurance while
limiting the trust placed in intermediary components. e proposal
benets from enabling isolated execution, secure I/O, and commu-
nication of sensitive sensing data in a manner that defends against
a compromised REE. In Sections 4 and 5, both the requirements
and protocols were formalised, along with the operational chal-
lenges. In Section 6, we discussed protocol implementation using
two widely-used development boards using ARM TrustZone, before
evaluating its performance against untrusted world TLS and SSH in
Section 7. Both protocols were subjected to formal analysis using
Scyther, which found no aacks. We showed that our proposal
executes within in reasonable time (under 1.7 seconds on average)
and exhibits approximately 4x overhead versus TLS and SSH.
8.1 Future Research
In future work, we aim to investigate the following lines of research:
Mutually Trusted Channels for Remote Sensing Devices with TEEs ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy
Trusted multi-party protocol. Generalising our protocol to
create a trusted channel shared between multiple devices
in close proximity. is could be advantageous where
security-sensitive, multi-party communications are used
frequently, such as authentication schemes using sensor
data from a body area network (BAN), or a sensor-driven
home automation system.
Performance comparison with TPMs and other TEEs. We aim
to conduct a broad performance evaluation of our protocol
with TPM-based solutions and emerging TEEs, such as the
AMD Platform Security Processor and Trustonic Kinibi,
on a range of device types. Furthermore, we plan a perfor-
mance comparison with other cryptographic libraries.
Applicability of elliptic curves. Recent GP specications
include Elliptic Curve Cryptography (ECC), but this is only
an optional extra for compliance. Moreover, only ve NIST
curves are supported currently, an further curves are ex-
pected to be released in the future [
18
]. Once matured, we
aim to revisit our protocol to provide elliptic curve Die-
Hellman to reduce key sizes and computational overhead,
and evaluating the range of curves on oer.
ACKNOWLEDGMENTS
Carlton Shepherd is supported by the EPSRC and the British govern-
ment as part of the Centre for Doctoral Training in Cyber Security at
Royal Holloway, University of London (EP/K035584/1). e authors
would like to thank the reviewers for their insightful comments.
REFERENCES
[1]
William Aiello, Steven M Bellovin, Ma Blaze, Ran Canei, John Ioannidis,
Angelos D Keromytis, and Omer Reingold. 2004. Just fast keying: Key agreement
in a hostile internet. ACM Transactions on Information and System Security
(TISSEC) 7, 2 (2004), 242–273.
[2]
Raja Akram, Konstantinos Markantonakis, Keith Mayes, Pierre-Francois Bon-
nefoi, Damien Sauveron, and Serge Chaumee. 2016. An Ecient, Secure and
Trusted Channel Protocol for Avionics Wireless Networks. IEEE Computer Society.
[3]
Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes. 2012. A pri-
vacy preserving application acquisition protocol. In 2012 IEEE 11th International
Conference on Trust, Security and Privacy in Computing and Communications.
IEEE, 383–392.
[4]
ARM. 2015. ARM Cortex Programmer’s Guide for ARMv8-A. Version 1.0.
(2015). hp://infocenter.arm.com/help/topic/com.arm.doc.den0024a/DEN0024A
v8 architecture PG.pdf.
[5] Myo Min Aung and Yoon Seok Chang. 2014. Temperature management for the
quality assurance of a perishable food supply chain. Food Control 40 (2014),
198–207.
[6]
Ashar Aziz and Whiteld Die. 1994. Privacy and authentication for wireless
local area networks. IEEE Personal Communications 1, 1 (1994), 25–31.
[7]
Ernie Brickell and Jiangtao Li. 2011. Enhanced privacy ID from bilinear pairing
for hardware authentication and aestation. International Journal of Information
Privacy, Security and Integrity 2 1, 1 (2011), 3–33.
[8]
Capgemini. 2016. Wearable Devices and their Applicability in the Life Insurance
Industry. (2016). hps://www.capgemini.com/resource-le-access/resource/pdf/
wearable devices and their applicability in the life insurance industry.pdf.
[9]
Victor Costan and Srinivas Devadas. 2016. Intel SGX Explained. IACR Cryptology
ePrint Archive 2016 (2016), 86. hps://eprint.iacr.org/2016/086.pdf.
[10] Cas JF Cremers. 2008. e Scyther Tool: Verication, falsication, and analysis
of security protocols. In International Conference on Computer Aided Verication.
Springer, 414–418.
[11]
Tim Dierks and Eric Rescorla. 2008. RFC 5246 – Transport Layer Security (TLS)
Protocol Version 1.2. (August 2008). hps://tools.ietf.org/html/rfc5246.
[12]
Whiteld Die, Paul C Van Oorschot, and Michael J Wiener.1992. Authentication
and authenticated key exchanges. Designs, Codes and Cryptography 2, 2 (1992),
107–125.
[13]
Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, and N.
Asokan. 2007. Beyond Secure Channels. In Proceedings of the 2007 ACM Workshop
on Scalable Trusted Computing (STC ’07). ACM, New York, NY, USA, 30–40.
DOI:
hp://dx.doi.org/10.1145/1314354.1314363
[14]
Peter Gilbert, Landon P Cox, Jaeyeon Jung, and David Wetherall. 2010. Toward
trustworthy mobile sensing. In Proceedings of the Eleventh Workshop on Mobile
Computing Systems & Applications. ACM, 31–36.
[15] GlobalPlatform. 2014. TEE Protection Prole (Version 1.2). (2014).
[16]
GlobalPlatform. 2015. Card Remote Application Management over HT TP. (2015).
[17]
GlobalPlatform. 2016. GlobalPlatform TEE Client API Specication v1.0. (2016).
[18]
GlobalPlatform. 2016. GlobalPlatform TEE Internal API Specication v1.0. (2016).
[19]
GlobalPlatform. 2016. GlobalPlatform TEE System Architecture Specication
v1.1. (2016).
[20]
Ulrich Greveler, Benjamin Justus, and Dennis Loehr. 2011. Mutual remote at-
testation: enabling system cloning for TPM based platforms. In International
Workshop on Security and Trust Management. Springer, 193–206.
[21]
Ramakrishna Gummadi, Hari Balakrishnan, Petros Maniatis, and Sylvia Rat-
nasamy. 2009. Not-a-Bot: Improving Service Availability in the Face of Botnet
Aacks.. In NSDI, Vol. 9. 307–320.
[22]
Dae-Man Han and Jae-Hyun Lim. 2010. Smart home energy management system
using IEEE 802.15.4 and ZigBee. IEEE Transactions on Consumer Electronics 56, 3
(2010).
[23]
G
¨
unther Horn and Bart Preneel. 2000. Authentication and Payment in Future
Mobile Systems. Journal of Computer Security 8, 2,3 (Aug. 2000), 183–207. hp:
//dl.acm.org/citation.cfm?id=1297828.1297832
[24]
Xiaochun Li, Anastasios Golnas, and Fritz B Prinz. 2000. Shape deposition
manufacturing of smart metallic structures with embedded sensors. In SPIE’s 7th
Annual International Symposium on Smart Structures and Materials. International
Society for Optics and Photonics, 160–171.
[25]
Linaro. 2017. OP-TEE : Open Source Trusted Execution Environment. (2017).
hps://www.op-tee.org/.
[26]
He Liu, Stefan Saroiu, Alec Wolman, and Himanshu Raj. 2012. Soware abstrac-
tions for trusted sensors. In Proceedings of the 10th international conference on
Mobile systems, applications, and services. ACM, 365–378.
[27]
Konstantinos Markantonakis and Keith Mayes. 2005. A Secure Channel pro-
tocol for multi-application smart cards based on public key cryptography. In
Communications and Multimedia Security. Springer, 79–95.
[28]
Jonathan M McCune, Bryan J Parno, Adrian Perrig, Michael K Reiter, and Hiroshi
Isozaki. 2008. Flicker: An execution infrastructure for TCB minimization. In
ACM SIGOPS Operating Systems Review, Vol. 42. ACM, 315–328.
[29]
Esmaeil S Nadimi, Rasmus Nyholm Jørgensen, Victoria Blanes-Vidal, and Svend
Christensen. 2012. Monitoring and classifying animal behavior using ZigBee-
based mobile ad hoc wireless sensor networks and articial neural networks.
Computers and Electronics in Agriculture 82 (2012), 44–54.
[30]
NIST. 2016. Recommendations for Key Management. (2016). Special Publication
800-57 Part 1 Rev. 4.
[31]
Norbert Noury, ierry Herv
´
e, Vicent Rialle, Gilles Virone, Eric Mercier, Gilles
Morey, Aldo Moro, and ierry Porcheron. 2000. Monitoring behavior in home
using a smart fall sensor and position sensors. In Microtechnologies in Medicine
and Biology, 1st Annual International, Conference On. 2000. IEEE, 607–610.
[32]
Alexandros Pantelopoulos and Nikolaos G Bourbakis. 2010. A survey on wearable
sensor-based systems for health monitoring and prognosis. IEEE Transactions
on Systems, Man, and Cybernetics, Part C (Applications and Reviews) 40, 1 (2010),
1–12.
[33]
Himanshu Raj, Stefan Saroiu, Alec Wolman, Ronald Aigner, Jeremiah Cox, Paul
England, Chris Fenner, Kinshuman Kinshumann, Jork Loeser, Dennis Maoon,
Magnus Nystrom, David Robinson, Rob Spiger, Stefan om, and David Wooten.
2016. f TPM: A Soware-Only Implementation of a TPM Chip. In Proceedings
of the 25th USENIX Security Symposium (USENIX Security 16). USENIX Associa-
tion, Austin, TX, 841–856. hps://www.usenix.org/conference/usenixsecurity16/
technical-sessions/presentation/raj
[34]
Parisa Rashidi and Alex Mihailidis. 2013. A survey on ambient-assisted living
tools for older adults. IEEE journal of biomedical and health informatics 17, 3
(2013), 579–590.
[35]
E. Rescorla and N. Modadugu. 2012. RFC 6347 – Datagram Transport Layer
Security (DTLS) Version 1.2. (January 2012). hps://tools.ietf.org/html/rfc6347.
[36]
Mohamed Sabt, Mohammed Achemlal, and Abdelmadjid Bouabdallah. 2015.
Trusted execution environment: what it is, and what it is not. In Trustcom/Big-
DataSE/ISPA, 2015 IEEE, Vol. 1. IEEE, 57–64.
[37]
Samsung Electronics Co. 2015. An Overview of the Samsung KNOX Platform.
(November 2015). hp://www.samsung.com/global/business/business-images/
resource/white-paper/2013/06/Samsung KNOX whitepaper June- 0.pdf.
[38]
Nuno Santos, Himanshu Raj, Stefan Saroiu, and Alec Wolman. 2011. Trusted
language runtime (TLR): enabling trusted applications on smartphones. In Pro-
ceedings of the 12th Workshop on Mobile Computing Systems and Applications.
ACM, 21–26.
[39]
A. Sarela, I. Korhonen, J. Salminen, E. Koskinen, O. Kirkeby, and D. Walters.
2009. A home-based care model for outpatient cardiac rehabilitation based on
mobile technologies. In 2009 3rd International Conference on Pervasive Com-
puting Technologies for Healthcare. 1–8.
DOI:
hp://dx.doi.org/10.4108/ICST.
ARES ’17, Aug. 29–Sep. 01, 2017, Reggio Calabria, Italy C. Shepherd, R. N. Akram and K. Markantonakis
PERVASIVEHEALTH2009.5970
[40]
Stefan Saroiu and Alec Wolman.2010. I am a sensor, and I approve this message. In
Proceedings of the Eleventh Workshop on Mobile Computing Systems & Applications.
ACM, 37–42.
[41]
F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, M. Peinado, G. Mainar-Ruiz, and
M. Russinovich. VC3: Trustworthy Data Analytics in the Cloud Using SGX. In
2015 IEEE Symposium on Security and Privacy.
[42]
Carlton Shepherd, Raja N Akram, and Konstantinos Markantonakis. 2017. To-
wards Trusted Execution of Continuous Authentication Schemes. In Proceedings
of the 32nd ACM Symposium on Applied Computing. ACM.
[43]
Carlton Shepherd, Ghada Arfaoui, Iakovos Gurulian, Robert P Lee, Konstantinos
Markantonakis, Raja N Akram, Damien Saveron, and Emmanuel Conchon. 2016.
Secure and Trusted Execution: Past, Present, and Future - A Critical Review in
the Context of the Internet of ings and Cyber-Physical Systems. In 2016 IEEE
Trustcom/BigDataSE/ISPA. 168–177.
DOI:
hp://dx.doi.org/10.1109/TrustCom.
2016.0060
[44]
Weidong Shi, Jun Yang, Yifei Jiang, Feng Yang, and Yingen Xiong. 2011. Senguard:
Passive user identication on smartphones using multiple sensors. In Wireless
and Mobile Computing, Networking and Communications (WiMob), 2011 IEEE 7th
International Conference on. IEEE, 141–148.
[45]
William G Sire, John A MacDonald, Keith Mayes, and Konstantinos Markan-
tonakis. 2006. Design, installation and execution of a security agent for mobile
stations. In International Conference on Smart Card Research and Advanced Appli-
cations. Springer, 1–15.
[46]
Upkar Varshney. 2007. Pervasive healthcare and wireless health monitoring.
Mobile Networks and Applications 12, 2-3 (2007), 113–127.
[47]
Tatu Ylonen and Chris Lonvick. 2006. RFC 4253 – e Secure Shell (SSH) Trans-
port Layer Protocol. (January 2006). hps://tools.ietf.org/html/rfc4253.
[48]
Zongwei Zhou, Virgil D Gligor, James Newsome, and Jonathan M McCune. 2012.
Building veriable trusted path on commodity x86 computers. In Security and
Privacy (SP), 2012 IEEE Symposium on. IEEE, 616–630.
A APPENDIX
A.1 BTP Protocol Scyther Source
hashfunction h;
// A tt e st at i on R eq u es t
co ns t At t Re q : Fu n ct i on ;
// At t e st a ti o n re s po n se ( qu o te )
us e rt y pe Q uo t e ;
us e rt yp e S es s io nK e y ;
// Di ff ie - He l lm a n co m po ne n ts
usertype DH;
pr o to c ol b tp ( T AS D , T AR E )
{
ma c ro S c o ok i e = h ( g SD ,n s d , T AS D , T A R E ) ;
role TASD
{
fr es h ns d : No n ce ;
va r nr e : Non c e ;
fr es h qs d : Qu o te ;
va r qr e : Quo t e ;
va r K: Se ss i on K ey ;
fr e sh g SD : DH ;
va r gR E : DH ;
se n d_ 1 ( T AS D , T AR E , ns d , gS D , At tR e q , S co o k ie ) ;
re cv _2 ( TAR E , T ASD , nr e , g RE ,{ { TAR E ,T ASD , nr e ,ns d ,g SD , gRE } sk (
TA RE ) , { qr e , nre , nsd } s k ( T AR E ) } K , At tR e q ) ;
se n d_ 3 ( T AS D , T AR E , { { h ( TA SD , TA RE , g RE ,g SD ,n re , ns d ) } sk ( T A SD ) , { qs d ,
nre , ns d } sk ( T A SD ) } K , Sc o o ki e ) ;
cl a im _ a 1 ( TA S D , Al i v e ) ;
cl a im _ a 2 ( TA S D , Ni a g re e ) ;
cl a im _ a 3 ( TA S D , Ni s y nc h ) ;
cl ai m _a 4 (T AS D , Se cr et , qs d );
cl a im _ a 5 ( TA S D , R ea c h ab l e ) ;
cl a im _ a 6 ( TA S D , SK R , K) ;
}
role TARE
{
fr es h nr e : No n ce ;
va r ns d : Non c e ;
fr es h qr e : Qu o te ;
va r qs d : Quo t e ;
fr es h K: S es si o nK e y ;
fr e sh g RE : DH ;
va r gS D : DH ;
re cv _1 ( TA SD , TAR E , nsd , gSD , At tR eq , Sc oo ki e );
se nd _2 ( TA RE , TAS D , nre , gRE , {{ T ARE , TA SD , nr e ,n sd , gSD , g RE }s k(
TA RE ) , { qr e , nre , nsd } s k ( T AR E ) } K , At tR e q ) ;
re c v_ 3 ( T AS D , T AR E , { { h ( TA SD , TA RE , g RE , gSD , nr e , n sd ) } s k ( T AS D ) , {
qsd ,n re , ns d } s k ( TA S D ) }K , S co o k ie ) ;
cl a im _ b 1 ( TA R E , Al i v e ) ;
cl a im _ b 2 ( TA R E , Ni a g re e ) ;
cl a im _ b 3 ( TA R E , Ni s y nc h ) ;
cl ai m _b 4 (T AR E , Se cr et , qr e );
cl a im _ b 5 ( TA R E , R ea c h ab l e ) ;
cl a im _ b 6 ( TA R E , SK R , K) ;
}
}
A.2 UTP Protocol Scyther Source
pr o to c ol u tp ( U AS D , T AR E )
{
ma c ro S c o ok i e = h ( g SD ,n s d , U AS D , T A R E ) ;
role UASD
{
fr es h ns d : No n ce ;
va r nr e : Non c e ;
va r qr e : Quo t e ;
va r K: Se ss i on K ey ;
fr e sh g SD : DH ;
va r gR E : DH ;
se n d_ 1 ( U AS D , T AR E , ns d , gS D , At tR e q , S co o k ie ) ;
re cv _2 ( TAR E , U ASD , nr e , gRE ,{ { TAR E ,U ASD , nr e ,n sd ,g SD , gRE } sk (
TA RE ) , { qr e , nr e , ns d } sk ( T A RE ) } K) ;
se n d_ 3 ( U AS D , T AR E , { { h ( UA SD , TA RE , g RE ,g SD ,n re , ns d ) } sk ( U A SD ) } K ,
Sc oo k ie ) ;
cl a im _ a 1 ( UA S D , Al i v e ) ;
cl a im _ a 2 ( UA S D , Ni a g re e ) ;
cl a im _ a 3 ( UA S D , Ni s y nc h ) ;
cl a im _ a 5 ( UA S D , R ea c h ab l e ) ;
cl a im _ a 6 ( UA S D , SK R , K) ;
}
role TARE
{
fr es h nr e : No n ce ;
va r ns d : Non c e ;
fr es h qr e : Qu o te ;
fr es h K: S es si o nK e y ;
fr e sh g RE : DH ;
va r gS D : DH ;
re cv _1 ( UA SD , TAR E , nsd , gSD , At tR eq , Sc oo ki e );
se nd _2 ( TAR E , U ASD , nr e , g RE ,{ { TAR E ,U ASD , nr e ,ns d ,g SD , gRE } sk (
TA RE ) , {q re , n re , ns d } sk ( T A RE ) } K ) ;
re c v_ 3 ( U AS D , T AR E , { { h ( UA SD , TA RE , g RE , gSD , n re , n s d ) } sk ( U A SD ) } K ,
Sc oo k ie ) ;
cl a im _ b 1 ( TA R E , Al i v e ) ;
cl a im _ b 2 ( TA R E , Ni a g re e ) ;
cl a im _ b 3 ( TA R E , Ni s y nc h ) ;
cl ai m _b 4 (T AR E , Se cr et , qr e );
cl a im _ b 5 ( TA R E , R ea c h ab l e ) ;
cl a im _ b 6 ( TA R E , SK R , K) ;
}
}
... In this context, Panwar et al. [33] proposed a framework to ensure trustworthy data collection from IoT devices. Shepherd et al. [10] and Tsai et al. [26] also implemented mutual attestation in device communication, with the last one allowing group communication. Wang et al. [12] addressed the IoT devices attestation in an enterprise network. ...
... Secure communication between IoT devices and cloud servers and devices is a subject of study in several papers. Shepherd et al. [10], and Zhang et al. [35] addressed attestation and secure communication among devices, proposing protocols and techniques to ensure the integrity and confidentiality of the exchanged data. Solutions are presented to attest IoT devices mutually, and cloud [12], and to ensure the security of network archives [30] and data sharing [9,25]. ...
... Fig. 6 shows the number of papers in each category. Shepherd et al. [10] presented a protocol to allow secure TEE-to-TEE communication, performing mutual attestation between small-scale devices. Other works proposed a middleware to ensure data protection when deploying and processing IoT application data to the cloud [9,28,37]. ...
Conference Paper
Due to the Internet of Things (IoT) devices' processing and memory constraints, the processing and analysis of data acquired by such devices are generally performed in a fog or cloud environment, which offers more processing power. When delegating data processing to third parties, it is necessary to ensure their confidentiality and their owners' privacy, which can be achieved using a Trusted Execution Environment, such as Intel SGX. In this paper, we present a systematic mapping study to review recent works related to the use of Intel SGX architecture in IoT scenarios. We conduct the study by selecting 35 papers published between 2017 and 2020 and providing a comprehensive overview of the application scenarios and solutions when combining Intel SGX and the IoT paradigm.
... Despite the commercial success of TrustZone-A, it lacks attestation mechanisms, preventing relying parties from validating and trusting the state of TrustZone-A remotely. Nevertheless, researchers proposed several variants of one-way remote attestation protocols for Arm TrustZone [56,34], as well as mutual remote attestation [2,48], thus extending the built-in capabilities of the architecture for attestation. All of these propositions require the availability of hardware primitives on the system-on-chip (SoC): (i) a root of trust in the secure world, (ii) a secure source of randomness for cryptographic operations, and (iii) a secure boot mechanism, ensuring the sane state of a system upon boot. ...
... We describe the remote attestation mechanism of Shepherd et al. [48] as a study case. This solution establishes mutually trusted channels for bi-directional attestation, based on a trusted measurer (TM), which is a software component located in the trusted world and authenticated by the TEE's secure boot, to generate claims and issue evidence based on the OS and TA states. ...
Chapter
Full-text available
Attestation is a fundamental building block to establish trust over software systems. When used in conjunction with trusted execution environments, it guarantees the genuineness of the code executed against powerful attackers and threats, paving the way for adoption in several sensitive application domains. This paper reviews remote attestation principles and explains how the modern and industrially well-established trusted execution environments Intel SGX, Arm TrustZone and AMD SEV, as well as emerging RISC-V solutions, leverage these mechanisms.KeywordsTrusted execution environmentsAttestationIntel SGXArm TrustZoneAMD SEVRISC-V
... Remote attestation can be based on software, hardware or a combination of both [37], [38]. Recent work addresses the remote attestation mechanisms and protocols, including for IoT and edge devices [4], [39]- [44]. Intel SGX has built-in support for remote attestation [45]. ...
... We excluded the cause of better benchmark scheduling, since OP-TEE relies on the REE Linux scheduler. Finally, we report how the performance obtained here confirms similar results in literature [44], where an equally powerful TrustZone hardware (HiKey Arm Cortex-A53, at 1.2 GHz) is used to benchmark remote attestation protocols using TrustZone. ...
Preprint
Full-text available
WebAssembly (Wasm) is a novel low-level bytecode format that swiftly gained popularity for its efficiency, versatility and security, with near-native performance. Besides, trusted execution environments (TEEs) shield critical software assets against compromised infrastructures. However, TEEs do not guarantee the code to be trustworthy or that it was not tampered with. Instead, one relies on remote attestation to assess the code before execution. This paper describes WaTZ, which is (i) an efficient and secure runtime for trusted execution of Wasm code for Arm's TrustZone TEE, and (ii) a lightweight remote attestation system optimised for Wasm applications running in TrustZone, as it lacks built-in mechanisms for attestation. The remote attestation protocol is formally verified using a state-of-the-art analyser and model checker. Our extensive evaluation of Arm-based hardware uses synthetic and real-world benchmarks, illustrating typical tasks IoT devices achieve. WaTZ's execution speed is on par with Wasm runtimes in the normal world and reaches roughly half the speed of native execution, which is compensated by the additional security guarantees and the interoperability offered by Wasm. WaTZ is open-source and available on GitHub along with instructions to reproduce our experiments.
... Despite the commercial success of TrustZone-A, it lacks attestation mechanisms, preventing relying parties from validating and trusting the state of TrustZone-A remotely. Nevertheless, researchers proposed several variants of one-way remote attestation protocols for Arm TrustZone [56,34], as well as mutual remote attestation [2,48], thus extending the built-in capabilities of the architecture for attestation. All of these propositions require the availability of hardware primitives on the system-on-chip (SoC): (i) a root of trust in the secure world, (ii) a secure source of randomness for cryptographic operations, and (iii) a secure boot mechanism, ensuring the sane state of a system upon boot. ...
... We describe the remote attestation mechanism of Shepherd et al. [48] as a study case. This solution establishes mutually trusted channels for bi-directional attestation, based on a trusted measurer (TM), which is a software component located in the trusted world and authenticated by the TEE's secure boot, to generate claims and issue evidence based on the OS and TA states. ...
Preprint
Full-text available
Attestation is a fundamental building block to establish trust over software systems. When used in conjunction with trusted execution environments, it guarantees the genuineness of the code executed against powerful attackers and threats, paving the way for adoption in several sensitive application domains. This paper reviews remote attestation principles and explains how the modern and industrially well-established trusted execution environments Intel SGX, Arm TrustZone and AMD SEV, as well as emerging RISC-V solutions, leverage these mechanisms.
... Despite the commercial success of TrustZone, it lacks attestation mechanisms, preventing relying parties from validating and trusting the state of a TrustZone TEE remotely. Many protocols have been proposed for Arm TrustZone one-way remote attestation [47,28], as well as for mutual remote attestation [1,41], extending the capabilities of built-in hardware. These protocols require the availability of extra hardware with a root of trust in the secure world, a secure source of randomness for cryptographic operations, and a secure boot mechanism. ...
... In the following, we describe the remote attestation mechanism of Shepherd et al. [41] as a study case. This solution establishes mutually trusted channels for bi-directional attestation, based on a Trusted Measurer (TM), which is a software component located in the trusted world and authenticated by the TEE's secure boot, to generate evidences based on the OS and TA states (i.e., a set of claims). ...
Preprint
Full-text available
Attestation is a fundamental building block to establish trust over software systems. When used in conjunction with trusted execution environments, it guarantees that genuine code is executed even when facing strong attackers, paving the way for adoption in several sensitive application domains. This paper reviews existing remote attestation principles and compares the functionalities of current trusted execution environments as Intel SGX, Arm TrustZone and AMD SEV, as well as emerging RISC-V solutions.
... Researchers should also be aware of emerging mobile TEE applications in recent research. Examples include secure mobile deep learning [89], protecting cryptocurrency wallets [51], authenticating adverts from mobile advertising networks [93], preserving the integrity of system logs [141,80], novel remote attestation mechanisms [142,143], protecting healthcare data [139], and confidential image processing [32]. Such proposals could serve as future attack targets. ...
Article
Full-text available
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, full-disk and file-based encryption. Both advancements have dramatically complicated the use of conventional physical attacks, requiring the development of specialised attacks. In this survey, we consolidate recent developments in physical fault injections and side-channel attacks 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 set of criteria, identify several challenges and shortcomings, and suggest future directions of research.
... The Intel SGX SDK provides a function call-like abstraction for entering and exiting an enclave. Calls into the enclave are referred to as ECALLs (enclave entry call), and calls from the enclave to outside as OCALLs (outside call) [15,39,52]. ...
Preprint
Full-text available
Modern ransomware often generate and manage cryptographic keys on the victim's machine, giving defenders an opportunity to capture exposed keys and recover encrypted data without paying the ransom. However, recent work has raised the possibility of future enclave-enhanced malware that could avoid such mitigations using emerging support for hardware-enforced secure enclaves in commodity CPUs. Nonetheless, the practicality of such enclave-enhanced malware and its potential impact on all phases of the ransomware lifecyle remain unclear. Given the demonstrated capacity of ransomware authors to innovate in order to better extort their victims (e.g. through the adoption of untraceable virtual currencies and anonymity networks), it is important to better understand the risks involved and identify potential mitigations. As a basis for comprehensive security and performance analysis of enclave-enhanced ransomware, we present RansomClave, a family of ransomware that securely manage their cryptographic keys using an enclave. We use RansomClave to explore the implications of enclave-enhanced ransomware for the key generation, encryption and key release phases of the ransomware lifecycle, and to identify potential limitations and mitigations. We propose two plausible victim models and analyse, from an attacker's perspective, how RansomClave can protect cryptographic keys from each type of victim. We find that some existing mitigations are likely to be effective during the key generation and encryption phases, but that RansomClave enables new trustless key release schemes that could potentially improve attacker's profitability and, by extension, make enclaves an attractive target for future attackers.
Article
Wireless sensor networks (WSNs) are widely implemented in military, intelligent medical, intelligent transportation, space exploration and other fields. However, the authentication and communication of WSNs are carried out in the harsh external environment via a public channel, which is more vulnerable to various attacks than the traditional networks. Authentication is the key technology of security measures, but a common authentication scheme is not suitable for WSNs due to limitations of memory, computing and energy consumption. Therefore, designing a secure and efficient authentication scheme is essential in WSNs. In recent years, several studies proved that the dynamic authentication credential (DAC) is efficient for enhancing the security of authentication scheme. This paper designs a secure authentication scheme for WSNs based on DAC and Intel software guard extensions (SGX). Compared with other DAC authentication schemes, our scheme provides the confirmation action of DAC rotation, which can effectively prevent the asynchronous update problem caused by packet loss. In order to resist the privileged user attack and the authentication table leakage attack, we choose the SGX, which can protect the data in use, as the trusted execution environment in the gateway node, and we adopt SGX to store the master key for protecting the authentication table. Finally, the security of our authentication scheme is verified by BAN logic, the simulation tool AVISPA and informal security analysis. Through the consumption overhead analysis, the NS3 simulation result and detailed comparison with other recent schemes, we conclude that our scheme is practical and achieves better security with less overhead.
Conference Paper
Full-text available
The emergence of powerful, sensor-rich devices has spawned the development of continuous authentication (CA) schemes on commodity hardware, where user behaviour is compared to past experience to produce an authentication decision, with the aim of addressing challenges with traditional authentication schemes. Current CA proposals, however, have largely neglected adversaries present in real-world deployments, namely the ubiquity of malware and arbitrary software attacks. This has particular importance when a device cannot be trusted by a third-party, e.g. a corporation, that controls access to assets based on CA decisions. A software compromise, either on the platform or scheme implementation, may enable the modification of authentication scores, gain insights into user behavioural patterns, or gain unauthorised access to restricted assets. For the first time, we examine two standardised constructs that offer isolated and trusted execution -- Secure Elements (SEs) and Trusted Execution Environments (TEEs) -- even when an adversary has root-level privileges for protecting CA schemes while retaining deployability. Based on these, we implement the first system for evaluating TEE-based CA on a consumer mobile device using Intel SGX -- providing confidentiality, integrity and trust assurances over untrusted world implementations. We present an evaluation of TEE- and non-TEE performance using methods proposed in related work. The results indicate that trusted CA can be performed in an efficient fashion while removing the main platform from the TCB.
Article
Full-text available
Avionics networks rely on a set of stringent reliability and safety requirements. In existing deployments, these networks are based on a wired technology, which supports these requirements. Furthermore, this technology simplifies the security management of the network since certain assumptions can be safely made, including the inability of an attacker to access the network, and the fact that it is almost impossible for an attacker to introduce a node into the network. The proposal for Avionics Wireless Networks (AWNs), currently under development by multiple aerospace working groups, promises a reduction in the complexity of electrical wiring harness design and fabrication, a reduction in the total weight of wires, increased customization possibilities, and the capacity to monitor otherwise inaccessible moving or rotating aircraft parts such as landing gear and some sections of the aircraft engines. While providing these benefits, the AWN must ensure that it provides levels of safety that are at minimum equivalent to those offered by the wired equivalent. In this paper, we propose a secure and trusted channel protocol that satisfies the stated security and operational requirements for an AWN protocol. There are three main objectives for this protocol. First, the protocol has to provide the assurance that all communicating entities can trust each other, and can trust their internal (secure) software and hardware states. Second, the protocol has to establish a fair key exchange between all communicating entities so as to provide a secure channel. Finally, the third objective is to be efficient for both the initial start-up of the network and when resuming a session after a cold and/or warm restart of a node. The proposed protocol is implemented and performance measurements are presented based on this implementation. In addition, we formally verify our proposed protocol using CasperFDR.
Conference Paper
Full-text available
Trust has various instantiations: some rely on real-world relationships between entities, while others depend on robust hardware and software technologies to establish it post-deployment. In this paper, we focus on the latter, analyse their evolution in previous years, and their scope in the near future. The evolution of such technologies has involved diverse approaches; consequently, trust is understood and ascertained differently across heterogeneous systems and domains. We look at trusted hardware and software technologies from a security perspective – revisiting and analysing the Trusted Platform Module (TPM); Secure Elements (SE); hypervisors and virtualisation, including Java Card and Intel's Trusted eXecution Technology (TXT); Trusted Execution Environments (TEEs), such as GlobalPlatform TEE and Intel SGX; Host Card Emulation (HCE); and the Encrypted Execution Environment (E3). In our analysis, we focus on these technologies and their application to the emerging domains of the Internet of Things (IoT) and Cyber-Physical Systems (CPS).
Chapter
Smart card secure channel protocols based on public key cryptography are not widely utilised mainly due to processing overheads introduced in the underlying smart card microprocessors and the complexities introduced by the operation of a PKI infrastructure. In this paper we analyse the significance of public key secure channel protocols in multi-application smart cards. We believe that multi-application smart card technology (e.g. the GlobalPlatform smart card specification) should benefit more from the advantages of public key cryptography specifically for the initiation and maintenance of a secure channel. This paper introduces a public key based cryptographic protocol for secure entity authentication, data integrity and data confidentiality. The proposed secure channel protocol uses a combination of public key, secret key and the main idea behind the Diffie-Hellman key establishment protocols in order to achieve the desired goals.
Article
We present VC3, the first system that allows users to run distributed MapReduce computations in the cloud while keeping their code and data secret, and ensuring the correctness and completeness of their results. VC3 runs on unmodified Hadoop, but crucially keeps Hadoop, the operating system and the hyper visor out of the TCB, thus, confidentiality and integrity are preserved even if these large components are compromised. VC3 relies on SGX processors to isolate memory regions on individual computers, and to deploy new protocols that secure distributed MapReduce computations. VC3 optionally enforces region self-integrity invariants for all MapReduce code running within isolated regions, to prevent attacks due to unsafe memory reads and writes. Experimental results on common benchmarks show that VC3 performs well compared with unprotected Hadoop: VC3's average runtime overhead is negligible for its base security guarantees, 4.5% with write integrity and 8% with read/write integrity.
Article
We present Flicker, an infrastructure for executing security-sensitive code in complete isolation while trusting as few as 250 lines of additional code. Flicker can also provide meaningful, fine-grained attestation of the code executed (as well as its inputs and outputs) to a remote party. Flicker guarantees these properties even if the BIOS, OS and DMA-enabled devices are all malicious. Flicker leverages new commodity processors from AMD and Intel and does not require a new OS or VMM. We demonstrate a full implementation of Flicker on an AMD platform and describe our development environment for simplifying the construction of Flicker-enabled code.