BRIDGE

Brokered Runtime-Integrated Distribution for Guarded Execution in IoT

A framework that integrates runtime protection into the software-delivery process itself, so that provenance authenticity, device binding, and runtime protection converge on one final execution object.

Core idea

Secure-update frameworks and runtime defenses each anchor their guarantees to a different artifact: provenance to the delivered package, device binding to the installation step, and runtime protection to a build-time policy shared by every deployment. A device can therefore accept software that passes each check in isolation while still executing an object that none of the checks was tied to — a time-of-check-to-time-of-use (TOCTOU) gap between the object verified at delivery and the object ultimately executed.

BRIDGE closes this gap by making the runtime protection policy a product of the delivery itself. A Broker derives, under a key recoverable only by the target device, per-basic-block reference tags over the program's executable code, and commits them — together with the payload and the device-binding evidence — into one signed manifest. Provenance, device binding, and runtime protection thus constrain the same final execution object, structurally eliminating the delivery-to-execution gap.

Repository layout

• runtime/ — basic-block runtime protection: an LLVM pass instruments each basic block, and a Cortex-M3 runtime verifies per-block integrity tags (a keyed PRF) plus a shadow return stack for backward-edge control-flow integrity. See runtime/README.md.
• delivery/ — the delivery framework: Publisher / Broker / Device protocols, hybrid encryption, Ed25519 signatures and X25519 encapsulation, ChaCha20-Poly1305 AEAD, and a software-simulated PUF with a fuzzy extractor for device binding. See delivery/README.md.
• performance/ — benchmarks (CoreMark, EMBench-IoT, and self-written micro-benchmarks) and overhead measurement.
• experiments/ — the attack harness and evaluation results (security battery and overhead).

Quick start

make build      # build the runtime demo, delivery payload, and device firmware
make test       # Python unit tests + device-side C host KAT/interop tests
make demo       # end-to-end delivery demo (publish → deliver → accept → execute)
make negative   # demo + 5 negative cases (all expected to REJECT)
make perf       # self-written benchmarks (N=3 wall-clock ratio)
make clean

Dependencies

• LLVM/Clang 18, LLD, CMake, Ninja
• QEMU (qemu-system-arm, for the lm3s6965evb Cortex-M3 target)
• Python 3 (standard library only)

On Ubuntu 24.04:

sudo apt install -y clang llvm llvm-dev lld cmake ninja-build qemu-system-arm

Target & toolchain

• Target: bare-metal ARM Cortex-M3 (lm3s6965evb, 64 KB SRAM / 256 KB Flash), emulated with QEMU.
• Instrumentation: LLVM 18 optimizer-last pass (runtime/pass/BridgePass.cpp).
• Broker & generators: Python 3; device firmware & runtime: C.

Threat model (summary)

In scope: network attackers, local attackers, and runtime attackers (code injection, instruction tampering, and control-flow hijacking). Out of scope: invasive hardware cloning, side-channel and microarchitectural attacks, and long-term key compromise. See the sub-READMEs and the accompanying manuscript for details.

Reference

BRIDGE is described in the accompanying manuscript "BRIDGE: Brokered Runtime-Integrated Distribution for Guarded Execution in IoT" (in preparation).