Scientific knowledge map · Paper #54
APEX: A Verified Architecture for Proofs of Execution on Remote Devices Under Full Software Compromise
2020 · 29th USENIX Security Symposium
- Theory
- Applied
- protocol
- primitive
Research question
What does the paper try to establish?
Can a low-end embedded device under complete software compromise prove to a remote verifier that specified software ran atomically and produced an authentic fresh output?
Central answer
What is the proposed answer?
APEX defines a proof-of-execution security game and extends the verified VRASED attestation architecture with hardware-enforced execution, output, and metadata invariants. The design is model checked, implemented on OpenMSP430 and an FPGA, released as an artifact, and evaluated with low measured hardware overhead.
Full paper abstract
Abstract
Modern society is increasingly surrounded by, and is growing 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 as well as industrial and residential automation, e.g., sensor-alarm combinations. On the lower end of the scale, these devices are small, cheap and specialized sensors and/or actuators. They tend to host small anemic CPUs, have small amounts of memory and run simple software. If such 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, or verify that commands were performed, by a simple remote embedded device?, (2) How to bind these actions/results to the execution of expected software? and, (3) Can (1) and (2) be attained even if all software on a device can be modified and/or compromised? In this paper we answer these questions by designing, demonstrating security of, and formally verifying, APEX: an Architecture for Provable 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, authenticated sensing and trustworthy actuation, which are increasingly relevant in the context of safety-critical systems. APEX is publicly available and our evaluation shows that it incurs low overhead, affordable even for very low-end embedded devices, e.g., those based on TI MSP430 or AVR ATmega processors.
Provenance: Transcribed from the checked-in full-text PDF; only typography, discretionary hyphenation, and line-break artifacts were normalized. Unusual source punctuation in the three numbered questions is preserved.
Evidence profile
Six dimensions, kept separate
The chart summarizes documented evidence and process. It is not a correctness probability, confidence score, or ranking, and no composite score is calculated.
LowMediumHighN/A = not assessed
A smaller value means less documented support for that dimension, not that the paper is false or unimportant.
- Epistemic evidence High
-
The source combines a formal security game, machine-checked hardware invariants, a reduction argument, synthesizable implementation, measured overheads, and an end-to-end proof of concept, while clearly stating its assumptions and exclusions.
Proof-of-execution syntax and security game LTL specification, model checking, and PoX proof argument OpenMSP430 implementation and evaluation Limitations and future directions - Auditability High
-
A checked-in author copy with fixity metadata, official open-access record, public code, formal specifications, and represented artifact badge make the evidence highly inspectable.
Motivation, questions, and claimed contribution Public implementation repository USENIX publication and artifact record - Production provenance Medium
-
Authors, venue, source copy, public repository, platform, and verification stack are documented, but contributor roles and exact commit-to-paper build provenance are not fully captured in this map.
Public implementation repository USENIX publication and artifact record - External scrutiny High
-
Publication at USENIX Security plus the Artifact Evaluated - Passed badge provides both venue and artifact scrutiny; private review reports and independent proof rechecking remain unavailable.
USENIX publication and artifact record - Reception High
-
The dated exact-title OpenAlex record located 38 citations. Under the author-defined corpus rule, 11 or more located citations is High; the count remains index- and date-dependent.
Dated citation-count snapshot - Contribution significance High
-
The work defines and realizes a new low-end proof-of-execution service with formal and concrete evidence, and the citation snapshot indicates substantial uptake. Priority and correctness are still not guaranteed by this rating.
Motivation, questions, and claimed contribution Conclusion Dated citation-count snapshot
Assessment: Ai draft author review pending · 2026-07-11 · rubric 0.2. These dimensions describe documented support and process, not truth, correctness, or a universal ranking. No composite score is calculated.
Top-down and bottom-up view
Hierarchical knowledge map
Collapse a branch for a top-level reading, or follow its source links and child nodes to audit the evidence and boundaries underneath it.
APEX: A Verified Architecture for Proofs of Execution on Remote Devices Under Full Software Compromise
A formally specified, model-checked, implemented, and evaluated proof-of-execution architecture for low-end microcontrollers under complete software compromise.
Motivation, questions, and claimed contribution-
question Research question
research questionCan a remote verifier bind a fresh device output to complete atomic execution of expected code even when every unprotected software component is adversarial?
Motivation, questions, and claimed contribution Proof-of-execution syntax and security game -
contribution Central answer
constructed and verifiedAPEX adds verified hardware monitors and protected execution metadata to VRASED so an attestation token authenticates the executable region, output region, request challenge, bounds, and a hardware-controlled successful-execution flag.
APEX protocol, architecture, and authenticated proof Execution, output, and metadata protection -
primitive Proof of execution primitive
formally definedPoX consists of request, atomic execution, proof generation, and verification algorithms. Security forbids convincing the verifier after no or incomplete execution and forbids substituting a tampered output for the actual execution result.
Proof-of-execution syntax and security game -
threat model Full software compromise defined
The adversary controls all device software, writable state, and DMA, and may read any memory not hardware-protected. It cannot change ROM, violate the assumed CPU semantics, induce physical faults, or extract secrets through physical side channels.
Full-software-compromise adversary and exclusions MCU machine axioms-
limitation Execution is not program correctness
explicitly scopedA valid APEX proof says the requested code ran under the defined conditions and produced the authenticated bytes; it does not establish that the code is bug-free, functionally correct, or safe on malicious inputs.
Proof-of-execution syntax and security game Limitations and future directions
-
-
protocol APEX protocol specified
The verifier supplies code or identifies preinstalled code, memory bounds, and a fresh challenge. Hardware enforces atomic execution and sets EXEC only after success; VRASED then computes an HMAC-based proof over code, output, and metadata.
APEX protocol, architecture, and authenticated proof-
mechanism Execution and output protection
hardware enforcedThe verified logic rejects interrupted execution, entry or exit at the wrong boundary, DMA or software modification of protected regions, and changes to the executable or output between completion and proof generation.
Execution, output, and metadata protection -
mechanism Protected metadata and freshness
hardware enforcedHardware makes the EXEC flag software read-only and protects challenge and region bounds; including the fresh challenge in key derivation and the MAC binds the proof to the current request.
APEX protocol, architecture, and authenticated proof Execution, output, and metadata protection
-
-
evidence group Formal evidence machine checked
APEX subproperties are expressed in linear temporal logic, translated into a finite-state hardware model, and checked with NuSMV; the security argument composes these invariants with VRASED remote-attestation security.
LTL specification, model checking, and PoX proof argument-
claim PoX security under the stated MCU model
proved under assumptionsThe paper argues that satisfying the verified execution, output, and metadata properties reduces a successful PoX forgery to breaking VRASED's attestation guarantee, under the cryptographic and machine assumptions.
Proof-of-execution syntax and security game LTL specification, model checking, and PoX proof argument
-
-
artifact group Hardware and software implementation implemented
The authors implement APEX on OpenMSP430, synthesize the design for an Artix-7 FPGA, reuse VRASED's protected attestation software, and publish the implementation.
OpenMSP430 implementation and evaluation Public implementation repository-
evidence Hardware, memory, and verification cost
measuredRelative to VRASED, APEX adds 44 registers and 302 lookup tables, reported as about 2 percent and 12 percent respectively, plus 9 bytes of metadata RAM. Model checking takes about three minutes and 280 MB on the reported workstation.
OpenMSP430 implementation and evaluation -
evidence Runtime boundary
measuredThe hardware monitor adds no instructions to the protected program; proof latency is the program's own execution plus VRASED attestation, reported around 900 ms on an 8 MHz device for the evaluated configuration.
OpenMSP430 implementation and evaluation
-
-
demonstration Authenticated sensing and actuation
proof of conceptA fire-sensor prototype on an APEX-enabled MSP430 and FPGA binds temperature or humidity reads and buzzer actuation to specified code, illustrating how a verifier can detect spoofed software outputs in the model.
Authenticated sensing and actuation proof of concept -
limitation group Limitations
materialPhysical attacks and CPU-design faults are outside scope; code with external shared-library calls must be made self-contained; self-modifying code violates immutability; and atomic execution currently rejects interrupts, creating a real-time compatibility problem.
Full-software-compromise adversary and exclusions Limitations and future directions -
artifact group Public and evaluated artifact
evaluated artifactThe paper, source repository, and official USENIX record are public, and the paper carries an Artifact Evaluated - Passed badge. This map did not independently rebuild the repository.
Public implementation repository USENIX publication and artifact record -
scrutiny External scrutiny
venue and artifact reviewedAPEX appeared at USENIX Security 2020 and passed the venue's represented artifact evaluation. Public review reports and independent formal re-verification are not linked.
USENIX publication and artifact record -
lineage Extension of VRASED
documentedAPEX deliberately reuses VRASED's verified remote-attestation root and adds a proof-of-execution layer without changing the protected attestation routine, so the two services can coexist.
APEX protocol, architecture, and authenticated proof LTL specification, model checking, and PoX proof argument
Audit trail
Source index
Locators state the depth of the current audit. PDF page numbers, where present, are one-based file pages; metadata-, summary-, and abstract-bounded records explicitly identify their limitations.
- Motivation, questions, and claimed contribution Abstract and Section 1, PDF pages 1-2
- Proof-of-execution syntax and security game Section 4 and Definitions 1-2, PDF pages 4-6
- Full-software-compromise adversary and exclusions Section 4.1 and physical-attack discussion, PDF pages 5-6
- MCU machine axioms Section 4.2, PDF pages 5-6
- APEX protocol, architecture, and authenticated proof Section 5.1 and Definition 3, PDF pages 6-8
- Execution, output, and metadata protection Section 5.2, PDF pages 8-9
- LTL specification, model checking, and PoX proof argument Section 6 and Definitions 4-6, PDF pages 9-11
- OpenMSP430 implementation and evaluation Sections 7-7.2 and Tables 2-3, PDF pages 11-13
- Authenticated sensing and actuation proof of concept Section 7.3, PDF pages 13-15
- Limitations and future directions Section 8, PDF pages 14-15
- Conclusion Section 9, PDF page 15
- Public implementation repository Repository cited by the paper; artifact was not rebuilt in this map audit
- USENIX publication and artifact record USENIX Security 2020 paper page; paper carries an Artifact Evaluated - Passed badge
- Dated citation-count snapshot OpenAlex reported 38 citations when accessed 2026-07-11