Provenance-Signed Fusion: A Cryptographic Identity and Transparency Profile for SAPIENT-Class Multi-Sensor Counter-UAS Detection

1. Motivation and threat context

Counter-UAS (C-UAS) detection has become a multi-sensor problem. Pure-RF systems miss radio-silent threats (Shahed-class INS-only terminal mode, fiber-optic-tethered FPV). Pure-acoustic systems are wind-limited at 60 to 250 m. Pure-EO/IR systems require cueing. The published literature on fusion (Dabbabi and Delleji’s GNN-tracker 2025; Frid et al. RF-plus-acoustic DNN fusion 2024; multi-modal RGB+acoustic detectors such as WAVE-DETR 2025) consistently reports 20 to 50 percent false-positive reduction over the best single modality, and the operational consensus across NATO STO MSG-SET-183 doctrine is that defense-in-depth requires fused detection.

Fusion solves a detection problem and creates a trust problem. A fused detection is a function over inputs that the operator cannot independently verify. The operator sees a track ID and a confidence score on a display. They do not see which sensor contributed which evidence, whether that sensor was healthy at the time of measurement, whether the model that produced the classification is the version that was certified, or whether any input has been replayed from an earlier capture. The SAPIENT open architecture (Dstl SAPIENT ICD v7, BSI Flex 335) defines a Protobuf message bus that allows multi-vendor sensors to interoperate at the data-exchange layer, and is the C-UAS open-architecture target NATO is rolling toward. SAPIENT does not, by design, specify cryptographic identity, signed measurements, or a transparency-log audit story. PSF is a profile that closes that gap.

Four adversaries motivate this work, and we extend the threat model in Section 2 to cover key-extraction and log-availability attacks that the v0.1 of this paper omitted.

Adversary A (corrupted sensor). An insider, a supply-chain implant, or a firmware downgrade attack causes a sensor to emit fabricated detections. Existing systems have no mechanism to detect that the sensor producing a detection is the same physical sensor that was certified at install time, running the firmware that was approved.

Adversary B (input manipulation). RF spoofing of OcuSync framing, acoustic injection of synthesized rotor signatures through nearby loudspeakers, and adversarial-image perturbations against EO/IR classifiers are all in the published literature. PSF’s cross-sensor sanity-check predicates are a detection-of-disagreement mechanism, not a defence against an adversary capable of spoofing two correlated modalities simultaneously; we are explicit about this limit in Section 7.

Adversary C (fusion-output manipulation). Cloud-coupled architectures concentrate trust in a server that the operator on the perimeter does not control. PSF’s edge-only fusion attestation prevents server-side rewrite or alert-suppression after the fact.

Adversary D (replay). An attacker captures a signed detection from a prior flight test and replays it during an actual incursion. PSF binds detections to a fresh nonce, a monotonic counter, and a per-sensor hash chain; we discuss the secure-element rollback variant of this attack (ROTE, Matetic et al., USENIX Security 2017) in Section 7.

Adversary E (key extraction from secure element). Power-analysis, EM-side-channel, and fault-injection literature against TPM 2.0, ARM TrustZone, and the ATECC608B class of secure elements is mature. PSF requires per-device revocation infrastructure under the manufacturing CA; we treat this as an operational requirement in Section 6 rather than as a fully-solved problem in v1.0.

Adversary F (transparency-log denial-of-service). PSF’s detection-of-fabrication property depends on the customer-local log being live, witnessable, and consistent. An attacker who can crash, partition, or fork-equivocate the log degrades that property without forging any signature. Section 3.4 specifies a witness/gossip discipline borrowed from Sigstore Rekor.

2. Existing trust mechanisms and the gap PSF closes

Several mature primitives address pieces of this problem. None has been integrated as a security profile for SAPIENT-class C-UAS sensor fusion in the published open literature.

SAPIENT (Dstl ICD v7, BSI Flex 335). The closest open architecture in the C-UAS space. Specifies a Protobuf message bus for multi-sensor data exchange across heterogeneous vendor stacks, with NATO STANAG track. SAPIENT does not specify cryptographic identity for sensors, signed measurements, model-version pinning, or transparency-log audit. PSF is a security profile on top of SAPIENT: SAPIENT messages remain the data-plane; PSF wraps the data-plane in a verifiable trust chain. A SAPIENT-only deployment has interoperability; a SAPIENT-plus-PSF deployment has interoperability and per-sensor cryptographic accountability.

C2PA hardware-signed camera credentials. The closest existing artifact in the cryptographic-provenance-of-sensor-data space. The Coalition for Content Provenance and Authenticity specification combined with hardware-rooted PKI is now shipping in production cameras (Canon EOS R1, EOS R5 Mark II) and in third-party hardware credentials (Lucid Truth Technologies). C2PA produces signed manifests at media-asset capture time, with a Trusted Service Authority chain and per-device key attestation. PSF differs in three ways: (a) PSF signs streaming sensor measurements at hundreds of events per second, not discrete media artifacts; (b) PSF aggregates signatures across a fusion of multiple heterogeneous sensors, not per-asset; (c) PSF binds detections to a customer-local transparency log rather than to a centralized provenance service. The joint NSA, FBI, and CISA Content Credentials advisory (January 2025) endorsed C2PA for government and critical-infrastructure media; PSF extends the same posture to multi-sensor C-UAS.

Hardware attestation: TPM 2.0, ARM TrustZone, Apple Secure Enclave, ATECC608B. TPM 2.0 provides a hardware root of trust, attestation key, and PCR-based measured-boot quotes. ARM TrustZone provides a Secure World partition for key storage and signing. The ATECC608B (Microchip) implements P-256 ECDSA and key storage but not Ed25519. Fu and Peng’s TPM-based remote attestation paper for wireless sensor networks (Tsinghua Science and Technology 2016) demonstrated the model in an IoT context; the 5GDrones modular attestation framework (Ould Imam, Lacoste, Arfaoui, IEEE WiMob 2021) addressed UAV onboard subsystems; neither addresses ground-based C-UAS detection sensors.

Sigstore / Rekor. Rekor is an immutable append-only transparency log built for software supply chain artifacts. It provides Merkle-tree-based inclusion and consistency proofs, an open API, and an established witness-protocol pattern that PSF adopts directly. Rekor is built for code signing; the data model maps cleanly onto sensor events with minor schema extension.

DICE (Device Identity Composition Engine). DICE (Trusted Computing Group) layers identity from a Unique Device Secret through firmware stages, producing a Compound Device Identifier per firmware version. DICE is suited to mid-tier sensors that lack a full TPM. It has not been applied in published work to C-UAS sensors.

Hash-chained audit logs. Schneier and Kelsey, “Secure Audit Logs to Support Computer Forensics” (1999), is the canonical hash-chained log construction. ROTE (Matetic et al., USENIX Security 2017) specifically addresses rollback protection for trusted-execution-environment streaming and is directly on point for the secure-element variant of Adversary D. SCADA replay-defence literature (Wiley 2021 and predecessors) covers the same pattern in industrial-control sensor networks. PSF’s per-sensor hash chain plus on-demand challenge-response is a deployment integration of these primitives, not a primitive contribution.

Lagrange DeepProve on Anduril Lattice (announced November 2025). zkSNARK proofs of model inference, integrated into the Lattice SDK. Addresses Adversary C at the model-inference layer. Closed, US-prime, cloud-coupled, complementary to PSF rather than competing.

Adjacent vertical patterns: smart-grid PMU authentication (NIST IR 7628 lineage), AUTOSAR SHE/HSM signed-sensor patterns in automotive, FDA cybersecurity guidance for signed medical-device telemetry. Each addresses cryptographic accountability for measured-data streams in a different vertical. PSF imports the principles into C-UAS sensor fusion with the SAPIENT-as-data-plane assumption.

The honest gap PSF closes: no security profile has been published that combines (a) SAPIENT-compatible message-bus integration, (b) per-sensor hardware-rooted identity across cheap and capable sensor tiers, (c) hash-chained per-sensor history with on-demand challenge-response audit, and (d) a customer-local append-only transparency log with witness-protocol consistency, deployable in civilian critical-infrastructure environments without raw-data egress. This is the contribution.

2.5 Prior-art search methodology and limitations

We document the scope and limits of the prior-art search behind every “to our knowledge” claim in this paper. Reviewers at IEEE S&P, USENIX Security, or NATO STO IST typically reject unqualified “first” claims that do not document a systematic literature search.

Scope of the literature review. We surveyed: SAPIENT (Dstl ICD v7, BSI Flex 335) and the NATO STANAG track; C2PA specifications (1.0 through 2.2) and C2PA hardware-credential implementations (Lucid Truth Technologies, Canon EOS R1/R5 Mark II, 2025-2026); the joint NSA/FBI/CISA “Content Credentials” advisory (January 2025); TPM 2.0 attestation flows including PCR-based measured boot; the ATECC608B and OPTIGA Trust M secure-element families; TCG DICE specification; Sigstore/Rekor transparency-log substrate (research dataset October 2025); ROTE (Matetic et al., USENIX Security 2017) for rollback-protected attested streaming; Schneier and Kelsey’s hash-chained audit log (1999); Lagrange Labs DeepProve as integrated into the Anduril Lattice SDK (November 2025); NATO STO MP-MSG-SET-183 paper 11 on passive sensor processing and data fusion; Atlas (Spoczynski, Melara, Szyller, Intel Labs, arXiv:2502.19567 2025) on ML lifecycle provenance; Fu and Peng’s TPM-based remote attestation for wireless sensor networks (Tsinghua Science and Technology 2016); the 5GDrones modular attestation framework (Ould Imam, Lacoste, Arfaoui, IEEE WiMob 2021); SCADA replay-defence literature (Wiley 2021); NIST IR 7628 smart-grid security architecture; AUTOSAR SHE/HSM patterns for automotive sensor authentication; FDA medical-device cybersecurity guidance; and the published C-UAS fusion literature cited in Section 1.

Limitations of the search. We did not conduct a systematic IEEE Xplore, ACM Digital Library, or USENIX search across every relevant query string combination. We did not survey defence-industry grey literature (proceedings of NATO STO restricted-distribution panels, MITRE technical reports behind paywalls, classified or controlled-distribution program documentation). We did not contact incumbent vendors (Anduril, Dedrone, DroneShield, Squarehead) to ask whether internal architectures address the same problem. We did not conduct a systematic patent search across USPTO, EPO, or WIPO databases for filed-but-unpublished work; we recommend a USPTO Patent Public Search before any formal venue submission.

Implications for the novelty claim. This is a position paper proposing an integration. It is not a peer-reviewed exhaustion of the prior art. The “to our knowledge” claim is conditional on the survey above. Reviewers, follow-on work, or a journal submission requiring a systematic literature review may identify prior or concurrent work missed here. If such work exists, we expect it to share primitives (TPM, DICE, ECDSA, Ed25519, Merkle logs) with PSF; the integration as a security profile on top of SAPIENT for civilian-deployable C-UAS detection with cheap-sensor retrofit and edge-only execution is the specific framing proposed, and we welcome citations to predating or concurrent work.

3. Architecture: Provenance-Signed Fusion (PSF)

PSF has four layers: sensor identity, measurement signing, fusion attestation, and transparency log. Each layer is independently auditable. PSF is designed to wrap a SAPIENT data-plane: the SAPIENT message bus carries sensor and fusion data between components; PSF signs and witnesses each event.

3.1 Sensor identity binding

Every sensor (RTL-SDR v4 with added secure element, KrakenSDR, MEMS microphone array, FLIR Boson EO/IR module) is bound to a hardware-rooted identity at first boot. Three implementation tiers exist depending on sensor class. Each tier signs detection events using primitives appropriate to its hardware; the verifier supports both Ed25519 and P-256 ECDSA, and the SignedEvent schema’s signature_alg field declares which is in use.

Tier 1: Sensors with native TPM 2.0 or TrustZone (Ed25519 in software, hardware-attested keys). The Jetson Orin Nano fusion node and any sensor running on a SoC with a Secure Element generates an Endorsement Key (EK) at manufacture, derives an Attestation Key (AK), and produces an attestation quote signed over Platform Configuration Register (PCR) values. The actual SignedEvent signing uses Ed25519 with keys protected by the TPM or TrustZone; PCR-based measured-boot quotes attest the firmware that executed the signing.

Tier 2: Sensors with DICE-capable microcontrollers (Ed25519 in firmware). Mid-tier sensors carry a microcontroller with a Unique Device Secret (UDS) burned at manufacture. Following the TCG DICE specification, the boot ROM derives a Compound Device Identifier (CDI) from the UDS and the hash of the next-stage firmware. The CDI seeds the per-stage Ed25519 signing key. A firmware downgrade or unauthorised firmware load produces a different CDI and fails downstream verification.

Tier 3: Sensors with no native root of trust, retrofit via ATECC608B (P-256 ECDSA in hardware). A small adjacent secure element (ATECC608B at approximately USD 1, or OPTIGA Trust M at approximately USD 5) is added to the sensor housing on a custom interposer board. The ATECC608B implements P-256 ECDSA in hardware, not Ed25519; PSF accommodates this by allowing per-tier signature algorithms with the verifier supporting both curves. The secure element stores the P-256 private key, exposes only signing primitives, and is paired with the SDR by USB descriptor binding plus a one-time provisioning ceremony at deployment. The interposer adds approximately USD 10 BOM and 2 cm of board area. The interposer-to-host I2C channel is itself a potential attack surface; we discuss the mitigation in Section 7.

The result of Layer 1: every sensor has a public identity certificate signed by Symvek’s offline manufacturing CA, plus per-firmware CDI when DICE is in use, plus per-deployment provisioning records logged to the transparency log at install time. The certificate includes the algorithm identifier (Ed25519 or P-256 ECDSA) so that verifiers select the correct verification path automatically.

3.2 Measurement signing

Each sensor signs every detection event it produces. A detection event is a structured record encoded canonically as deterministic CBOR per RFC 8949 §4.2 (deterministic encoding rules) for unambiguous interoperability:

SignedEvent {
  schema_version: u16,
  sensor_id: bytes32,                   // hash of public identity cert
  signature_alg: enum {Ed25519, P256_ECDSA},
  firmware_cdi: bytes32,                // DICE CDI for current firmware (where applicable)
  model_id: bytes32,                    // hash of signed model artifact
  timestamp_ns: u64,                    // monotonic time since boot, plus PTP-disciplined wall clock
  monotonic_counter: u64,               // strictly increasing, replay-prevention
  feature_hash: bytes32,                // BLAKE3 unkeyed hash of canonical feature serialisation
  feature_serialisation_id: u16,        // identifier of the feature serialisation format
  detection_payload: bytes,             // structured payload (track ID, confidence, DoA, classification)
  detection_payload_schema_id: u16,     // identifier of the detection payload schema
  health_attestation: bytes,            // self-test results, temperature, antenna VSWR
  prev_event_hash: bytes32,             // hash chain to previous event from this sensor
  signature: bytes                      // Ed25519 (64 B) or P-256 ECDSA (~70 B DER)
}

Three design choices matter.

Feature hashes, not raw IQ. The signed payload includes a hash of the input features (the spectrogram window, the mel filterbank output, the YOLO bounding-box crop), not the raw waveform. This is the privacy primitive. The feature_serialisation_id field identifies the canonical byte serialisation that produced the hash, so two implementations of the same feature extractor produce identical hashes.

Hash-chained per-sensor history. Each event includes the hash of the previous event from the same sensor. An auditor querying a sensor for its last N seconds receives a continuous chain. Any gap, any out-of-order entry, or any silent drop is immediately detectable. Sensor genesis (first event after manufacturing or after a deliberate reset) uses a domain-separated zero value; reboot recovery is discussed in Section 7. This blocks Adversary D in the absence of secure-element rollback; ROTE-class rollback is discussed in Section 7.

Domain separation between event types. SignedEvent and ChallengeResponse use distinct Ed25519 contexts per RFC 8032 Ed25519ctx (or equivalent context-binding domain tags for P-256 ECDSA), so that a captured signature of one type cannot be replayed as the other.

Signing cost: Ed25519 on Cortex-M4 at 100 MHz is approximately 240,000 cycles per signature (Fujii and Aranha, “Curve25519 for the Cortex-M4 and Beyond,” LATINCRYPT 2017), which is approximately 2.4 ms; side-channel-hardened implementations (Bisheh-Niasar et al., IEEE TVLSI 2024) increase this to approximately 39.88 ms. Ed25519 on Jetson Orin Nano CPU using a modern optimised library (libsodium or BoringSSL) signs in approximately 50 microseconds. P-256 ECDSA on the ATECC608B is bounded by Microchip’s documented Sign command latency (typical approximately 50 ms, maximum approximately 200 ms per Microchip’s ATECC608B summary datasheet); measured-on-author-hardware figures will be reported in the Months-1-to-3 prototype deliverable. For dominant detection rates in C-UAS (1 to 10 Hz per sensor in steady state, bursting to 100 Hz under contact), Tiers 1 and 2 are unconstrained at the per-event signing rate; Tier 3 requires batching (sign one envelope over a window of events with the per-event hashes inside) when burst rates exceed approximately 10 Hz.

3.3 Fusion attestation

The Jetson Orin Nano fusion node consumes signed events from N sensors and produces a fused track. The fused track itself is a SignedEvent with two extensions:

Merkle proof of contributing inputs. The fusion event payload includes a Merkle root over the set of input SignedEvent hashes that contributed to this fusion result. An auditor presented with the fusion event plus N sensor SignedEvents can verify the Merkle inclusion of each contributing sensor input in roughly N hash operations.

Signed model version pin. The fusion model itself (the GNN tracker, the late-fusion classifier) is built reproducibly and the build artifact is signed offline by Symvek’s release CA. The build hash appears in the fusion event’s model_id field. A field operator can verify that the model that produced this fusion result is the model that was certified for this deployment, without trusting the running fusion node beyond its TPM quote.

Cross-sensor sanity-check predicates (clarified scope from v0.1). Cross-sensor consistency checking is table-stakes practice in fielded C-UAS fusion. PSF’s contribution at this layer is not the predicate logic itself but the operational guarantee that the predicate runs over signed inputs only: a sensor whose signature does not verify is excluded from the fusion attestation regardless of the predicate result. Predicates over signed inputs are a structural defence against an adversary capable of corrupting one sensor’s data path; they are not a defence against an adversary capable of consistent multi-modal spoofing, which we are explicit about in Section 7.

3.4 Append-only transparency log with witness discipline

Every signed event (sensor and fusion) is written to a customer-local append-only Merkle log running on the Jetson Orin Nano. The log uses Trillian or a Trillian-compatible implementation, the same data structure underlying Sigstore Rekor.

The log root is published every T seconds (configurable, default 60 s) to a tamper-evident publication channel: a customer-controlled S3 bucket with object-lock, a customer-internal blockchain or hashchain, or a public Rekor instance for non-sensitive deployments. A witness/gossip protocol modelled on Sigstore Rekor’s witness pattern is required to address Adversary F (log denial-of-service or fork-equivocation): independent witnesses periodically sign the published log root, and verifiers reject log states that are not co-signed by a quorum of witnesses. Customers requiring fully air-gapped operation publish to a write-once optical or paper trail; the witness discipline degrades gracefully to “next-online-witness verifies on reconnect.”

The log enables three operator workflows: audit replay (auditor verifies root continuity, signature continuity, and witness co-signing across an audit window), inclusion proof (operator produces a Merkle inclusion proof for a single suspicious detection at log position K), and consistency proof (verifier checks that the log at time T2 is an append-only extension of the log at time T1 < T2).

3.5 Cryptographic challenge-response

An operator or auditor can issue a fresh-nonce challenge to any sensor. The sensor’s secure element returns a signed ChallengeResponse including the nonce, the sensor identity, the firmware CDI, current health, the last N event hashes from the per-sensor chain, and the current witnessed log root. ChallengeResponse signatures use a distinct domain context from SignedEvent signatures so that captured ChallengeResponse signatures cannot be replayed as SignedEvents.

4. Privacy properties

PSF is privacy-preserving by construction.

No raw IQ leaves the box. The signed event carries only feature hashes and structured outputs. An attacker who compromises the published transparency log learns that a detection occurred with a given timestamp, bearing, and classification; they do not recover the underlying RF waveform, audio capture, or EO/IR frame.

Per-sensor DoA is exported; raw waveforms are not. The KrakenSDR and the MEMS array compute direction-of-arrival on board and emit only the angular estimate, the confidence, and the feature hash.

Differential-privacy aggregation across sites. For multi-site deployments, aggregate statistics are computed with Laplace noise added at the edge before publication. The local audit log retains exact events for the local operator; cross-site dashboards see noise-protected aggregates only.

Audit-log subpoena posture. A customer-local log of detection events with timestamps, sensor IDs, feature hashes, and classification metadata is a discoverable record under legal process. PSF supports two operational postures: (a) field-redacted retention, in which non-classification metadata (precise bearings, EO/IR crop hashes) is held in a separately-keyed envelope that requires court-authorised access to decrypt, with the bare detection record (timestamp, classification, sensor ID, feature hash) discoverable directly; and (b) full-record retention, with retention periods bounded by customer policy. The choice is operator-configurable. We are explicit that PSF, as an audit-record-producing architecture, is not the right tool for operators who require zero-record deployment; this is a brand-honest limit consistent with privacy-by-construction posture.

PIPEDA / GDPR posture. PSF lets a deployment attest that the sensor processed only feature hashes against a signed classifier, did not retain raw waveforms, and produced an auditable record of what was retained.

5. Novel contributions and reused primitives

We are explicit about what is new, what is reuse, and what is adjacent.

Reused primitives (no novelty claimed): Ed25519, P-256 ECDSA, TPM 2.0 attestation, TCG DICE, Trillian/Rekor append-only Merkle log structure, Schneier-Kelsey hash-chained audit log construction (1999), C2PA claim-and-assertion data model, BLAKE3 hash function, deterministic CBOR canonical encoding (RFC 8949 §4.2), Sigstore witness/gossip protocol pattern.

Novel contributions, scoped to C-UAS sensor fusion as a security profile on top of SAPIENT:

1. The integration as a SAPIENT security profile. Wrapping the SAPIENT data-plane in per-sensor cryptographic identity, signed measurements, fusion attestation via Merkle aggregation, and a customer-local append-only transparency log with witness discipline. The components are mature; their composition into a deployable C-UAS security profile compatible with the open architecture NATO is rolling toward is the contribution.

2. The cheap-sensor retrofit as a published deployable pattern for C-UAS. Documenting the ATECC608B-on-interposer pattern for RTL-SDR-class hardware, with explicit accommodation of the P-256-vs-Ed25519 algorithm split through a verifier that supports both. Secure-element retrofit is mature in adjacent IoT fields (LoRaWAN, automotive); its application to commodity SDR in C-UAS is, to our knowledge, not previously published as a documented deployment pattern.

3. The cross-tier algorithm split with uniform verifier. Allowing Tier 1 and Tier 2 to use Ed25519 (where the host can choose primitives) and Tier 3 to use P-256 ECDSA (where the secure element fixes the curve) without requiring the verifier to commit to one curve. The schema-level signature_alg field plus the multi-curve verifier is a minor but practical contribution to deployability.

4. Subpoena-aware dual-retention posture for the audit log. Field-redacted retention with court-authorised decryption versus full-record retention as an operator-configurable property. We are not aware of prior work that posits this property explicitly for C-UAS detection logs.

Adjacent and acknowledged:

• C2PA hardware-signed camera credentials (Lucid Truth Technologies, Canon EOS R1/R5 Mark II) provides per-asset cryptographic provenance for media; PSF extends the same posture to streaming multi-sensor fusion.
• Lagrange DeepProve on Anduril Lattice provides zkSNARK proofs of model inference inside a closed cloud architecture; PSF provides chain-of-custody from sensor housing to fused output in an open, edge-only architecture. The two are complementary; a future PSF version can include zkSNARK proofs of inference inside the fusion-event payload.
• ROTE (Matetic et al., USENIX Security 2017) addresses rollback protection for trusted-execution-environment streaming; PSF imports the principle for sensor-side monotonic counter rollback in Section 7.
• Fu and Peng’s TPM-based remote attestation in WSN (2016), the 5GDrones modular attestation framework (2021), NIST IR 7628 smart-grid PMU authentication, AUTOSAR SHE/HSM signed-sensor patterns, and FDA-guidance signed medical-device telemetry each cover sensor-identity layers in adjacent verticals; none address C-UAS sensor fusion as a SAPIENT-compatible profile.

6. Roadmap

The roadmap below describes PSF’s reference-implementation timeline from prototype through TRL-5 demonstration to public specification, in three phases.

Months 1 to 3 (prototype, two sensor types). AntSDR E200 plus an 8-channel MEMS array. Ed25519 signing on Jetson Orin Nano CPU. Trillian-based append-only log running locally on the Jetson, publishing root hashes to a customer S3 bucket every 60 s with a single witness. SignedEvent schema v1, deterministic-CBOR canonical encoding, hash-chain plumbing, challenge-response endpoint, multi-curve verifier (even if Tier 3 is not yet exercised). Test rig: two DJI drones (Mini 2, Mavic 3) plus three confounders. Deliverable: signed detection log over a 24-hour outdoor capture, externally replayable using a published Symvek auditor CLI, with measured-on-author-hardware signing-cost figures.

Months 4 to 6 (TPM-backed identity, multi-sensor fusion, witness discipline). Jetson Orin Nano TPM 2.0 module integration, PCR-based measured-boot quotes at sensor power-on. DICE-capable secondary microcontroller for the MEMS array with proper UDS provisioning. ATECC608B interposer prototype for an RTL-SDR v4, exercising the Tier 3 P-256 ECDSA path end-to-end through the multi-curve verifier. KrakenSDR added as third sensor with DoA fusion. Fusion-event Merkle proofs and signed model pinning. Three-witness gossip protocol active. Deliverable: TRL-5 demonstration report, security white paper, draft protocol specification.

Months 7 to 12 (open specification). Public specification document with licensing terms decided alongside the spec. Canonical publication at symvek.com/research; arXiv preprint optional for citation accessibility. External venue submission (IEEE Security & Privacy Workshop, USENIX, NATO STO IST sensor track) remains an open future option but is not a required deliverable. Outreach to NATO partner labs for coalition-interoperability test using SAPIENT plus PSF. Engagement with C2PA technical committee on streaming-sensor extensions to the C2PA claim model. Engagement with the SAPIENT working group on PSF as a candidate security profile.

7. Limitations and trade-offs

This section enumerates what PSF is not, the operational costs the architecture imposes, and the residual attack surface.

Compute overhead is real. Ed25519 signing per event on Jetson Orin Nano is small relative to detection-pipeline cost; sub-millisecond signing on a CNN-inference budget of tens of milliseconds is not the bottleneck. Tier 3 P-256 ECDSA signing on ATECC608B at typical 50 ms (maximum 200 ms per Microchip documentation) forces batching for high-burst scenarios on the cheapest tier. Side-channel-hardened Ed25519 on Cortex-M4 at approximately 39.88 ms per signature is the realistic bound for security-conscious Tier 2 deployments; the unhardened figure is closer to 2.4 ms but is not appropriate where physical access to the sensor cannot be excluded.

Hardware roots of trust must be retrofitted onto cheap sensors, with attendant attack surface. The interposer adds approximately USD 10 BOM. The interposer-to-host I2C bus is itself a potential attack channel; an adversary with physical access can in principle tap the bus, replay, or substitute responses. Mitigations are I2C-level authenticated commands where supported, host-side challenge-response that includes bus-state attestation, and tamper-evident enclosure for high-assurance deployments. We do not claim that the interposer pattern is secure against a fully-capable physical-access adversary.

This is a security profile, not a fundamental detection improvement. PSF makes detection records auditable; it does not make the underlying detector more accurate. If the spectrogram CNN misclassifies a Mavic 3 as an Autel EVO at 80 percent confidence, PSF signs the misclassification. The architecture provides a trust boundary around a deployed sensor stack, complementary to the detection science under separate development.

Operational complexity for the operator. An operator running PSF must maintain the audit log infrastructure, manage publication of root hashes, manage at least one witness or arrange for a third-party witness service, and respond to auditor queries. Sensible defaults and a reference auditor CLI mitigate the burden; the residual operational cost remains non-zero.

Manufacturing CA scale-out. The offline manufacturing CA is the trust root for all sensor identities. Compromise of the CA breaks the field. Operationally, a sub-CA structure with online intermediate CAs, hardware-security-module-backed signing, key rotation procedures, and a transparency log entry for every identity certificate ever issued is required; PSF v1.0 specifies the trust topology but the field-deployment runbook for CA scale-out is not in this paper.

Sensor decommissioning and housing reuse. A sensor retired without zeroing the secure element is a recoverable identity. PSF requires per-device revocation under the manufacturing CA when sensors are decommissioned; operationally, this is a process discipline that the customer must implement. The transparency log records every revocation as a first-class event so that a verifier with the up-to-date log can detect post-decommission impersonation attempts.

Key extraction from secure element (Adversary E). Power-analysis, EM-side-channel, and fault-injection attacks against TPM 2.0 and the ATECC608B class are mature threats. PSF requires per-device revocation and depends on the secure element’s published security target. It does not provide independent defence against successful key extraction beyond rapid revocation through the transparency log.

Transparency log denial-of-service and equivocation (Adversary F). PSF requires the witness/gossip discipline described in Section 3.4. A log without witnesses degrades to a single trust point; this is documented as a deployment constraint.

Monotonic counter rollback (ROTE-class attack on Adversary D). Hash-chained per-sensor history is replay-safe in steady state. ROTE (Matetic et al., USENIX Security 2017) shows that secure-element monotonic counters can be rolled back through cold-reset, glitch, or sleep-recovery attacks. PSF imports the ROTE mitigation pattern: the verifier holds out-of-band anchor hashes from the transparency log, so that a rolled-back chain that does not connect to a previously-witnessed anchor is detected. This is documented as a verifier requirement, not solved by sensor-side primitives alone.

Adversary B (input manipulation) defence is detection of disagreement. Cross-sensor sanity-check predicates over signed inputs detect inconsistency between modalities; they are not a defence against an adversary capable of consistent multi-modal spoofing (e.g., RF spoof correlated with acoustic injection). Bounding the attacker’s cross-modal capability is a future-work item.

Quantum-resistance is a future migration. Neither Ed25519 nor P-256 ECDSA is post-quantum-secure. A migration to post-quantum signatures (Dilithium 3 or 5) is straightforward at the cryptography layer; the schema field signature_alg is reserved for this. Signature-size and signing-cost budgets on cheap sensors get worse under Dilithium; the migration is gated on standardisation and on hardware support landing in successor secure elements.

8. Closing position

We are not proposing a better detector, and we are not proposing an alternative open architecture to SAPIENT. We are proposing a verifiable trust boundary around the detector, integrated as a security profile that the SAPIENT data-plane can carry. The detection science (CNN on spectrograms, RF-acoustic-EO/IR fusion, distributed TDoA) is the subject of separate, parallel research efforts. PSF is the architecture that turns “trust the vendor” into “verify the math,” and it is the architecture under which a single-vendor compromise does not break the operator’s audit posture, in a form compatible with the open architecture NATO is rolling toward.

The contribution is the integration as a SAPIENT-compatible security profile, not any single primitive. The primitives are mature; the composition into a deployable civilian C-UAS architecture with cheap-sensor retrofit, cross-tier algorithm flexibility, edge-only execution, and subpoena-aware audit posture is, to our knowledge and within the search limits documented in Section 2.5, not present in the published open literature.

We invite collaboration on the protocol specification. The licensing terms for the specification and the reference implementation will be decided as the prototype matures. The high-performance fusion pipeline and the trained classifiers remain proprietary. The trust chain is a public good in principle, because a trust chain that only the vendor can audit is not a trust chain.

References

1. Schiller, N., Chlosta, M., Schloegel, M., et al. “Drone Security and the Mysterious Case of DJI’s DroneID.” NDSS 2023.
2. Glüge, S., Nyfeler, M., Aghaebrahimian, A., Ramagnano, N., & Schüpbach, C. “Robust Low-Cost Drone Detection and Classification Using Convolutional Neural Networks in Low SNR Environments.” IEEE Journal of Radio Frequency Identification, vol. 8, pp. 821-830, 2024. DOI 10.1109/JRFID.2024.3487303. arXiv:2406.18624.
3. Trusted Computing Group. “Hardware Requirements for a Device Identifier Composition Engine.” TCG DICE Specification.
4. Sigstore project. “Rekor: Software Supply Chain Transparency Log.” docs.sigstore.dev, 2025.
5. C2PA. “Coalition for Content Provenance and Authenticity Specifications.” c2pa.org, 2024 to 2026.
6. NSA, FBI, CISA. “Content Credentials: Strengthening Multimedia Integrity in the Generative AI Era.” Joint Cybersecurity Information Sheet, January 29, 2025.
7. Lagrange Labs. “Lagrange Integrates DeepProve into the Anduril Lattice SDK Environment.” November 5, 2025.
8. NATO STO MP-MSG-SET-183, paper 11. “Passive Sensor Processing and Data Fusion for Drone Detection.” Specialist Team scope: Detection and Characterization of a UAS RF FHSS Communication Link.
9. Fu, D., & Peng, X. “TPM-Based Remote Attestation for Wireless Sensor Networks.” Tsinghua Science and Technology, vol. 21, no. 3, pp. 312-321, 2016.
10. Ould Imam, Z., Lacoste, M., & Arfaoui, G. “Towards a Modular Attestation Framework for Flexible Data Protection for Drone Systems.” IEEE WiMob 2021, October 11-13, 2021.
11. Spoczynski, M., Melara, M. S., & Szyller, S. “Atlas: A Framework for ML Lifecycle Provenance & Transparency.” arXiv:2502.19567, 2025.
12. Dabbabi, K., & Delleji, T. “Graph neural network-tracker: a graph neural network-based multi-sensor fusion framework for robust unmanned aerial vehicle tracking.” Visual Computing for Industry, Biomedicine, and Art, 8:18, 2025. DOI 10.1186/s42492-025-00200-2.
13. Frid, A., Ben-Shimol, Y., Manor, E., & Greenberg, S. “Drones Detection Using a Fusion of RF and Acoustic Features and Deep Neural Networks.” Sensors 24(8):2427, April 2024. DOI 10.3390/s24082427.
14. “WAVE-DETR Multi-Modal Visible and Acoustic Real-Life Drone Detector.” arXiv:2509.09859, September 2025.
15. Defence Science and Technology Laboratory (Dstl) and BSI. “SAPIENT (Sensors for Asset Protection using Integrated Electronic Networked Technology), Interface Control Document v7.” BSI Flex 335.
16. Lucid Truth Technologies. “Hardware-Signed C2PA Camera Credentials.” 2025.
17. Bormann, C., & Hoffman, P. “Concise Binary Object Representation (CBOR).” RFC 8949, December 2020. Section 4.2 (deterministic encoding).
18. Josefsson, S., & Liusvaara, I. “Edwards-Curve Digital Signature Algorithm (EdDSA).” RFC 8032, January 2017.
19. Schneier, B., & Kelsey, J. “Secure Audit Logs to Support Computer Forensics.” ACM Transactions on Information and System Security, vol. 2, no. 2, pp. 159-176, 1999.
20. Matetic, S., Ahmed, M., Kostiainen, K., Dhar, A., Sommer, D., Gervais, A., Juels, A., & Capkun, S. “ROTE: Rollback Protection for Trusted Execution.” USENIX Security 2017.
21. Microchip Technology. “ATECC608B CryptoAuthentication Device Summary Datasheet.” DS40002239.
22. Fujii, H., & Aranha, D. F. “Curve25519 for the Cortex-M4 and Beyond.” LATINCRYPT 2017.
23. Bisheh-Niasar, M., Azarderakhsh, R., Mozaffari-Kermani, M., et al. “Efficient and Side-Channel Resistant Ed25519 on ARM Cortex-M4.” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2024.
24. NIST. “Guidelines for Smart Grid Cybersecurity.” NIST IR 7628, Revision 1.
25. AUTOSAR. “Specification of Secure Hardware Extensions (SHE) and Hardware Security Module (HSM) integration patterns.” AUTOSAR Classic Platform.

---

Symvek Technologies Inc. | Counter-surveillance and counter-UAS infrastructure. symvek.com.