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

Abstract

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.

Full text

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.
X→YMessage 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) ;
}
}