Secure Edge Computing with ARM TrustZone

Robert Pettersen, Håvard D. Johansen and Dag Johansen

University of Tromsø, The Arctic University of Norway, Tromsø, Norway

Keywords:

IoT, ARM TrustZone, Intel SGX, Secure Enclave, Trusted Execution, Edge Computing, Cloud Computing.

Abstract:

When connecting Internet of Things (IOT) devices and other Internet edge computers to remote back-end

hybrid or pure public cloud solutions, providing a high level of security and privacy is critical. With billions

of such additional client devices rapidly being deployed and connected, numerous new security vulnerabilities

and attack vectors are emerging. This paper address this concern with security as a ﬁrst-order design principle:

how to architect a secure and integrated middleware system spanning from IOT edge devices to back-end cloud

servers. We report on our initial experiences from building a prototype utilizing secure enclave technologies

on IOT devices. Our initial results indicate that isolating execution on ARM TrustZone processors comes at a

relatively negligible cost.

1 INTRODUCTION

Internet application and service components are cur-

rently being relocated from central cloud backend ser-

vices to less resource-rich IOT and mobile devices at

the edges of the Internet. Such edge computing is a

natural evolutionary step in distributed systems archi-

tectures, and is at the heart of the “4th Industrial Rev-

olution” currently unfolding (Schwab, 2016). We are

about to witness a paradigm shift where computer-

science innovations have the potential to disrupt so-

ciety at a scale never witnessed before by tapping into

the wide variety of data generated by edge devices.

Because IOT and mobile devices are designed to

operate in physical proximity to end-users, they give

hostile entities ample opportunities to tinker with the

hardware and software stacks. Such malicious mod-

iﬁcation to the edge devices can lead to unspeciﬁed

system behavior and new attack vectors. This inher-

ent weakness of edge computing is particularly con-

cerning for applications that monitor and control IOT

devices in modern buildings and critical infrastruc-

ture (e.g., power grid), or applications that collect and

analyze sensitive personal information from wearable

or ambient lifelogging devices, like surveillance cam-

eras or smart watches (Johansen et al., 2015a).

In response to the rising need of modern

distributed-system architecture to securely execute

software remotely on untrusted hardware, several

hardware vendors have devised new on-chip security

measures in their products. Most notably are perhaps

the Intel Software Guard Extensions (SGX) (Anati

et al., 2013) and ARM TrustZone technologies (ARM

Limited, 2009; Ngabonziza et al., 2016; Shuja et al.,

2016). Although their underlying hardware design,

features, and interfaces differ substantially, both SGX

and TrustZone essentially provide the same key con-

cepts of hardware isolated execution domains, which

we commonly refer to as enclaves, and the ability to

bootstrap attested software stacks into those enclaves.

These features mitigate need to include the Operating

System (OS) and any hypervisor in the Trusted Com-

puting Base (TCB): a previous major security problem

for both cloud and edge-computing systems. Note

also that SGX and TrustZone only targets enforcement

of conﬁdentiality and integrity policies, and not avail-

ability or liveness. The host OS can still halt execution

of protected software, delay calls when they cross ex-

ecution domains (or into the OS kernel), and ignore

incoming network packets.

This paper reports on our initial experiences in-

corporating ARM TrustZone technology into Diggi:

a generic IOT/mobile/cloud platform that enables IOT

devices, mobile phones, smart-home computers, per-

sonal computers, hybrid-cloud solutions, and propri-

etary cloud solutions from different vendors to seam-

lessly connect and integrate in a privacy-preserving

and secure manner. Application programmers would

normally need to decide at design time where data

should be cached and stored, and where computations

should be executed. However, Diggi attempt to bet-

Diggi translates to the word “thing” in the indigenous

arctic North-Sami language.

102

Pettersen, R., Johansen, H. and Johansen, D.

Secure Edge Computing with ARM TrustZone.

DOI: 10.5220/0006308601020109

In Proceedings of the 2nd International Conference on Internet of Things, Big Data and Secur ity (IoTBDS 2017), pages 102-109

ISBN: 978-989-758-245-5

ter utilize resources at edge-nodes by making those

decisions just-in-time by shipping functional meta-

code components between computational devices at

run-time. Understanding how Diggi can best utilize

existing hardware isolation mechanisms, like ARM

TrustZones, for secure remote execution of meta-code

components, is essential for Diggi and therefore the

main topic of this paper.

The rest of the paper is organized as follows. Sec-

tion 2 outlines the broader architecture and motiva-

tion for using secure enclave technologies as a fun-

damental building block in Diggi. Section 3 details

Diggi core design related to ARM TrustZone. Sec-

tion 4 reports on initial, general performance results,

while Section 5 presents related work. Finally, Sec-

tion 6 concludes.

2 Diggi OVERVIEW

Diggi is a middleware system for secure federation of

IOT and other edge devices with backend enterprise

and public cloud services. Central concepts to enable

this includes meta-code and secure enclave technolo-

gies.

2.1 Architecture

We are developing Diggi towards an open-source in-

frastructure seamlessly integrating IOT/mobile/cloud

systems utilizing secure enclave technologies. Code

and data within an enclave are protected by the hard-

ware from disclosure or modiﬁcation from any thread

executing on the outside: providing strict conﬁden-

tiality and integrity guarantees. Both ARM TrustZone

and Intel SGX enable such protections through the

use of on-chip features that sets up isolated execution

domains into which the application programmer can

load his code and data. Execution threads external to

an enclave cannot read or tamper with that enclave’s

execution or data. Data may be taken out of an en-

clave and stored externally, but typically only in en-

crypted form.

We are currently using Diggi as a middleware glue

between secure enclaves residing in this very hetero-

geneous network of IOT devices, personal computers,

enterprise clouds, and public clouds. ARM TrustZone

is developed for lightly equipped devices, while In-

tel SGX can span the broader spectrum of more re-

source rich computers. Hence, an integration of and

combination of both these state-of art secure tech-

nologies from ARM and Intel ensure that the same

security-sensitive applications can be deployed in a

very heterogeneous distributed system with the same

security property guarantees. Secure communication

channels are established between the different Diggi

nodes.

Edge Device

TrustZone

Enterprise Cloud

TrustZone / SGX

Public Cloud

SGX

Diggi

Runtime

Figure 1: Secure integration of edge devices with enterprise

and public clouds using trusted hardware.

The Diggi architecture consists of three vertically

stacked layers, as shown in Figure 1. The top-most

layer contains the edge client devices and is primarily

based on ARM TrustZone. This can be, for instance,

an IOT sensor device or a cellular phone. Intel SGX

already runs in, for instance, notebooks and can be a

client device as well. The middle layer is a client fed-

erating layer typically in the same administrative do-

main as the client devices it connects to. As such, this

can be a private SGX server or an enterprise cloud. By

connecting to the third layer containing SGX nodes,

the public clouds, a hybrid cloud solution with one

cloud provider can be conﬁgured. Alternatively, a

multi-cloud deployment is possible by connecting to

two different public cloud providers. We have pre-

viously built Balava (Nordal et al., 2011), a three-

layer multi-cloud storage system based on meta-code

spanning such a deployment, but this was prior to the

emergence of Intel SGX and ARM TrustZone. How-

ever, Diggi also builds on the concept of meta-code,

which we will discuss next.

2.2 Meta-code

The meta-code concept (Hurley and Johansen, 2014)

is a convenient structuring mechanism for supporting

autonomic and distributed computing in this broad

domain. The idea is to attach ﬁne level, autonomic

meta-code processes to any data element being ac-

cessed. The meta-code is distributed, installed, and

revoked as mobile-code components that execute ei-

ther periodically or on data access. This way, user-

Secure Edge Computing with ARM TrustZone

103

Table 1: Example meta-code policies applicable to common

data operations.

Operation Meta-code

open() Download an up-to-date remote

access-control list. Decrypt object

into enclave memory only if autho-

rized by access-control list.

read() De-identify or remove any personal

identiﬁers contained in the returned

data. Log data access patterns in a

local ledger.

ﬂush() Send recorded data access patterns

from a local ledger to a remote audit

server.

write() Replicate encrypted data to multi-

ple remote cloud hosted sites.

centric functionality can be installed and executed on-

demand when, for instance, data from a remote IOT

sensor is being read. This can implement upstream

evaluation and ﬁltering physically close to a sen-

sor (Carzaniga et al., 2001), highly personalized ac-

cess control, auditing, and privacy policies (Johansen

et al., 2015b; Brasser et al., 2016), or personalized

storage systems spanning IOT/mobile/clouds (Nordal

et al., 2011). Examples of meta-code for various ob-

ject operations can be found in Table 1.

Meta-code gives users the powerful ability to cus-

tomize policies for their data, and enforces those poli-

cies without needing to trust applications or their pro-

grammers. For example, when attached to a ﬁle, the

following meta-code grants access to that ﬁle for only

24 hours after the ﬁle was initially created:

if (time() - lstat(path).st_ctime > 86400){

throw OSError(EACCES);

}

A compelling and promising applicability of

meta-code in the IOT/mobile/cloud domain is for the

problem of software upgrading. Hundreds of IOT de-

vices might soon be the rule in a modern smart home,

and proper safeguards must be put in place to pre-

vent updating IOT interfaces from becoming security

holes themselves. Our conjecture is that we can take

advantage of secure enclave technologies running on

special hardware to remedy the situation. Potentially

this protects an application and its secrets from a full

compromise of a remote system as well as from a ma-

licious insider. Deﬁned secure regions of code and

data will maintain conﬁdentiality even when an at-

tacker has physical control of the node and can con-

duct direct attacks on memory. The Diggi run-time

is designed to allow meta-code and sensitive data to

be hosted and run remotely within memory protected

from application running on the same machine, in-

cluding the operating system itself.

We are currently building Diggi for two secure en-

clave platforms to be integrated into one. One version

is for resource-rich cloud servers (Gjerdrum et al.,

2016) based on the Intel SGX processor. The other

version is for IOT devices based on the ARM Trust-

Zone.

2.3 ARM TrustZone Hardware Layer

The ARM TrustZone technology is a hardware se-

curity architecture that can be incorporated into

ARMv7-A, ARMv8-A and ARMv8-M System on

a Chips (SOCs) (ARM Limited, 2009; Ngabonziza

et al., 2016; Shuja et al., 2016). Its main purpose

is to enable devices to counter many of the threats

that have been difﬁcult to address earlier, such as at-

tacks from the OS running on the device. TrustZone

technology provides the infrastructural foundation for

the SOC designer to compose a system, choosing be-

tween a range of available component, to fulﬁll spe-

ciﬁc security requirements. The primary security ob-

jective of the architecture is enabling the construction

of a programmable environment that allows the conﬁ-

dentiality and integrity of almost any asset to be pro-

tected from speciﬁc attacks. A platform with these

characteristics can be used to build a wide range of

cost-effective security solutions, compared to tradi-

tional methods where SOC designers utilized propri-

etary methods.

The TrustZone technology deﬁnes two distinct

and isolated execution contexts, partitioning all the

SOC hardware and software resources into two

worlds: the Normal world

and the Secure world.

The Normal world hosts the traditional non-trusted OS

with its associated processes and subsystems, while

the Secure world run trusted software components

that enforce conﬁdentiality and integrity constraints

in the normal world.

The ARM AMBA3 AXI bus is the primary hard-

ware component enforcing the isolation policy of a

TrustZone enabled SOC. This bus matrix extends the

32 bit control signal for each read and write chan-

nel with an extra Non-Secure (NS) bit dictating what

world each transaction belongs to. By ensuring that

all transactions from bus masters in the Normal world

have their NS bit set high, insecure information ﬂow

from a slave in the secure world can be prevented. In

addition to the AMBA3 AXI bus, each physical pro-

cessor core can securely multiplex instructions from

concurrent processes of both world, exposed to the

system as two distinct virtual cores: one normal and

one secure. This design saves both silicon area and

power compared to having a separate core for each

The Normal world is sometimes refereed to as the Non-

Secure (NS) world.

IoTBDS 2017 - 2nd International Conference on Internet of Things, Big Data and Security

104

world. In a multiprocessor system, cores may operate

and transition between worlds independently of one

another using hardware interrupts. The mechanism to

context switch between processes running in different

world is known as monitor mode. The virtual core’s

identity dictates the NS bit used for bus operations, set

in the Secure Conﬁguration Register (SCR), and thus

also dictates which bus slaves can be accessed. Also,

the hardware provides two virtual Memory Manage-

ment Units (MMUs) extended with NS bits to parti-

tion memory between the two worlds. The security of

other system components, like tightly coupled mem-

ories and the accelerator coherency port, also depend

on NS bit to control information ﬂow.

In addition to the main AXI bus, ARM systems

may include a lower APB bus, which most periph-

erals will use. To ensure compatibility with existing

devices, the APB bus does not carry the NS bit. It

is the AXI-to-APB Bridge’s responsibility to manage

the NS bit translation to and from connected devices

using a special per device signal located on the bus.

The TrustZone framework includes secure boot

facilities from a trusted boot loader located in the on-

SOC Read-Only Memory (ROM). This ROM is the

only system component that cannot be easily changed

by an attacker, and is responsible for securely boot-

strapping remaining software component into the on-

SOC memory.

2.4 Trusted Execution Environments

Because the TrustZone technology only distinguish

two protection domains at the hardware level, con-

current mutually distrusting applications must be fur-

ther isolated in software. Such Trusted Execution

Evironments (TEEs) can range from simple libraries,

to a full operating system kernel. In the latter case,

the TrustZone system will be running two concurrent

operating-system kernels: one in the Normal world

and one in the Secure world. By using the MMU’s

ability to partition Secure world memory, the Secure

world kernel can run concurrent and mutually dis-

trusting application in separate user-space sandboxes.

While the ARM TrustZone architecture speciﬁes

mechanisms to handle secure interrupts, memory and

peripherals, it is up to the SOC designer to implement

these. Vendors can choose to implement all the mech-

anisms, or only a subset of them, to provide the secu-

rity mechanisms needed for devices that will utilize

the speciﬁc SOC. In our case, Diggi aims to follow the

GlobalPlatform Trusted Execution Evironment (TEE)

client API speciﬁcation 1.0 (Global Platform, 2011).

3 DESIGN AND

IMPLEMENTATION

Diggi aims to utilize secure enclave technology to

provide secure communication, provisioning and ex-

ecution between the cloud, mobile, and IOT devices.

We start by implementing the Diggi architecture run-

ning on IOT devices with TrustZone technology. The

Raspberry Pi 3 model b

embedded development

board was chosen as a starting point for our imple-

mentation. The Raspberry Pi has a SOC which only

provides TrustZone exception states, the mechanisms

and hardware required to implement secure memory

and peripherals are not available.

TrustZone exception states enable the Raspberry

Pi to execute code both in the Normal and Secure

worlds. Allocating memory, and accessing storage

and network interfaces cannot be performed in the Se-

cure world and need to be emulated. Requests for

memory and access to peripherals are routed to a pro-

cess running in the Normal world called the TEE Sup-

plicant. The supplicant process will perform the re-

quest in the Normal world on behalf of the Secure

world, and will not offer the security and isolation that

the TrustZone architecture speciﬁes.

The Raspberry Pi runs Linaro’s

OP-TEE OS

the Secure world, and a 64 bit Linux kernel version

4 running in the Normal world with a TEE driver to

facilitate communication between worlds. The Se-

cure world OS is accessible from the Normal world

OS using the GlobalPlatform TEE client API speciﬁca-

tion 1.0 (Global Platform, 2011), which is also used

to trigger execution of applications within the Secure

world.

Our previous work with dynamic resolution of

code (Valvåg et al., 2016) was used to create mech-

anisms for dynamically resolving trusted applica-

tion dependencies in the Secure world OS. Each

trusted application is identiﬁed by a 128 bit Univer-

sally Unique Identiﬁer (UUID), which is used in the

run-time dependency resolution process. The pro-

cess starts by installing an application on the device

through the normal appstore associated with the OS

running in the Normal world (se Figure 2). The app-

store can be Google Play, Apple’s iTunes store, the

Ubuntu’s apt-get, or a similar well established chan-

nel for distribution of native applications.

When the application needs to execute in the Se-

cure world, a request is sent through the TEE driver

to the Secure world OS. The request will contain the

http://www.raspberrypi.org

http://www.linaro.org

https://github.com/OP-TEE/optee_os

Secure Edge Computing with ARM TrustZone

105

Device

Rich OS

TEE

Services

Trusted Services

Native

Apps

Rich Cloud Services

Rich

Cloud

Services

Native App Store

Secure Cloud Services

Cloud Hardware

Trusted Cloud OS

App

Store

Meta

Code

ARM TrustZone enabled chipset

Normal World

Secure World

Trusted

Apps

Diggi Runtime

Trusted

Cloud

Services

Meta Code

Store

Cloud Hardware

Rich Cloud OS

Figure 2: Outline of application provisioning for IOT devices in Diggi. The Normal world part of the application is distributed

from a cloud-hosted appstore to the Normal world OS. When the application requests trusted execution or access meta-code

protected data, the Secure world will request the secure part of the application through the secure appstore and do validation

of the code before installing it and allowing requests between worlds.

UUID of the trusted application. If the trusted appli-

cation is not installed on the device, which will be the

case at the ﬁrst invocation, the Secure world OS will

utilize Diggi resolution service to locate the trusted

application. Diggi will establish a connection to a se-

cure appstore and retrieve the application associated

with the UUID. The application will be validated be-

fore it is installed and loaded in the Secure world. Af-

ter the application has been successfully installed, the

request from the native application will be delivered

for processing. Figure 2 illustrates this architecture.

4 PERFORMANCE EVALUATION

For our performance evaluation, we chose the Rasp-

berry Pi 3 model b embedded development board to

host Diggi. The Raspberry Pi has 1 GB RAM and

a 1.2 GHz quad-core ARM Corex-A53 CPU and pro-

vides TrustZone exception states which enable execu-

tion in the Secure world. The mechanisms and hard-

ware required to implement secure memory and pe-

ripherals are not available. Our experiments in this

paper are therefore focused on transitions between the

Normal and the Secure world, and execution in the

Secure world.

4.1 World-switch Overhead

In our ﬁrst experiment, we measure the end-to-end

overhead of switching from executing in the Normal

world to executing in the Secure world inside a TEE

hosted application. Such world switches are neces-

sary to achieve secure execution of code, and knowl-

edge about their performance characteristics are im-

0 20 40

80 100

NW IPC

SW noop

33.01

8.54

81.96

Time (µsec)

Figure 3: Mean end-to-end execution times for a noop Se-

cure world invocation executed 1000 times, compared to

traditional IPC between Normal world processes through

named pipes.

portant when deciding how an application or system

is best partitioned between the worlds.

Conceptually, communication between applica-

tions in the Normal world and the Secure world can be

compared to Interprocess Communication (IPC) be-

tween two processes. We measure the end-to-end de-

lay for IPC communication between two processes in

the Normal world to get a baseline communication

cost between processes.

All measurements have been executed 1000 times,

and we present the mean. Figure 3 shows the mea-

sured mean execution time for our noop Secure world

invocation. The observed mean end-to-end time is

81.96 µs. Included in this is two world changes, one

from the Normal world to the Secure world, and one

from the Secure world to the Normal world. The ob-

served mean time for a single world change is 8.54 µs.

For comparison, the mean end-to-end time for IPC be-

tween two Normal world processes is 33.01 µs.

The time to switch worlds only amounts to

17.08 µs of the total time for the noop invocation.

By instrumenting the code path from the start of the

invocation to the end, a breakdown of where time

IoTBDS 2017 - 2nd International Conference on Internet of Things, Big Data and Security

106

0 20 40

80 100

SW noop

Time (µsec)

Syscall WS SW Upcall SW Return

Figure 4: Breakdown of the Secure world noop invocation.

was spent was produced, as seen in Figure 4. Here,

48.77 µs of the total time is spent in the Secure world

OS and switching to the Secure world user level.

4.2 Execution Overhead

The second experiment compares execution times in

the Secure world to the Normal world. Since the Se-

cure world is expected to perform cryptographic op-

erations we chose to execute a series of cryptographic

hashing operations to evaluate the execution perfor-

mance of the Secure world.

Linaro’s OP-TEE OS has adapted LibTomCrypt

to provide cryptographic operations through the

GlobalPlatform Application Programming Interfaces

(APIs) for applications in the Secure world. The same

library was used when executing the cryptographic

operations in the Normal world.

SHA-256 was used to hash a variable sized buffer

1000 times, both in the Secure world and the Normal

world. We have omitted the time needed for world

switches and copying of data, since the Raspberry Pi

does not support secure memory. The mean execution

times is presented in Figure 5. The results show no

negative impact of hashing in the Secure world.

The ARM TrustZone architecture includes efﬁcient

hardware cryptographic engines that can accelerate

security and cryptographic operations. Unfortunately,

the Raspberry Pi does not include this hardware and

the effects from this hardware cannot be seen in the

graphs.

5 RELATED WORK

Mechanisms for providing a trusted execution envi-

ronment is not new. Popular banking services have al-

ready utilized the Secure Element (SE) in SIM cards to

provide secure authentication for users of their bank

services. The Apple A7 (and later) SOC utilizes sepa-

rate ARM processor cores to provide a trusted execu-

tion environment to store and authenticate user ﬁnger-

prints both for the device and supported applications.

https://github.com/libtom/libtomcrypt

124 8

1,000

2,000

3,000

4,000

Size of buffer (Kb)

Time (µsec)

Secure world

Normal world

Figure 5: Mean execution times for SHA-256 hashing a

variable sized buffer in the Secure world, compared to hash-

ing in the Normal world.

Smartcards have frequently been deployed in sys-

tems that need a high-degree of security assurance.

Such cards, however, have limited processing, band-

width, and memory capacity; and cannot directly in-

teract with the user to, for instance, obtain personal

identiﬁcation numbers. As such, smartcards depend

on untrusted OS logic for some of their operations.

Trusted Platform Modules (TPMs) (TCG Published,

2011) are chips typically permanently embedded on

a system’s mainboard, providing similar features as

smartcards. TPMs were initially speciﬁed by the

Trusted Computing Group (TCG), and now approved

as the standardized speciﬁcation ISO/IEC 11889.

In the Trusted Language Runtime (TLR) (Santos

et al., 2014), programmers can specify which of the

classes of a .NET program, or trustlets, that should run

within the secure world, and how they are to interface

with the normal world. Although the primitives de-

scribed in this work is highly relevant for Diggi, it

is unclear how the proposed trustlets mechanism, and

their trustboxes execution environments, can support

our more dynamic and mobile meta-code concept.

The PrivateZone framework (Jang et al., 2016) ad-

dress the limited ability of the TrustZone hardware to

host mutually distrusting applications within a single

TEE OS. For this, PrivateZone sets up private execu-

tion environments in the normal word using the se-

cure world monitoring mode, controlled by a normal

world kernel driver, to switch between the different

execution contexts. The approach requires some mod-

iﬁcation to the underlying normal world OS that may

prevent practical deployment.

Conceptually, sandboxing (Goldberg et al., 1996)

relates to our work by providing a security mecha-

nism for separating running programs. Diggi sep-

arates software execution in a trusted Secure world

and an untrusted Normal world. Similar structuring

Secure Edge Computing with ARM TrustZone

107

can be done using sandboxes with code running in-

side or outside a sandbox. A sandbox, however, con-

trols the resources an application can use securing the

local computer; a secure enclave though secures the

application from security violations originating from

software at the computer.

TaintDroid (Enck et al., 2014) extends Google’s

Android kernel to track third-party binary applica-

tions dynamically at run-time by labeling data from

possible sensitive sources as tainted during execu-

tion. The taint is encoded using a single bit on certain

memory regions, similarly how the TrustZone hard-

ware use the NS-bit on memory and buses to cre-

ate two execution domains. Unlike the TrustZone

technology, TaintDroid leverages facilities in the Java

virtual machine instead of the hardware level to la-

bel data as either tainted or not. The taint follows

the data as it propagates through program variables,

inter-process communication, and ﬁle IO, and enables

TaintDroid to monitor and control that sensitive data

is not transmitted out of the phone. Because taint is

encoded as a single bit on certain memory regions,

isolating multiple execution domains would require

additional mechanisms, as with ARM TrustZone. Au-

tomated partitioning of Android applications to run

on TrustZone hardware has also been suggested (Ru-

binov et al., 2016).

In the security-typed Java derived programming

language JiF (Sabelfeld and Myers, 2003), program-

mers can express rich information-ﬂow control poli-

cies as labels attached to variables at the source code

level to express restriction on information ﬂow within

the program. This include setting up multiple exe-

cution privilege levels and policies on how data can

ﬂow between those. The compiler analyzes the code

to make sure that information ﬂows in accordance

with those policies, and admits only complying pro-

grams. Although expressive, these language based

methods cannot secure legacy applications and re-

quire the compiler to be part of the TCB. Some ker-

nels, like Asbestos (Efstathopoulos et al., 2005), use

labels expressed in terms of tags combined with ca-

pabilities to enforce information-ﬂow security poli-

cies between hosted, but are currently only available

in prototype form.

Secure Data Capsules (Maniatis et al., 2011) are

data objects associated with a policy tag that deﬁnes

the provenance and a usage policy, similarly to our

meta code. These policy tags are cryptographically

bound to the associated data, and derived data are

tagged with a derived policy tag. Untrusted applica-

tions can operate on tagged objects only while inside a

secure execution environment that enforces and prop-

agates policy tags.

6 CONCLUSION

We cannot naively assume that computers running

IOT software are totally trustworthy. Despite use

of state-of-the-art authentication and access control

mechanisms from distributed systems, we might need

to minimize what components to trust and even regard

the OS and co-located applications on a single IOT de-

vice with suspicion and care.

Integrating IOT devices with other client comput-

ers or remote cloud servers opens the overall system

for unwanted security attack vectors that should be

avoided. This might include that IOT devices have

USB ports probably not needed for operation of the

device, devices are out of sight for users and might

be physically tampered with, and functionality not re-

quired for the current deployment is available via an

API layer. The list is, unfortunately, very long and

growing.

We are investigating how to properly secure such

an IOT infrastructure and have adopted a rigorous

security-by-design strategy. Our current IOT proto-

type is therefore built around secure hardware from

scratch with a trusted module known as secure en-

clave technology at its foundation. We use Intel SGX

for the resource-rich cloud servers, and we use ARM

TrustZone for IOT devices to enforce security isola-

tion on even a layer below the operating system. This

reduces the trusted computing platform to a mini-

mum; to the vendors Intel and ARM that in any case

must be trusted if you want to algorithmically auto-

mate any task of interest.

Securing a heterogeneous distributed system with

IOT devices at the edges and cloud servers at the core

is a daunting task. Our humble attitude includes ac-

cepting that secure hardware is just a piece in the

holistic security puzzle. It is fundamentally impor-

tant though, and will gradually be complemented with

our on-going work on utilizing secure and encrypted

storage, in our work on making upgrades to IOT de-

vices secure during the lifetime of the device through

meta-code, and how to protect data integrity while in

transit to and from the IOT devices. Each such ap-

proach builds greater security assurance in the overall

infrastructure, and we are conﬁdent that secure en-

clave technologies like reported in this paper will play

a pivotal role.

ACKNOWLEDGMENTS

This work was supported in part by the Norwegian

Research Council project numbers 231687/F20, and

the Corpore Sano Centre at UiT, Norway. We would

IoTBDS 2017 - 2nd International Conference on Internet of Things, Big Data and Security

108

like to thank the anonymous reviewers for their useful

insights and comments.

REFERENCES

Anati, I., Gueron, S., Johnson, S., and Scarlata, V. (2013).

Innovative technology for cpu based attestation and

sealing. In Proceedings of the 2nd international work-

shop on hardware and architectural support for secu-

rity and privacy, volume 13.

ARM Limited (2009). ARM security technology: Building

a secure system using TrustZone technology. White

paper PRD29-GENC-009492C, ARM Limited.

Brasser, F., Kim, D., Liebchen, C., Ganapathy, V., Iftode,

L., and Sadeghi, A.-R. (2016). Regulating arm trust-

zone devices in restricted spaces. In Proceedings of

the 14th Annual International Conference on Mobile

Systems, Applications, and Services, pages 413–425.

ACM.

Carzaniga, A., Rosenblum, D. S., and Wolf, A. L. (2001).

Design and evaluation of a wide-area event notiﬁca-

tion service. ACM Transactions on Computer Systems

(TOCS), 19(3):332–383.

Efstathopoulos, P., Krohn, M., VanDeBogart, S., Frey, C.,

Ziegler, D., Kohler, E., Mazières, D., Kaashoek, F.,

and Morris, R. (2005). Labels and event processes in

the asbestos operating system. In Proceedings of the

20th ACM Symposium on Operating Systems Princi-

ples, SOSP ’05, pages 17–30, New York, NY, USA.

ACM.

Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-

G., Cox, L. P., Jung, J., McDaniel, P., and Sheth,

A. N. (2014). Taintdroid: an information-ﬂow track-

ing system for realtime privacy monitoring on smart-

phones. ACM Transactions on Computer Systems

(TOCS), 32(2):5.

Gjerdrum, A. T., Håvard, D., and Johansen, D. (2016).

Implementing informed consent as information-ﬂow

policies for secure analytics on ehealth data: Prin-

ciples and practices. In Connected Health: Ap-

plications, Systems and Engineering Technologies

(CHASE), 2016 IEEE First International Conference

on, pages 107–112. IEEE.

Global Platform (2011). TEE system architecture. Global

Platform technical overview.

Goldberg, I., Wagner, D., Thomas, R., Brewer, E. A., et al.

(1996). A secure environment for untrusted helper ap-

plications: Conﬁning the wily hacker. In Proceedings

of the 6th conference on USENIX Security Symposium,

Focusing on Applications of Cryptography, volume 6,

pages 1–1.

Hurley, J. and Johansen, D. (2014). Self-managing data in

the clouds. In Cloud Engineering (IC2E), 2014 IEEE

International Conference on, pages 417–423. IEEE.

Jang, J., Choi, C., Lee, J., Kwak, N., Lee, S., Choi, Y., and

Kang, B. (2016). Privatezone: Providing a private exe-

cution environment using arm trustzone. IEEE Trans-

actions on Dependable and Secure Computing.

Johansen, H., Gurrin, C., and Johansen, D. (2015a). To-

wards consent-based lifelogging in sport analytic. In

MMM 2015, Part II, number 8936, pages 335–344.

Springer International Publishing.

Johansen, H. D., Birrell, E., Van Renesse, R., Schneider,

F. B., Stenhaug, M., and Johansen, D. (2015b). En-

forcing privacy policies with meta-code. In Proceed-

ings of the 6th Asia-Paciﬁc Workshop on Systems,

page 16. ACM.

Maniatis, P., Akhawe, D., Fall, K., Shi, E., McCamant, S.,

and Song, D. (2011). Do you know where your data

are? Secure data capsules for deployable data protec-

tion. In of the 13th USENIX Conference on Hot Top-

ics in Operating Systems, HotOS ’11, pages 22–27.

USENIX Association.

Ngabonziza, B., Martin, D., Bailey, A., Cho, H., and Mar-

tin, S. (2016). Trustzone explained: Architectural fea-

tures and use cases. In Collaboration and Internet

Computing (CIC), 2016 IEEE 2nd International Con-

ference on, pages 445–451. IEEE.

Nordal, A., Kvalnes, Å., Hurley, J., and Johansen, D.

(2011). Balava: Federating private and public clouds.

In Services (SERVICES), 2011 IEEE World Congress

on, pages 569 –577.

Rubinov, K., Rosculete, L., Mitra, T., and Roychoudhury,

A. (2016). Automated partitioning of android applica-

tions for trusted execution environments. In Proceed-

ings of the 38th International Conference on Software

Engineering, pages 923–934. ACM.

Sabelfeld, A. and Myers, A. (2003). Language-based

information-ﬂow security. Selected Areas in Commu-

nications, IEEE Journal on, 21(1):5–19.

Santos, N., Raj, H., Saroiu, S., and Wolman, A. (2014).

Using arm trustzone to build a trusted language run-

time for mobile applications. In Proceedings of the

19th International Conference on Architectural Sup-

port for Programming Languages and Operating Sys-

tems, ASPLOS ’14, pages 67–80, New York, NY,

USA. ACM.

Schwab, K. (2016). The fourth industrial revolution. World

Economic Forum Geneva.

Shuja, J., Gani, A., Bilal, K., Khan, A. U. R., Madani, S. A.,

Khan, S. U., and Zomaya, A. Y. (2016). A survey of

mobile device virtualization: taxonomy and state of

the art. ACM Computing Surveys (CSUR), 49(1):1.

TCG Published (2011). TPM main part 1 design principles.

Speciﬁcation Version 1.2 Revision 116, Trusted Com-

puting Group,.

Valvåg, S. V., Pettersen, R., Johansen, H., and Johansen,

D. (2016). Lady: Dynamic resolution of assemblies

for extensible and distributed .net applications. In

CLOSER 2016 : Proceedings of the 6th International

Conference on Cloud Computing and Services Sci-

ence, pages 118–128.

Secure Edge Computing with ARM TrustZone

109