ERASMUS: Efficient Remote Attestation via Self- Measurement for Unattended Settings
Xavier Carpent Norrathep Rattanavipanon Gene Tsudik
cs.CR

A search for FRB 121102-like persistent radio-luminous sources – Candidates and implications for the FRB rate and searches
    Eran O. Ofek1

    December 30, 2023
==========================================================================================================================





Remote attestation (RA) is a popular means of detecting malware in embedded and IoT devices. 
RA is usually realized as an interactive protocol, whereby a trusted party – verifier – 
measures integrity of a potentially compromised remote device – prover. 
Early work focused on purely software-based and fully hardware-based techniques, 
neither of which is ideal for low-end devices. More recent results have yielded hybrid 
(SW/HW) security architectures comprised of a minimal set of features to support 
efficient and secure RA on low-end devices.

All prior RA techniques require on-demand operation, i.e, RA is performed in real time. 
We identify some drawbacks of this general approach in the context of unattended devices: 
First, it fails to detect mobile malware that enters and leaves the prover between successive 
RA instances. Second, it requires the prover to engage in a potentially expensive (in terms of time 
and energy) computation, which can be harmful for critical or real-time devices.

To address these drawbacks, we introduce the concept of self-measurement where a prover device 
periodically (and securely) measures and records its own software state, based on a pre-established schedule. 
A possibly untrusted verifier occasionally collects and verifies these measurements.  We present the design of a 
concrete technique called : Efficient Remote Attestation via Self-Measurement 
for Unattended Settings, 
justify its features and evaluate its performance. In the process, we also define a new metric – Quality of 
Attestation (). We argue that is well-suited for time-sensitive and/or safety-critical applications that 
are not served well by on-demand RA. Finally, we show that is a promising stepping stone towards 
handling attestation of multiple devices (i.e., a group or swarm) with high mobility.





§ INTRODUCTION
 

In recent years, embedded and cyber-physical systems (CPS), under the guise of Internet-of-Things (IoT),
have entered many aspects of daily life, such as: homes, office buildings, public venues, factories and vehicles. 
This trend of adding computerized components to previously analog devices and then inter-connecting them 
brings many obvious benefits. However, it also greatly expands the so-called “attack surface" and turns 
these newly computerized gadgets into natural and attractive attack targets.  In particular, as recent incidents 
demonstrated, IoT devices can be infected with malware and used as bot-controlled
zombies in Distributed Denial-of-Service (DDoS) attacks. Also, IoT-borne malware can snoop on device
owners (by sensing) or maliciously control critical services (by actuation), as happened with Stuxnet <cit.>.

One key component in securing IoT devices is malware detection, which is typically attained
with Remote Attestation (RA). RA is a distinct security service that allows a trusted party, 
called verifier, to securely verify the internal state (including memory and storage) of a remote
untrusted and potentially malware-infected device, called prover.
RA is realized via an interactive protocol between prover and verifier. A typical example
is described in <cit.>:  (1) verifier sends an attestation request to prover,
(2) prover verifies the request[Since attestation is a potentially expensive task, this verification 
mitigates computational DoS attacks.] and (3) computes a cryptographic function of its internal state, 
then (4) sends the result to verifier, and finally, (5) verifier checks the result and decides whether prover is infected.

This general approach is referred to as on-demand attestation and all current RA techniques adhere to it.
In this paper, we identify two important limitations of this approach. First, it is a poor match for unattended devices,
since malware that “comes and goes” (i.e., mobile malware <cit.>) can not be detected if it leaves prover by the time
attestation is performed. Second, for a device working under time constraints (real-time operation)
or otherwise providing critical services, on-demand attestation requires performing a possibly 
time-consuming task while deviating from the device's main function(s). 

To address these issues, we design : Efficient Remote Attestation via Self-Measurement 
for Unattended Settings. is based on self-measurements. Basically, a device (prover) 
measures and records its state at scheduled times. Measurements are stored in prover's insecure memory. 
Verifier occasionally collects and validates these measurements in order to establish the history of prover's state. 
Notably, with this general approach,  verifier imposes only negligible real-time burden on prover. 

It also offers strictly better quality-of-service than prior attestation techniques, because verifier obtains
prover's entire history of measurements, since the last verifier request. In other words, de-couples 
(1) frequency of prover checking, from (2) frequency of prover measurements, which are equivalent in 
on-demand attestation. Finally, simplifies RA design (in terms of required features) for prover: authentication of verifier requests is no longer needed, since computational DoS attacks do not arise.[This 
is unlike requirements in <cit.> that stipulate (potentially expensive) prover auhentication of verifier's requests.]

We also introduce the new notion of Quality of Attestation () which captures: (1) how a device (prover) is attested, 
(2) how often its state is measured, and (3) how often these measurements are verified. It is the temporal 
analogue of the concept of quality of swarm attestation (QoSA) introduced in <cit.> 
in the context of attesting groups of devices.

NOTE:
is not intended as a replacement for on-demand attestation, mainly because for some devices and
some settings, real-time on-demand attestation is mandatory, e.g., immediately before or after a software update or for secure erasure/reset. 
Also, on-demand attestation may be more flexible, e.g., if the verifier is only interested in  
measuring a fraction of prover's memory. These two approaches are not mutually exclusive and 
may be used together to increase , specifically, in terms of freshness of the latest measurement.

The last incentive for our self-measurement approach is its suitability for highly mobile groups of devices. 
RA protocols developed for “swarm attestation”, e.g., <cit.>, are designed to efficiently attest 
groups of interconnected devices on-demand, with a single verifier-prover interaction. However,
they do not work in highly mobile swarms, since on-demand attestation requires topology 
to remain essentially static during the entire attestation protocol instance – the time for which is dominated by
computation on all swarm devices. Since involves virtually no real time computation for prover,
it is much more suitable for high-mobility swarm settings.

After overviewing the state-of-the-art in Section <ref>, we introduce and in Section <ref>. 
An implementation and experimental results are discussed in Sect <ref>. Issues arising in time-sensitive 
applications and partial mitigation measures are discussed in Section <ref>. Applicability of to swarm attestation is considered in Section <ref>.





§ REMOTE ATTESTATION (RA)







RA aims to detect malware presence by verifying integrity of a remote and untrusted 
embedded (or IoT) device. As mentioned earlier, it is typically realized as a protocol where trusted verifier 
interacts with a remote prover to obtain an integrity measurement of the latter's state.

RA techniques fall into the three main categories. (1) Hardware-based 
attestation <cit.> uses dedicated hardware features such as a 
Trusted Platform Module (TPM) to execute attestation code in a secure environment. 
Even though such features are currently available in personal computers and smartphones, 
they are considered a relative “luxury” for very low-end embedded devices. 
(2) Software-based attestation <cit.> 
requires no hardware support and performs attestation solely based on precise timing measures. 
However, it limits prover to being one-hop away from verifier, so that round-trip time is either negligible or fixed. 
It also relies on strong assumptions about attacker behavior <cit.> and is typically only used 
for legacy devices where no other RA techniques are viable.
(3) Finally, hybrid attestation <cit.>, based on a software/hardware 
co-design, provides RA while minimizing its impact on underlying hardware features.

<cit.> is the first hybrid RA design with minimal hardware modifications to existing microcontroller units (MCUs).
It has the following key features:

	
  * Attestation code is immutable: located in and executed from ROM.
	
  * Attestation code is safe: its execution always terminates
	and leaks no information other than the attestation result (token).
	
  * Attestation is atomic: (1) it is uninterruptible,
	and (2) it starts from the first instruction and exits at the last instruction.
	This is realized in by using hard-wired MCU access controls
	and disabling interrupts upon entering attestation code.
	
  * A secret key () is stored in a secure memory location where it  
	can be accessed only from within the attestation code: is stored in ROM and is
	guarded by specialized MCU rules.


<cit.> extended to defend against denial-of-service (DoS) attacks
that try to impersonate verifier. We refers to this extended design as .
<cit.> additionally requires prover to have a Reliable Read-Only Clock (RROC),
which is needed to perform verifier authentication and prevent replay, reorder and delay attacks. 
To ensure reliability, RROC must not be modifiable by software.
Upon receiving a verifier request, ROM-resident attestation code checks the request's freshness using 
RROC, authenticates it, and only then proceeds to perform attestation.

The TrustLite <cit.> security architecture also supports RA for low-end devices. It differs 
from in two ways: (1) interrupts are allowed and handled securely by the CPU Exception 
Engine, and (2) access control rules can be programmed using an Execution-Aware Memory 
Protection Unit (EA-MPU). TyTAN <cit.> adopts a similar approach while providing 
additional real-time guarantees and dynamic configuration for safety- and security-critical applications.

<cit.> is a hybrid RA design for medium-end devices devices with a Memory Management Unit 
(MMU). It builds upon a formally verified micro-kernel, <cit.>, to ensure memory isolation
and enforce access control to memory regions.  Using these formally and mathematically proven features, 
access control rules can be implemented in software and enforced by . 
Consequently, stores and attestation code in writable memory regions (e.g., flash or RAM) 
and configures the system such that no other process, besides the attestation process,
can access those memory regions. Access control configuration in also
involves the attestation process having exclusive access to its thread control block 
as well as to memory regions used for -related computations. 
The latter ensures the protection property. To ensure atomic execution, runs the attestation 
process as the initial user-space process with the highest scheduling priority, while the rest of 
user-land processes are spawned by the attestation process, with lower priorities.
Finally, hardware-enforced secure boot is used to provide integrity of and the attestation process at 
system initialization time.



In this paper, we use and as the base security architecture for . 
However,  should be equaly applicable to other on-demand RA techniques, such as TrustLite<cit.> or TyTan<cit.>.





§ SELF-MEASUREMENTS


As discussed in Section <ref>, all current RA techniques perform on-demand attestation,
whereby prover computes verifier-requested measurements in real-time. This can be a time-consuming activity
that takes prover away from its primary mission. However, prover performs no RA-related computation
between verifier's requests.



























In contrast, divides RA into two phases. In the measurement phase, prover 
performs self-measurements based on a pre-established schedule and stores the results. In the collection
phase, verifier (whenever it chooses to do so) contacts prover to fetch these measurements. The collection
phase is very fast since it requires practically no computation by prover. In particular, since measurements
are based on a MAC computed with a key shared between prover and verifier, no extra protection is needed
when prover sends these measurements to verifier. Furthermore, unlike in on-demand RA, there is no 
threat of computational DoS on prover. Thus, there is no need to authenticate verifier's requests, 
in contrast with on-demand attestation. 

A prover's measurement M_t computed at time t is defined as:


    M_t = <t, H(mem_t), MAC_K(t, H(mem_t))>


where H is a suitable cryptographic hash function and mem_t represents prover's memory at time t. 
The computation of H(mem_t) and MAC is done in the context of the security architecture, e.g., or .

From here on, and are used to denote verifier and prover, respectively. 
Although assumes a symmetric key K shared between and ,
a public key signature scheme could be used instead, with no real impact on security 
of the scheme except for higher cost of measurements.





 §.§ Quality of Attestation 


Quality of Attestation () is primarily determined by two parameters: (1) time T_M between two successive 
measurements on , and (2) time T_C between two successive requests by to collect measurements from . 

We assume that in most cases T_C>T_M.
If it so happens that T_C≤ T_M, verifier will simply collect the same measurements more than once, which is redundant.
Instead,  can explicitly request to perform a measurement before the collection.
In that case, 's request would
have to be authenticated and checked for freshness (as in  <cit.>)
before the on-demand measurement is computed. These activities clearly incur additional 
real-time overhead and delays. 
We refer to this 
variant as .

Exactly how T_C and T_M are determined clearly depends on specifics of 's mission 
and its deployment setting. Security impact of these parameters is intuitive. 
Smaller T_M implies smaller window of opportunity for mobile malware to escape detection. 
Smaller T_C implies faster malware detection. If either value is large, attestation becomes ineffective. 
Meanwhile, though low values increase , they also increase 's overall burden, in terms of 
computation, power consumption and communication.

Without loss of generality, we assume that measurements and collections occur at regular intervals. 
Of course, in practice this might not work in scenarios that involve critical or time-sensitive applications (see Section <ref>). In fact, it might be advantageous to take measurements at irregular intervals,
as doing so might give prover a bit of an extra edge against mobile malware (see Section <ref>).




Another parameter is the number of measurements (referred to as k) obtained by in each collection phase. It can range between one (only the most recent measurement) and all. 

In a typical setting, 's history size should be set such that each measurement is collected exactly once. That is, k = ⌈ T_C / T_M ⌉. 

Finally, the collection phase involves the notion of freshness, i.e., how recent is 's latest measurement. 
Depending on the application, maximal freshness might be required, e.g., right before or after a software
update. Maximal freshness is attainable via on-demand attestation


In , freshness of a measurement (denoted as f) ranges between T_M and 0, which correspond
to minimal and maximal freshness, respectively. On average, we expect f=T_M/2.

















































Figure <ref> shows an example with two malware infections. In the first, malware covers its tracks and 
leaves before any measurement takes place. In the second, malware persists on . Although measurement 
occurs perhaps soon after infection, corrective action can be taken only after collection, thus illustrating the
importance of a small T_C. Measurements and collections are shown as punctual events in Figure <ref>. 
Although they do take some time to complete (measurements, in particular), it is considered negligible even for low-end
devices (see Section <ref>).





 §.§ Measurements Storage & Collection


A naïve way for to store measurements is to keep track of them indefinitely. 
However, this will eventually consume a lot of 's storage.
To this end, uses rolling measurements. A fixed section of 's 
insecure storage is allocated as a windowed (circular) buffer for n measurements. The i-th measurement 
is stored at location L_i n. However, it is expected that  collects measurements 
sufficiently often, such that no measurement is over-written. That is, the time between successive
collections should be at most T_C ≤ n · T_M.

The interaction between and is very simple: asks for k latest measurements, which simply reads from the buffer and transmits. The collection phase does not involve any change of state 
on and sent measurements are not encrypted. (Though recall that they are authenticated, since
each measurement is computed using K). It also does not trigger any significant computation on ,
i.e., in contrast with on-demand attestation, no cryptographic operations are required in
the collection phase. 

However, this is not the case in the variant mentioned in Section <ref>, where (1) 's
request must be authenticated and checked for freshness, and (2) a current measurement must be computed.


Self-measurements can be stored in 's unprotected storage. This allows malware (that is possibly present on )
to tamper with measurements, by modifying, re-ordering and/or deleting them. However, since malware (by design of )
cannot access K, it cannot forge measurements. 
Thus, it is easy to see that any tampering will be detected by at the next collection phase and malware presence 
would be immediately be noticed. For the same reasons, code that handles request parsing as well as storage and transmission of measurements 
does not need to be executed in a secure environment or stored in ROM. Code that performs self-measurement, however, 
must be protected by the underlying security architecture, as in on-demand attestation.

Scheduling in can be implemented in a very simple and stateless manner. Let t be the value of RROC at the time of measurement M_t, and let T_M be the time between two successive
measurements, as configured in . The windowed buffer slot L_i, used to store M_t, is determined by:
i = ⌊ t / T_M ⌋ n.

collection protocol is shown in Figure <ref>. No operation involves the underlying architecture during 
collection; only during measurements. Notation ^*L_j refers to contents of location L_j. A sample memory layout is shown 
in Figure <ref>.









 §.§ : with On-demand Attestation


As mentioned in Section <ref>, may be combined with on-demand attestation to benefit from 
advantages of both approaches. This variant, , records 's state history to detect 
mobile malware, and uses on-demand attestation to obtain better freshness. Freshness is particularly 
relevant whenever real-time attestation is mandatory, e.g., immediately before or after a software update.

The measurement phase is not modified, while the collection phase is combined with on-demand 
attestation request as follows. First, as part of each attestation request now computes and includes an 
authentication token and specifies k. As in  <cit.>, authentication of protects against computational DoS. 
Then, only after checking that a request is valid, computes a measurement. Finally, this real-time measurement 
is sent to , along with k previous measurements. This protocol is shown in Figure <ref>.



This anti-DoS protection incurs an additional cost for which may interfere with its normal function. A major advantage of over and regular on-demand attestation is that no such protection is required.





 §.§ Security Considerations


Security of the measurement process itself is based on the underlying security architecture, 
e.g.,  or , which: (1) provides measurements code with exclusive access to , 
(2) ensures non-malleability and non-interruptibility of the measurement code, and (3) performs 
memory-cleanup after execution.

The timestamps used in the measurement process must be based on the RROC which 
(by definition) can not be modified by non-physical means. This is important since 
malware should not  influence when measurements are taken. 

If RROC value could be modified, the following attack scenario would become possible: malware enters at time 
t_0 and remains active long enough so that a measurement at time t_0 + δ (with δ < T_M) is taken. 
Before leaving, malware discards that measurement and resets the counter to t_0. 
Soon after δ (so that a measurement, valid this time, has been taken for t_0 + δ), malware returns and resets 
the counter to time elapsed since t_0. Though this example works for one T_M window, it can be extended to 
arbitrarily many. It requires an additional assumption that no collection took place during the presence of malware.

Fortunately, RROC is already a requirement of the underlying security architecture, for a totally different reason. 
In , RROC helps prevent replay and computational DoS attacks on . Thus, does not require any 
changes to the underlying security architecture.

As mentioned earlier, measurements need not be stored in protected memory because 
tampering with them is detectable and indicates malware presence on .
Likewise, the code to support the collection phase does not require any protection 
since measurements are not secret (they are unique for every device and every timestamp value), 
and their absence or alteration is self-incriminating.





 §.§ Irregular Intervals


A natural extension to  is to use irregular measurements intervals instead of a fixed T_M. The motivation is that mobile malware that is aware of fixed scheduling knows when to enter/leave the device in order to stay undetected.

One way to implement irregular intervals is to use a Cryptographically Secure Pseudo Random Number Generator (CSPRNG) iniatialized (seeded) with the secret key K. Output of the CSPRNG can be truncated such that T_M is upper- and/or lower-bounded.

For example, after computing M_t_i, can set the measurement timer to:

    T_M^next = map(CSPRNG_k(t_i)),

where map is a function that maps CSPRNG output to seconds, e.g. map : x ↦ x (U-L) + L, with U and L upper and lower bounds, respectively.

The timer itself must be read-protected to ensure that T_M^next is unknown to malware potentially present on . CSPRNG code must be protected in the same way as the measurement collection.







§ IMPLEMENTATION




We implemented on two security architectures: and .

The main difference between them is that the former targets low-end devices,
and the latter – medium-end devices with a memory management unit (MMU).



 §.§ Implementation on 





Figure <ref> shows the implementation of atop the
 architecture.
As in ,  measurement code and reside in ROM.
However, the code is invoked periodically and autonomously, whenever 
a scheduled timer interrupt occurs. 




We now examine ROM size, hardware costs and run-time on architecture.




ROM Size greatly depends on the choice of MAC algorithms.
We implement ROM-resident code in "C" using three MAC functions: HMAC-SHA1 <cit.>[Note 
that HMAC-SHA1 is used for comparison purposes only. We exclude it in our actual implementations due to a 
recent collision attack in SHA1 <cit.>.], HMAC-SHA256 <cit.> and keyed 
BLAKE2S <cit.>. We then use open-source MSP430-gcc compiler <cit.> to compile the 
"C" code into an MSP430 executable. Table <ref> shows the ROM size 
for each -based approach. As expected, requires slightly less 
ROM than on-demand attestation.






















Hardware Cost: 
We implement the hardware part of by modifying the MSP430 architecture, using
open-source OpenMSP430 core <cit.>.


We modify the memory backbone module in the OpenMSP430 core to support atomic 
execution of ROM code and exclusive access to . RROC is realized as a peripheral 
using a 64-bit register incremented for every clock cycle. 
To ensure write-protection, a write-enable wire is removed in the RROC module.
For timer components, we use the unmodified version of omsp_timerA module provided by OpenMSP430. 
Note that hardware timers are not considered to represent additional hardware cost.
This is because they are common and crucial components of embedded systems.
Indeed, it is unusual to find an embedded device not equipped with at least one timer.
Finally, we use Xilinx ISE 14.7 <cit.> to synthesize our modifications of the MSP430 core from 
a hardware description language to a combination of registers and look-up tables that serve as 
building blocks in FPGA. 



As expected, our synthesized results show that utilizes the same amount of registers
and look-up tables as the on-demand attestation.
Compared to the unmodified MSP430 core, requires roughly 13% (655 vs. 579) 
and 14% (1,969 vs. 1,731) 
additional registers and look-up tables respectively.



Measurement Run-Time:




Figure <ref> illustrates run-time of the measurement phase for various memory sizes. 
Not surprisingly, it is linearly dependent on memory size and roughly equivalent to that 
of on-demand attestation.




 §.§ Implementation on 




Figure <ref> illustrates implementations of -based and
on-demand attestation. 


We implement these two techniques on an I.MX6 Sabre Lite <cit.> development board.


RROC is implemented based on the software clock approach, suggested by Brasser et al. <cit.>.
Specifically, we use a short-term counter from Sabre Lite's General Purpose Timer (GPT) and our 
clock code in to construct RROC. When the counter wraps around and causes an interrupt, 
our clock code handles it by updating higher-order bits of the clock in . Then, the clock value is 
constructed by combining these bits with the GPT counter.

To ensure read-only property, is given exclusive write-access to RROC components.

Also, we utilize Sabre Lite's Enhanced Periodic Interrupt Timer (EPIT) to schedule
execution of measurement code

We base the code of on open-source libraries <cit.>: seL4utils, seL4vka, seL4vspace,
and seL4bench. The first three provide abstractions of: process, memory management 
and virtual space, respectively, while the last one is used to evaluate performance. 
Finally, we use <cit.> to implement th network stack: an Ethernet driver and timer drivers in .

Executable Size:
Table <ref> compares executable sizes of in on-demand attestation and .
Results show that is only about 1% higher in terms of the executable size.
This overhead mostly comes from the need for an additional timer driver.

Measurement Run-time:
Measurement run-time of -based in Figure <ref> follows the same trend 
as -based : (1) it is linear as a function
of memory sizes, and (2) it is roughly equal to that of on-demand attestation.



Collection Run-time:






Table <ref> shows the run-time breakdown of the collection phase
for each variant.
Clearly, in , 
run-time of the collection phase is negligible (by at least a factor of 3,000), 
compared to that of the measurement phase.
Collection run-time in ERASMUS+OD, on the other hand, is dominated by run-time
of performing on-demand attestation.





































§ AVAILABILITY IN TIME-SENSITIVE APPLICATIONS


In some cases, it might be undesirable to interrupt execution of the 's application process
in order to obtain a measurement. This is particularly the case for time-sensitive or safety-critical 
applications. As discussed in Section <ref>, measurements can take non-negligible time, e.g., 
7 seconds on an 8-MHz device with 10KB RAM. Making unavailable for that long is 
not appropriate.

As is, pure on-demand attestation is poorly suited for such applications. At the same time, if follows a strict schedule, 
is also not a remedy since it suffers from the same issue. However, it can be made more flexible.

One partial measure is for to be self-aware of when time-sensitive tasks occur. That way, it can schedule 
measurements at appropriate times. If this knowledge is also available to , on-demand attestation could be 
used if adapts to 's schedule. 

Another approach is to allow to abort the measurement in progress, if the need arises. However, this has some
caveats: First, the security architecture needs to be adapted to allow interrupts during measurements. Protection of keys 
(and cleanup in case of an interrupt) is still required; thus, there is still a need for some hardware support. Second, 
it would be trivial for malware to abort computation of measurements in order to avoid detection, or simply pretend,
when queried by , that all attempted measurements have been aborted. Therefore, must use some external 
information or policy to decide whether there is a valid justification for each aborted measurement.

To handle such situations, we consider another variant that involves lenient scheduling. 
Instead of performing a measurement every T_M, has a window of w× T_M where w≥ 1. 
Under normal conditions, behaves as usual, using the T_M window. If something causes a measurement 
to be aborted, it can be rescheduled to the end of the current window.

These are certainly not ideal measures, the underlying problem seems quite difficult to address deterministically.
As is typical for security/usability compromises, real deployment would likely involve policy-based decisions. 








§ SWARM ATTESTATION


Some applications require attesting a group (or swarm) of interconnected embedded devices. In such a setting, 
it is beneficial to take advantage of interconnectivity and perform collective attestation using a dedicated protocol. 
Several swarm attestation techniques have been proposed. SEDA <cit.> is the first such scheme, which
relies on hybrid attestation security architectures:  <cit.> and TrustLite <cit.>. SEDA 
combines them with a request-flooding and response-gathering protocol. SEDA was improved and further 
specified in LISA <cit.>. Other related techniques deal with report aggregation <cit.> or physical attacks <cit.>.

A concept of Quality of Swarm Attestation (QoSA) was introduced in <cit.> to capture  the level of information 
that  obtains as a result of swarm attestation. This can range from binary (“is the whole swarm healthy?”) to full 
(state of each individual device and topology information). , as introduced in this paper, is an orthogonal measure 
that captures the state of a given device in time. and QoSA can be used in concert with one another.

could be used instead of on-demand attestation in the context of swarm RA protocols. In particular, 
self-measurements can be coupled with a collection protocol, such as LISA-α, where the latter 
only relays reports and does not perform any computation. This would yield a clean and conceptually simple approach
to swarm attestation, with all the benefits of .

An additional advantage of using in the swarm setting is support for high mobility. Prior swarm RA techniques, such 
as SEDA, SANA and LISA require swarm topology to remain almost static during the whole swarm attestation instance. 
This process may be long and prohibitive for applications where connectivity changes often. 
does not require external input and its collection phase is very fast, since it does not involve 
any computation; only reading and sending stored measurements. This makes a very natural and 
viable technique for highly-mobile swarms.

Finally, related to the discussion in Section <ref>, we consider the scenario where availability of at least 
one in (or a part of) a group of devices is required at all times. This cannot be guaranteed by on-demand swarm attestation, 
where a large part of the network may be concurrently busy. Meanwhile, with , it is trivial to establish a 
schedule which ensures that only a fraction of the swarm computes measurements at any given time.





§ CONCLUSION


We designed as an alternative to current methods that perform 
on-demand RA for low-end devices. provides better in that it
allows to detect mobile malware, which is not possible with on-demand techniques
that only detect malware if it is currently on . makes it harder for malware to avoid 
detection. 's other major advantage is that it requires no cryptographic computation by as part of its interaction with . This is particularly relevant in time-sensitive and critical 
applications, where 's availability is very important. We discuss partial mitigation measures for this
problem.

We present the new notion of Quality-of-Attestation () as a measure of temporal security 
guarantees given by an attestation technique. We show that timing of measurements and timing 
of verifications (that are conjoined in on-demand attestation) are two distinct aspects of . 
They are treated as distinct parameters in . We also discuss that the possibility of 
using on-demand attestation as part of collection phase to obtain maximal
freshness.

We implemented on two hybrid RA architectures, and , and demonstrated  
its viability on both. does not require extra features or a larger ROM than what is 
needed in , and each measurement is fast than on-demand attestation since no authentication
of requests is needed. Finally, we show that is a promising option for highly-mobile 
groups/swarms of devices, for which no current RA technique works well.






10

abera2016invited
Tigist Abera, N Asokan, Lucas Davi, Farinaz Koushanfar, Andrew Paverd,
  Ahmad-Reza Sadeghi, and Gene Tsudik.
Invited: Things, trouble, trust: on building trust in IoT systems.
In ACM/IEEE Design Automation Conference (DAC), 2016.

seda
N Asokan, Ferdinand Brasser, Ahmad Ibrahim, Ahmad-Reza Sadeghi, Matthias
  Schunter, Gene Tsudik, and Christian Wachsmann.
SEDA: Scalable embedded device attestation.
In ACM SIGSAC Conference on Computer and Communications Security
  (CCS), 2015.

sabre-lite
Boundary Devices.
i.mx6 arm development board.

brasser2015tytan
Ferdinand Brasser, Brahim El Mahjoub, Ahmad-Reza Sadeghi, Christian Wachsmann,
  and Patrick Koeberl.
TyTAN: tiny trust anchor for tiny devices.
In ACM/IEEE Design Automation Conference (DAC), 2015.

brasser2016remote
Ferdinand Brasser, Ahmad-Reza Sadeghi, and Gene Tsudik.
Remote attestation for low-end embedded devices: the prover's
  perspective.
In ACM/IEEE Design Automation Conference (DAC), 2016.

lisa
Xavier Carpent, Karim ElDefrawy, Norrathep Rattanavipanon, and Gene Tsudik.
Lightweigh swarm attestation: a tale of two LISA-s.
In ACM Asia Conference on Computer and Communications Security
  (ASIACCS), 2017.

sha1
D Eastlake 3rd and Paul Jones.
Us secure hash algorithm 1 (sha1).
Technical report, 2001.

hydra
Karim ElDefrawy, Norrathep Rattanavipanon, and Gene Tsudik.
Hydra: Hybrid design for remote attestation (using a formally
  verified microkernel).
arXiv preprint arXiv:1703.02688, 2017.

smart
Karim Eldefrawy, Gene Tsudik, Aurélien Francillon, and Daniele Perito.
SMART: Secure and minimal architecture for (establishing dynamic)
  root of trust.
In Network and Distributed System Security Symposium (NDSS),
  2012.

openmsp430
Olivier Girard.
Openmsp430, 2009.

darpa
Ahmad Ibrahim, Ahmad-Reza Sadeghi, Gene Tsudik, and Shaza Zeitouni.
DARPA: Device attestation resilient to physical attacks.
In ACM Conference on Security and Privacy in Wireless and Mobile
  Networks (WiSec), 2016.

klein2009sel4
Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock,
  Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael
  Norrish, et al.
sel4: Formal verification of an os kernel.
In Proceedings of the ACM SIGOPS 22nd symposium on Operating
  systems principles, pages 207–220. ACM, 2009.

trustlite
Patrick Koeberl, Steffen Schulz, Ahmad-Reza Sadeghi, and Vijay Varadharajan.
TrustLite: A security architecture for tiny embedded devices.
In ACM European Conference on Computer Systems (EuroSys), 2014.

sel4-libs
National ICT Australia and other contributors.
sel4 libraries, 2014.

sel4-util-libs
National ICT Australia and other contributors.
util_libs, 2014.

ostrovsky1991withstand
Rafail Ostrovsky and Moti Yung.
How to withstand mobile virus attacks.
In Proceedings of the tenth annual ACM symposium on Principles
  of distributed computing, pages 51–59. ACM, 1991.

blake2
MJ Saarinen and JP Aumasson.
The blake2 cryptographic hash and message authentication code (mac).
2015.

sana
Ahmad-Reza Sadeghi, Matthias Schunter, Ahmad Ibrahim, Mauro Conti, and Gregory
  Neven.
SANA: Secure and scalable aggregate network attestation.
In ACM Conference on Computer and Communications Security
  (CCS), 2016.

SCHELLEKENS200813
Dries Schellekens, Brecht Wyseur, and Bart Preneel.
Remote attestation on legacy operating systems with trusted platform
  modules.
Science of Computer Programming, 74(1):13 – 22, 2008.

Seshadri:2006:SSC:1161289.1161306
Arvind Seshadri, Mark Luk, Adrian Perrig, Leendert van Doorn, and Pradeep
  Khosla.
Scuba: Secure code update by attestation in sensor networks.
In ACM Workshop on Wireless Security (WiSe), 2006.

seshadri2004swatt
Arvind Seshadri, Adrian Perrig, Leendert Van Doorn, and Pradeep Khosla.
SWATT: Software-based attestation for embedded devices.
In IEEE Symposium on Research in Security and Privacy (S&P),
  2004.

sha256
Secure Hash Standard.
Fips pub 180-2.
National Institute of Standards and Technology, 2002.

sha1-atk
Marc Stevens, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov.
The first collision for full sha-1.
URL: https://shattered. it/static/shattered. pdf, 2017.

Stumpf2006
Frederic Stumpf, Omid Tafreschi, Patrick Röder, and Claudia Eckert.
A robust integrity reporting protocol for remote attestation.
In Workshop on Advances in Trusted Computing (WATC), 2006.

msp-gcc
Texas Instruments.
Msp430-gcc-opensource gcc - open source compiler for msp
  microcontrollers, 2017.

stuxnet
Jaikumar Vijayan.
Stuxnet renews power grid security concerns, june 2010.

xilinx2013
ISE Xilinx.
Design suite, 2013.



