Karim Eldefrawy

Cryptography, Cybersecurity, Privacy

Co-founder and CTO at Confidencial.io
2017-2021: SRI
2011-2016: HRL Laboratories
2006-2010: PhD@UC Irvine

Scientific curiosity

Scientific knowledge map · Paper #54

APEX: A Verified Architecture for Proofs of Execution on Remote Devices Under Full Software Compromise

Ivan De Oliveira Nunes, Karim Eldefrawy, Norrathep Rattanavipanon, and Gene Tsudik

2020 · 29th USENIX Security Symposium

  • Theory
  • Applied
  • protocol
  • primitive

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?

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.

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.

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.

The visual spider chart requires JavaScript. The complete values and rationales follow in text.

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.

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.

paper

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
  1. primitive

    Proof of execution primitive

    formally defined

    PoX 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
  2. 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
  3. 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
    1. mechanism

      Execution and output protection

      hardware enforced

      The 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
  4. 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
  5. 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
    1. evidence

      Hardware, memory, and verification cost

      measured

      Relative 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
    2. evidence

      Runtime boundary

      measured

      The 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
  6. demonstration

    Authenticated sensing and actuation

    proof of concept

    A 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
  7. scrutiny

    External scrutiny

    venue and artifact reviewed

    APEX 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

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.

  1. Motivation, questions, and claimed contribution Abstract and Section 1, PDF pages 1-2
  2. Proof-of-execution syntax and security game Section 4 and Definitions 1-2, PDF pages 4-6
  3. Full-software-compromise adversary and exclusions Section 4.1 and physical-attack discussion, PDF pages 5-6
  4. MCU machine axioms Section 4.2, PDF pages 5-6
  5. APEX protocol, architecture, and authenticated proof Section 5.1 and Definition 3, PDF pages 6-8
  6. Execution, output, and metadata protection Section 5.2, PDF pages 8-9
  7. LTL specification, model checking, and PoX proof argument Section 6 and Definitions 4-6, PDF pages 9-11
  8. OpenMSP430 implementation and evaluation Sections 7-7.2 and Tables 2-3, PDF pages 11-13
  9. Authenticated sensing and actuation proof of concept Section 7.3, PDF pages 13-15
  10. Limitations and future directions Section 8, PDF pages 14-15
  11. Conclusion Section 9, PDF page 15
  12. Public implementation repository Repository cited by the paper; artifact was not rebuilt in this map audit
  13. USENIX publication and artifact record USENIX Security 2020 paper page; paper carries an Artifact Evaluated - Passed badge
  14. Dated citation-count snapshot OpenAlex reported 38 citations when accessed 2026-07-11