ENF Protocol · Technical Document · Specification Amendment · Draft
Reusing shipping C2PA capture-side trust roots to harden Layer 2 against pre-correlation frame substitution — and an explicit account of the attack it does not close.
Amendment target
This document amends Prototype Node Architecture Specification v0.1. It does not replace it. Apply against:
TPM-class hardware attestation from deferred to partially specified, for the camera channel only.The v0.1 spec treats the camera witness (§5) as a passive sensor: a commodity camera captures luminance, software extracts the ENF component, and the correlation engine (§3) compares it against the electrical sensor. The security of cross-modal correlation rests on the assumption that the two channels are independent and both reflect physical reality at capture time.
That assumption has a gap the original spec does not address directly. On a general-purpose node, every frame travels sensor → ISP → kernel driver → userspace → correlation engine. Any layer in that path with sufficient privilege can substitute a forged frame before the correlation engine ever sees it. An adversary who controls the node software does not need to defeat the cross-correlation — they can feed both channels matching forged signals and the correlation will pass cleanly.
§12 acknowledges this obliquely by deferring "off-grid adversary hardening" to follow-on work "requiring hardware attestation (TPM-class)." This amendment specifies that hardening for the camera channel, using attestation hardware that already ships in consumer and professional cameras as of 2025–2026 — the C2PA / Content Credentials capture-signing stack.
A correct mental model of the threat requires distinguishing two boundaries that are often conflated:
| Attestation type | What it proves | Where it sits |
|---|---|---|
| Host TPM (PC-class) Win11 fTPM/PTT, Linux /dev/tpm0 | The host's boot/software state; that a known key signed this | Beside the CPU. Frames already passed through OS, drivers, userspace before signing. |
| Capture-side secure element C2PA camera signing chip | That light hit a physical sensor and produced this specific file, before software touched it | In the sensor/ISP path. Signs the manifest at the moment of capture. |
Critical clarification
A host TPM — including the ubiquitous Windows 11 fTPM and the Linux-accessible TPM 2.0 — attests the wrong boundary for this purpose. It will faithfully sign a forged frame handed to it by compromised software, because it has no independent view of what the sensor saw. The §12 reference to "TPM-class hardware attestation" should not be read as "the node's PC TPM is sufficient." It is not. The attestation must originate forward of the host OS, in the capture device itself.
The host TPM remains useful, but for a different job: as the node's device-identity key store and measured-boot anchor (the Ed25519 node keypair in §7, the regional-cluster identity in §8). On Linux this is the stronger substrate — tpm2-tss for non-migratable signing keys, IMA + measured boot to attest the capture daemon binary. That hardens node identity, not frame provenance. Both are needed; they are not interchangeable.
Rather than designing and fabricating a bespoke sensor-side secure element (the hardest and slowest part of off-grid hardening), this amendment reuses the trust root already present in C2PA-signing cameras. The ENF camera-witness output (§5) is carried as a custom assertion inside the camera's existing C2PA manifest, bound into the same secure-element signature the hardware already produces at capture.
// Extends the §5 camera ENF time-series. The luminance-derived // ENF window is embedded as a C2PA assertion and signed by the // camera's capture-side secure element — not by node software. { "c2pa_manifest": { "claim_generator": "<camera model + firmware>", "assertions": [ { "label": "c2pa.actions", "data": { "action": "c2pa.created" } }, { "label": "org.felineunion.enf.witness.v1", "data": { "grid_region": "WECC-CA", "window_start_unix_ms": 1748000000000, "window_seconds": 60, "camera_enf_samples": [ /* freq_hz per frame */ ], "camera_window_hash": "sha256 of samples", // REQUIRED — see A1.4 / ENF-X-02 "chain_binding_prev_hash": "sha256 of previous committed block" } } ], "signature": "capture-side secure-element signature over manifest", "cert_chain": "chains to camera vendor CA (C2PA trust list)" } }
The correlation engine (§3) then takes the camera channel from inside the verified C2PA manifest rather than from a raw userspace frame buffer. Verification adds two steps before correlation: (1) validate the C2PA signature and certificate chain against the trust list; (2) confirm chain_binding_prev_hash matches the node's view of the current chain tip.
What this buys, precisely
An adversary can no longer substitute a forged camera frame at the node software layer, because the camera channel arrives pre-signed by a secure element the node software cannot impersonate. To forge the camera witness, the attacker must now defeat the camera's capture-side signing — a materially harder target than injecting frames into a Linux frame buffer. This is a real increase in the cost of one of the two cross-modal channels.
The single most important section of this amendment. The strong, un-inflated claims:
| Node-software frame substitution | Camera channel is signed forward of the host OS. Compromised node software can no longer swap the camera witness undetected. |
| Camera-channel device provenance | The manifest cryptographically asserts a specific physical camera produced this luminance series. |
| Replay (ENF-X-02) | C2PA does nothing for replay. The camera's own timestamp is self-attested by a clock the adversary may control, and a genuine (signal, frame) pair can still be lifted from public grid logs and re-presented. Replay is prevented only by chain_binding_prev_hash — the same ledger-state binding ENF-X-02 already demands. C2PA is not a substitute for it. |
| Electrical channel (Layer 1) | There is no shipping consumer secure-element product for mains-frequency capture. This amendment hardens the camera witness only. The electrical sensor remains as trustworthy as the node software running it. Cross-modal correlation now rests on one hardware-attested channel and one software-trust channel — an asymmetric, not symmetric, improvement. |
| Absence of signal | A node in a DC-LED environment (already excluded in §5) produces no camera ENF, and therefore no C2PA witness. Absence of a manifest is not evidence of forgery — it is absence of capability. The protocol must not treat unsigned capture as inherently suspect. |
| Manifest stripping downstream | C2PA manifests are routinely stripped by platforms on transcode/upload. This is irrelevant inside the node (the manifest is consumed at correlation, not transported), but it means this mechanism gives no provenance guarantee for any media that leaves the node. |
| Trust-root compromise | The chain is only as strong as the camera vendor's signing infrastructure. Precedent: a major vendor's C2PA certificate was revoked in September 2025 after a signing-infrastructure vulnerability. A compromised or revoked vendor CA invalidates every node depending on that hardware. |
Net honest framing
This amendment converts the camera witness from a fully software-trusted channel into a hardware-attested one, at near-zero fabrication cost, by reusing shipping hardware. It does not make the node tamper-proof, does not resolve replay, and does not harden the electrical channel. It is a genuine improvement to one of three legs of the "defeat all three at once" claim on the index page — not a closure of the off-grid adversary problem.
Devices performing capture-time C2PA signing in a secure element, suitable as Layer 2 witness hardware. Selection criteria for testnet: high frame rate (§5 requires ≥120 fps for 60 Hz Nyquist), and a documented custom-assertion path.
| Device | Type | Note for ENF use |
|---|---|---|
| Sony PXW-Z300 | Camcorder | First camcorder with native C2PA video signing (IBC 2025). Video-native makes it the strongest fit for a continuous luminance witness; verify frame-rate ceiling against §5. |
| Sony α1 II / α9 III | Mirrorless | Capture-time C2PA; high-speed modes. Stills-oriented — burst/video frame rate must be checked against the 120 fps floor. |
| Leica M11-P / SL3-S | Mirrorless | First-mover hardware (M11-P, 2023). Note the plain SL3 lacks the signing chip — confirms the requirement is silicon, not firmware. |
| Nikon Z6 III | Mirrorless | C2PA via late-2025 firmware. Caution: Nikon's signing cert was revoked Sept 2025 — track CA status before relying on it. |
| Google Pixel 10 | Smartphone | Native C2PA at Assurance Level 2; video credentials rolling to Pixel 8/9/10. Cheapest attested-capture path; integrated for a single-box node. |
Frame-rate caveat
Most C2PA cameras sign at standard photo/video rates, not at the 120–240 fps §5 requires for clean 60 Hz extraction. Whether a vendor's high-speed mode also emits a signed manifest per window is an open verification item per device — flagged below as ENF-C2PA-02. The Pixel/Sony video paths are the most likely to satisfy both constraints; confirm empirically, do not assume.
Added to the §10 critical-path register. Each is a testnet measurement or verification target, consistent with the v0.1 convention.
ENF-C2PA-01 · revises ENF-X-02
Does embedding chain_binding_prev_hash inside the signed C2PA assertion actually prevent replay, given that the camera signs the assertion but the prev-hash is supplied by node software? If node software injects a stale prev-hash, does verification still catch it at the BFT layer? Specify the exact point at which chain-binding is validated.
ENF-C2PA-02
For each candidate device: does the high-frame-rate mode required by §5 (≥120 fps) also produce a per-window C2PA-signed manifest, or does signing only occur at standard capture rates? Per-device empirical check. If signing and high-frame-rate are mutually exclusive on a device, that device cannot serve as an attested witness.
ENF-C2PA-03
Latency: does C2PA verification (signature + cert-chain + trust-list lookup) per window fit inside the BFT round time alongside the §3 correlation cost (ENF-X-03)? Measure combined latency on testnet hardware.
ENF-C2PA-04
Trust-list governance: which vendor CAs does the federation accept, and what is the node's behaviour when a CA is revoked mid-operation (cf. Nikon Sept 2025)? Define the revocation-handling rule before any production reliance.
ENF-C2PA-05
Custom-assertion support: which candidate devices permit a third-party custom assertion (org.felineunion.enf.witness.v1) inside the manifest at capture, versus only fixed vendor assertions? If no device permits custom assertions at capture, the fallback is signing the raw luminance frames and computing the ENF assertion post-hoc against the verified frame hash — which weakens the guarantee. Determine which path each device forces.
This amendment is optional for the 7-node testnet and should not block the §11 critical-path measurements. The base testnet still uses the Raspberry Pi Camera Module 3 (unattested) to answer ENF-C-01/02/03 and the correlation unknowns — those measurements do not require attestation hardware.
Recommended sequencing: run the base testnet first to validate that cross-modal ENF correlation works at all on commodity hardware. Only once ENF-C-01 through ENF-X-03 return usable data does the attested-camera path become worth the added cost and integration. Introduce one or two attested nodes (e.g. a Pixel 10 or Sony video body) into the existing 7-node testnet as an A/B comparison against the Pi-camera nodes, measuring ENF-C2PA-02/03/05 without rebuilding the cluster.
Added testnet cost
One attested witness device, ~$800–$2,500 depending on body, added to two nodes for comparison. This is the only line item in the testnet that meaningfully exceeds the ~$167/node commodity budget — which is itself the argument for deferring it until the base correlation question is answered. Do not buy attestation hardware before ENF-C-01 confirms the camera channel produces usable signal at all.
Spec Amendment A1 · amends Prototype Node Architecture Specification v0.1 · pre-prototype · not peer reviewed.
All device facts current to June 2026 and subject to firmware/CA change — re-verify before reliance.
C2PA hardens the camera witness only; replay (ENF-X-02) and the electrical channel remain open.
Prepared by flipkoin · GoComputerHelp · Regina, Saskatchewan · Treaty 4 territory — oskana kâ-asastêki · June 2026.