Verifiable sensing · OP-TEE remote attestation

A sensor that proves what it isn't doing.

An open-source audio guardian. The detector runs inside a secure enclave, the raw sound is discarded there, and the only thing that leaves is a tiny signed verdict — alarm, voice, or nothing. You don't trust it. You check it.

Veraison: affirming on QEMU e2e: 13/13 reproducible host build

The idea

Stop trusting the microphone. Start checking it.

Privacy today is a promise. open-opticon turns it into something you can verify.

Every other always-on mic

"We don't record you."

A sentence in a policy document. You can't inspect the firmware, you can't tell what an update changed, and nothing technically stops it from listening. You're asked to trust.

open-opticon

"Here's the proof."

Every result comes with a cryptographic proof that the genuine, published code ran inside a secure enclave and emitted only a minimal verdict for a fresh challenge — with the raw audio destroyed in the enclave. Anyone can check it. No trust required.

Walkthrough

The whole pipeline, end to end

Every frame is real captured output: the host test suite, an OP-TEE attestation on Arm TrustZone (QEMU), the in-enclave bound output, and the tamper fail-closed path.

Rendered from the captured stdout of the real runs — no screen recorder. walkthrough.cast replays in asciinema.

How it works

One chain, three independent links

Each link is checked separately. Break any one and the verdict turns red.

01 — attest

Prove the firmware

The enclave emits a PSA attestation token. Veraison confirms the running code is the exact published firmware.

Catches: a tampered or unpublished build.
02 — bind

Bind the verdict

That same attested key signs a minimal CBOR predicate, bound to a verifier-chosen nonce and a counter that must advance.

Catches: a replayed or pre-recorded "all clear".
03 — verify

Verify the output

Anyone checks the signature, the firmware identity, the freshness, and the anti-replay counter — with no audio and no trust.

Catches: a forged, stale, or cloned bundle.

Evidence

Real receipts, from a real run

Verbatim output from an OP-TEE run on QEMU (Arm TrustZone) and the host verifier — not mockups.

veraison · firmware attestation
$ optee_remote_attestation
# PSA/COSE token  →  Veraison verifier

ear.status                : affirming
ear.trustworthiness-vector:
  executables       : 2   genuine published firmware
  instance-identity : 2   correct attestation key
  hardware          : 2
  runtime-opaque    : 2
  storage-opaque    : 2
measurement-value : HqLzzpodsF4k9oSVJ3/u22Xb…
signer-id         : rLsRx+TaIXIFUjzkzhokWuGi…
he_host · bound output, signed in the enclave
# raw PCM never leaves the TA; only this leaves
$ he_host /usr/bin/clip.pcm $NONCE
{
  "schema": "honest-ear/bound-output/v1",
  "payload": "a900010158 20…ab73f9d0",
  "sig":     "a4a30c413f…7fe799af",
  "pub_x":   "30a0424cd2…0aafec3e",
  "pub_y":   "e04b65e924…ce081723"
}
# pub_x/pub_y == the key Veraison attested
he-verify · accepts the genuine proof, rejects everything else
$ he-verify --nonce $NONCE bundle.json
PASS  bound output verified (signature + freshness + anti-replay)
      event: alarm_tone   presence: 1   voice_active: false   frames: 62 (~992 ms)

$ he-verify --nonce DEADBEEF… bundle.json                       # stale nonce
FAIL  nonce mismatch (stale/replayed evidence)

$ he-verify --nonce $NONCE --pin-x <x> --pin-y <y> bundle.json   # cloned to another box
FAIL  public key does not match pinned endorsement

$ he-verify --nonce $NONCE --last-counter 1 bundle.json          # replay
FAIL  counter 1 not greater than last seen 1

Full appraisal + reproduction steps: SAMPLE_ATTESTATION.md · RUNBOOK.md

Honest scope

What it proves — and what it doesn't

The whole point is honesty, so here is exactly where the guarantee starts and stops.

Proves today
  • The genuine, published firmware is what ran (attested measurement).
  • The raw audio was processed and zeroized in the enclave — there is no export path.
  • The output is bound to a fresh challenge and a counter that must advance.
  • Opening the enclosure makes the device refuse to attest (fail-closed).
Does not claim
  • A hardened detector — today it's a threshold/VAD stub, not an audited model.
  • Nation-state side-channel resistance against a physical attacker.
  • Device identity on the QEMU build (shared test key) — that needs the i.MX CAAM key.
  • Safety from a broken TEE vendor — the k-of-n quorum verifier and a real independent ZK prover leg already ship; wiring genuinely heterogeneous silicon (a second-vendor TEE, a TPM quote) into the live quorum is the roadmap item.
The guarantee is about the machinery, not the microphone: the same attestation, binding, and verifier already drive a vision occupancy detector that emits only empty / occupied + a region count — never the frame — verified by the identical he-verify (make vision-e2e). A camera that proves it can't see you, from the same primitive.

Full analysis: THREAT_MODEL.md

Hardness tiers

Same verifier, three levels of guarantee

Higher tiers add hardware. Items marked proven today ran on a laptop, no special hardware.

Tier 1 — genuine code proven

  • OP-TEE on Arm TrustZone (QEMU); Veraison affirming
  • In-enclave Goertzel detector; audio zeroized in the TA
  • Output signed by the attested key; verify PASS, tamper FAIL

Tier 2 — device identity needs i.MX CAAM

  • proven verifier-side pinning: wrong key → FAIL, genuine → PASS
  • he_host --key-hex path wired end-to-end
  • Hardware adds only non-extractability (CAAM black key)

Tier 3 — tamper case fail-closed proven

  • GPIO loop: breach → key erased + TA flag latched
  • In QEMU: after --trip, attestation returns TEE_ERROR_SECURITY
  • Production: route the loop into the secure element / CAAM

Building it on a real board (BOM, wiring, bring-up, and why a phone is the verifier — not the sensor): HARDWARE.md

Design

Why a TEE, and not ZK or FHE

For a real-time sensor that captures the physical world, a TEE is the only approach that is fast, cheap, and end-to-end today — and it composes with the others later.

ApproachReal-time on a $5–60 boardHides raw audioProves which code ran
TEE + attestationYes, integer detector in-enclaveYes, zeroized in the TAYes — that is what attestation proveschosen
ZK proof of the detectorBatch only (~min / clip)YesYes, of the computationshipped · 2nd leg
FHENo, too slow to streamYesNo, not by itselfnot viable now
A TEE is a hardware trust assumption, not a math proof. So it doesn't stand alone: reproducible builds let anyone recompute the measurement, a 2-of-3 multi-prover means no single TEE vendor is load-bearing, and a real ZK proof of the detector now ships as an independent batch/audit leg (no enclave trusted for the math — see zk/) — and that ZK receipt can be checked permissionlessly on an EVM — including a heterogeneous both-required check (a 2-of-2) that returns a verdict only if the ZK proof and the device's P-256 signature both verify and agree (real proof + device bundle, local-EVM tests green, and deployed live on Sepolia), see onchain/. See WHY_TEE.md and ROADMAP.md.

Architecture

Two worlds, one signed verdict

The secure world never hands the normal world anything but a signed verdict.

architecture
  mic ─▶ ┌────────────── SECURE WORLD (OP-TEE) ───────────────┐
           Honest Ear TA                                    
            • integer Goertzel + VAD over the PCM           
            • audio buffer zeroized — never stored/exported  
            • emit predicate {event, presence, counter}     
            • PTA_SIGN_DATA → ECDSA P-256 over CBOR payload  
         └───────────────────────┬────────────────────────────┘
                                 │ signed bundle only
       ┌─────── NORMAL WORLD ───────┐          ┌──────────────┐
        he_host (CA) → JSON bundle   ───────▶  he-verify /   
        optee_remote_attestation     ──token▶  Veraison +    
       └────────────────────────────┘           nonce/counter 
                                                └──────────────┘

Deep dive: ARCHITECTURE.md · USE_CASES.md

Don't trust this page

Verify it yourself

Everything above is a claim. Here is how to check it on your own machine — the host pipeline needs only gcc, go, openssl, and python3, and runs offline.

check it
$ git clone https://github.com/NubsCarson/open-opticon && cd open-opticon
$ make test     # C + Go units, e2e (13/13), tamper self-test — offline
  ALL HOST TESTS PASSED
$ make repro    # build twice in two trees, assert byte-identical artifacts
  REPRODUCIBLE  all host artifacts are byte-identical
$ make cross    # cross-compile the verifier for Raspberry Pi (arm64 / armv7)
$ make sites    # launch the interactive apps + print their URLs

The interactive apps are dynamic servers (they need the Go backend, so they run locally rather than on this static site). make sites starts all three and prints the links:

localhost:8095

Click-to-listen

Tap the mic; it shows the verified verdict and lets you try to forge it in the browser.

localhost:8090

Verification server

Mint a fresh challenge, then sign it on the device and watch it verify.

localhost:8090/v

Phone verifier

Scan the QR; the phone shows the live PASS/FAIL verdict for that challenge.

The OP-TEE/QEMU attestation (Docker, ~40 GB) is the full reference in RUNBOOK.md; reproducibility details in REPRODUCIBLE.md.

FAQ

The obvious questions

Is the raw audio really gone?
Yes — the detector runs in the enclave and zeroizes the PCM buffer before returning. The published firmware has no code path that exports samples, and the attestation proves that this is the firmware running. You're not trusting that claim; you're verifying the code's measurement.
What if the TEE itself is broken?
A TEE is a hardware trust assumption, not a proof — a broken vendor enclave is a single point of failure. The mitigations: the output is deliberately tiny (a break leaks a number, not a recording), the build is reproducible, and the quorum verifier and one real independent leg (a ZK proof) already ship; enrolling genuinely different silicon (a second-vendor TEE + a TPM quote) into the live quorum is the remaining roadmap work, so no single enclave is load-bearing.
Is this production-ready?
No. It's a working proof-of-concept. The host pipeline and the cryptographic binding are fully tested and the OP-TEE path runs green on QEMU, but the detector is a threshold stub, device identity needs i.MX CAAM hardware, and the tamper response is best-effort software. The scope section above is the honest line.
Does it run on a Raspberry Pi?
That's the target. The detector and host code are integer-only C that builds natively on Raspberry Pi OS, OP-TEE attestation is a Tier-1 target for the Pi 3B+ (everything proven so far is on QEMU — no board has run yet; see HARDWARE.md), and the Go verifier cross-compiles to arm64/armv7 with make cross.
What's "honest-ear" vs "open-opticon"?
Same project. open-opticon is the public name; honest-ear is the internal codename, which is why it appears in the schema string, the Go module, and the on-device paths.
How is this different from C2PA / signed cameras?
C2PA signs the raw content a device keeps. open-opticon proves what it discarded: it attests the transformation inside the enclave and emits only the minimal, non-reconstructable result — provenance of restraint, not of content.

Use cases

Where provable restraint matters

safety

Gunshot / alarm detection

Deploy "tell me if an alarm or a gunshot fires" and prove the device cannot become a listening device.

eldercare

Fall & distress audio

"Call for help on a cry or a thud" with a cryptographic guarantee the feed is not recorded.

civic

Consent-grade monitoring

Public spaces, rentals, workplaces: restraint anyone can audit, not promised in a policy PDF.