Seed: Secure Non-Interactive Attestation For Embedded Devices
Seed: Secure Non-Interactive Attestation For Embedded Devices
Embedded Devices
Ahmad Ibrahim Ahmad-Reza Sadeghi Shaza Zeitouni
TU Darmstadt TU Darmstadt TU Darmstadt
[email protected]. [email protected]. [email protected].
de de de
ABSTRACT or enables a more sophisticated attack threatening safety of the
Remote attestation is a security service that is typically realized users (e.g., see Jeep hack [1]).
by an interactive challenge-response protocol that allows a trusted One important defense mechanism against malware infestation,
verifier to capture the state of a potentially untrusted remote device. is remote attestation. Remote attestation is a security service that
However, existing attestation schemes are vulnerable to Denial of enables the detection of malware attacks on embedded devices. It is
Service (DoS) attacks, which can be carried out by swamping the usually realized as an interactive protocol between a trusted entity
targeted device with fake attestation requests. (denoted by the verifier), and one (or multiple) untrusted remote
In this paper, we propose SeED, the first non-interactive attesta- prover(s). The successful execution of this protocol provides assur-
tion protocol that mitigates DoS attacks and is highly efficient. ance to the verifier about the trustworthiness of (every) prover’s
Designing such a protocol is not straightforward, since it relies on software (i.e., absence of malware).
a potentially malicious prover to trigger the attestation process. We Existing attestation schemes targeting one prover can be clus-
investigate the related challenges and subtleties and describe how tered into three main classes: (1) Software-based attestation relies
to address them with minimal assumptions. As evaluation results on time-based checksums and requires no hardware modifications
show, our non-interactive attestation protocol is particularly suit- while providing weak (or no) security guarantees [14, 17, 20, 28–31];
able for resource-constrained embedded devices, since it is highly (2) Hardware-based attestation provides stronger security guaran-
efficient in terms of power consumption and communication. tees but requires complex and expensive hardware [4, 19, 24]; (3) Hy-
brid attestation schemes involve software/hardware co-design and
ACM Reference format:
are based on identifying minimal hardware trust anchor while pro-
Ahmad Ibrahim, Ahmad-Reza Sadeghi, and Shaza Zeitouni. 2017. SeED:
Secure Non-Interactive Attestation for Embedded Devices. In Proceedings viding strong security guaranties. The trust anchor can be as small
of WiSec ’17 , Boston, MA, USA, July 18-20, 2017, 11 pages. as a Read-Only Memory (ROM), and a simple Memory Protection
https://doi.org/10.1145/3098243.3098260 Unit (MPU) [8, 12, 13, 18]. It is worth mentioning that such hy-
brid schemes have enabled scaling attestation protocols to large
networks of embedded devices resulting in a collective (or swarm)
1 INTRODUCTION
attestation protocol as shown in [3, 6, 16].
Embedded devices are proliferating into numerous and diverse All existing attestation schemes involve an interactive protocol
aspects of everyday life. These devices are utilized in different (i.e., initiated with a random challenge sent by the verifier), and are
domains ranging from tiny personal gadgets to large industrial in- vulnerable to Denial of Service (DoS) attacks. DoS attacks originate
stallations. Unlike traditional computing devices, embedded devices from the use of un-authenticated challenges, and can be carried out
are (1) limited in cost, size, energy consumption, and computing by sending (a large number of) fake attestation requests to a targeted
power; (2) have limited and intermittent connectivity; and (3) lack prover. DoS attacks on provers caused by maliciously invoking
the resources necessary to defend themselves against attacks. As attestation procedures represent a real security threat, since it may
a consequence, despite obvious benefits, enabling remote access drain the battery of a device, or preclude it from performing its
to such unprotected devices with limited resources poses a great original tasks. We are aware of only two existing schemes, which
security challenge. Indeed, these devices present an attractive tar- take DoS attacks against attestation protocols into consideration.
get for remote attackers, and a successful attack would have major SANA [3] requires a security token (acquired from a trusted third
consequences compromising both privacy and safety. party) for attesting an embedded network, in order to prevent
Malware infestation involves modifying a device’s firmware and/or the scaling of attestation-based DoS attacks to large embedded
software, and replacing benign code with a malicious one. This can networks. Howerver, SANA requires a trusted third party, and is
cause the destruction of physical equipment (e.g., see Stuxnet [34]), based on expensive public key cryptography which increases the
Permission to make digital or hard copies of all or part of this work for personal or attestation overhead considerably. The work in [9], proposes a
classroom use is granted without fee provided that copies are not made or distributed DoS Mitigation technique for attestation based on authenticating
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
attestation requests (challenges) such that a prover has to verify
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, that the request is sent by a ‘trusted verifier’ before proceeding
to post on servers or to redistribute to lists, requires prior specific permission and/or a with attestation computations. However, it also imposes additional
fee. Request permissions from [email protected].
WiSec ’17 , July 18-20, 2017, Boston, MA, USA
overhead on a resource-constrained prover without completely
© 2017 Association for Computing Machinery. preventing DoS attacks, which would still be possible, as an attacker
ACM ISBN 978-1-4503-5084-6/17/07. . . $15.00
https://doi.org/10.1145/3098243.3098260
64
WiSec ’17 , July 18-20, 2017, Boston, MA, USA Ahmad Ibrahim, Ahmad-Reza Sadeghi, and Shaza Zeitouni
can simply flood the prover with bogus requests and force it to verify being compromised. This approach is usually adopted when
them. attestation is triggered by some detection mechanism, e.g.,
intrusion detection techniques, which are known to generate
Goals and contributions: false positives.
In this paper, we present SeED, the first non-interactive attesta- • Strategy #2 (Maintenance): In other scenarios, attestation
tion protocol that completely mitigates DoS attacks on the prover is used as a standalone method for monitoring untrusted
side. Designing such a protocol is challenging, since it relies on devices and detecting malware infestation. In these scenarios,
a potentially malicious prover to trigger the attestation process. Vrf decides when to attest Prv(s) to determine whether they
Therefore, we analyze the requirements for designing secure and are infested by malware.
non-interactive attestation protocol and depict how to address them In both strategies, Vrf is required to initiate the attestation proto-
with minimal features and assumptions. Further, we identify possi- col. However, we claim that strategy #2 corresponds to the most
ble use-cases, where a non-interactive attestation protocol can be vibrant use of attestation, especially in the case of standalone de-
applied. Our work brings the following three contributions: vices, where detection techniques (such as intrusion detection) do
• Non-Interactive Attestation: We present SeED– the first not apply. Therefore, providing the necessary hardware features
Secure Non-Interactive attestation scheme that is inherently (see Section 3), the trust anchor on Prv that is entitled of the gener-
resilient to DoS attacks. Since it is not initiated by the verifier, ation and authentication of software measurements, can be trusted
SeED imposes low communication overhead and reduces to initiate the attestation protocol and generate timely responses.
power consumption.
• Requirement Analysis: We analyze the security of non- 2.1 Adversary Models
interactive attestation under different adverserial capabilities We cluster attackers on attestation into three classes based on their
and extract the minimal requirements for securing such a capabilities and/or attack strategies. Our classification is inspired
protocol. by the taxonomy in [2]. Note that, these three classes fall under the
• Implementation and Evaluation: We implement SeED on software-only advesary model assumed in all existing attestation
top of different security architectures for low-end embedded schemes [8, 9, 12, 13, 18]. However, the distinction between different
devices (e.g., SMART [12] and TrustLite [18]). Evaluation re- capabilities/strategies is only required to extract and motivate our
sults show an improvement of up to 50% in energy consump- protocol construction and its underlying hardware features.
tion and 35% over runtime of existing attestation schemes.
Communication Adversary. ADVcom has full control over all
We further discuss its inherent benefits and influence on
communication channels; it is capable of injecting its own packets
attestation of embedded networks.
and eavesdropping on, modifying, delaying, and dropping packets
Outline. We review in Section 2 existing attestation protocols, exchanged between Vrf and Prv.
relevant adversary models and DoS attacks on attestation. In Sec- Software Adversary. ADVsoft exploits software vulnerabilities
tion 3, we provide required preliminaries and notations, identify to infect Prv, read its unprotected memory regions, and manipulate
the minimal requirements for secure non-interactive attestation its software state (e.g., by injecting malware in Prv).
and describe SeED. Two prototype implementation of SeED are Mobile Adversary. In addition to ADVsoft capabilities, ADVmob
then described in Section 4, its application to collective attestation is also capable of erasing all traces of its previous presence on Prv
is explained in Section 5, and performance results are shown in Sec- (e.g., removing malware from Prv). ADVmob follows a sophisti-
tion 6. Next, security of SeED is evaluated in Section 7. Related work cated attack strategy in order to evade detection by the attestation
is summarized in Section 8 and the paper concludes in Section 9. protocol. The attack is executed in two phases:
2 PROBLEM DESCRIPTION: INTERACTIVE • Phase #1: ADVmob compromises Prv by installing mal-
ware (i.e., introducing malicious code)
ATTESTATION & DOS ATTACKS
• Phase #2: Right before the execution of attestation protocol,
Remote attestation is an interactive protocol between a trusted ADVmob leaves Prv, i.e., it erases its traces by removing
verifier (denoted by Vrf) and a potentially untrusted remote prover the introduced malware, and restoring Prv to its original
(Prv). It provides assurance to Vrf that Prv is in a trustworthy soft- benign state
ware state (i.e., not infested by malware). The protocol is initiated
by Vrf sending a random challenge N to Prv. N indicates Vrf’s Note that, executing such a sophisticated attack requires the knowl-
interest in attesting Prv, and is necessary for mitigating replay edge of the exact execution time of attestation.
attacks. Upon receipt of the challenge, the trust anchor on Prv cre-
ates a measurement h of its software (e.g., a hash of its binary). h is 2.2 DoS Attack on Attestation Protocols
attached to N and is usually authenticated via a symmetric shared Denial of Service attacks on attestation protocols impose a seri-
key (katt ), then sent back to Vrf. As shown in Figure 1, two different ous security threat, especially when targeting low-end embedded
strategies can be followed by Vrf to determine the attestation time, devices, as such attacks can dissipate their limited resources and
i.e., the time at which it initiates the attestation protocol: cause them to shut down. DoS attack can be carried out through
• Strategy #1 (Suspicion): Vrf initiates attestation of a cer- the repeated un-authorized invocation of attestation functionality
tain Prv based on some event, e.g., when Prv is suspected of on Prv, i.e., by replaying or fabricating bogus attestation requests.
65
SeED: Secure Non-Interactive Attestation for
Embedded Devices WiSec ’17 , July 18-20, 2017, Boston, MA, USA
As a countermeasure, authors of [9] propose using MACs to au- hand, due to its low communication overhead and random attesta-
thenticate attestation requests such that Prv has to verify that the tion times (see Section 3), Non-interactive attestation also causes
request is coming from the trusted verifier before proceeding with lower network congestion and end-to-end delay when multiple
the attestation. The freshness of the request is guarnteed using provers are attested individually.
timestamps (assuming that both, Vrf and Prv, have synchronized
clocks). However, even when such countermeasure is applied, an 3.1 Preliminaries and Notation
attacker, who can eavesdrop on communications between Vrf and
Let |M | denotes the number of elements in a finite set M. Further-
Prv could still replay authenticated requests, causing Prv to repeat-
more, let {0, 1} ℓ be the set of all bit-strings of length ℓ. If E is some
edly invoke the verification process before dropping the incoming
event (e.g., the result of a security experiment), then Pr[E] denotes
request (due to timestamps’ staleness). Based on public key cryptog-
the probability that E occurs. Probability ϵ(ℓ) is called negligible if,
raphy, SANA [3] adopts the same solution to prevent DoS attacks
for all polynomials f , ϵ(ℓ) ≤ 1/f (ℓ) for all sufficiently large ℓ ∈ N.
on collective attestation. Since verifying a digital signature is more
expensive than verifying a MAC, SANA is considered more prune Message Authentication Code. Message authentication code (MAC)
to the DoS attack described above. is defined as a tuple of (probabilistic polynomial time) algorithms
(genkeymac, mac, vermac). k ← genkeymac(1ℓmac ) outputs a se-
cret key k with security parameter ℓmac ∈ N. µ ← mac(k; m) out-
3 SECURE NON-INTERACTIVE puts a MAC digest µ on input of m and k. vermac(k; m, µ) ∈ {0, 1}
ATTESTATION verifies µ on input of m and k.
As shown in Figure 1, a non-interactive attestation protocol between Pseudorandom Number Generator. A pseudorandom number
a verifier Vrf and a prover Prv is composed of a single response generator (PRNG) is a (probabilistic polynomial time) algorithm
message sent from Prv to Vrf. This brings a number of benefits to gen. {σi , θ i } ← gen(σi−1 ) outputs internal state σi ∈ {0, 1} ℓσ and
Prv that we list below: random output θ i ∈ {0, 1} ℓθ on input of previous internal state
Resiliency to DoS Attacks. Non-interactive attestation is inher- σi−1 .
ently secure against DoS attacks on Prv. In fact, it completely solves A summary of all variables, parameters and procedures used
the DoS problem on the prover of an attestation protocol, without in the description and evaluation of our proposed protocol, in the
imposing the additional overhead of authenticating attestation re- following sections, is available in Table 1.
quests [9]. The reason for this is that Prv has no incoming traffic
for the attestation protocol. 3.2 Requirements Identification
Low Communication Overhead. It is self-evident that a non- For the sake of simplicity, we gradually identify the requirments for
interactive attestation protocol has lower communication overhead designing a secure non-interactive attestation protocol. We start
than interactive attestation. In fact, by dropping the challenge, the with the following assumption: Prv performs attestation periodi-
communication overhead can be reduced by up to 50% (depending const . We assess this assumption under
cally at fixed time interval tatt
on the hash function used). This reduction is particularly significant different attackers from different adverserial classes to extract the
for battery-operated low-end embedded devices, since, on such minimal requirments in order to assure security of non-interactive
devices, the energy consumption required for communicating 1-bit attestation.
of data, can be as high as for executing 800 − 1000 instructions [15]. At Prv side, attestation procedure starts at Tatt by generating re-
Low Network Congestion. Non-interactive attestation induces sponse message; a MAC digest µ based on the attestation key katt
lower latency and energy consumption when combined with ex- (pre-shared with Vrf) over: a measurement h of the current soft-
isting collective attestation schemes (e.g., SEDA [6]). On the other ware state of Prv, and a monotonic counter C (to prevent replay
66
WiSec ’17 , July 18-20, 2017, Boston, MA, USA Ahmad Ibrahim, Ahmad-Reza Sadeghi, and Shaza Zeitouni
Table 1: Variables, parameters and procedures that, the common assumption in such attacks is that Vrf is unaware
when to expect an attestation response.
Entities
• Delay Attacks: The simplest way to avoid detection of
Vrf Verifier ADVcom , during the execution of an attack, is to delay
Prv Prover the attestation response sent by Prv until ADVcom is done
EN Embedded Network executing the attack and has achieved its goal
Prvi Prv i in EN • Dropping Attacks: Since Vrf detects compromised Prv
ADV Adversary only when receiving an attestation response showing a mea-
ADVcom Communication Adversary surement of a malicious software. ADVcom may drop every
ADVsoft Software Adversary attestation response which doesn’t indicate a benign soft-
ADVmob Mobile Adversary ware state
Protocol parameters • Record and Play Attacks: The ultimate attack would in-
volve recording and dropping benign attestation responses
katt Secret Attestation Key and later replaying them during an attack to convince the
satt Secret Random Seed Vrf that Prv is in a benign state
n Number of Devices in EN
N Random Nonce Mitigation. To mitigate such attacks, Vrf and Prv should have
h Software Measurement of Prv synchronized clocks that indicate attestation times for both entities.
b Benign Software Measurement of Prv When Vrf does not receive an attestation response within the
µ A MAC based on katt expected time limits, it assumes that Prv has been compromised.
r Attestation Result (1 indicates success and 0 Note that, since synchronized clocks are identified as a requirement
indicates failure) for non-interactive attestation, timestamps can replace monotonic
σ Internal State of PRNG counters.
Security under ADVsoft . Based on purely remote software
Time parameters
techniques, ADVsoft may perform the following attacks:
Trec Time of receiving an attestation response
Tatt Attestation time • Fake Measurements: ADVsoft can intercept and modify
tatt Random time interval before the next attesta- the process responsible for measuring the software state.
tion Thus, enabling the generation of a benign attestation re-
Max
tatt Maximum time period between two consecu- sponse which is independent of the actual software state on
tive attestations Prv
const
tatt Fixed time interval between two consecutive • Forged Measurements: Relying on software techniques,
attestations ADVsoft can extract the key katt used for authenticating
ttr Maximum time required to communicate a re- attestation results. Having katt , ADVsoft would be capable
sponse between Vrf and Prv of forging any attestation response at anytime regardless of
δt Maximum clock skew between Vrf and Prv Prv’s state
tmal Time period during which Prv is compromised • Pre-Generated Measurements: By manipulating Prv’s clock,
C Monotonic Counter ADVsoft can trick Prv to generate future measurements of
current benign software. These measurements can be stored
Procedures for later use as attestation responses sent to Vrf during the
time( ) Returns current time execution of an attack
timeout(tatt ) Sets timer to expire after tatt period of time
Mitigation. To tackle these attacks, the integrity of the measure-
getSoftMeas( ) Returns a measurement of the current software
ment process, the confidentiality of katt , and the integrity of Prv’s
of Prv
clock must all be protected by leveraging hardware assistance.
Security under ADVmob . Knowing the exact time interval
between attestation measurments tatt const , ADV
attacks). After receiving a message from Prv, Vrf determines the mob can evade de-
trustworthiness of Prv by: (1) checking the message’s authenticity, tection, by following the strategy described in Section 2.1. More
i.e., verifying µ; (2) checking its freshness, i.e., checking whether particularly, ADVmob observes Prv for some period of time to
const . Then, ADV
figure out tatt
the value of received counter C is higher than its locally-stored mob infects Prv (i.e., by installing
value; and (3) checking whether the contained measurement h malware) at the end of a successful attestation. Directly before
corresponds to a benign software state. Vrf outputs its decision the consequent execution of the attestation protocol, ADVmob
r indicating whether Prv is in a benign or malicious state (0 for restores the original benign software. By executing this process re-
malicious and 1 for benign). peatedly, ADVmob can evade detection while keeping Prv infected
Security under ADVcom . Having full control over commu- for the longest time possible.
nication channels between Vrf and Prv, ADVcom can perform Mitigation. A key aspect of the attack described above is the previ-
several attacks. In the following, we outline some of them. Note ous knowledge of the exact attestation time. Consequently, securing
67
SeED: Secure Non-Interactive Attestation for
Embedded Devices WiSec ’17 , July 18-20, 2017, Boston, MA, USA
non-interactive attestation, requires hiding the exact attestation the protocol code only. MPU has been identified as a minimal
times from ADV. This is achieved in two steps: requirement for secure remote attestation in [8, 12, 13, 18]
(1) Randomization: Attestation should be executed at random • Real-Time Clock (RTC): A measurement of Prv’s soft-
times, that are not predictable by ADV. However, as men- ware should be tied to its generation time. Therefore, a real-
tioned above, these times should be known to both Vrf and time write-protected clock, which is not modifiable by a
Prv. For this reason, we propose using pseudorandom num- software-only adversary, is required. RTC enforces the gen-
bers. Consequently, Vrf and Prv are required to at least share eration of attestation responses on-time and prohibts the
the seed for a Pseudorandom Number Generator (PRNG) generation of responses over old software measurements.
(2) Confidential Trigger Time: The attestation time should not RTC has already been used to detect physical attacks in [16]
be readable by the code responsible for triggering the at- and to mitigate DoS attacks on attestation in [9]
testation process (e.g., scheduler). This can be either done • Attestation Trigger: In a secure non-interactive attestation
(1) in software, using polling; or (2) in hardware, based on scheme, the attestation time should not even be known to
non-maskable interrupt (NMI) the entity triggering the attestation process (i.e., operating
system). For this reason, a dedicated timeout circuit is re-
3.3 SeED: Protocol Description quired. This timeout circuit, simply updates and monitors
the value of a timer stored in a secure register. It also triggers
Taking into consideration all previously mentioned requirements,
a non-maskable interrupt (NMI) upon the expiry of the timer
and assuming that Vrf and Prv share two secrets: (1) the attestation
key katt used for authenticating the attestation response, and (2) the Note that, all of the aforementioned hardware features, except
random seed satt used by the Pseudorandom Number Generator for the attestation trigger, have already been either required for
(PRNG) to generate a random attestation time (timer) that triggers enabling secure remote attestation (i.e., ROM and MPU), or for
the next attestation process at Tatt . We now describe a secure non- mitigating DoS attacks on Prv (i.e., RTC).
interactive attestation protocol – SeED. As shown in Figure 2, at
attestation time Tatt , Prv generates a measurement h of its software, 4 PROTOTYPE AND IMPLEMENTATION
attaches it to the current time attestation time Tatt , authenticates it We implemented SeED on top of two recent security architectures
with a MAC based on katt , and send it to Vrf. Vrf, in turn, expects for attestation on low-end embedded devices: SMART [12] and
to receive an attestation response at any time between Tatt − δ t and TrustLite [18]. In the following we describe these implementations.
Tatt +δ t + ttr (i.e., Tatt −δ t < Trec < Tatt +δ t + ttr ), where Tatt is the
expected attestation time, δ t is the maximum clock skew between 4.1 SMART and TrustLite
Vrf and Prv, and ttr is the maximum time required to transmit SMART. SMART [12] provides secure remote attestation for low-
the response between Vrf and Prv. If a response is received at end embedded devices based on minimal hardware assumptions.
Trec , Vrf checks (1) its authenticity, by verifying the MAC µ; (2) its The two main components of SMART are: (1) a read-only mem-
freshness, by checking whether the attached time corresponds to ory (ROM) storing the attestation code (denoted by ROM code)
the present Tatt ; and (3) Prv’s trustworthiness, by checking whether and the attestation key katt ; and (2) a simple Memory Protection
the measurement h corresponds to a benign software state b. If all Unit (MPU), that restricts access to ROM, where katt is stored, to
checks succeed, Vrf concludes that Prv is in a trustworthy state, the software entitled to access it. Both ROM and MPU represent
setting r to 1. On the other hand, if no attestation response was minimal hardware requirement for secure remote attestation and
received when expected, or any if the three checks failed, Vrf they are simple and inexpensive to realize. The basic idea is that
concludes that Prv is malicious (i.e., infested by malware) and sets ADVsoft is unable to modify any code stored in ROM. Thus en-
r to 0. suring the integrity of attestation code. On the other hand, MPU
grants exclusive access to katt to ROM code. This is done by check-
3.4 Requirements Implementation ing whether the program counter is within the ROM address space
Securing non-interactive attestation, as discussed above, requires whenever katt is to be accessed. As a result, only genuine attestation
leveraging hardware assistance to: (1) have synchronized clocks code has access to katt .
between Prv and Vrf; (2) assure integrity of both, the clock and We implement our protocol on a slightly modified version of
the measurement process on Prv side; and (3) securely provision SMART, as shown in Figure 3. We extend MPU rules to control
Prv with katt and satt . This can be achieved by having the following access to a small portion of the re-writable memory. This preserved
features: memory, with restricted access, is required to store protocol’s inter-
• Read-Only Memory (ROM): The integrity of the code used mediate data. Mainly, it is used to store the internal state of PRNG
to perform measurement should be protected. This can be σ , and the timer tatt .
done by storing the code itself in ROM (e.g., SMART [12]), TrustLite. TrustLite [18] is a security architecture for embedded
or verifying its integrity through a secure boot procedure, systems, that enables isolated execution of software components
whose code is stored in ROM (e.g., TrustLite [18]) (e.g., SeED’s code). Similar to SMART, a simple MPU ensures that
• Memory Protection Unit (MPU): In order to preserve the data can be accessed only by the code of the component that owns
confidentiality of the attestation key katt and attestation that data. Access rules are enforced based on the value of the pro-
times (generated from the seed satt ), a simple MPU is re- gram counter (PC). and is hereby called execution-aware memory
quired. MPU provides read-only access to these secrets to protection unit (EA-MPU). Finally, authenticity and confidentiality
68
WiSec ’17 , July 18-20, 2017, Boston, MA, USA Ahmad Ibrahim, Ahmad-Reza Sadeghi, and Shaza Zeitouni
{σi , θi } ← gen(σi−1 )
Max
tatt ← θi mod tatt
timeout(tatt )
h ← getSoftMeas( )
µ ← mac(katt ; hkTatt )
µ
{σi , θi } ← gen(σi−1 )
Max
tatt ← θi mod tatt
Trec ← time( )
r ←1
end if
end if
Memory Memory
CPU Clock System CPU Clock System
ROM ROM
OS OS
Program Memory Program Memory
RTC Timeout 𝑅0 Counter (PC) Address
RTC Timeout
𝑅0
Counter (PC) Address σx Secure Boot 𝑅2 SeED
SeED
MPU 𝑅2 Tatt satt
𝐌𝐚𝐱
𝐓𝐚𝐭𝐭 MPU katt
satt 𝑅1 kplatform
𝑅1
Code Region Memory Region Permissions
tatt
Code Region Memory Region Permissions 𝑅3 σx
katt
R0 R1 r R0 R1 r Tatt
Max
R0 R2 r&w SW 1 R0 R2 r Tatt
R2 R3 r&w tatt
Figure 3: Implementation of SeED based on SMART [12] Figure 4: Implementation of SeED based on TrustLite [18]
of both code and data of isolated components are ensured via means this data to SeED’s code only. Finally, the integrity of SeED’s code is
of secure boot. On the other hand, the integrity of secure boot code protected via ROM (on SMART) or secure boot (on TrustLite). Also,
is protected by storing it in ROM. run-time threats on the protocol code are reduced by limiting code
Keys and Variables. Our implementation of SeED is illustrated entry points [12], and leveraging control flow integrity (CFI) [5].
in Figure 3 and Figure 4. The secret attestation key katt and the Real-Time Clock. As discussed in Section 3, enabling secure non-
secret random seed satt , are both read- and write-protected by ROM interactive attestation requires a Real-Time Clock (RTC), that is not
and/or by an MPU rule. This rule ensures that SeED’s code has modifiable by software. In addition to being write-protected, RTC
exclusive read access to these two secrets. On the other hand, SeED’s should have a very large counter, that does not wrap around during
intermediate data (i.e., timer, and internal state of PRNG) are stored Prv’s lifetime. Indeed, using a 64-bit register solves this problem, as
in writable memory, and are both read- and write-protected through it would need 73, 117 years to wrap around on an 8 MHz SMART,
an MPU rule. This rule provides exclusive read and write access to even when incremented at every clock cycle. However, since SeED
69
SeED: Secure Non-Interactive Attestation for
Embedded Devices WiSec ’17 , July 18-20, 2017, Boston, MA, USA
does not require such a granular time input, a 32-bit register would cryptographic primitives are required to be implemented. We only
suffice, if it is incremented every 100, 000 cycle (i.e., providing a need to add the code required for: (1) generating random attesta-
resolution of 13 ms), as it would wrap around in about 2 years. On a tion time, and writing it to I/O mapped memory; and (2) requesting
24 MHz TrustLite, on the other hand, a 64-bit register would wrap and including a timestamp in the attestation response. These mod-
around in 24, 372 years, and a 32-bit register would wrap around ification incurs only few additional Lines-of-Code (LoCs), which
in 3 years, if incremented every 500, 000 cycle (i.e., providing a corresponds to less than 200 bytes increase in code size.
resolution of 21 ms). Hardware Costs. The implemented hardware components include
a real-time clock, a timeout circuit and MPU rules required to con-
5 APPLICATION TO COLLECTIVE trol access to sensitive data in the memory. We compare the hard-
ATTESTATION ware cost of our implementation of SeED to that of TrustLite [18]
Securing embedded networks is a challenging problem. A number and DoS-Resilient attestation from [9], in terms of required registers
of research work has been conducted that aims at scaling existing and Look-up Tables (LUT).
remote attestation protocol to large networks [3, 6, 16] (denoted
by swarm/collective attestation). Existing collective attestation pro- Table 2: Hardware cost of SeED
tocols can also be realized as non-interactive protocols.1 This is
done by sharing the same random seed between all n provers (Prv1 Register Look-up Table
through Prvn ) in a network EN, making them all report within a
very short time interval from each other, and then aggregating the TrustLite [18] 6038 15142
reports based on the protocol in [6].
On the other hand, SeED can also be extended to support a more DoS-Resilient [9] 6186 15356
efficient individual attestation of Prv’s in EN. In this extension, Prv’s SeED 6335 15580
are made to report at different times, by giving them different secret
random seeds. Consequently, bursty network traffic is avoided by
spreading reporting over a large time window. In the following we As shown in Table 2, the DoS-Resilient attestation described in
describe this extension. [9] imposes an increase of 2.45% and 1.41% over the original cost
Initialization. Each prover Prvi in EN is initialized by Vrf with the of TrustLite (in terms of the required registers and LUTs). This is
cryptographic secrets required for non-interactive attestation, i.e., due to the cost of the clock, and the additional MPU rule required
i used for authenticating attestation responses,
an attestation key katt to protect the clock. SeED has only an additional cost of 4.92% and
i , used for generating random attestation 2.9% compared to TrustLite.
and a random seed satt
times. Overhead. In the following we quantify the memory, computa-
i , and tional, and communication costs of SeED:
Attestation. Each prover Prvi waits until attestation time Tatt
then generates an attestation response formed of a MAC µ i over • Memory: Prv in SeED needs to store a 20-byte secret key
its current software measurement hi and the attestation time Tatt i , and a 20-byte secret random seed in ROM which should be
i
based on katt shared with Vrf. On the other hand, for each prover read-protected. Also, Prv stores a 4-byte protocol constant
Max , a 4-byte timer t , and a 20-byte internal state σ of
tatt
Prvi , Vrf awaits an attestation response to be received within the att
i − δ , T i + δ + t ]. When a response is received, Vrf
interval [Tatt PRNG on write-protected memory. Overall, SeED requires
t att t tr
verifies its authenticity, freshness, and trustworthiness. If all checks additional 20 bytes of ROM, and 28 bytes of Random Access
succeed, Vrf concludes that Prvi is benign. Otherwise, if one check Memory (RAM) or flash on SMART and 48 bytes of Random
fails or no response was received within the expected interval, Vrf Access Memory (RAM) or flash on TrustLite.
concludes that Prvi is malicious. If all provers in EN are benign, Vrf • Computation: Most of the computational cost in SeED is due
outputs r = 1. Otherwise, it outputs r = 0. to cryptographic operations. For every generated attestation
In addition to lower communication overhead, non-interactive response, SeED needs to generate 32 random bits, and one
collective attestation offers lower network congestion compared MAC, and calculate a hash over the amount of memory
to naively attesting individual devices at the same time. It also to be attested. The additional computation cost imposed
normalizes Vrf’s overhead and stretches it over a longer period of over traditional attestation is only due to random number
time. Leading to a shorter end-to-end delay (i.e., time between the generation.
initiation of the protocol and identification of a prover’s infection). • Communication: In SeED, each Prv is only required to send
a 20 bytes MAC to Vrf for each run of the protocol. In tradi-
6 PERFORMANCE EVALUATION tional attestation protocols, Prv is also required to receive a
random challenge of at least 20 bytes. As mentioned earlier,
6.1 SeED: Single-Device Attestation on low-end devices the energy consumption of communicat-
Software Complexity. In our implementation on SMART [12] and ing 1-bit of data is equivalnet to that of executing 800 − 1000
TrustLite [18], we use HMAC-DRBG [7] based on SHA-1 as a Pseu- instructions [15].
dorandom Number Generator (PRNG). Consequently, no additional Energy costs. Based on previous studies, that reported energy
1 We assume that the spanning tree is already constructed following the protocol in consumption for cryptographic operations and communication in
[6]. sensor networks [11], we estimate energy consumption of SeED,
70
WiSec ’17 , July 18-20, 2017, Boston, MA, USA Ahmad Ibrahim, Ahmad-Reza Sadeghi, and Shaza Zeitouni
0.7 0.9
0.6 0.8
Traditional
DoS-protected 0.7
0.5
SeED 0.6
Runtime (s)
Runtime (s)
0.4 0.5
0.3 0.4
Traditional
0.3 DoS-protected
0.2 SeED
0.2
0.1 0.1
0 0
2 4 6 8 10 12 14 16 18 20 50 100 150 200 250 300
Number of hops Software size (KB)
Figure 5: Attestation runtime as function of number of hops Figure 6: Attestation runtime as function of attested soft-
ware size
and compare it to traditional and DoS-Resilient attestation schemes.
Our estimation excludes the energy required to generate the soft- 12
ware measurement which is the same in all cases. The results are 10
SEDA(MICAz)
shown in Table 3. As shown in the table, the additional energy SEDA(telosB)
Energy (mJ)
8 SeED(MICAz)
consumption required by DoS-protected attestation is almost 70% SeED(telosB)
of that of traditional attestation (for both TelosB and MICAz sensor 6
Traditional 0.253 0.241 number hops of between Vrf and Prv, and (4) the size of the mea-
DoS-Resilient [9] 0.418 0.408 sured software. Figure 5 and Figure 6 show the runtime of SeED
on TrustLite as function of the number of hops and the size of the
SeED 0.129 0.152 attested software respectively. Figures for SMART are omitted due
to space constraints.
Runtime. We also measure the runtime of SeED and compare it
to both traditional and DoS-Resilient attestation schemes. We base
6.2 SeED: Collective Attestation
our measurements on the 20-kbps minimum communication rate We evaluated the energy consumption and runtime of a collective
of ZigBee2 . non-interactive attestation protocol based on SEDA [6] in compari-
son to the original implementation of the protocol.
Table 4: Runtime of SeED (ms) Energy costs. Figure 7 shows estimations of the energy consump-
tion on each individual device after one execution of the protocol.
These estimations are also based on previously reported energy
SMART [12] TrustLite [18]
consumption for cryptographic operations and communication in
Traditional 948 288 sensor networks [11]. As can be seen in Figure 7, the energy con-
sumption of both protocols is linear in the number of neighbors
DoS-Resilient [9] 1, 150 394 per device. However, SeED shows a considerably lower energy con-
SeED 692 187 sumption on both MICAz and TelosB sensor nodes, when applied to
a collective attestation protocol like SEDA. The reduction in energy
consumption comes mainly from a lower communication overhead
As shown in Table 4, SeED leads to an improvement of 27% (and induced by SeED. This reduction increases linearly with the number
35%) over the runtime of traditional attestation, and that of 40% of neighbors per device. It can be as low as 0.6 mJ (40% of the over-
(and 53%) over runtime of DoS-Resilient attestation on SMART all energy consumption) in networks with 1 neighboring MICAz
(and TrustLite respectively). These measurements assume that Vrf devices, and up to 5 mJ (45% of the overall energy consumption) in
and Prv are 10 hops away, and that the size of the software to be networks with 12 neighboring telosB device.
measured is 50-kilobytes. Note that, the improvement percentage Runtime. We used OMNeT++ [23] event simulator to evaluate the
depends on different factors including: (1) the bandwidth of the performance of the non-interactive collective attestation protocol
communication channel, (2) devices’ computational power, (3) the based on SEDA [6]. Similar to previous work [3, 6, 16], we simulate
2 ZigBee is a common communication protocol for IoT devices. cryptographic operations as delays based on real measurements
71
SeED: Secure Non-Interactive Attestation for
Embedded Devices WiSec ’17 , July 18-20, 2017, Boston, MA, USA
0.8
0.6
SEDA
0.4
SeED Proof sketch of Theorem 1. Vrf returns b = 1, only if (1) no
0.2 attestation responses were expected during the time of the attack;
0
or (2) attestation response(s) was received in the expected time, and
0 200000 400000 600000 800000 1e+06 it passed Vrf’s checks (i.e., the response is fresh, authentic, and
Network size
corresponds to a benign software). We distinguish among three
cases:
Figure 8: Attestation runtime of SeED vs. SEDA
• Communication Attacks: Given full control over commu-
nication channels between Vrf and Prv, ADVcom either
from SMART [12] and TrustLite [18]. We considered networks with completely drops, or delays the attestation response till the
up to 1, 000, 000 devices, having different topologies, and variable end of the experiment (i.e., after Vrf outputs its decision).
number of neighbors. However, due to limited space, we only show However, since: (1) the attack time tmal is greater than the
the results for binary trees. We assume that each device has 50 KB maximum time between two consecutive attestations (tatt Max ),
of software to be attested. As shown in Figure 8, the runtime of both Vrf would be expecting an attestation response before the
SeED and SEDA is logarithmic in the size of the network. However, end of the experiment. Therefore, dropping or delaying re-
SeED shows a considerably better performance than SEDA. The sponses will be detected by Vrf, which will output b = 0. On
significance of the performance improvement increases with the the other hand, ADVcom replays previously recorded re-
size of the network. It can be as low as 5% (27-milliseconds) in sponses which correspond to benign software measurements.
networks of only 3 devices, and as high as 28% (346-milliseconds) However, since Vrf checks the freshness of the received re-
in networks of 1, 000, 000 devices. Note that, SeED shows more sponses, the probability of Vrf accepting replayed responses
improvement over SEDA in linear topologies, as communication and outputting b = 1 is negligible in ℓclock
in such topolgies plays a more significant role. However, we only • Software Attacks: Based on purely remote software tech-
show performance results for tree topology, since it presents the niques, ADVsoft may enable the generation of fresh, au-
most interesting use case for collective attestation in general. thentic, and benign response by: (1) modifying the process
responsible for measuring software state, (2) extracting the
7 SECURITY ANALYSIS authentication key katt used for authenticating attestation
The goal of a non-interactive attestation protocol is to enable Vrf responses, or (3) manipulating Prv’s clock. However, this
to detect modifications to Prv’s software (e.g., malware infesta- is not possible since: (1) the integrity of the measurement
tion). We formalize this based on a security experiment Exp A D V , code is protected through Read-only Memory (ROM) on
where an adversary ADV interacts with Prv and Vrf. Recall that, SMART [12] (and secure boot on TrustLite [18]), (2) secrecy
ADV can eavesdrop on, delete, and modify any message between of katt is protected by appropriate rules in Memory Protec-
Prv and Vrf. It can also send arbitrary messages to Prv and Vrf tions Unit (MPU), and (3) Prv has a Real-Time Clock (RTC),
(ADVcom ). Furthermore, ADV can modify Prv’s software by which is not accessible by any software. Finally, ADVcom
injecting malware (ADVsoft ). It can also erase all traces of its pres- may try to modify the software in a way that is not de-
ence, i.e., erasing malware and restoring Prv to its original benign tectable by the measurement process, or forge a MAC on
state (ADVmob ). During the experiment, ADV attacks Prv and the benign measurement and a fresh timestamp, in order to
modifies its software. In order to achieve its goal, the attack should convince Vrf into outputting b = 1. However, these attacks
last for a non-negligible amount of time tmal > tattMax , during which are negligible in ℓhash and ℓmac respectively
ADV can restore Prv to its original state within a negligible pe- • Hide and Seek: A more sophisticated adversary ADVmob
riod of time. After a polynomial number (in terms of the security may try to evade detection and convince Vrf to output b = 1,
parameters ℓmac , ℓhash , ℓclock , and ℓgen ) of steps by ADV, Vrf by restoring Prv to its original benign state directly before
outputs its decision bit b = 1 indicating that it considers Prv to be the execution of the attestation protocol. Since ADVmob
benign, or b = 0 if otherwise. The result is defined as the output can restore Prv within a negligible amount of time, ADVmob
of Vrf, i.e., Exp A D V = b. A secure non-interactive attestation should know the exact attestation time in order for this at-
scheme is defined as: tack to succeed. However, ADVmob has no access to the
next attestation time tatt , which is protected by appropriate
Definition 1 (Secure non-interactive attestation). A non- rule of MPU, and the probability of predicting it is negligible
interactive attestation scheme is secure if Pr b = 1|Exp A D V (1ℓ ) = b in ℓgen
is negligible in value of ℓ = f (ℓmac , ℓhash , ℓclock , ℓgen ), where func-
tion f is polynomial in ℓmac , ℓhash , ℓclock , and ℓgen . This means that the probability of ADV convincing Vrf that a
Theorem 1 (Security of SeED). SeED is a secure non-interactive compromised Prv is benign is negligible in ℓmac , ℓhash , ℓclock , and
attestation scheme (Definition 1) if the underlying MAC scheme is ℓgen .
72
WiSec ’17 , July 18-20, 2017, Boston, MA, USA Ahmad Ibrahim, Ahmad-Reza Sadeghi, and Shaza Zeitouni
minimal architecture for (establishing a dynamic) root of trust. In Network and [25] Petroni, Jr., N. L., Fraser, T., Molina, J., and Arbaugh, W. A. Copilot —
Distributed System Security Symposium (2012). A coprocessor-based kernel runtime integrity monitor. In USENIX Security
[13] Francillon, A., Nguyen, Q., Rasmussen, K. B., and Tsudik, G. A minimalist Symposium (2004), USENIX Association, pp. 13–13.
approach to remote attestation. In Design, Automation & Test in Europe (2014). [26] Sailer, R., Zhang, X., Jaeger, T., and Van Doorn, L. Design and implementation
[14] Gardner, R., Garera, S., and Rubin, A. Detecting code alteration by creating a of a TCG-based integrity measurement architecture. In Proceedings of the 13th
temporary memory bottleneck. IEEE Transactions on Information Forensics and USENIX Security Symposium (2004), pp. 223–238.
Security (2009). [27] Schellekens, D., Wyseur, B., and Preneel, B. Remote attestation on legacy op-
[15] Hill, J., Szewczyk, R., Woo, A., Hollar, S., Culler, D., and Pister, K. System erating systems with trusted platform modules. Science of Computer Programming
architecture directions for networked sensors. In Proceedings of the Ninth In- 74, 1 (2008), 13–22.
ternational Conference on Architectural Support for Programming Languages and [28] Seshadri, A., Luk, M., and Perrig, A. SAKE: Software attestation for key
Operating Systems (New York, NY, USA, 2000), ASPLOS IX, ACM, pp. 93–104. establishment in sensor networks. In Distributed Computing in Sensor Systems.
[16] Ibrahim, A., Sadeghi, A.-R., and Tsudik, G. DARPA: Device Attestation Resilient 2008.
against Physical Attacks. In Proceedings of the 9th ACM Conference on Security [29] Seshadri, A., Luk, M., Perrig, A., van Doorn, L., and Khosla, P. SCUBA:
and Privacy in Wireless and Mobile Networks (2016), WiSec ’16. Secure code update by attestation in sensor networks. In ACM Workshop on
[17] Kennell, R., and Jamieson, L. H. Establishing the genuinity of remote computer Wireless Security (2006).
systems. In USENIX Security Symposium (2003). [30] Seshadri, A., Luk, M., Shi, E., Perrig, A., van Doorn, L., and Khosla, P. Pioneer:
[18] Koeberl, P., Schulz, S., Sadeghi, A.-R., and Varadharajan, V. TrustLite: A Verifying code integrity and enforcing untampered code execution on legacy
security architecture for tiny embedded devices. In European Conference on systems. In ACM Symposium on Operating Systems Principles (2005).
Computer Systems (2014). [31] Seshadri, A., Perrig, A., van Doorn, L., and Khosla, P. SWATT: Software-
[19] Kovah, X., Kallenberg, C., Weathers, C., Herzog, A., Albin, M., and But- based attestation for embedded devices. In IEEE Symposium on Security and
terworth, J. New results for timing-based attestation. In IEEE Symposium on Privacy (2004).
Security and Privacy (2012), pp. 239–253. [32] Shankar, U., Chew, M., and Tygar, J. D. Side Effects Are Not Sufficient to
[20] Li, Y., McCune, J. M., and Perrig, A. VIPER: Verifying the integrity of peripherals’ Authenticate Software. In Proceedings of the 13th USENIX Security Symposium
firmware. In ACM Conference on Computer and Communications Security (2011). (2004).
[21] McCune, J. M., Li, Y., Qu, N., Zhou, Z., Datta, A., Gligor, V., and Perrig, A. [33] Trusted Computing Group (TCG). Website.
TrustVisor: Efficient TCB reduction and attestation. In Proceedings of the 2010 http://www.trustedcomputinggroup.org, 2015.
IEEE Symposium on Security & Privacy (2010), S&P ’10, pp. 143–158. [34] Vijayan, J. Stuxnet renews power grid security concerns, june 2010.
[22] McCune, J. M., Parno, B. J., Perrig, A., Reiter, M. K., and Isozaki, H. Flicker: [35] Wurster, G., Van Oorschot, P. C., and Somayaji, A. A generic attack on
An execution infrastructure for TCB minimization. SIGOPS Operating Systems checksumming-based software tamper resistance. In Proceedings of the 2005 IEEE
Review 42, 4 (Apr. 2008), 315–328. Symposium on Security and Privacy (2005), S&P ’05, pp. 127–138.
[23] OpenSim Ltd. OMNeT++ discrete event simulator. http://omnetpp.org/, 2015.
[24] Parno, B., McCune, J., and Perrig, A. Bootstrapping trust in commodity com-
puters. In IEEE Symposium on Security and Privacy (2010), pp. 414–429.
74