A Verified Architecture for Proofs of Execution on Remote Devices under Full Software Compromise

TL;DR

This paper introduces VAPE, a verified architecture ensuring trustworthy execution proofs on remote, potentially compromised devices, enabling secure sensing and actuation in safety-critical cyber-physical systems.

Contribution

It presents the first verified architecture for proofs of execution on low-end embedded systems, with formal security guarantees and low overhead.

Findings

VAPE is secure against software compromise.

VAPE incurs low computational overhead.

Applicable to low-end embedded devices like MSP430 and ATMega.

Abstract

Modern society is increasingly surrounded by, and accustomed to, a wide range of Cyber-Physical Systems (CPS), Internet-of-Things (IoT), and smart devices. They often perform safety-critical functions, e.g., personal medical devices, automotive CPS and industrial automation (smart factories). Some devices are small, cheap and specialized sensors and/or actuators. They tend to run simple software and operate under control of a more sophisticated central control unit. The latter is responsible for the decision-making and orchestrating the entire system. If devices are left unprotected, consequences of forged sensor readings or ignored actuation commands can be catastrophic, particularly, in safety-critical settings. This prompts the following three questions: (1) How to trust data produced by a simple remote embedded device? and (2) How to ascertain that this data was produced via execution of expected software? Furthermore, (3) Is it possible to attain (1) and (2) under the assumption that all software on the remote device could be modified or compromised? In this paper we answer these questions by designing, proving security of, and formally verifying, VAPE: Verified Architecture for Proofs of Execution. To the best of our knowledge, this is the first of its kind result for low-end embedded systems. Our work has a range of applications, especially, to authenticated sensing and trustworthy actuation, which are increasingly relevant in the context of safety-critical systems. VAPE architecture is publicly available and our evaluation demonstrates that it incurs low overhead, affordable even for lowest-end embedded devices, e.g., those based on MSP430 or ARV ATMega processors.

Tables

Table 1. Table 1: Notation

$PC$	Current Program Counter value
$R_{en}$	Signal that indicates if the MCU is reading from memory (1-bit)
$W_{en}$	Signal that indicates if the MCU is writing to memory (1-bit)
$D_{addr}$	Address for an MCU memory access
$DM{A}_{en}$	Signal that indicates if DMA is currently enabled (1-bit)
$DM{A}_{addr}$	Memory address being accessed by DMA, if any
$irq$	Signal that indicates if an interrupt is happening
$CR$	Memory region where SW-Att is stored: $CR=[C{R}_{min},C{R}_{max}]$
$MR$	(MAC Region) Memory region in which SW-Att computation result is written: $MR=[M{R}_{min},M{R}_{max}]$. The same region is used to pass the attestation challenge as input to SW-Att
$AR$	(Attested Region) Memory region to be attested. Can be fixed/predefined or specified in an authenticated request from $𝒱\mathrm{𝗋𝖿}$: $AR=[A{R}_{min},A{R}_{max}]$
$KR$	(Key Region) Memory region that stores $𝒦$
$XS$	(Exclusive Stack Region) Exclusive memory region that contains SW-Att’s stack and can be only accessed by SW-Att
$reset$	A 1-bit signal that reboots/resets the MCU when set to logical $1$
$ER$	(Execution Region) Memory region that stores an executable to be executed: $ER=[E{R}_{min},E{R}_{max}]$
$OR$	(Output Region) Memory region that stores execution output: $OR=[O{R}_{min},O{R}_{max}]$
$EXEC$	1-bit execution flag indicating whether a successful execution has happened
$METADATA$	Memory region containing VAPE’s metadata

Table 2. Table 2: Evaluation results.

	Hardware		Reserved	Verification
	Reg	LUT	RAM (byte)	# LTL Invariants	Verified Verilog LoC	Time (s)	Mem (MB)
OpenMSP430 [25]	691	1904	0	-	-	-	-
VRASED [17]	721	1964	2332	10	481	0.4	13.6
VAPE +VRASED	735	2206	2341	20	1385	183.6	280.3

Equations

$$\mathcal{H}=HMAC(KDF(\mathcal{K},\mathcal{C}\mathsf{hal}),ER,OR,METADATA,...)$$

$$\mathcal{H}\equiv HMAC(KDF(\mathcal{K},{\mathcal{C}\mathsf{hal}}_{\mathcal{V}\mathsf{rf}}),\mathcal{S},\mathcal{O},METADAT{A}_{\mathcal{V}\mathsf{rf}},...)$$

$$\begin{array}{rl}& \{\\ & PC=E{R}_{min}\text{leavevmode}\wedge \text{leavevmode}[(PC\in ER\wedge \neg Interrupt\wedge \neg reset\wedge \neg DM{A}_{en})\text{U}PC=E{R}_{max}]\wedge \\ & [(\neg \text{leavevmode}\text{Modify\_Mem}(ER)\wedge \neg \text{leavevmode}\text{Modify\_Mem}(METADATA)\wedge (PC\in ER\vee \neg \text{leavevmode}\text{Modify\_Mem}(OR)))\text{U}PC=C{R}_{min}]\\ & \}\text{B}\{EXEC\wedge PC\in CR\}\end{array}$$

$$\begin{array}{r}\text{G}:\{[W_{en}\wedge (D_{addr}\in ER)]\vee [DM{A}_{en}\wedge (DM{A}_{addr}\in ER)]\to \neg EXEC\}\end{array}$$

$$\begin{array}{r}\text{G}:\{(PC\in ER)\wedge \neg (\text{X}(PC)\in ER)\to PC=E{R}_{max}\vee \neg \text{X}(EXEC)\}\end{array}$$

$$\begin{array}{rl}& \text{G}:\{\neg (PC\in ER)\wedge (\text{X}(PC)\in ER)\to \text{X}(PC)=E{R}_{min}\vee \neg \text{X}(EXEC)\}\end{array}$$

$$\begin{array}{rl}& \text{G}:\{(PC\in ER)\wedge irq\to \neg EXEC\}\end{array}$$

$$\begin{array}{r}\text{G}:\{[\neg (PC\in ER)\wedge (W_{en}\wedge D_{addr}\in OR)]\vee (DM{A}_{en}\wedge DM{A}_{addr}\in OR)\vee (PC\in ER\wedge DM{A}_{en})\to \neg EXEC\}\end{array}$$

$$\begin{array}{rl}& \text{G}:\{E{R}_{min}>E{R}_{max}\vee O{R}_{min}>O{R}_{max}\to \neg EXEC\}\end{array}$$

$$\begin{array}{rl}& \text{G}:\{E{R}_{min}\le C{R}_{max}\vee E{R}_{max}>C{R}_{max}\to \neg EXEC\}\end{array}$$

$$\begin{array}{r}\text{G}:\{[W_{en}\wedge (D_{addr}\in METADATA)]\vee [DM{A}_{en}\wedge (DM{A}_{addr}\in METADATA)]\to \neg EXEC\}\end{array}$$

$$\begin{array}{r}\text{G}:\{\neg EXEC\wedge \text{X}(EXEC)\to \text{X}(PC=E{R}_{min})\}\end{array}$$

$$\begin{array}{r}\text{G}:\{reset\to \neg EXEC\}\end{array}$$

$${\mathcal{O}}_{\mathcal{A}\mathsf{dv}}\equiv {\mathsf{XAtomicExec}}^{\mathcal{P}\mathsf{rv}}(E{R}_{\mathcal{A}\mathsf{dv}},t_{req}\to t_{verif})$$

Full text

In this paper we answer these questions by designing, showing security of, and formally verifying, VAPE: Verified Architecture for Proofs of Execution. To the best of our knowledge, this is the first of its kind result for low-end embedded systems. Our work has a range of applications, especially, to authenticated sensing and trustworthy actuation, which are increasingly relevant in the context of safety-critical systems. VAPE architecture is publicly available and our evaluation indicates that it incurs low overhead, affordable even for very low-end embedded devices, e.g., those based on TI MSP430 or AVR ATmega processors.

1 Introduction

The number and diversity of special-purpose computing devices has been increasing dramatically. This includes all kinds of embedded devices, cyber-physical systems (CPS) and Internet-of-Things (IoT) gadgets, utilized in various “smart” or instrumented settings, such as homes, offices, factories, automotive systems and public venues. Tasks performed by these devices are often safety-critical. For example, a typical industrial control system depends on physical measurements (e.g., temperature, pressure, humidity, speed) reported by sensors, and on actions taken by actuators, such as: turning on the A/C, sounding an alarm, or reducing speed.

A cyber-physical control system is usually composed of multiple sensors and actuators, at the core of each is a low-cost micro-controller unit (MCU). Such devices typically run simple software, often on "bare metal", i.e., with no microkernel or hypervisor. They tend to be operated by a remote central control unit. Despite their potential importance to overall system functionality, low-end devices are typically designed to minimize cost, physical size and energy consumption, e.g., TI MSP430.

Therefore, their architectural security is usually primitive or non-existent, thus making them vulnerable to malware infestations and other malicious software modifications. A compromised MCU can spoof sensed quantities or ignore actuation commands, leading to potentially catastrophic results. For example, in a smart city, large-scale erroneous reports of electricity consumption by smart meters might lead to power outages. A medical device that returns incorrect values when queried by a remote physician might result in a wrong drug being prescribed to a patient. A compromised car engine temperature sensor that reports incorrect (low) readings can lead to undetected overheating and major damage. However, despite very real risks of remote software compromise, most users believe that these devices execute expected software and thus perform their expected function.

In this paper, we argue that Proofs of Execution (PoX) are both important and necessary for securing low-end MCUs. Specifically, we demonstrate in Section 7.3, that PoX schemes can be used to construct sensors and actuators that “cannot lie”, even under the assumption of full software compromise. In a nutshell, a PoX conveys that an untrusted remote (and possibly compromised) device really executed specific software, and all execution results are authenticated and cryptographically bound to this execution. This functionality is similar to authenticated outputs that can be produced by software execution in SGX-alike architectures [28, 15]. However, such architectures are comparatively heavy-weight and unsuitable for low-end devices.

One key building block in designing PoX schemes is Remote Attestation ($\sf{RA}$). Basically, $\sf{RA}$ is a means to detect malware on a remote low-end MCU. It allows a trusted verifier ($\sf{\mathcal{V}rf}$) to remotely measure memory contents (or software state) of an untrusted embedded device ($\sf{\mathcal{P}rv}$). $\sf{RA}$ is usually realized as a 2-message challenge-response protocol:

$\sf{\mathcal{V}rf}$ sends an attestation request containing a challenge ($\sf{\mathcal{C}hal}$) to $\sf{\mathcal{P}rv}$. It might also contain a token derived from a secret (shared by $\sf{\mathcal{V}rf}$ and $\sf{\mathcal{P}rv}$) that allows $\sf{\mathcal{P}rv}$ to authenticate $\sf{\mathcal{V}rf}$. 2. 2.

$\sf{\mathcal{P}rv}$ receives the attestation request, authenticates the token (if present) and computes an authenticated integrity check over its memory and $\sf{\mathcal{C}hal}$. The memory region can be either pre-defined, or explicitly specified in the request. 3. 3.

$\sf{\mathcal{P}rv}$ returns the result to $\sf{\mathcal{V}rf}$. 4. 4.

$\sf{\mathcal{V}rf}$ receives the result, and decides whether it corresponds to a valid memory state.

The authenticated integrity check is typically realized as a Message Authentication Code (MAC) computed over $\sf{\mathcal{P}rv}$ memory. We discuss one concrete $\sf{RA}$ architecture in Section 3.

Despite major progress and several proposals for $\sf{RA}$ architectures with different assumptions and guarantees [42, 39, 36, 22, 32, 7, 21, 6, 37, 10, 38, 11, 27, 8, 17], $\sf{RA}$** alone is insufficient to obtain proofs of execution**. $\sf{RA}$ allows $\sf{\mathcal{V}rf}$ to ascertain integrity of software residing in $\sf{\mathcal{P}rv}$ attested memory region. However, $\sf{RA}$ by itself offers no guarantee that the attested software is ever executed or that any such execution completes successfully. Even if the attested software is executed, there is no guarantee that it has not been modified (e.g., by malware residing elsewhere in memory) in the time between its execution and its attestation. This phenomenon is well known as the Time-Of-Check-Time-Of-Use (TOCTOU) problem. Finally, $\sf{RA}$ does not guarantee authenticity and integrity of any output produced by the execution of the attested software.

To bridge this gap, we design and implement VAPE: Verified Architecture for Proofs of Execution. In addition to $\sf{RA}$, VAPE allows $\sf{\mathcal{V}rf}$ to request an unforgeable proof that the attested software executed successfully and (optionally) produced certain authenticated output. These guarantees hold even in case of full software compromise on $\sf{\mathcal{P}rv}$. Our intended contributions are:

– New security service: we design and implement VAPE for unforgeable remote proofs of execution (PoX). VAPE is composed with VRASED [17], a formally verified hybrid $\sf{RA}$ architecture. As we discuss in the rest of this paper, obtaining provably secure PoX requires significant architectural support in addition to a secure $\sf{RA}$ functionality (see Section 7); Nonetheless, we show that VAPE careful design achieves all necessary properties for secure PoX at fairly low overhead. To the best of our knowledge, this is the first security architecture for proofs of remote software execution on low-end devices.

– Provable security & implementation verification: secure PoX involves reasoning about several details which can be easily overlooked. Ensuring that all necessary PoX components are correctly implemented, composed, and integrated with the underlying $\sf{RA}$ functionality is not trivial. In particular, early $\sf{RA}$ architectures oversimplified PoX requirements, leading to the incorrect conclusion that PoX can be obtained directly from $\sf{RA}$; see Section 2 for examples. In this work, we prove that VAPE yields a secure PoX architecture. All security properties expected from VAPE implementation are formally specified using Linear Temporal Logic (LTL) and VAPE modules are verified to adhere to these properties. We also prove that the composition of VAPE new modules with a formally verified $\sf{RA}$ architecture (VRASED) implies a concrete definition of PoX security.

– Evaluation, publicly available implementation and applications: VAPE was implemented on a real-world low-end MCU (TI MSP430) and deployed using commodity FPGAs. Both design and verification are publicly available at [2]. Our evaluation shows low hardware overhead, affordable even for low-end MCUs. The implementation is accompanied by a sample PoX application; see Section 7.3. As a proof of concept, we use VAPE to construct a trustworthy safety-critical device, on which malware can not spoof execution results (e.g., spoof sensed values) without detection.

Targeted Devices & Scope: This work focuses on CPS/IoT sensors and actuators with relatively low computing power. These are some of the lowest-end devices based on low-power single core MCUs with only a few KBytes of program and data memory. Two prominent examples are: TI MSP430 and Atmel AVR ATmega. These are $8$- and $16$-bit CPUs, typically running at $1$-$16$MHz clock frequencies, with $\approx 64$ KBytes of addressable memory. SRAM is used as data memory and its size is normally within $4$-$16$KBytes with the rest of address space available for program memory. These devices execute instructions in place (in physical memory) and have no memory management unit (MMU) to support virtual memory. Our implementation focuses on MSP430. This choice is due to public availability of a well-maintained open-source MSP430 hardware design from Open Cores [25]. Nevertheless, our machine model and the entire methodology developed in this paper are applicable to other low-end MCUs in the same class, such as Atmel AVR ATmega.

Organization: Section 2 discusses related work on remote attestation, formal verification of security services and control flow attestation. Section 3 provides some background on automated verification, and VRASED $\sf{RA}$ architecture. Section 4 introduces Proofs of Execution (PoX), followed by a realization thereof in Section 5, including technical details of VAPE design, as well as the adversarial model and assumptions. Section 6 presents VAPE’s formal verification. Next, in Section 7, we report VAPE’s evaluation results and describe how to use VAPE to implement authenticated sensing/actuation. Section 8 concludes the paper with a summary of results.

2 Related Work

Remote Attestation ($\sf{RA}$)– architectures fall into three categories: hardware-based, software-based, or hybrid. Hardware-based [40, 46, 34] relies on dedicated secure hardware components, e.g., Trusted Platform Modules (TPMs) [45]. However, the cost of such hardware is normally prohibitive for low-end IoT/CPS devices. Software-based attestation [30, 43, 44] requires no hardware security features but imposes strong security assumptions about communication between $\sf{\mathcal{P}rv}$ and $\sf{\mathcal{V}rf}$, which are unrealistic in the IoT/CPS ecosystem (though, it is the only choice for legacy devices). Hybrid $\sf{RA}$ [21, 23, 33, 24, 7] aims to achieve security equivalent to hardware-based mechanisms at minimal cost. It thus entails minimal hardware requirements while relying on software to reduce overall complexity and $\sf{RA}$ footprint on $\sf{\mathcal{P}rv}$.

The first hybrid $\sf{RA}$ architecture – SMART [22] – acknowledged the importance of proving remote code execution on $\sf{\mathcal{P}rv}$, in addition to just attesting $\sf{\mathcal{P}rv}$’s memory. Using an attest-then-execute approach (see Algorithm 4 in [22]), SMART attempts to achieve software execution guarantees by specifying the address of the first instruction to be executed after completion of attestation. We consider this to be a best-effort approach which merely guarantees that the code starts executing. However, it does not guarantee that execution completes successfully. For example, SMART’s approach cannot detect if execution is interrupted (e.g., by malware) and never resumed. It also cannot detect when a reset (e.g., due to software bugs, or $\sf{\mathcal{P}rv}$ running low on power) happens during execution, thus preventing its successful completion. Furthermore, direct memory access (DMA) can occur during execution and it can modify the code being executed, or its output. In other words, SMART offers no guarantees beyond “invoking the executable”.

Another notable $\sf{RA}$ architecture is TrustLite [32], which builds upon SMART to allow secure interrupts. However, TrustLite does not enforce temporal consistency of attested memory; it is thus conceptually vulnerable to self-relocating malware and memory modification during attestation [9]. Consequently, it is challenging to deriving secure PoX from TrustLite. Several other prominent low-to-medium-end $\sf{RA}$ architectures – e.g., SANCUS [37], HYDRA [21], and TyTaN [7] – do not offer PoX. In this paper, we show that the execute-then-attest approach, using a temporally consistent $\sf{RA}$ architecture, provides unforgeable proofs of execution that are produced only if the execution and its results are not tampered with, and it completes successfully.

Control Flow Attestation (CFA)– In contrast with $\sf{RA}$, which measures $\sf{\mathcal{P}rv}$’s software integrity, CFA techniques [1, 19, 47, 18] provide $\sf{\mathcal{V}rf}$ with a measurement of the exact control flow path taken during execution of specific software on $\sf{\mathcal{P}rv}$. Such measurements allow $\sf{\mathcal{V}rf}$ to detect run-time attacks. We believe that it is possible to construct a PoX scheme that relies on CFA to produce proofs of execution based on the attested control flow path. However, in this paper, we advocate a different approach – specific for proofs of execution – for two main reasons:

• •

CFA requires substantial additional hardware features in order to attest, in real time, executed instructions along with memory addresses and the program counter. For example, C-FLAT [1] assumes ARM TrustZone, while LO-FAT [19] and LiteHAX[18] require a branch monitor and a hash engine. We believe that such hardware components are not viable for low-end devices, since their cost (in terms of price, size, and energy consumption) is typically higher than the cost of a low-end MCU itself. For example, the cheapest Trusted Platform Module (TPM) [45], is about $10\times$ more expensive than MSP430 MCU itself111Source: https://www.digikey.com/. As shown in Section 7.2, current CFA architectures are also considerably more expensive than the MCU itself and hence not realistic in our device context.

• •

CFA assumes that $\sf{\mathcal{V}rf}$ can enumerate a large (potentially exponential!) number of valid control flow paths for a given program, and verify a valid response for each. This burden is unnecessary for determining if a proof of execution is valid, because one does not need to know the exact execution path in order to determine if execution occurred (and terminated) successfully (see Section 4.2 for a discussion on run-time threats).

Instead of relying on CFA, our work constructs a PoX-specific architecture – VAPE– that enables low-cost PoX for low-end devices. VAPE is non-invasive (i.e.,it does not modify MCU behavior and semantics) and incurs low hardware overhead: around 2% for registers and 12% for LUTs. Also, $\sf{\mathcal{V}rf}$ is not required to enumerate valid control flow graphs and the verification burden for PoX is exactly the same as the effort to verify a typical remote attestation response for the same code.

Formally Verified Security Services– In recent years, several efforts focused on formally verifying security-critical systems. In terms of cryptographic primitives, Hawblitzel et al. [26] verified implementations of SHA, HMAC, and RSA. Bond et al. [5] verified an assembly implementation of SHA-256, Poly1305, AES and ECDSA. Zinzindohoué, et al. [48] developed HACL*, a verified cryptographic library containing the entire cryptographic API of NaCl [3]. Larger security-critical systems have also been successfully verified. Bhargavan [4] implemented the TLS protocol with verified cryptographic security. CompCert[35] is a C compiler that is formally verified to preserve C code semantics in generated assembly code. Klein et al. [31] designed and proved functional correctness of the seL4 microkernel. More recently, VRASED [17] realized a formally verified hybrid $\sf{RA}$ architecture. VAPE architecture, proposed in this paper, uses VRASED $\sf{RA}$ functionality (see Section 3.2 for details) composed with additional formally verified architectural components to obtain provably secure PoX.

3 Background

3.1 Formal Verification, Model Checking & Linear Temporal Logic

Computer-aided formal verification typically involves three basic steps. First, the system of interest (e.g., hardware, software, communication protocol) is described using a formal model, e.g., a Finite State Machine (FSM). Second, properties that the model should satisfy are formally specified. Third, the system model is checked against formally specified properties to guarantee that the system retains them. This can be achieved by either Theorem Proving or Model Checking. In this work, we use the latter to verify the implementation of system modules, and the former to derive new properties from sub-properties that were proved for the modules’ implementation.

In one instantiation of model checking, properties are specified as formulae using Temporal Logic (TL) and system models are represented as FSMs. Hence, a system is represented by a triple $(S,S_{0},T)$, where $S$ is a finite set of states, $S_{0}\subseteq S$ is the set of possible initial states, and $T\subseteq S\times S$ is the transition relation set – it describes the set of states that can be reached in a single step from each state. The use of TL to specify properties allows representation of expected system behavior over time.

We apply the model checker NuSMV [13], which can be used to verify generic HW or SW models. For digital hardware described at Register Transfer Level (RTL) – which is the case in this work – conversion from Hardware Description Language (HDL) to NuSMV model specification is simple. Furthermore, it can be automated [29], because the standard RTL design already relies on describing hardware as an FSM.

In NuSMV, properties are specified in Linear Temporal Logic (LTL), which is particularly useful for verifying sequential systems, since LTL extends common logic statements with temporal clauses. In addition to propositional connectives, such as conjunction ($\land$), disjunction ($\lor$), negation ($\neg$), and implication ($\rightarrow$), LTL includes temporal connectives, thus enabling sequential reasoning. In this paper, we are interested in the following temporal connectives:

• •

X$\phi$ – neXt $\phi$: holds if $\phi$ is true at the next system state.

• •

F$\phi$ – Future $\phi$: holds if there exists a future state where $\phi$ is true.

• •

G$\phi$ – Globally $\phi$: holds if for all future states $\phi$ is true.

• •

$\phi$ U $\psi$ – $\phi$ Until $\psi$: holds if there is a future state where $\psi$ holds and $\phi$ holds for all states prior to that.

• •

$\phi$ B $\psi$ – $\phi$ Before $\psi$: holds if the existence of state where $\psi$ holds implies the existence of an earlier state where $\phi$ holds. This connective can be expressed using U through the equivalence: $\phi$ B $\psi\equiv\neg(\neg\phi$ U $\psi)$.

This set of temporal connectives combined with propositional connectives (with their usual meanings) allows us to specify powerful rules. NuSMV works by checking LTL specifications against the system FSM for all reachable states in such FSM.

3.2 Formally Verified $\sf{RA}$

VRASED [17] is a formally verified hybrid (hardware/software co-design) RA architecture, built as a set of sub-modules, each guaranteeing a specific set of sub-properties. All VRASED sub-modules, both hardware and software, are individually verified. Finally, the composition of all sub-modules is proved to satisfy formal definitions of $\sf{RA}$ soundness and security. $\sf{RA}$** soundness** guarantees that an integrity-ensuring function (HMAC in VRASED’s case) is correctly computed on the exact memory being attested. Moreover, it guarantees that attested memory remains unmodified after the start of $\sf{RA}$ computation, protecting against “hide-and-seek” attacks caused by self-relocating malware [9]. $\sf{RA}$** security** ensures that $\sf{RA}$ execution generates an unforgeable authenticated memory measurement and that the secret key $\mathcal{K}$ used in computing this measurement is not leaked before, during, or after, attestation.

To achieve aforementioned goals, VRASED software (SW-Att) is stored in Read-Only Memory (ROM) and relies on a (previously) formally verified HMAC implementation from HACL* cryptographic library [48]. A typical execution of SW-Att is carried out as follows:

Read challenge $\sf{\mathcal{C}hal}$ from memory region $MR$. 2. 2.

Derive a one-time key from $\sf{\mathcal{C}hal}$ and the attestation master key $\mathcal{K}$. 3. 3.

Generate an attestation token $H$ by computing an HMAC over an attested memory region $AR$ using the derived key:

$H=HMAC(KDF(\mathcal{K},MR),AR)$ 4. 4.

Write $H$ into $MR$ and return the execution to unprivileged software, i.e, normal applications.

VRASED hardware (HW-Mod) monitors $7$ MCU signals:

• •

$PC$: Current Program Counter value;

• •

$R_{en}$: Signal that indicates if the MCU is reading from memory (1-bit);

• •

$W_{en}$: Signal that indicates if the MCU is writing to memory (1-bit);

• •

$D_{addr}$: Address for an MCU memory access;

• •

$DMA_{en}$: Signal that indicates if Direct Memory Access (DMA) is currently enabled (1-bit);

• •

$DMA_{addr}$: Memory address being accessed by DMA.

• •

$irq$: Signal that indicates if an interrupt is happening (1-bit);

These signals are used to determine a one-bit $reset$ signal output. Whenever $reset$ is set to $1$ a system-wide MCU reset is triggered immediately, i.e., before the execution of the next instruction. This condition is triggered whenever VRASED’s hardware detects any violation of its security properties. VRASED hardware is described in Register Transfer Level (RTL) using Finite State Machines (FSMs). Then, NuSMV Model Checker [14] is used to automatically prove that such FSMs achieve claimed security sub-properties. Finally, the proof that the conjunction of hardware and software sub-properties implies end-to-end soundness and security is done using an LTL theorem prover. More formally, VRASED end-to-end security proof guarantees that no probabilistic polynomial time (PPT) adversary can win the $\sf{RA}$ security game with non-negligible probability in terms of the security parameter. (See Definition 7 in Appendix B).

4 Proof of Execution (PoX) Schemes

A Proof of Execution (PoX) is a scheme involving two parties: (1) a trusted verifier $\sf{\mathcal{V}rf}$, and (2) an untrusted (potentially infected) remote prover $\sf{\mathcal{P}rv}$. Informally, the goal of PoX is to allow $\sf{\mathcal{V}rf}$ to request execution of specific software ${\sf{\mathcal{S}}}$ by $\sf{\mathcal{P}rv}$. As part of PoX, $\sf{\mathcal{P}rv}$ must reply to $\sf{\mathcal{V}rf}$ with an authenticated unforgeable cryptographic proof ($\sf{\mathcal{H}}$) that convinces $\sf{\mathcal{V}rf}$ that $\sf{\mathcal{P}rv}$ indeed executed $\sf{\mathcal{S}}$. To accomplish this, verifying $\sf{\mathcal{H}}$ must prove that: (1) $\sf{\mathcal{S}}$ executed atomically, in its entirety, and that such execution occurred on $\sf{\mathcal{P}rv}$ (and not on some other device); and (2) any claimed result/output value of such execution, that is accepted as legitimate by $\sf{\mathcal{V}rf}$, could not have been spoofed or modified. Also, the size and behavior (i.e., instructions) of $\sf{\mathcal{S}}$, as well as the size of its output (if any), should be configurable and optionally specified by $\sf{\mathcal{V}rf}$. In other words, PoX should provide proofs of execution for arbitrary (including possibly buggy) software, along with corresponding authenticated outputs. Definition 1 specifies PoX schemes in more detail.

We now justify the need to include atomic execution of $\sf{\mathcal{S}}$ in the definition of PoX. On low-end MCUs, software typically runs on “bare metal" and, in most cases, there is no mechanism to enforce memory isolation between applications. Therefore, allowing $\sf{\mathcal{S}}$ execution to be interrupted would permit other (potentially malicious) software running on $\sf{\mathcal{P}rv}$ to alter the behavior of $\sf{\mathcal{S}}$. This might be done, for example, by an application that interrupts execution of $\sf{\mathcal{S}}$ and changes intermediate computation results in $\sf{\mathcal{S}}$ data memory, thus tampering with its output or control flow. Another example is an interrupt that resumes $\sf{\mathcal{S}}$ at different instruction modifying $\sf{\mathcal{S}}$ execution flow. Such actions could modify $\sf{\mathcal{S}}$ behavior completely via return oriented programming (ROP).

4.1 PoX Adversarial Model & Security Definition

We consider an adversary $\sf{\mathcal{A}dv}$ that might control $\sf{\mathcal{P}rv}$’s entire software state, code, and data. $\sf{\mathcal{A}dv}$ can modify any writable memory and read any memory that is not explicitly protected by hardware-enforced access control rules. $\sf{\mathcal{A}dv}$ may also have full control over all Direct Memory Access (DMA) controllers of $\sf{\mathcal{P}rv}$. Recall that DMA allows a hardware controller to directly access main memory (e.g., RAM, flash or ROM) without going through the CPU.

We consider a scheme PoX $=$ $(\mathsf{XRequest},$ $\mathsf{XAtomicExec},$ $\mathsf{XProve},$ $\mathsf{XVerify})$ to be secure if the aforementioned $\sf{\mathcal{A}dv}$ has only negligible probability of convincing $\sf{\mathcal{V}rf}$ that $\sf{\mathcal{S}}$ executed successfully when, in reality, such execution did not take place, or was interrupted. In addition we require that, if execution of $\sf{\mathcal{S}}$ occurs, $\sf{\mathcal{A}dv}$ cannot tamper with, or influence, this execution’s outputs. These notions are formalized by the security game in Definition 2.

We note that Definition 2 binds execution of $\sf{\mathcal{S}}$ to the time between $\sf{\mathcal{V}rf}$ issuing the request and receiving the response. Therefore, if a PoX scheme is secure according to this definition, $\sf{\mathcal{V}rf}$ can be certain about freshness of the execution. In the same vein, the output produced by such execution is also guaranteed to be fresh. This timeliness property is important to avoid replays of previous valid executions; in fact, it is essential for safety-critical applications. See Section 7.3 for examples.

Correctness of the Executable: we stress that the purpose of PoX is to offer a guarantee that $\sf{\mathcal{S}}$, as specified by $\sf{\mathcal{V}rf}$, was executed. Similar to Trusted Execution Environments targeting high-end CPUs, such as Intel SGX, PoX schemes do not aim to check correctness and absence of implementation bugs in $\sf{\mathcal{S}}$. As such, it is not concerned with run-time attacks that exploit bugs and vulnerabilities in $\sf{\mathcal{S}}$ implementation itself, to change its expected behavior (e.g., by executing $\sf{\mathcal{S}}$ with inputs crafted to exploit $\sf{\mathcal{S}}$ bugs and hijack its control flow). In particular, correctness of $\sf{\mathcal{S}}$ need not be assured by the low-end $\sf{\mathcal{P}rv}$. Since $\sf{\mathcal{V}rf}$ is a more powerful device and knows $\sf{\mathcal{S}}$, it has the ability (and more computational resources) to employ various vulnerability detection methods (e.g., fuzzing [12] or static analysis [16]) or even software formal verification (depending on the level of rigor desired) to avoid or detect implementation bugs in $\sf{\mathcal{S}}$. This type of techniques can be performed offline before sending $\sf{\mathcal{S}}$ to $\sf{\mathcal{P}rv}$ and the whole issue is orthogonal to PoX functionality.

Physical Attacks: physical and hardware-focused attacks are out of scope of this paper. Specifically, we assume that $\sf{\mathcal{A}dv}$ cannot modify code in ROM, induce hardware faults, or retrieve $\sf{\mathcal{P}rv}$ secrets via physical presence side-channels. Protection against such attacks is considered orthogonal and could be supported via standard physical security techniques [41].

4.2 MCU Assumptions

VAPE is composed with VRASED to enable a verified architecture for proofs of execution. Therefore, we assume the same machine model introduced in VRASED and make no additional assumptions. We review these assumptions throughout the rest of this section and then formalize them as an LTL machine model in Section 6.

Verification of the entire CPU is beyond the scope of this paper. Therefore, we assume the CPU architecture strictly adheres to, and correctly implements, its specifications. In particular, our design and verification rely on the following simple axioms:

A1 – Program Counter (PC): $PC$ always contains the address of the instruction being executed in a given CPU cycle.

A2 – Memory Address: Whenever memory is read or written, a data-address signal ($D_{addr}$) contains the address of the corresponding memory location. For a read access, a data read-enable bit ($R_{en}$) must be set, while, for a write access, a data write-enable bit ($W_{en}$) must be set.

A3 – DMA: Whenever the DMA controller attempts to access the main system memory, a DMA-address signal ($DMA_{addr}$) reflects the address of the memory location being accessed and a DMA-enable bit ($DMA_{en}$) must be set. DMA cannot access memory when $DMA_{en}$ is off (logical zero).

A4 – MCU Reset: At the end of a successful reset routine, all registers (including $PC$) are set to zero before resuming normal software execution flow. Resets are handled by the MCU in hardware. Thus, the reset handling routine cannot be modified. When a reset happens, the corresponding $reset$ signal is set. The same signal is also set when the MCU initializes for the first time.

A5 – Interrupts: Whenever an interrupt occurs, the corresponding $irq$ signal is set.

5 VAPE: A Secure PoX Architecture

We now present VAPE, a new PoX architecture that realizes the PoX security definition in Definition 2. The key aspect of VAPE is a computer-aided formally verified and publicly available implementation thereof. This section first provides some intuition behind VAPE’s design. All VAPE properties are overviewed informally in this section and are later formalized in Section 6.

In the rest of this section we use the term “unprivileged software” to refer to any software other than SW-Att code from VRASED. $\sf{\mathcal{A}dv}$ is allowed to overwrite or bypass any “unprivileged software”. Meanwhile, “trusted software” refers to VRASED’s implementation of SW-Att (see Section 3) which is formally verified and can not be modified by $\sf{\mathcal{A}dv}$, since it is stored in ROM. VAPE is designed such that no changes to SW-Att are required. Therefore, both functionalities ($\sf{RA}$ and PoX, i.e., VRASED and VAPE) can co-exist on the same device without interfering with each other.

Notation is summarized in Table 1.

5.1 Protocol and Architecture

VAPE implements a secure PoX $=$ $(\mathsf{XRequest},$ $\mathsf{XAtomicExec},$ $\mathsf{XProve},$ $\mathsf{XVerify})$ scheme conforming to Definition 3. The steps in VAPE workflow are illustrated in Figure 1. The main idea is to first execute code contained in $ER$. Then, at some later time, VAPE invokes VRASED verified $\sf{RA}$ functionality to attest the code in $ER$ and include, in the attestation result, additional information that allows $\sf{\mathcal{V}rf}$ to verify that $ER$ code actually executed. If $ER$ execution produces an output (e.g., $\sf{\mathcal{P}rv}$ is a sensor running $ER$’s code to obtain some physical/ambient quantity), authenticity and integrity of this output can also be verified. That is achieved by including the $EXEC$ flag among inputs to HMAC computed as part of VRASED $\sf{RA}$. The value of this flag is controlled by VAPE formally verified hardware and its memory can not be written by any software running on $\sf{\mathcal{P}rv}$. VAPE hardware module runs in parallel with the MCU, monitoring its behavior and deciding the value of $EXEC$ accordingly.

Figure 2 depicts VAPE’s architecture. In addition to VRASED hardware that provides secure $\sf{RA}$ by monitoring a set of CPU signals (see Section 3.2), VAPE monitors values stored in the dedicated physical memory region called $METADATA$. $METADATA$ contains addresses/pointers to memory boundaries of $ER$ (i.e., $ER_{min}$ and $ER_{max}$) and memory boundaries of expected output: $OR_{min}$ and $OR_{max}$. These addresses are sent by $\sf{\mathcal{V}rf}$ as part of $\mathsf{XRequest}$, and are configurable at run-time. The code $\sf{\mathcal{S}}$ to be stored in $ER$ is optionally222Sending the code to be executed is optional because $\sf{\mathcal{S}}$ might be pre-installed on $\sf{\mathcal{P}rv}$. In that case the proof of execution will allow $\sf{\mathcal{V}rf}$ to conclude that the pre-installed $\sf{\mathcal{S}}$ was not modified and that it was executed. sent by $\sf{\mathcal{V}rf}$.

$METADATA$ includes the $EXEC$ flag, which is initialized to [math] and only changes from [math] to $1$ (by VAPE’s hardware) when $ER$ execution starts, i.e., when the PC points to $ER_{min}$. Afterwards, any violation of VAPE’s security properties (detailed in Section 5.2) immediately changes $EXEC$ back to [math]. After a violation, the only way to set the flag back to $1$ is to re-start execution of $ER$ from the very beginning, i.e., with PC=$ER_{min}$. In other words, VAPE verified hardware makes sure that $EXEC$ value covered by the HMAC’s result (represented by $\sf{\mathcal{H}}$) is $1$, if and only if $ER$ code executed successfully. As mentioned earlier, we consider an execution to be successful if it runs atomically (i.e., without being interrupted), from its first $ER_{min}$ to its last instruction $ER_{max}$.

In addition to $EXEC$, HMAC covers a set of parameters (in $METADATA$ memory region) that allows $\sf{\mathcal{V}rf}$ to check whether executed software was indeed located in $ER=[ER_{min},ER_{max}]$. If any output is expected, $\sf{\mathcal{V}rf}$ specifies a memory range $OR=[OR_{min},OR_{max}]$ for storing output. Contents of $OR$ are also covered by the computed HMAC, allowing $\sf{\mathcal{V}rf}$ to verify authenticity of the output of the execution.

Remark: Our notion of successful execution requires $\sf{\mathcal{S}}$ to have a single exit point – $ER_{max}$. Any self-contained code with multiple legal exits can be trivially instrumented to have a single exit point by replacing each exit instruction with a jump to the unified exit point $ER_{max}$. This notion also requires $\sf{\mathcal{S}}$ to run atomically. Since this constraint might be undesirable for some real-time systems, we discuss how to relax it in Appendix C. Finally, $\sf{\mathcal{V}rf}$ is responsible for defining $OR$ memory region according to $\sf{\mathcal{S}}$ behavior. $OR$ should be large enough to fit all output produced by $\sf{\mathcal{S}}$ and $OR$ boundaries should correspond to addresses where $\sf{\mathcal{S}}$ writes its output values to be sent to $\sf{\mathcal{V}rf}$.

5.2 VAPE’s Sub-Properties at a High-Level

We now describe sub-properties enforced by VAPE. Section 6 formalizes them in LTL and provides a single end-to-end definition of VAPE correctness. This end-to-end correctness notion is provably implied by the composition of all sub-properties. Sub-properties fall into two major groups: Execution Protection and Metadata Protection. A violation of any of these properties implies one or more of:

• •

Code in $ER$ was not executed atomically and in its entirety;

• •

Output in $OR$ was not produced by $ER$ execution;

• •

Code in $ER$ was not executed in a timely manner, i.e., after receiving the latest $\mathsf{XRequest}$.

Whenever VAPE detects a violation, $EXEC$ is set to [math]. Since $EXEC$ is included among inputs to the computation of HMAC (conveyed in $\sf{\mathcal{P}rv}$’s response), it will be interpreted by $\sf{\mathcal{V}rf}$ as failure to prove execution of code in $ER$.

Remark: We emphasize that properties discussed below are required in addition to VRASED verified properties, i.e., these are entirely different properties used specifically to enforce PoX security and should not be viewed as replacements for any of VRASED properties that are used to enforce $\sf{RA}$ security.

5.2.1 Execution Protection:

EP1 – Ephemeral Immutability: Code in $ER$ cannot be modified from the start of its execution until the end of SW-Att computation in $\mathsf{XProve}$ routine. This property is necessary to ensure that the attestation result reflects the code that executed. Lack of this property would allow $\sf{\mathcal{A}dv}$ to execute some other code $ER_{\sf{\mathcal{A}dv}}$, overwrite it with expected $ER$ and finally call $\mathsf{XProve}$. This would result in a valid proof of execution of $ER$ even though $ER_{\sf{\mathcal{A}dv}}$ was executed instead.

EP2 – Ephemeral Atomicity: $ER$ execution is only considered successful if $ER$ runs starting from $ER_{min}$ until $ER_{max}$ atomically, i.e., without any interruption. This property conforms with $\mathsf{XAtomicExec}$ routine in Definition 1 and with the notion of successful execution in the context of our work. As discussed in Section 4, $ER$ must run atomically to prevent malware residing on $\sf{\mathcal{P}rv}$ from interrupting $ER$ execution and resuming it at a different instruction, or modifying intermediate execution results in data memory. Without this property, Return-Oriented Programming (ROP) and similar attacks on $ER$ could change its behavior completely and unpredictably, making any proof of execution (and corresponding output) useless.

EP3 – Output Protection: Similar to EP1, VAPE must ensure that $OR$ is unmodified from the time after $ER$ code execution is finished until completion of HMAC computation in $\mathsf{XProve}$. Lack of this property would allow $\sf{\mathcal{A}dv}$ to overwrite $OR$ and successfully spoof $OR$ produced by $ER$, thus convincing $\sf{\mathcal{V}rf}$ that it produced output $OR^{\sf{\mathcal{A}dv}}$.

5.2.2 Metadata Protection:

MP1 - Executable/Output ($ER$/$OR$) Boundaries: VAPE hardware ensures properties EP1, EP2, and EP3 according to values: $ER_{min}$, $ER_{max}$, $OR_{min}$, $OR_{max}$. These values are configurable and can be decided by $\sf{\mathcal{V}rf}$ based on application needs. They are written into metadata-dedicated physical addresses in $\sf{\mathcal{P}rv}$ memory before $ER$ execution. Therefore, once $ER$ execution starts, VAPE hardware must ensure that such values remain unchanged until $\mathsf{XProve}$ completes. Otherwise, $\sf{\mathcal{A}dv}$ could generate valid attestation results, by attesting [$ER_{min}$, $ER_{max}$], while, in fact, having executed code in a different region: [$ER_{min}^{\sf{\mathcal{A}dv}}$, $ER_{max}^{\sf{\mathcal{A}dv}}$].

MP2 - Response Protection: The appropriate response to $\sf{\mathcal{V}rf}$’s challenge must be unforgeable and non-invertible. Therefore, in the $\mathsf{XProve}$ routine, $\mathcal{K}$ used to compute HMAC must never be leaked (with non-negligible probability) and HMAC implementation must be functionally correct, i.e., adhere to its cryptographic specification. Moreover, contents of memory being attested must not change during HMAC computation. We rely on VRASED to ensure these properties. Also, to ensure trustworthiness of the response, VAPE guarantees that no software in $\sf{\mathcal{P}rv}$ can ever modify $EXEC$ flag and that, once $EXEC=0$, it can only become $1$ if $ER$’s execution re-starts afresh.

MP3 - Challenge Temporal Consistency: VAPE must ensure that ${\sf{\mathcal{C}hal}}$ cannot be modified between $ER$’s execution and HMAC computation in $\mathsf{XProve}$. Without this property, the following attack is possible: (1) $\sf{\mathcal{P}rv}$-resident malware executes $ER$ properly (i.e., by not violating EP1-EP3 and MP1-MP2), resulting in $EXEC=1$ after execution stops, and (2) at a later time, malware receives $\sf{\mathcal{C}hal}$ from $\sf{\mathcal{V}rf}$ and simply calls $\mathsf{XProve}$ on this $\sf{\mathcal{C}hal}$ without executing $ER$. As a result, malware would acquire a valid proof of execution (since $EXEC$ remains $1$ when the proof is generated) even though no $ER$ execution occurred before $\sf{\mathcal{C}hal}$ was received. Such attacks are prevented by setting $EXEC=0$ whenever the memory region storing ${\sf{\mathcal{C}hal}}$ is modified.

6 Formal Specification & Verified Implementation

Our formal verification approach starts by formalizing VAPE sub-properties Linear Temporal Logic (LTL) to define invariants that must hold throughout the MCU operation. We then use a theorem prover [20] to write a computer-aided proof that the conjunction of the LTL sub-properties imply an end-to-end formal definition for the guarantee expected from VAPE hardware. VAPE correctness, when properly composed with VRASED guarantees, yields a PoX scheme secure according to Definition 2. This is proved by showing that, if the composition between the two is implemented as described in Definition 3, VRASED security can be reduced to VAPE security.

VAPE hardware module is composed of several sub-modules written in Verilog Hardware Description Language (HDL). Each sub-module is responsible for enforcing a set of LTL sub-properties and is described as an FSM in Verilog at Register Transfer Level (RTL). Individual sub-modules are combined into a single Verilog design. The resulting composition is converted to the SMV model checking language using the automatic translation tool Verilog2SMV [29]. The resulting SMV is simultaneously verified against all LTL specifications, using the model checker NuSMV[14], to prove that the final Verilog of VAPE complies with all necessary properties.

6.1 Machine Model

Definition 4 models, in LTL, the behavior of low-end MCUs considered in this work. It consists of a subset of the machine model introduced by VRASED. Nonetheless, this subset models all MCU behavior relevant for stating and verifying correctness of VAPE’s implementation.

Modify_Mem models that a given memory address can be modified by a CPU instruction or by a DMA access. In the former, $W_{en}$ signal must be set and $D_{addr}$ must contain the target memory address. In the latter, $DMA_{en}$ signal must be set and $DMA_{addr}$ must contain the target DMA address. The requirements for reading from a memory address are similar, except that instead of $W_{en}$, $R_{en}$ must be on. We do not explicitly state this behavior since it is not used in VAPE proofs. For the same reason, modeling the effects of instructions that only modify register values (e.g., ALU operations, such as $add$ and $mul$) is also not necessary. The machine model also captures the fact that, when an interrupt happens during execution, the $irq$ signal in MCU hardware is set to $1$.

With respect to memory layout, the model states that $MR$, $CR$, $AR$, $KR$, $XS$, and $METADATA$ are disjoint memory regions. The first five memory regions are defined in VRASED. As shown in Figure 2, $METADATA$ is a fixed memory region used by VAPE to store information about software execution status.

6.2 Security & Implementation Correctness

We use a two-part strategy to prove that VAPE is a secure PoX architecture, according to Definition 2:

1. [A]:

We show that properties EP1-EP3 and MP1-MP3, discussed in Section 5.2 and formally specified next in Section 6.3, are sufficient to guarantee that $EXEC$ flag is $1$ iff $\sf{\mathcal{S}}$ indeed executed on $\sf{\mathcal{P}rv}$. To show this, we compose a computer proof using SPOT LTL proof assistant [20]. 2. [B]:

We use cryptographic reduction proofs to show that, as long as part A holds, VRASED security can be reduced to VAPE’s PoX security from Definition 2. In turn, HMAC’s existential unforgeability can be reduced to VRASED’s security [17]. Therefore, both VAPE and VRASED rely on the assumption that HMAC is a secure MAC.

In the rest of this section, we convey the intuition behind both of these steps. Proof details are in Appendix B.

The goal of part A is to show that VAPE’s sub-properties imply Definition 5. LTL specification in Definition 5 captures the conditions that must hold in order for $EXEC$ to be set to 1 during execution of $\mathsf{XProve}$, enabling generation of a valid proof of execution. This specification ensures that, in order to have $EXEC=1$ during execution of $\mathsf{XProve}$ (i.e, for $[EXEC\land PC\in CR]$ to hold), at least once before such time the following must have happened:

The system reached state $S_{0}$ where software stored in $ER$ started executing from its first instruction ($PC=ER_{min}$). 2. 2.

The system eventually reached a state $S_{1}$ when ER finished executing ($PC=ER_{max}$). In the interval between $S_{0}$ and $S_{1}$ $PC$ kept executing instructions within $ER$, there were no interrupts, no resets, and DMA remained inactive. 3. 3.

The system eventually reached a state $S_{2}$ when $\mathsf{XProve}$ started executing ($PC=CR_{min}$). In the interval between $S_{0}$ and $S_{2}$, $METADATA$ and $ER$ regions were not modified. 4. 4.

In the interval between $S_{0}$ and $S_{2}$, $OR$ region was only modified by $ER$’s execution, i.e., $PC\in ER\lor\neg\leavevmode\nobreak\ \text{Modify\_Mem}(OR)$.

Figure 3 shows the time windows wherein each memory region must not change during VAPE’s PoX as implied by VAPE’s correctness (Definition 5). Violating any of these conditions will cause $EXEC$ have value [math] during $\mathsf{XProve}$’s computation. Consequently, any violation will result in $\sf{\mathcal{V}rf}$ rejecting the proof of execution since it will not conform to the expected value of $\sf{\mathcal{H}}$, per Equation 2 in Definition 3.

The intuition behind the cryptographic reduction (part B) is that computing $\sf{\mathcal{H}}$ involves simply invoking VRASED SW-Att with $MR={\sf{\mathcal{C}hal}}$, $ER\in AR$, $OR\in AR$, and $METADATA\in AR$. Therefore, a successful forgery of VAPE’s $\sf{\mathcal{H}}$ implies breaking VRASED security. Since $\sf{\mathcal{H}}$ always includes the value of $EXEC$, this implies that VAPE is PoX-secure (Definition 2). The complete reduction is presented in Appendix B.

6.3 VAPE’s Sub-Properties in LTL

We formalize the necessary sub-properties enforced by VAPE as LTL specifications 3–12 in Definition 6. We describe how they map to high-level notions EP1-EP3 and MP1-MP3 discussed in Section 5.2. Appendix B discusses a computer proof that the conjunction of this set of properties is sufficient to satisfy a formal definition of VAPE correctness from Definition 5.

LTL 3 enforces EP1 – Ephemeral immutability by making sure that whenever $ER$ memory region is written by either CPU or DMA, $EXEC$ is immediately set to logical 0 (false).

EP2 – Ephemeral Atomicity is enforced by a set of three LTL specifications. LTL 4 enforces that the only way for $ER$’s execution to terminate, without setting $EXEC$ to logical [math], is through its last instruction: $PC=ER_{max}$. This is specified by checking the relation between current and next $PC$ values using LTL neXt operator. In particular, if current $PC$ value is within $ER$, and next $PC$ value is outside SW-Att region, then either current $PC$ value is the address of $ER_{max}$, or $EXEC$ is set to [math] in the next cycle. Also, LTL 5 enforces that the only way for $PC$ to enter $ER$ is through the very first instruction: $ER_{min}$. This prevents $ER$ execution from starting at some point in the middle of $ER$, thus making sure that $ER$ always executes in its entirety. Finally, LTL 6 enforces that $EXEC$ is set to zero if an interrupt happens in the middle of $ER$ execution. Even though LTLs 4 and 5 already enforce that PC cannot change to anywhere outside $ER$, interrupts could be programmed to return to an arbitrary instruction within $ER$. Although this would not violate LTLs 4 and 5, it would still modify $ER$’s behavior. Therefore, LTL 6 is needed to prevent that.

EP3 – Output Protection is enforced by LTL 7 by making sure that: (1) DMA controller does not write into $OR$; (2) CPU can only modify $OR$ when executing instructions within $ER$; and 3) DMA cannot be active during $ER$ execution; otherwise, a compromised DMA could change intermediate results of $ER$ computation in data memory, potentially modifying $ER$ behavior.

Similar to EP3, MP1 – Executable/Output Boundaries and MP3 – Challenge Temporal Consistency are enforced by LTL 10. Since $\sf{\mathcal{C}hal}$ as well as $ER_{min}$, $ER_{max}$, $OR_{min}$, and $OR_{max}$ are all stored in $METADATA$ reserved memory region, it suffices to ensure that $EXEC$ is set to logical [math] whenever this region is modified. Also, LTL 8 enforces that $EXEC$ is only set to one if $ER$ and $OR$ are configured (by $METADATA$ values $ER_{min}$, $ER_{max}$, $OR_{min}$, $OR_{max}$) as valid memory regions.

Finally, LTLs 11, and 12 (in addition to VRASED verified $\sf{RA}$ architecture) are responsible for ensuring MP2- Response Protection by making sure that $EXEC$ always reflects what is intended by VAPE hardware. LTL 7 specifies that the only way to change $EXEC$ from [math] to $1$ is by starting $ER$’s execution over. Finally, LTL 12 states that, whenever a reset happens (this also includes the system initial booting state) and execution is initialized, the initial value of $EXEC$ is [math].

To conclude, recall that $EXEC$ is read-only to all software running on $\sf{\mathcal{P}rv}$. Therefore, malware can not change it directly.

VAPE is designed as a set of seven hardware sub-modules, each verified to enforce a subset of properties discussed in this section. Due to space constraints, examples of implementation of verified sub-modules as FSMs are discussed in Appendix A.

7 Implementation & Evaluation

VAPE implementation uses OpenMSP430 [25] as its open core implementation. We implement the hardware architecture shown in Figure 2. In addition to VAPE and VRASED modules in HW-Mod, we implement a peripheral module responsible for storing and maintaining VAPE $METADATA$. As a peripheral, contents of $METADATA$ can be accessed in a pre-defined memory address via standard peripheral memory access. We also ensure that $EXEC$ (located inside $METADATA$) is unmodifiable in software by removing software-write wires in hardware. Finally, we use Xilinx Vivado to synthesize an RTL description of the modified HW-Mod and deploy it on the Artix-7 FPGA class.

7.1 Evaluation Results

Hardware & Memory Overhead. Table 2 reports VAPE hardware overhead as compared to unmodified OpenMSP430 [25] and VRASED [17]. VAPE hardware overhead is small compared to the baseline VRASED; it requires 2% and 12% additional registers and LUTs, respectively. In absolute numbers, it adds 44 registers and 302 Look-Up Tables (LUTs) to the underlying MCU. In terms of memory, VAPE needs 9 extra bytes of RAM for storing $METADATA$. This overhead corresponds to 0.01% of MSP430 16-bit address space.

Run-time. We do not observe any overhead for software’s execution time on the VAPE-enabled $\sf{\mathcal{P}rv}$ since VAPE does not introduce new instructions or modifications to the MSP430 ISA. VAPE hardware runs in parallel with the original MSP430 CPU. Run-time to produce a proof of $\sf{\mathcal{S}}$ execution includes: (1) time to execute $\sf{\mathcal{S}}$ ($\mathsf{XAtomicExec}$), and (2) time to compute an attestation token ($\mathsf{XProve}$). The former only depends on $\sf{\mathcal{S}}$ behavior itself (e.g., SW-Att can be a small sequence of instructions or have long loops). As mentioned earlier, VAPE does not affect $\sf{\mathcal{S}}$ runtime. $\mathsf{XProve}$’s run-time is linear in the size of $ER+OR$. In the worst-case scenario where these regions occupy the entire program $8$kB memory, $\mathsf{XProve}$ takes around $900$ms on an 8MHz device.

Verification Efforts. We verify VAPE on an Ubuntu 16.04 machine running at 3.40GHz. Results are shown in Table 2. VAPE verification requires checking 10 extra invariants (shown in Definition 6) in addition to existing VRASED invariants. It also consumes significantly higher run-time and memory usage than VRASED verification. This is because additional invariants introduce five additional variables ($ER_{min}$, $ER_{max}$, $OR_{min}$, $OR_{max}$ and $EXEC$), potentially resulting in an exponential increase in complexity of the model checking process. Nonetheless, the overall verification process is still reasonable for a commodity desktop – it takes around 3 minutes and consumes 280MB of memory.

7.2 Comparison with CFA

To the best of our knowledge, VAPE is the first of its kind and thus there are no other directly comparable PoX architectures. However, to provide a (performance and overhead) point of reference and a comparison, we contrast VAPE overhead with that state-of-the-art CFA architectures. As discussed in Section 2, even though CFA is not directly applicable for producing proofs of execution with authenticated outputs, we consider it to be the closest-related service, since it reports on the exact execution path of a program.

We consider three recent CFA architectures: Atrium [47], LiteHAX [18], and LO-FAT [19]. Figure 4.a compares VAPE to these architectures in terms of number of additional LUTs. In this figure, the black dashed line represents the total cost of the MSP430 MCU: 1904 LUTs. Figure 4.b presents a similar comparison for the amount of additional registers required by these architectures. In this case, the total cost of the MSP430 MCU itself is of 691 registers. Finally, Figure 4.c presents the amount of dedicated RAM required by these architectures (VAPE’s dedicated RAM corresponds to the exclusive access stack implemented by VRASED).

As expected, VAPE incurs much lower overhead. According to our results, the cheapest CFA architecture, LiteHAX, would entail an overhead of nearly 100% LUTs and 300% registers, on MSP430. In addition, LiteHAX would require $150$ $kB$ of dedicated RAM. This amount far exceeds entire addressable memory ($64$ $kB$) of 16-bit processors, such as MSP430. Results support our claim that CFA is not applicable to this class of low-end devices. Meanwhile, VAPE needs a total of 12% additional LUTs and 2% additional registers. VRASED requires about $2$ $kB$ of reserved RAM, which is not increased by VAPE PoX support.

7.3 Proof of Concept: Authenticated Sensing and Actuation

As discussed in Section 1 an important functionality attainable with PoX is authenticated sensing/actuation. In this section, we demonstrate how to use VAPE to build sensors and actuators that “cannot lie”.

As a running example we use a fire sensor: a safety-critical low-end embedded device commonly present in households and workplaces. It consists of an MCU equipped with analog hardware for measuring physical/chemical quantities, e.g., temperature, humidity, and $CO_{2}$ level. It is also usually equipped with actuation-capable analog hardware, such as a buzzer. Analog hardware components are directly connected to MCU General Purpose Input/Output (GPIO) ports. GPIO ports are physical wires directly mapped to fixed memory locations in MCU memory. Therefore, software running on the MCU can read physical quantities directly from GPIO memory.

In this example, we consider that MCU software periodically reads these values and transmits them to a remote safety authority, e.g., a fire department, which then decides whether to take action. The MCU also triggers the buzzer actuator whenever sensed values indicate a fire. Given the safety-critical nature of this application, the safety authority must be assured that reported values are authentic and were produced by execution of expected software. Otherwise, malware could spoof such values (e.g., by not reading them from the proper GPIO). PoX guarantees that reported values were read from the correct GPIO port (since the memory address is specified by instructions in the ER executable), and produced output (stored in OR) was indeed generated by execution of ER and was unmodified thereafter. Thus, upon receiving sensed values accompanied by a PoX, the safety authority is assured that the reported sensed value can be trusted.

As a proof of concept, we use VAPE to implement a simple fire sensor that operates with temperature and humidity quantities. It communicates with a remote $\sf{\mathcal{V}rf}$ (e.g., the fire department) using a low-power ZigBee radio333https://www.zigbee.org/ typically used by low-end CPS/IoT devices. Temperature and humidity analog devices are connected to a VAPE-enabled MSP430 MCU running at 8MHz and synthesized using a Basys3 Artix-7 FPGA board. As shown in Figure 5, MCU GPIO ports connected to the temperature/humidity sensor and to the buzzer.

VAPE is used to prove execution of the fire sensor software. This software is shown in Figure 8a in Appendix D. It consists of two main functions: ReadSensor and SoundAlarm. Proofs of execution are requested by the safety authority via $\mathsf{XRequest}$ to issue commands to execute these functions. ReadSensor reads and processes the value generated by temperature/humidity analog device memory-mapped GPIO, and copies this value to $OR$. The SoundAlarm function turns the buzzer on for 2 seconds, i.e., it writes “1” to the memory address mapped to the buzzer, busy-waits for 2 seconds, and then writes “0” to the same memory location. This implementation corresponds to the one in the open-source repository 444https://github.com/Seeed-Studio/LaunchPad_Kit and was ported to a VAPE-enabled MCU. The porting effort was minimal: it involved around 30 additional lines of C code, mainly for re-implementing sub-functions originally implemented as shared APIs, e.g., digitalRead/Write. Finally, we transformed ported code to be compatible with VAPE’s PoX architecture. Details can be found in Appendix D.

8 Conclusion

This paper introduces VAPE, a novel and formally verified security service targeting low-end embedded devices. It allows a remote untrusted prover to generate unforgeable proofs of remote software execution. We envision VAPE’s use in many IoT application domains, such as authenticated sensing and actuation. Our implementation of VAPE is realized on a real embedded system platform, MSP430, synthesized on an FPGA, and the verified implementation is publicly available. Our evaluation shows that VAPE has low overhead for both hardware footprint and time for generating proofs of execution.

Appendix A Sub-Module Verification

VAPE is designed as a set of seven sub-modules. We now describe VAPE’s verified implementation, by focusing on two of these sub-modules and their corresponding properties. The Verilog implementation of omitted sub-modules is available in [2]. Each sub-module enforces a sub-set of the LTL specifications in Definition 6. As discussed in Section 6, sub-modules are designed as FSMs. In particular, we implement them as Mealy FSMs, i.e, their output changes as a function of both the current state and current input values. Each FSM takes as input a subset of signals shown in Figure 2 and produces only one output – $EXEC$ – indicating violation of PoX properties.

To simplify the presentation, we do not explicitly represent the value of $EXEC$ for each state transition. Instead, we define the following implicit representation:

$EXEC$ is 0 whenever an FSM transitions to $NotExec$ state. 2. 2.

$EXEC$ remains 0 until a transition leaving $NotExec$ state is triggered. 3. 3.

$EXEC$ is 1 in all other states. 4. 4.

Sub-modules composition: Since all PoX properties must simultaneously hold, the value of $EXEC$ produced by VAPE is the conjunction (logical $AND$) of all sub-modules’ individual $EXEC$ flags.

Figure 6 represents a verified model enforcing LTLs 4-6, corresponding to the high-level property EP2- Ephemeral Atomicity. The FSM consists of five states. $notER$ and $midER$ represent states when $PC$ is: (1) outside $ER$, and (2) within $ER$ respectively, excluding the first ($ER_{min}$) and last ($ER_{max}$) instructions. Meanwhile, $fstER$ and $lstER$ correspond to states when $PC$ points to the first and last instructions, respectively. The only possible path from $notER$ to $midER$ is through $fstER$. Similarly, the only path from $midER$ to $notER$ is through $lstER$. A transition to the $NotExec$ state is triggered whenever: (1) any sequence of values for $PC$ do not follow the aforementioned conditions, or (2) $irq$ is logical 1 while $PC$ is inside $ER$. Lastly, the only way to transition out of the $NotExec$ state is to restart $ER$’s execution.

Figure 7 shows the FSM verified to comply with LTL 10 (MP3- Challenge Temporal Consistency). The FSM has two states: $Run$ and $NotExec$. The FSM transitions to the $NotExec$ state and outputs $EXEC=0$ whenever a violation happens, i.e., whenever $METADATA$ is modified in software. It transitions back to $Run$ when $ER$’s execution is restarted without such violation.

Appendix B Proofs for Implementation Correctness & Security

In this section we discuss the computer proof for VAPE’s implementation correctness (Theorem 1) and the reduction proof that VAPE is a secure PoX architecture as long as VRASED is a secure $\sf{RA}$ architecture (Theorem 2).

A formal LTL computer proof for Theorem 1 is available at [2]. We here discuss the intuition behind such proof. Theorem 1 states that LTLs 3 – 12, when considered in conjunction with the machine model in Definition 4, imply VAPE’s implementation correctness.

Recall that Definition 5 states that, in order to have $EXEC=1$ during the computation of $\mathsf{XProve}$, at least once before such time the following must have happened:

The system reached state $S_{0}$ in which the software stored in $ER$ started executing from its first instruction ($PC=ER_{min}$). 2. 2.

The system eventually reached a state $S_{1}$ when ER finished executing ($PC=ER_{max}$). In the interval between $S_{0}$ and $S_{1}$ $PC$ remained executing instructions within $ER$, there were no interrupts, no resets, and DMA remained inactive. 3. 3.

The system eventually reached a state $S_{2}$ when $\mathsf{XProve}$ started executing ($PC=CR_{min}$). In the interval between $S_{0}$ and $S_{2}$ the memory regions of $METADATA$ and $ER$ were not modified. 4. 4.

In the interval between $S_{0}$ and $S_{2}$ the $OR$ memory region was only modified by $ER$’s software execution ($PC\in ER\lor\neg\leavevmode\nobreak\ \text{Modify\_Mem}(OR)$).

The first two properties to be noted are LTL 12 and LTL 11. LTL 12 establishes the default state of $EXEC$ is [math]. LTL 11 enforces that the only possible way to change $EXEC$ from [math] to $1$ is by having $PC=ER_{min}$. In other words, $EXEC$ is $1$ during the computation of $\mathsf{XProve}$ only if, at some before that, the code stored in ER started to execute (state $S_{0}$).

To see why state $S_{1}$ (when ER execution finishes, i.e., $PC=ER_{max}$) is reached and until then ER executes atomically, we look at LTLs 4, 5, 6, and 9. LTLs 4, 5 and 6 enforce that $PC$ will stay inside $ER$ until $S_{1}$ or otherwise $EXEC$ will be set to [math]. On the other hand, it is impossible to execute instructions of $\mathsf{XProve}$ ($PC\in CR$) without leaving $ER$, because LTL 9 guarantees that $ER$ and $CR$ do not overlap, or $EXEC=0$.

So far we have argued that to have a token $\sf{\mathcal{H}}$ that reflects $EXEC=1$ the code contained in $ER$ must have executed successfully. What remains to be shown is: producing this token implies the code in $ER$ and $METADATA$ are not modified in the interval between $S_{0}$ and $S_{2}$ and only $ER$’s execution can modify $OR$ in the same time interval.

Clearly, the contents of $ER$ cannot be modified after $S_{0}$ because Modify_Mem($ER$) directly implies that LTL 3 will set $EXEC=0$. The same reasoning is applicable for modifications to $METADATA$ region with respect to LTL 10. The same argument applies to modifying $OR$, with the only exception that $OR$ modifications are allowed only by the CPU and when $PC\in ER$ (LTL 7). This means that $OR$ can only be modified by the execution of $ER$. In addition, LTL 7 also ensures that DMA is disabled during the execution of $ER$ to prevent unauthorized modification of intermediate results in data memory. Therefore, the timeline presented in Figure 3 is strictly implied by VAPE’s implementation. This concludes the reasoning behind Theorem 1.

Proof.

Assume that $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ is an adversary capable of winning the security game in Definition 2 against VAPE with more than negligible probability. We show that, if such $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ exists, then it can be used to construct (in a polynomial number of steps) $\sf{\mathcal{A}dv}_{{\sf{RA}}}$ that wins VRASED’s security game (Definition 7) with more than negligible probability. Therefore, by contradiction, nonexistence of $\sf{\mathcal{A}dv}_{{\sf{RA}}}$ (i.e., VRASED’s security) implies nonexistence of $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ (VAPE’s security).

First we recall that to win VAPE’s security game $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ must provide (${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$, ${\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}}$), such that $\mathsf{XVerify}({\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}},{\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}},{\sf{\mathcal{S}}},{\sf{\mathcal{C}hal}},\cdot)=1$. To comply with conditions 3.a and 3.b in Definition 2, this must be done either of the following two cases:

• Case1

$\sf{\mathcal{A}dv}$ does not execute ${\sf{\mathcal{S}}}$ in the time window between $t_{req}$ and $t_{verif}$ (i.e., $\neg\mathsf{XAtomicExec}^{{\sf{\mathcal{P}rv}}}({\sf{\mathcal{S}}},t_{req}\rightarrow t_{verif})$).

• Case2

$\sf{\mathcal{A}dv}$ calls $\mathsf{XAtomicExec}^{{\sf{\mathcal{P}rv}}}({\sf{\mathcal{S}}},t_{req}\rightarrow t_{verif})$ but modifies its output $\sf{\mathcal{O}}$ in between the time when the execution of $\sf{\mathcal{S}}$ completes and the time when $\mathsf{XProve}$ is called.

However, according to the specification of VAPE’s $\mathsf{XVerify}$ algorithm (see Definition 3) a token ${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$ will only be accepted if it reflects an input value with $EXEC=1$, as expected by $\sf{\mathcal{V}rf}$. In VAPE’s implementation $\sf{\mathcal{O}}$ is stored in region $OR$, and $\sf{\mathcal{S}}$ in region $ER$. Moreover, given Theorem 1, we know that having $EXEC=1$ during $\mathsf{XProve}$ implies three conditions have been fulfilled:

1. Cond1

The code in $ER$ executed successfully. 2. Cond2

The code in $ER$ and $METADATA$ were not modified after starting $ER$’s execution and before calling $\mathsf{XProve}$. 3. Cond3

Outputs in $OR$ were not modified after completing $ER$’s execution and before calling $\mathsf{XProve}$.

The third condition rules out the possibility of Case2 since that case assumes $\sf{\mathcal{A}dv}$ can modify $\sf{\mathcal{O}}$, resided in $OR$, after $ER$ execution and $EXEC$ stays logical 1 during $\mathsf{XProve}$. We further break down Case1 into three sub-cases:

• Case1.1

$\sf{\mathcal{A}dv}$ does not follow Cond1-Cond3. The only way for $\sf{\mathcal{A}dv}$ to produces (${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$, ${\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}}$) in this case is to not call $\mathsf{XProve}$, i.e., by directly guessing $\sf{\mathcal{H}}$.

• Case1.2

$\sf{\mathcal{A}dv}$ follows Cond1-Cond3 but does not execute $\sf{\mathcal{S}}$ between $t_{req}$ and $t_{verif}$. Instead, it produces (${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$, ${\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}}$) by calling:

[TABLE]

where $ER_{\sf{\mathcal{A}dv}}$ is a memory region different from the one specified by $\sf{\mathcal{V}rf}$ on $\mathsf{XRequest}$ ($\sf{\mathcal{A}dv}_{\texttt{PoX}}$ can do this by modifying $METADATA$ to different values of $ER_{min}$ and $ER_{max}$ before calling $\mathsf{XAtomicExec}$).

• Case1.3

Similar to Case1.2, but $ER_{\sf{\mathcal{A}dv}}$ is the same region specified by $\sf{\mathcal{V}rf}$ on $\mathsf{XRequest}$ containing a different executable ${\sf{\mathcal{S}}}_{\sf{\mathcal{A}dv}}$.

We show that an adversary that succeeds in any of these cases can be used win VRASED’s security game. To see why this is the case, we note that VAPE’s $\mathsf{XProve}$ function is implemented by using VRASED’s SW-Att without any modification. SW-Att covers memory regions $MR$ (challenge memory) and $AR$ (attested region). Hence, VAPE instantiates these memory regions as:

$MR={\sf{\mathcal{C}hal}}$; 2. 2.

$ER\subset AR$; 3. 3.

$OR\subset AR$; 4. 4.

$METADATA\subset AR$;

Doing so ensures that all sensitive memory regions used by VAPE are included among the inputs to VRASED’s attestation. Let $X(t)$ denote the content in memory region $X$ at time $t$. $\sf{\mathcal{A}dv}_{{\sf{RA}}}$ can then be constructed using $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ as follows:

$\sf{\mathcal{A}dv}_{{\sf{RA}}}$ receives $\sf{\mathcal{C}hal}$ from the challenger in step (2) of $\sf{RA}$ security game of Definition 7. 2. 2.

At arbitrary time $t$, $\sf{\mathcal{A}dv}_{{\sf{RA}}}$ has 3 options to write $AR(t)=AR_{\sf{\mathcal{A}dv}}$ and call $\sf{\mathcal{A}dv}_{\texttt{PoX}}$:

1. (a)

Modify $ER(t)\neq{\sf{\mathcal{S}}}$ or $OR(t)\neq{\sf{\mathcal{O}}}$ or $METADATA(t)\neq METADATA_{{\sf{\mathcal{V}rf}}}$. It then calls $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ in Case1.1. 2. (b)

Modify $ER$ to be different from the range chosen by $\sf{\mathcal{V}rf}$. Therefore, $METADATA(t)\neq METADATA_{{\sf{\mathcal{V}rf}}}$. It then calls $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ in Case1.2. 3. (c)

Modify $ER(t)$ to be different from $\sf{\mathcal{S}}$. It then calls $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ in Case1.3.

In any of these options, $\sf{\mathcal{A}dv}_{{\sf{RA}}}$ will produce (${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$,${\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}}$), such that $\mathsf{XVerify}({\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}},{\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}},{\sf{\mathcal{S}}},{\sf{\mathcal{C}hal}},\cdot)=1$ with non-negligible probability. 3. 3.

$\sf{\mathcal{A}dv}_{{\sf{RA}}}$ replies to the challenger with the pair $(M,{\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}})$, where $M$ corresponds to the values of ${\sf{\mathcal{S}}}$, ${\sf{\mathcal{O}}}$ and $METADATA_{{\sf{\mathcal{V}rf}}}$, matching ${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$ and ${\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}}$ generated by $\sf{\mathcal{A}dv}_{\texttt{PoX}}$. By construction $M\neq AR_{\sf{\mathcal{A}dv}}=AR(t)$, as required by Definition 7. 4. 4.

Challenger will accept $(M,{\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}})$ with the same non-negligible probability that $\sf{\mathcal{A}dv}_{\texttt{PoX}}$ has of producing (${\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}}$,${\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}}$) such that $\mathsf{XVerify}({\sf{\mathcal{H}}}_{\sf{\mathcal{A}dv}},{\sf{\mathcal{O}}}_{\sf{\mathcal{A}dv}},{\sf{\mathcal{S}}},{\sf{\mathcal{C}hal}},\cdot)=1$.

∎

Appendix C Executable Limitations

We now discuss the limitations of our approach on the executable types.

Shared libraries. In order to produce a valid proof, $\sf{\mathcal{V}rf}$ must ensure that execution of $\sf{\mathcal{S}}$ does not depend on external code located outside its execution range $ER$ (e.g., shared libraries). A call to such code would violate LTL 4, resulting in $EXEC=0$ during the HMAC computation. One possible way to support this type of executable is to transform it into a self-contained executable by statically linking all dependencies during the compilation time. Another is to appropriately set $ER$ to cover all external code used by $\sf{\mathcal{S}}$.

Self-modifying code (SMC). SMC is a type of executable that alters itself while executing. Clearly, this executable type violates LTL 3 that requires the code in $ER$ to remain unchanged during $ER$ execution. It is unclear how VAPE can be adapted to support SMC; however, we are unaware of any legitimate and realistic use-case of SMC in our target bare-metal applications.

Interrupts. Our notion of successful execution in Section 5.1 prohibits an interrupt to happen during $\sf{\mathcal{S}}$’s execution. This limitation can be problematic especially for interrupt-driven programs such as the ones in real-time systems. Nonetheless, simply allowing interrupts to happen during the execution may result in attacks that allow malware to modify intermediate execution results in data memory and consequently influence the execution output. One possible way to remedy this issue is to allow interrupts as long as all interrupt handlers are: (1) immutable from the start of execution till the end of attestation and (2) included in the attested memory range during the attestation process. $\sf{\mathcal{V}rf}$ then can determine whether an interrupt that may have happened during the execution is malicious by inspecting all interrupt handlers from the proof of execution.

Appendix D Software Transformation

Recall that our notion of successful execution (in Section 5.1) requires the function’s entry point to be at the first instruction and the exit point to be at the last instruction. In this section, we discuss an efficient way to transform arbitrary software (besides the ones in Appendix C) implementing a function to conform with this requirement.

Line 10-17 of Figure 8 shows an (partial) implementation of the ReadSensor function described in Section 7.3. This implementation, when converted to an executable, does not guarantee VAPE’s executable requirement since the compiler may choose to place one of its sub-functions, instead of ReadSensor, to the entry and/or exit points of the executable. One obvious way to fix this issue is to implement all of its sub-functions as inline functions; however, such approach may be inefficient as in this example it will create multiple duplicate code for the same sub-functions (e.g., digitalWrite) inside the executable.

Instead, we created the dedicated functions for the entry (Line 1-4) and exit (Line 6-8) points, and assign those functions to separated executable sections – “.exec.entry” for the entry and “.exec.exit” for the exit. Then, we labeled all sub-functions used by ReadSensor as well as ReadSensor itself to the same section – “.exec.body” – and modified the MSP430 linker to place “.exec.body” between “.exec.entry” and “.exec.exit” sections. The modified linker script is shown in Figure 8b. This way, we ensure that the entry and exit function locate at the beginning and the end of the executable, respectively, and thus the resulting executable conforms with VAPE’s requirement.