AID: Autonomous Attestation of IoT DevicesAhmad Ibrahim

TU DarmstadtDarmstadt, Germany

Ahmad.Ibrahim@trust.tu-darmstadt.de

Ahmad-Reza SadeghiTU Darmstadt

Darmstadt, GermanyAhmad.Sadeghi@trust.tu-darmstadt.de

Gene TsudikUC Irvine

Irvine, U.S.Gene.Tsudik@uci.edu

Abstract—Embedded devices, personal gadgets and networksthereof are becoming increasingly pervasive, mainly due theadvent of, and hype surrounding, the so-called Internet of Things(IoT). Such devices often perform critical actuation tasks, aswell as collect, store and process sensitive data. Therefore, asconfirmed by recent examples (such as the Mirai botnet), theyalso represent very attractive attack targets. To mitigate attacks,remote attestation (RA) has emerged as a distinct security servicethat aims at detecting malware presence on an embedded device.Most prior RA schemes focus on attesting a single device anddo not scale. In recent years, schemes for collective (group orswarm) RA have been designed. However, none is applicable toautonomous and dynamic network settings.

This paper presents AID – the first collective attestationschemes for large autonomous dynamic networks of embeddeddevices. AID verifies overall network integrity by combiningcontinuous in-network attestation with a key exchange mecha-nism and Proofs-of-non-Absence. Using device absence detectionAID defends against physical attacks that require disconnectingattacked devices from the network for a non-negligible time.

We demonstrate feasibility of AID with proof-of-concept imple-mentation on state-of-the-art security architectures for low-endembedded devices and on an autonomous testbed formed of sixdrones. We also assess its scalability and practicality via extensivesimulations.

I. INTRODUCTION

In recent years, embedded devices proliferated into numer-ous domains, collecting, processing and exchanging sensitiveinformation, while performing safety- and security-criticaloperations. Interconnection of embedded devices within theexisting network infrastructure enables a wide range of ap-plications, including centrally managed “smart” environments(e.g., cars, homes, buildings, and factories) and autonomousdynamic ad-hoc networks, such as vehicular ad-hoc networksfor autonomous driving, and swarms of self-organizing col-laborating embedded devices, e.g., robots and drones. Despitemany benefits, allowing embedded devices to be accessed andcontrolled remotely poses a formidable security challenge,since it greatly broadens the attack surface and magnifiesconsequences of a successful attack.

Remote malware attacks usually involve modifying de-vice firmware and/or software, e.g., Stuxnet [28], and Jeephack [21]. Unfortunately, sophisticated security features com-mon on general-purpose computing devices are lacking onmost embedded devices, due to their limited resources. Thismakes them attractive targets for remote attackers. On the otherhand, IoT networks can involve hundreds and even thousandsof autonomous, mobile and inter-connected devices, operating

in hostile environments. In particular, whenever devices arenot always within a physical security perimeter, they can besubject to capture and physical attacks.

For this reason, much effort has been invested in recentyears into Remote Attestation (RA) – a distinct security servicethat aims to detect presence of malware on a potentiallycompromised embedded device. RA is usually realized as aprotocol between an untrusted Prover device that securelyreports its current software state to a trusted remote Verifier.Most prior work focused on this setting. There are threegeneral types of RA protocols: software-based [22], [18],coprocessor-based [2], [17], and software/hardware co-designor hybrid [10], [11], [16]. Currently, hybrid attestation isviewed as the most promising approach, since it providesstrong security guarantees while involving lightweight hard-ware features: a small amount of Read-Only Memory (ROM),and a simple Memory Protection Unit (MPU).

Most prior attestation schemes – regardless of the type – aregeared for a single-prover setting, i.e., do not scale to manyprovers, and only consider remote software-only attacks. Sev-eral recent efforts [5], [1], [13], [6] yielded attestation methodsfor networks or groups of devices that provide collective orswarm attestation. SEDA [5] efficiently attests a network oflow-end embedded devices. SANA [1] is based on OptimisticAggregate Signatures (OAS) to provide better efficiency andresiliency. Finally, DARPA [13] allows detection of physicalattacks by extending SEDA with a periodic network-wideheartbeat protocol. DARPA assumes that a physical attackrequires disconnecting the target device for a non-negligibleamount of time, and uses a global absence detection protocolto detect such physical attacks.

Problem Statement. Prior collective RA schemes focused oncentralized IoT networks with restricted mobility, meaning thatthe network topology must remain static during RA protocolexecution. Moreover, such schemes cannot mitigate physicalattacks, except for DARPA [13], which scales poorly as itincurs high computation and communication costs, quadraticin the network size. Emerging IoT networks have highlydynamic topologies and include large numbers of devices,where multiple devices can be subject to physical attacks.

Goals and Contributions. This paper presents AID – thefirst attestation protocol for large, autonomous and dynamic-topology networks of embedded devices. Designing AID posesseveral challenges. In particular, attestation and physical attack

detection should be combined with key management in orderto allow detection of malicious devices, while preservingscalability (i.e., keeping costs constant in terms of the networksize) and device mobility. This requires ensuring secure flowof attestation results throughout the network, in order to allowmobile devices to prove their trustworthiness to new neighborswhile incurring minimal and constant costs. Finally, compu-tation, communication, and energy costs should be evenlydistributed over all devices, to prevent performance bottle-necks. AID combines continuous attestation of neighbors andperiodic local heartbeats with a key exchange mechanism todetect both software attacks and physical attacks with minimalcost. It handles dynamic topology using a dedicated roamingprotocol. This paper makes three technical contributions:• In-network Attestation: AID is the first efficient, scalable

and secure attestation scheme for large autonomous dy-namic networks of embedded devices, that allows isola-tion of potentially malicious devices.

• Proof-of-Concept Implementation: AID was implementedon two recent RA architectures for low-end embeddeddevices: SMART [10] and TrustLite [16], and on anautonomous testbed formed of six interconnected dronesequipped with a Raspberry Pi 3 Model B.

• Performance Analysis: We conducted a thorough perfor-mance and security assessment of AID with simulationresults for networks of up to 1, 000, 000 devices.

II. AIDA. System Model

We consider a dynamic network E composed of devices:Ei for i = 1, . . . , n. Each Ei has a unique ID id i. Devices canbe heterogeneous and might be spread over a large physicalarea. As discussed in Section II-B, devices can have varioussoftware and hardware. However, all devices should havea lightweight RA architecture. We assume that mobility iscontiguous, i.e., a device can move gradually and change itsset of direct neighbors.1 However, a moving device never dis-appears from one neighborhood and instantaneously reappearsin a physically far neighborhood. Each Ei is always availableand reachable (e.g., smart IoT environments), i.e., we do notconsider networks where devices can be completely switchedoff for an extended period of time.2 We denote by IDi theset of current neighbors of Ei. The (trusted) network operatorO is responsible for initialization and maintenance of E , e.g.,adding new, and removing defective, devices. The overall goalof AID is to detect and isolate devices (see adversary modelin Section II-B). Policies that govern the network reaction toisolated malicious devices are out-of-scope.

B. Requirements Analysis

Adversary and Trust Model. We assume that owner Ois trusted and initializes devices in a trusted environment.Other entities (devices) can potentially be under the control

1Two devices are considered neighbors if they can communicate, i.e., ifthey are within each others communication range.

2Sleep mode is allowed as long as devices are awake to execute the protocol.

of A, which aims to compromise devices and evade detection,similar to Stuxnet [28]. Hence, we do not consider DoS attackswhich reveal A’s presence.A can compromise communication channels and/or de-

vices. More concretely, it can (1) control all communicationchannels, inject its own packets and eavesdrop on, modify,and delay packets exchanged between devices; (2) exploitsoftware vulnerabilities to gain control over devices, extractunprotected secrets and modify unprotected software; and (3)mount physical attacks in order to modify devices’ hardware orsoftware components and/or learn hardware-protected secrets.In order to physically attack a device, we assume that A hasto turn it off for a non-negligible amount of time tphy .

We consider three types of physical attacks: invasive, semi-invasive and non-invasive. An invasive attack [24] involvesA trying to extract information from a device through directaccess to its internal components. It requires sophisticated andexpensive lab equipment. Semi-invasive attacks [25] are lessexpensive and less complicated. They use cheaper equipment(e.g., laser microscopes) and only require de-capsulation. Ex-amples include: thermal imaging, ultra-violet attacks, opticalfault injections and laser scanning. Both invasive and semi-invasive attacks require possession of the victim device for anon-negligible length time: from hours to weeks [24], [23].Meanwhile, non-invasive attacks [29] use low-cost electricalengineering tools, such as fault injection and various side-channels (e.g., time, power or electromagnetic radiation) toextract device’s cryptographic keys during normal operation.

We do not claim that AID can mitigate all physical attacks.We specifically exclude non-invasive hardware side-channelattacks that might not require physically disconnecting thetarget device from the network. Since physical attacks are notscalable, we assume that A can physically attack a limitednumber of devices.

Main objectives. In the assumed settings, there is no centralauthority to initiate the RA protocol and verify results. Hence,we envisage a collective attestation scheme that: (1) is effi-cient, ideally with constant computation and communicationcosts in terms of the network size, achieved by requiringeach device to only assess trustworthiness of its neighboringdevices; (2) assures detection and isolation of compromiseddevices, achieved by combining attestation and absence detec-tion with key exchange; and (3) captures network’s dynamicbehavior whereby devices move and gradually change theirneighborhood, done through a dedicated roaming protocolwhich allows the secure flow of RA results.Device Requirements. Every Ei has a signing key-pair(sk i, pk i), and is equipped with a lightweight RA trust anchor.The trust anchor may consist of a small ROM and a simpleMPU (see Section IV). This hardware protects AID protocolcode and cryptographic keys, against software-based attacks.We assume that each Ei has a loosely synchronized reliableread-only clock (RROC), i.e., a clock that is not modifiableby software. We acknowledge that tight clock synchronizationacross all devices is not always feasible, especially, in very

2

large networks. For this reason, AID requires loosely synchro-nized clocks with skews in the order of minutes.Network Requirements. We assume that the network isconnected and devices are available at all times. Time totransmit a message between two neighboring devices is upper-bounded by ttr . We assume smooth mobility, meaning thatdevices approach each other gradually, i.e., when Ei movestowards Ej it establishes a neighborhood with all devices onits path to Ej . Consequently, before Ei and Ej come withineach others range, they have at least one common neighbor.3

C. High Level Protocol Description

We present a high-level overview of AID based on thesample network E illustrated in Figure 1 with E1–E8. AIDincorporates multiple protocols executed at different phasesand for various purposes.• init 1 : is executed by O before enrollment. O initializes

each device with the required cryptographic materials,e.g., a signing key-pair and a device certificate (E8 in thefigure).

• connect: is executed when two devices become neigh-bors, i.e., when a new device (E8 2 ) joins E , orchanges its position (E6 3 ). The purpose of connectis twofold: (1) it allows devices to share secret keysused for authenticating protocol messages; and (2) itenables benign devices to report their state to newlyestablished neighbors. New neighbors establish a securecommunication (i.e., share keys) only if they can verifyeach other’s trustworthiness.

• attest 4 : is launched at random times between everytwo neighboring devices, allowing each device to attestits direct neighbors and keep track of their software state.For instance, E6 attests its every neighbor, e.g., E5. Thedevice then records its list of neighbors that attestedsuccessfully, and drops secure communication (i.e., deleteshared keys) with all devices that failed attestation.

• beat 5 : is executed periodically allowing each device tokeep track of its neighbors’ presence, based on absencedetection. Each device (e.g., E6) sends a heartbeat toall neighbors demonstrating its presence. Each devicerecords the list of devices from which it received a heart-beat and drops secure communication with all devicesthat did not send a heartbeat. Moreover, as a response to aheartbeat, each device gets Proof-of-non-Absence (PonA)tokens from its neighbors. These are used by a mobiledevice to prove its trustworthiness to new neighborsthrough connect.

Each device keeps track of software/hardware trustworthinessof its neighbors through attestation and absence detection. Byestablishing secure communication to only those neighborsthat have proven their trustworthiness, AID allows formationof a secure connected sub-network of devices that are notcompromised, i.e., passed attestation and are always present:

3Network partitioning is tolerated, though it requires O to reconnectpartitions. Similarly, power losses and node crashes would always requireO’s assistance, e.g., to replace a depleted battery.

{E1, E3, E4, E5, and E7}. This allows detecting and isolatingpossibly compromised devices (E2).

III. DETAILED PROTOCOL DESCRIPTION

A. Notations and Definition

Before describing AID, we introduce the notation:Benign and Secure Device Lists. Each Ei keeps two lists:(1) Bi stores IDs of neighbors, that Ei believes to have benignsoftware. They are known to Ei through continuous attestation.(2) Si stores IDs of neighbors that Ei believes have not beenphysically attacked. These are known to Ei through absencedetection (see Section II-B).Heartbeat Interval. Time is divided into uniform-size heart-beat intervals; this value is upper-bounded by the minimumtime for A to perform a physical attack: thb < tphy . Everyheartbeat interval starts at Thb and is identified by its ID qi.Present Device List. For every heartbeat interval, each Ei

keeps a list Pi of neighbors present during this interval.Heartbeat. Each Ei with ID id i generates at Thb of everyheartbeat interval qi a heartbeat. Ei authenticates the heartbeatusing a MAC µij based on a heartbeat key kbeat

ij sharedbetween Ei and every neighbor Ej , and sends it to Ej . Wedenote this heartbeat by HB ij = {{qi, id i}, µij}. It provescontinuous presence of Ei to Ej .Proof-of-Secure-Enrollment (PoSE). At Ei’s initializing timeTinit, O generates a token formed of Ei’s ID id i and Tinit,creates a digital signature σi over it, and sends it to Ei. Wedenote this token by PoSE πi = {{id i,Tinit}, σi}. πi provesthat Ei was enrolled securely.Proof-of-non-Absence (PonA). Every Ei with ID id i provesits presence, at heartbeat interval qi, to all its neighbors. As aresponse, each neighbor Ej creates a set of tokens formed ofid i, qi, and time TEi

A of the last attestation of Ei by Ej . It thenauthenticates them based on a heartbeat key kbeat

jk shared withevery neighbor Ek of Ej , and sends them to Ei. We denoteby ψjk/i = {{id i, qi,T

Ei

A }, µ̂jk/i, idk} an individual token,and by Πi – the set of all authenticated tokens received by Ei

from every neighbor Ej . Each ψjk/i in Πi proves that Ei wascontinuously present and successfully attested.

B. Protocol Details

AID includes the following protocols:Initialization. Each Ei is initialized by O with:• a signing key-pair (sk i, pk i), public key certificatecertO(pk i), and public key pkO of O – sk i is hardware-protected and is only accessible to AID code,

• a reference software configuration ci indicating the cor-rect software that should be present on Ei, and a softwareconfiguration certificate certO(ci),

• and a Proof-of-Secure-Enrollment (PoSE) πi, whichproves that Ei is not compromised directly after initial-ization.

Roaming. As shown in Figure 2, connect has four mainmodules executed between Ei and Ek. These are: (1) sharingprotocol keys, (2a) verifying a token in PonA or (2b) a PoSE,

3

Figure 1: AID in a network of 8 devices.

Πi|πi, idi / Πk|πk, idk

kmasterik ← KEP(sk i, skk, cert(pk i), cert(pkk))

ATTESTATION

Πi|πi = {{idi,Tinit}, σi}, IDi,Bi,Si, ci, sk i, pkO , cert(pk i)

Device Ei

append(idk, IDi)

kbeatik ← hash("beat:"|kmaster

ik )

kattestik ← hash("attest:"|kmaster

ik )

idj ← findNeighbor(Πk)

if vermac(kbeatij ; {idk, qk,TA}, µ̂ij/k) then

if qk = qi thenappend(idk,Si)append(idk,Pi)

endifendif

if versig(pkO ; {idk,Tinit}, σk) thenif Thb + δt + ttr − Tinit < thb then

endifendif

append(idk,Si)

if TA < tmaxA then

append(idk,Bi)

endif

else if attest(Ek)thenappend(idk,Bi)

if idk ∈ Si and idk ∈ Bi then

k encik ← hash("encrypt:"|kmaster

ik )

kauthik ← hash("authenticate:"|kmaster

ik )

endif

(1) Share protocol keys

(2a) Find and verify a token in PonA

(2b) Or verify PoSE

(3) Attest new neighbor (if needed)

(4) Create authentication and encryption keys

Device Ek

Πk|πk = {{idk,Tinit}, σk}, IDk,Bk,Sk, ck, skk, pkO , cert(pkk)

append(idi, IDk)

kbeatik ← hash("beat:"|kmaster

ik )

kattestik ← hash("attest:"|kmaster

ik )

idj ← findNeighbor(Πi)

if vermac(kbeatjk ; {idi, qi,TA}, µ̂jk/i) then

if qi = qk thenappend(idi,Sk)

append(idi,Pk)

endifendif

if versig(pkO ; {idi,Tinit}, σi) thenif Thb + δt + ttr − Tinit < thb then

endifendif

append(idi,Sk)

append(idi,Bk)

endifappend(idi,Bk)

else if attest(Ei)then

if TA < tmaxA then

k encik ← hash("encrypt:"|kmaster

ik )

kauthik ← hash("authenticate:"|kmaster

ik )

if idi ∈ Sk and idi ∈ Bk then

endif

(1) Share protocol keys

(2a) Find and verify a token in PonA

(2b) Or verify PoSE

(3) Attest new neighbor (if needed)

(4) Create auth and enc keys

Figure 2: Protocol connect: executed when a device joins or changes its position.

(3) attesting new neighbors, and (4) creating authenticationand encryption keys.

In detail, upon joining, or moving within, E , each Ei usesa Key Exchange Protocol KEP (authenticated Diffie-Hellmanbased on signing key-pairs) to compute, with every neighborEk, the following protocol keys:• attestation key k attest

ik that is used for mutual attestationbetween Ei and Ek,

• and heartbeat key kbeatik used for authenticating heartbeats

and PonA-s exchanged between Ei and Ek.Two devices also:• Exchange their respective reference software configura-

tions ci and ck as well as certificates (certO(ci) andcertO(ck)). This allows device to attest each other at any

later point in time.• Add each other’s IDs idk and id i to their respective list

of neighbors IDi and IDk.• Exchange PoSE (for newly added devices) or PonA (for

roaming devices). Recall that, PoSE-s and PonA-s allowa device to prove to its new neighbors that it has not beencompromised.

When Ek receives a PoSE or a PonA from a neighbor Ei

during connect, it does the following:• Verifies its authenticator (MAC or digital signature).• Verifies its freshness by checking Tinit (or qi).• Decides whether to accept the latest attestation of Ei, or

to attest it again, based on Tinit (or TEi

A ).If authenticator verification and attestation were successful on

4

IDi, Ki, cj

Device Ei

for each Ej ∈ IDi

Nj ←R {0, 1}`N

startTimer(tA)

tA ← random(tmaxA )

TA = time()

if vermac(kattestij ;Nj‖cj , µij) then

endif

TEj

A = TA

delete(idj ,Bi)delete(kauth

ik , kij)

delete(k encik , kij)

else

endforendif

if timerExpired() then

(1) Generate nonce for each neighbor

(3) Verify attestation report and store time

Device Ej

kattestij

µij ← mac(kattestij ;Nj‖c′j)

c′j ← getSoftConfig()

(2) Measure software stateNj

µij

Figure 3: Protocol attest: executed at random times between neighboring devices.

both devices participating in connect, Ei and Ek then:• Share two new keys: authentication key k auth

ik , and en-cryption key k enc

ik . The list of all keys shared between Ei

and its neighbors is denoted by Ki.• Mark each other as trustworthy: add each other’s ID to

their B and S lists.Consequently, connect allows benign devices to share authen-tication and encryption keys with benign neighbors.Attestation. As shown in Figure 3, attest has three mainmodules executed between Ei and Ej . These are: (1) gener-ating a nonce, (2) measuring software state, and (3) verifyingattestation report.

In detail, every Ei attests each neighbor Ej at random times(upper bounded by tmax

A ). attest is executed as follows:• At attestation time TA, Ei sends Ej a random challengeNj .

• Ej replies with a MAC µij of its current softwareconfiguration c′j and received challenge.

• If verification of µij fails, Ei deletes idj from its list ofbenign neighbors Bi. Ei also deletes functionality keys(k enc

ij and k authij ) from set kij of keys shared with Ej .

• If attestation succeeds, Ei stores the time TA (as TEj

A )for inclusion in any future PonA sent to Ej .

attest allows each device to continuously check softwareintegrity of all its neighbors and update B of benign neighbors.

Algorithm 1: checkTime on Ej

1 Function checkTime(qi, t, qj)2 if qi = qj ∧ Thb < t < Thb + δt + ttr then3 return true4 else if qi = qj + 1 ∧ Thb − δt < t < Thb then5 return true6 else7 return false

Heartbeat. As shown in Figure 4, beat has four main modulesexecuted between Ei and Ej . These are: (1) generating a

heartbeat, (2) verifying a heartbeat, (3) generating tokens forPonA, and (4) verifying MAC on PonA tokens.

In detail, each Ei periodically (i.e., at Thb) sends a heartbeatHB ij to every neighbor Ej to prove its presence in E . Uponreceiving HB ij , Ej verifies its authenticity, and its freshnessaccording to checkTime (shown in Algorithm 1). This allowsto verify that HB ij belongs to current heartbeat interval qjand is received within accepted tolerance interval ttol aroundthe current Thb . ttol is required to tolerate clock drifts andtransmission delays between devices.

If all checks are successful, Ej adds id i to its list of presentdevices Pj . It then creates a tuple %i = {id i, qi,T

Ei

A } andauthenticates it with MACs based on every symmetric keykbeatjk shared with each neighbor Ek, hereby creating tokensψjk/i. The set of all created tokens is then sent to Ei, whichstores them along with other tokens received from all otherneighbors into a PonA Πi. At the end of ttol , each Ej comparesIDs of its neighbors that have not been physically attacked Sjto the list of present neighbors Pj . Every id i not present in Pj

is deleted from Sj , and devices’ corresponding functionalitykeys (k auth

ij and k encij ) are deleted from kij .

The beat protocol allows every device to periodically checkpresence of each neighbor and its hardware trustworthiness,and then update S . Also, Πi acquired by every Ei after beatallows it to later prove its hardware and software trustworthi-ness to any new neighbor via connect.

IV. IMPLEMENTATION

We implemented AID on two security architectures for low-end embedded devices: SMART [10] and TrustLite [16] inorder to evaluate its performance. However, since SMARTand TrustLite are not commodity devices we also implementedAID on a small autonomous network formed of six RaspberryPi-based drones communicating over WiFi. This implementa-tion allowed us to further prove practicality of AID. Finally, inorder to evaluate AID for very large networks we used networksimulation based on the measurements from our SMART and

5

HB ij

Ψj/i, µ̃j/i

Device Ej

qj ,Sj , Kj ,TEiA

if vermac(kbeatij ; hbi, µij) then

append(idi,Pj)

if checkTime(qi, time(), qj) then

if idi ∈ Sj then

%i ← {idi, qi,TEiA }

for each kbeatjk ∈ Kj \ {kbeat

ij } doµ̂jk/i ← mac(kbeat

jk ; %i)

ψjk/i ← {%i, µ̂jk/i, idk}append(ψjk/i,Ψj/i)

endforµ̃j/i ← mac(kbeat

ij ; Ψj/i‖qi)

endifendif

endif

(2) Verify heartbeat

(3) Generate tokens for PonA

kij , qi, IDi

Device Ei

qi ← qi + 1

for each Ej ∈ IDi

hbi ← {qi, idi}µij ← mac(kbeat

ij ; hbi)

HB ij ← {hbi, µij}

if vermac(kbeatij ; Ψj/i‖qi, µ̃j/i) then

append(Ψj/i,Πi)

endif

(1) Generate a heartbeat

(4) Verify MAC on PonA tokens

endfor

Figure 4: Protocol beat: executed periodically between neighboring devices.

Memory System

ski

LTi

STi

cert(pki)

cert(ci)

Device OS

Task 1

connectattestbeat

Primitives

ROM RAM

PROCESSOR

MPU

# if PC in access to is (rw)

1

2

r5r1

r1-5 r6-7

10

11

read protected r/w protected none

r1

r2

r3

r4

r5

r6

r7

Figure 5: Implementation of AID on SMART [10]

Memory System

ski

LTi

STi

cert(pki)

cert(ci)

Device OS

Task 1

Secure Boot

kplatform

ROM RAM

PROCESSOR

MPU

# if PC in access to is (rw)

1

2

r1-7r1

r3 r7

10

10

read protected r/w protected none

r1

r2

r3

r4

r5

r6

r7

r8

connectattestbeat

Primitives

r9

3 r3-6 r8-9 11

Figure 6: Implementation of AID on TrustLite [16]

TrustLite implementations. In this section we describe ourimplementations.

A. SMART & TrustLite Overview

SMART [10] (shown in Figure 5) is a security architecture,which enables secure remote attestation on low-end embedded

systems based on minimal hardware assumptions. Main hard-ware components of SMART are: (1) A read-only memory(ROM), which stores program code used for attestation (de-noted by ROM code) and an attestation key. ROM providesimmutability and ensures integrity of the attestation code; and(2) A simple memory protection unit (MPU), which controlsaccess to the attestation key. MPU grants access to the keyonly to ROM code based on the value of the program counter.Consequently, only genuine attestation code can access theattestation key. SMART also provides additional features forprotecting the attestation key, e.g., it ensures that ROM code isexecuted uninterrupted starting from the first, and terminatingin its last instruction.

TrustLite [16] (shown in Figure 6) is an embedded securityarchitecture which generalizes SMART allowing the executionof multiple tasks (i.e., processes) in isolation. Isolation of tasksis attained via secure boot and an execution aware memoryprotection unit (EA-MPU), where EA-MPU is set up by accessrules between tasks and their corresponding data. Changes toEA-MPU are prevented by starting the system via secure boot,which verifies that the correct software sets up the rules inthe EA-MPU, then sets EA-MPU’s configurations registers toread-only to prevent further changes. A main advantage ofSMART over TrustLite is that it allows secure interruption oftasks while executing.

B. Implementation Details

SMART-specific Extensions. To allow implementation ofAID, we needed to extend SMART to enable (1) restrictedaccess to writable memory, and (2) Multiple entry and exitpoints of trusted ROM code. First, restricting access to writablememory is needed to store the symmetric key shared withneighboring devices, in addition to AID’s intermediate data. It

6

was done by extending the MPU to control access to a smallarea of writable non-volatile memory. Second, allowing mul-tiple entry and exit points enables running different protocolsindependently, from the same ROM. It was done by extendingthe hardware entry and exit points with software entry points.We implemented our protocol as a single function called AID,which takes as input the identity of the protocol, and alwaysexits from the same address. No such extensions are requiredfor TrustLite as it already provides secure writable memoryand multiple entry and exit points for trusted code.Keys and Variables. The secret key sk i, is both read- andwrite-protected by a dedicated EA-MPU rule (rule #1 in Fig-ure 5 and rule #2 in Figure 6), which ensures that connect hasexclusive read access to sk i while all other code has neitherread nor write access to sk i. Long term LTi and short termSTi protocol data (including symmetric keys and variables)are also both read- and write-protected through dedicated EA-MPU rules, (see Figure 5 and 6). At the same time, protocolcode integrity is assured by ROM (on SMART [10]) and secureboot (on TrustLite [16]).Real-time Clock. In order to enable secure in-network at-testation and absence detection a real-time clock is required.The clock is write-protected and does not wrap around withinthe lifetime of a device. For example, a 64-bit register wouldwrap around in 12, 186.3 years on our 48 MHz TrustLite ifincremented every clock cycle. On the other hand, a 32-bitregister can be made to wrap around in 3 years, if incrementedevery one million cycle, i.e., providing a resolution of 21 ms,which is appropriate for AID.Functionality. In order to reflect the outcome of attestationand absence detection in the network’s functionality andprovide real isolation of detected malicious device, we imple-mented an additional component denoted by Primitives.It provides authentication (authenticate, and verify in Algo-rithm 2 and 3) and encryption services to all software compo-nents residing on a device and contributing to its functionality,without granting them direct access to the shared symmetrickeys. In particular, before performing the required action (i.e.,authenticate or encrypt), Primitives on Ei check whetherthe ID id j of the device Ej , to which Ei is communicating,exists in both Bi and Si.

Algorithm 2: authenticate on Ei

1 Function authenticate (m, idj)2 if idj ∈ Si and idj ∈ Bi then3 return mac(kauth

ij ;m)

Algorithm 3: verify on Ei

1 Function verify (m,µ, idj)2 if idj ∈ Si and idj ∈ Bi then3 return vermac(kauth

ij ;m,µ)

Implementation on a drones testbed. To further test and

demonstrate the feasibility of AID, we implemented and testedAID on our autonomous testbed, which is composed of sixdrones forming an ad-hoc network as shown in Figure 7. Eachindividual drone is equipped with a Raspberry Pi 3 Model Bwith a 1.2 GHz Quad-core 64-bit CPU. Further, the dronescommunicate via WiFi using a 150 MBit/s USB WLAN stick.Each drone is initialized with an RSA private key, a public keycertificate, and the public key of a network operator O . For ourimplementation we used C programming language and utilizedmbed TLS [3] library for handling cryptographic operations.

V. PERFORMANCE EVALUATION

We evaluated AID based on our implementations in Sec-tion IV. In this section we present evaluation results forTrustLite. Results for SMART are very similar to those ofTrustLite and are hence omitted, due to space limitations.Software Complexity and Memory Requirements. All cryp-tographic operations required for AID (i.e., authentication andencryption) are inherently existing on TrustLite. We only needto add the code responsible for creating, sending, and handlingbeat, attest and connect messages, as well as handling thelists K, ID, P , S, and B. Let g denotes the number ofneighbors of each device in the network, each device needto store 36 · g2 + 56 · g + 228 bytes of long term LT and shortterm ST protocol data, 56 · g + 80 bytes of which should beread- and/or write-protected.Hardware Costs. We compare our implementation to thecurrent implementation of TrustLite [16]. The results areshown in Table I.

Table I: Hardware cost of AID

TrustLite AID % of increase

Register 6038 6186 2.45%

Look-up Table 15142 15356 1.41%

The total cost of AID is 6186 registers and 15356 LUTs,which is a very small increase of 2.45% and 1.41% of the costof TrustLite in terms of registers and LUTs respectively.Energy Costs. Energy consumption estimates4 of AID areshown in Figure 8. We base it on previously reported energyconsumption for communication and cryptographic operationsof TelosB and MICAz sensor nodes [9] which fall into thesame class of low-end embedded devices as SMART [10]and TrustLite [16]. Measurements exclude energy requiredfor generating the software configuration and executing a keyexchange protocol, which is dependent on the KEP protocolused. Energy consumption of one execution of all of theprotocols is linear in the number of neighbors, except for move(i.e., connect for a moving device), whose energy consumptionis cubic in the number of neighbors. This is mainly dueto the size of the Proofs-of-non-Absence (PonA-s). Energy

4It is not possible to analyze the energy consumption of AID directly onSMART [10] and TrustLite [16] as they are only available on FPGAs.

7

Figure 7: Our autonomous drones testbed

consumption in all protocols is constant in the size of thenetwork and can be as low as 1, 5, and 20 mJ for attest, join(i.e., connect for a new device) / beat, and move, respectively,in networks with up to 4 neighbors per a MICAz device.

Figure 9 shows the energy consumption of beat (executedwith 8 neighbors) as function of the number of heartbeatintervals elapsing within a specific period of time, where aheartbeat interval is the time between two consecutive execu-tions of beat protocol. The energy consumption of beat growslinearly with the number of heartbeat intervals. The length ofheartbeat intervals depends on anticipated adversary’s budgetand devices’ hardware complexity. In other words, the lengthof heartbeat interval presents a trade-off between security andperformance, where short heartbeat intervals provide moreaccurate detection of physical attacks by adversaries withbigger budgets, while implying additional energy consumptionwhich grows linearly with the number of these intervals.

0 10 20 30 40 50 60

2 4 6 8 10 12Ener

gy c

onsu

mpt

ion

(mJ)

Number of neighbors

joinmovebeat

attest

(a) TelosB

0 10 20 30 40 50

2 4 6 8 10 12Ener

gy c

onsu

mpt

ion

(mJ)

Number of neighbors

joinmovebeat

attest

(b) MICAz

Figure 8: Performance evaluation of AID

Run-time of Primitives. Table II presents an evaluation ofPrimitives on TrustLite. The time required to authenticateand encrypt a 64 Byte message can be as low as 780 µs. On theother hand, verifying and decrypting such a message requiresonly 1190 µs.

0 200 400 600 800

1000 1200 1400 1600

20 40 60 80 100 120

Ener

gy c

onsu

mpt

ion

(mJ)

Number of heartbeat periods

Heartbeat (MICAz)Heartbeat (TelosB)

Figure 9: Energy consumption of beat

Table II: Run-time of Primitives

Run-time at 48 MHz TrustLite [16] (µs)

for 64 Byte messages

authenticate verify encrypt decrypt

320 320 460 870

0 0.2 0.4 0.6 0.8

1

4 8 12 16 20

Run

-tim

e (s

)

Number of neighbors

joinmovebeat

attest

(a) Per neighbors

0 0.5

1 1.5

2 2.5

3 3.5

250K 500K 750K 1M

Run

-tim

e (s

)

Number of devices

joinmove

beatattest

(b) Per network size

Figure 10: Run-time of AID

Simulation Results. We used OMNeT++ [19] simulation en-vironment to evaluate performance of AID. Cryptographic op-erations were simulated as delays based on real measurementsfrom our SMART [10] and TrustLite [16] implementations.Networks with up to 1,000,000 devices and variable numberof neighbors were simulated. We assume that each device has100 KB of memory to be attested. We also exclude the timeneeded to execute a key exchange protocol KEP since it doesnot present additional overhead5 and it depends on the specificKEP used. The results are shown in Figure 10, and 11.

Run-time of beat and attest is linear, while run-time ofjoin and move is quadratic in the number of neighbors.This is due to the exchange of local Proofs-of-non-Absence(PonA-s), whose size is quadratic in the number of neighbors(Figure 10(a)). Figure 10(b) shows the run-time of AID innetworks with 12 neighbors per device. The run-time of allAID protocols is independent of the network size, i.e., scalable.Finally, Figure 11 shows the run-time of AID in comparisonto the closest related work in the literature, i.e., SEDA [5]and DARPA [13]. While the run-time of attest and beat inAID is low and constant in network size, the run-time ofattest (described in SEDA) and the most efficient version ofcollect (described in DARPA) is logarithmic in the networksize. Note that, collect has a linear verification time on the

5Regardless of AID, devices must share keys. This overhead is also sharedwith all existing collective attestation schemes [5], [1], [13], [6].

8

0 0.5

1 1.5

2 2.5

3

0 2500 5000

Run

-tim

e (s

)

Number of devices

US-AIDSEDA

DARPA

(a) attest

0

5

10

15

20

25

500 1000 1500 2000

Run

-tim

e (s

)

Number of devices

US-AIDDARPA

(b) beat

Figure 11: AID vs. SEDA and DARPA

verifier (Figure 11(a)). On the other hand, the most efficientversion of heartbeat (described in DARPA) has a linear run-time compared to the constant run-time of beat in AID(Figure 11(b)).Run-time on Autonomous Drones Network. AID’s run-timesin our testbed are much smaller than those of SMART andTrustLite (targeted by AID) due to the powerful CPU of ourRaspberry Pis. For the sake of completeness we list the run-times for each of the protocols.6 The run-time of beat of drone#5 is less than 4 ms; the run-time of attest of drone #6 to attest(100 KB of code on) drone #3, #4 and #5 is less than 17 ms;and the run-time of move (i.e., connect for a moving device)of drone #3 to connect to drone #1 is less than 12 ms (seeFigure 7).

VI. SECURITY CONSIDERATION

An adversary can break the security goal of AID (i.e., isola-tion) and convince a benign Eb in E to securely communicatewith a malicious device Em, only if (1) Em is one of Eb’sexisting neighbors which sends correct heartbeats at correcttimes, and is successfully attested; or (2) Em is a mobile ora newly added device, which proves the trustworthiness of itsstate through a correct Proofs-of-Secure-Enrollment (PoSE)or Proof-of-non-Absence (PonA). We consider the followingcases:A Attacks beat. Non-negligible tampering time implies that,in order to physically attack Em, A should detach it for a non-negligible amount of time, which is greater than the acceptedtolerance interval ttol around Thb (see Section III for details).Therefore, A should forge or replay a correct heartbeat HBmb

in order to convince an existing neighbor Eb that Em has notbeen absent. This would require A to either forge the MACµmb, or find and replay an old MAC that is valid over a freshheartbeat interval qm, which is periodically incremented.A Attacks attest. The time between two consecutive attes-tations is upper bounded by tmax

A . To keep a device Em

connected to the secure sub-network after its compromise, Amust forge or replay a valid attestation response µmb over abenign software configuration c′m of Em. This would requireA to either forge the MAC µmb, find and replay an old MACthat is valid over a fresh random nonce and a benign softwareconfiguration, or find a collision for the hash function used tomeasure the software state and generate c′m.

6Results are an average over 100 executions

A Attacks move (i.e., connect for a Moving Device). Twodevices Em and Eb can only become neighbors if they canprove to each other, through a token (ψjb/m for Em and ψjm/b

for Eb) in their PonA-s, that they have been present for allprevious heartbeat intervals. Since each token in PonA shouldbe authenticated with a MAC µjb by a common neighbor Ej ,which is in the secure sub-network, A must forge or reuseψjb/m. This would require A to either forge the MAC µjb, orfind and replay an old MAC that is valid over a fresh heartbeatinterval qm.A Attacks join (i.e., connect for a New Device). A newlyadded Em only acquires neighbors if: (1) it can prove thetrustworthiness of its state through a PoSE πm; and (2) everynew neighbor Eb in its first heartbeat interval can prove itspresence through a token ψjm/b in PonA. Consequently, inorder to add Em to the secure sub-network, A must forge orreplay a πm. This would require A to either forge the digitalsignature σm of O , or find and replay a digital signature thatis valid over a fresh timestamp Tinit. Similarly, in order to addEm as a bridge between the secure sub-network and maliciousdevices, A must forge or replay ψjb/m. This would require Ato either forge a MAC µjb, or find and replay a MAC that isvalid over a fresh heartbeat interval qm.

VII. RELATED WORK

Remote Attestation. In remote attestation protocol, a trustedverifier obtains an authenticated report about the currentsoftware state of a remote and possibly compromised deviceprover. A trust anchor on the prover is required to guaranteethe integrity of the attestation code. Typically the trust anchoris implemented in hardware, e.g., based on Trusted PlatformModules (TPM). However, TPMs and other similar modulesare complex and expensive [27], [17] and not suitable for low-end embedded devices. On the other hand, software-basedattestation [22], [18] schemes require no hardware securityfeatures and are suitable for attesting non-remote embeddeddevices. However, these schemes are based on strong assump-tions that are hard to achieve in practice [4]. Finally, hybridattestation [10], [11], [16] provide strong security guarantieswhile requiring minimal hardware security features. All of theabove assume a single prover device.Collective Attestation. A collective attestation protocol is aremote attestation protocol, with many provers, i.e., a net-work of devices [5], [1], [13], [6]. SEDA [5] was the firststep towards collective attestation of a network of connectedembedded devices. It performs attestation of swarms of inter-connected embedded devices by distributing attestation burdenacross the entire network. Unfortunately, SEDA considers onlyremote software attacks and fails as soon as a single device isphysically-attacked. SANA [1] combines SEDA with a novelaggregate signature scheme which makes it more resilient tophysical attacks. DARPA [13] builds on top of SEDA byextending it with an absence detection protocol, which enablesdetection of physical attacks. However, DARPA’s computationand communication overhead is quadratic in the size of the

9

network. AID identifies physical attacks also based on absencedetection. However, AID enables efficient detection of physicalattacks based on local heartbeats. Also, by combining frequentattestation and absence detection with key exchange, AID en-ables detection of all software-compromised and/or physically-attacked devices in autonomous dynamic networks.Attestation & Key Exchange. There exists multiple work thatcombines attestation with key exchange [22], [20]. SAKE [22]aims at establishing shared keys between neighboring nodes insensor networks without relying on any prior shared secrets.Key exchange in SAKE is based on the attestation resultof one involved sensor node. Unfortunately, SAKE relieson a software-based attestation scheme whose security isbased on strong and unrealistic assumptions [4]. In [20] theauthors propose extending IPsec [15] key exchange protocolIKEv2 [14] with attestation. The goal of this extension is toensure the software trustworthiness of end points while theIPsec connection is running. However, the proposed extensiontargets legacy networks of high-end computing platformsand is not applicable to autonomous dynamic networks ofembedded systems.Absence Detection. Absence detection has been studied inthe context of Wireless Sensor Networks (WSNs) where it hasbeen used for detecting node failures. There are several priortechniques for both static [26] and dynamic topologies (e.g.,[12]). However, these are not designed with security in mind,and thus ineffective in our adversarial setting. Furthermore,there are WSN-focused techniques that use absence detectionto identify captured devices [7], [8]. However, some tech-niques are probabilistic and allow false negatives in dynamicnetworks, while others are only suitable for static networks,and cannot be easily extended to dynamic ones. The Proof-of-non-Absence (PonA) proposed in this paper allows one suchextension. Finally, the main drawback of all existing workis insecurity in our stronger adversary model as they are allvulnerable to remote software attacks.

VIII. CONCLUSIONS

Current attestation techniques are not scalable to large net-works of devices. For this reason, several collective attestationtechniques have been proposed. However, such techniques arenot applicable to large, autonomous dynamic IoT networks.In this paper, we present AID – the first collective attestationscheme for such networks. We reported on the implementationof AID on recent security architectures for low-end embeddeddevices, showing additional hardware cost. Further, in order todemonstrate its feasibility, we implemented and tested AID onour autonomous ad-hoc network formed of six interconnecteddrones. We also asses performance of AID, in terms of energyand run-time, based on real measurements and simulations ofup to 1, 000, 000-device networks.

ACKNOWLEDGMENT

This research was co-funded by the German Science Foun-dation, as part of project S2 within CRC 1119 CROSS-ING, HWSec, and the Intel Collaborative Research Institute

for Collaborative Autonomous & Resilient Systems (ICRI-CARS). Gene Tsudik was supported in part by: (1) DHS undersubcontract from HRL Laboratories, (2) ARO under contractW911NF-16-1-0536, and (3) NSF WiFiUS Program Award1702911.

REFERENCES

[1] M. Ambrosin et al. SANA: Secure and Scalable Aggregate NetworkAttestation. In ACM CCS, 2016.

[2] W. Arbaugh et al. A secure and reliable bootstrap architecture. InIEEE S&P, 1997.

[3] ARM Limited. Ssl library mbed tls / polarssl. https://tls.mbed.org/.[4] F. Armknecht et al. A security framework for the analysis and design

of software attestation. In ACM CCS, 2013.[5] N. Asokan et al. Seda: Scalable embedded device attestation. In ACM

CCS, 2015.[6] X. Carpent et al. Lightweight swarm attestation: A tale of two lisa-s.

In ASIACCS, 2017.[7] M. Conti et al. Emergent properties: Detection of the node-capture

attack in mobile wireless sensor networks. In WiSec, 2008.[8] M. Conti et al. Mobility and cooperation to thwart node capture

attacks in manets. EURASIP WCN, 2009.[9] G. de Meulenaer et al. On the energy cost of communication and

cryptography in wireless sensor networks. In WiMob, 2008.[10] K. Eldefrawy et al. SMART: Secure and minimal architecture for

(establishing a dynamic) root of trust. In NDSS, 2012.[11] A. Francillon et al. A minimalist approach to remote attestation. In

DATE, 2014.[12] N. Hayashibara et al. Failure detectors for large-scale distributed

systems. In SRDS, 2002.[13] A. Ibrahim et al. DARPA: Device Attestation Resilient against

Physical Attacks. In WiSec, 2016.[14] C. Kaufman. Internet Key Exchange (IKEv2) Protocol. RFC 4306

(Proposed Standard), 2005.[15] S. Kent et al. Security Architecture for the Internet Protocol. RFC

4301 (Proposed Standard), 2005.[16] P. Koeberl et al. TrustLite: A security architecture for tiny embedded

devices. In EuroSys, 2014.[17] X. Kovah et al. New results for timing-based attestation. In IEEE

S&P, 2012.[18] Y. Li et al. VIPER: Verifying the integrity of peripherals’ firmware. In

ACM CCS, 2011.[19] OpenSim Ltd. OMNeT++ discrete event simulator.

http://omnetpp.org/.[20] A.-R. Sadeghi et al. Extending ipsec for efficient remote attestation. In

FC, 2010.[21] D. Schneider. Jeep Hacking 101. http://spectrum.ieee.org/cars-that-

think/transportation/systems/jeep-hacking-101, 2015.[22] A. Seshadri et al. SAKE: Software attestation for key establishment in

sensor networks. In DCOSS. 2008.[23] S. Skorobogatov. Physical attacks on tamper resistance: Progress and

lessons. In Workshop on Hardware Assurance, 2011.[24] S. Skorobogatov. Physical attacks and tamper resistance. In

Introduction to Hardware Security and Trust. 2012.[25] S. P. Skorobogatov. Semi-invasive attacks: a new approach to

hardware security analysis. PhD thesis, 2005.[26] P. Stelling et al. A fault detection service for wide area distributed

computations. Cluster Computing, 1999.[27] Trusted Computing Group (TCG). Website.

http://www.trustedcomputinggroup.org, 2015.[28] J. Vijayan. Stuxnet renews power grid security concerns, 2010.[29] Y. Zhou et al. Side-channel attacks: Ten years after its publication and

the impacts on cryptographic module security testing. IACRCryptology ePrint Archive, 2005.

10