Source-linked AI summary

CRSF: Collusion-Resilient Privacy-Preserving Sensor Fusion with Byzantine-Robust Participation

Chao Yin, Haihong Tian, Zheng Yang, Haibin Zhang, Fabio Massacci, Chenglu Jin

arXiv:2609.01096v1cs.CR

TL;DR

Prior garbled-circuit sensor-fusion protocols leave sensor-server collusion and Byzantine control of participation insufficiently addressed. CRSF adds robust agreement on submissions and protected, status-dependent label release; the authors report its security guarantees with moderate online overhead.

  • Problem

    Existing privacy-preserving sensor-fusion protocols leave sensor-server collusion and Byzantine server control of sensor participation unaddressed.

    Source: §1 · p. 2
  • Method

    CRSF extends garbled-circuit sensor fusion with Byzantine-robust agreement on submissions, status-dependent label release, and threshold protection of circuit-input labels.

    Source: §1 · p. 3
  • Results

    CRSF provides privacy, correctness with explicit abort, and liveness, while evaluation reports predictable scaling across the evaluated circuits despite added online runtime.

    Source: §1 · p. 3, §8 · p. 17
  • Takeaways & Limitations

    The authors conclude stronger robustness against sensor-server collusion and Byzantine participation manipulation is achievable with moderate online overhead.

    Source: §8 · p. 17

    The cited limitation evidence describes PG, not CRSF: PG's original model excludes sensor-server collusion and assumes prescribed server participation.

    Source: §3 · pp. 6–7

Abstract

from arXiv · show

Privacy-preserving sensor fusion enables an untrusted server to compute an aggregate result over distributed sensor measurements without learning either individual inputs or the final output. Recent garbled-circuit-based protocols provide an efficient realization of this functionality in a sensor--server--client architecture, but remain vulnerable to sensor--server collusion and Byzantine manipulation of sensor participation. These weaknesses can compromise honest-sensor privacy, incorrectly exclude honest sensors, and corrupt the computed fusion result, thereby undermining the security guarantees expected from the protocol. We present CRSF, a collusion-resilient sensor-fusion protocol that addresses these weaknesses while providing privacy, correctness with explicit abort, and liveness. CRSF introduces a Practical Byzantine Fault Tolerance (PBFT)-based agreement phase for sensor submissions and uses server-specific, status-dependent label release with threshold protection of circuit-input labels. This design prevents any Byzantine server from unilaterally manipulating sensor participation and prevents any admissible sensor-server coalition from obtaining enough secret material to compromise honest-sensor privacy. We implement CRSF and compare its online execution time with the most relevant state-of-the-art baseline. Our Google Cloud evaluation measures the total computation and communication cost of the online protocol under fault-free and representative faulty executions. Across a range of fault-tolerant fusion circuits and up to 261 sensors, CRSF demonstrates a highly practical trade-off between robust security and protocol performance.

1 Introduction

CRSF strengthens garbled-circuit sensor fusion against sensor-server collusion and Byzantine manipulation of participation through robust agreement and threshold-protected circuit-input labels. It provides privacy, correctness with explicit abort, and liveness, with online evaluation reporting total measured phase time around one second at the largest tested instances.

Introduction

  • Three-role sensing systems rely on sensors to contribute measurements, a client to specify and consume the fusion task, and an intermediate platform to process or store data.Their security goals include protecting readings from server and client, preventing corrupted sensors from biasing computation, and ensuring result delivery under intended availability assumptions.Source: §1 · p. 2
  • PG combines input privacy and pollution-attack robustness with guaranteed output delivery under a bounded Byzantine model, making it an important baseline.The authors identify it as the first construction to achieve these properties together in a three-role sensor-fusion architecture.Source: §1 · p. 2
  • Under sensor-server collusion, PG [13] can expose complementary circuit-input labels, while a Byzantine server can exclude honest sensors and retain malicious ones.This can compromise honest-sensor privacy and result integrity or invalidate the fault-threshold premise; participation decisions and input labels therefore require protection.Source: §1 · pp. 2–3
  • At the largest tested instances, total measured phase time remains around one second across fault-free and representative faulty executions.The evaluation reports moderate overhead from sensor participation agreement and label reconstruction.Source: §1 · p. 3
  • CRSF proves privacy against corrupted sensors colluding with one Byzantine server, correctness with explicit abort, and liveness under its threat model.Source: §1 · p. 3
  • CRSF adds agreement on sensor participation before status-dependent label release and threshold protection of downstream circuit-input labels before fusion evaluation.It retains the client-sensor-server workflow and follows the garbled-circuit workflow of PG.Source: §1 · p. 3

2 System and Threat Model

CRSF models private fusion among a client, independent sensors, and four servers, with an adversary corrupting sensors and at most one server. It targets privacy, correct output or abort, liveness, and agreement on sensor participation under bounded faults.

System Model

  • The client obtains the fusion output from four servers without seeing plaintext measurements or computing on its own; only the client decodes the result.Sensors independently encode and submit measurements to the servers, which compute on encoded inputs; sensors do not communicate with one another.Source: §2 · pp. 3–4

Threat Model

  • The adversary may corrupt multiple sensors and at most one server, but malicious and unavailable sensors together must stay below the fusion algorithm’s fault threshold.Corrupted sensors may submit malformed labels and collude with the server, which may send inconsistent messages; the threshold may be fewer than 1/3 or 1/2 of sensors. The model follows common sensing and aggregation abstractions and prior sensor-server collusion threats.Source: §2 · p. 4

Security and Robustness Goals

  • CRSF targets privacy under bounded sensor-server collusion, correct output or explicit abort, eventual output or abort, and honest-server agreement on each sensor’s acceptance or exclusion.The client learns only the protocol output and status information needed for delivery; correctness applies to protocol-determined inputs and default replacements.Source: §2 · p. 4

3 Preliminaries

The preliminaries define the garbled-circuit, threshold-sharing, and Byzantine-agreement tools underlying CRSF, then describe PG’s workflow and the collusion and participation-manipulation vulnerabilities that motivate CRSF.

Garbled Circuits

  • Garbled circuits encode each Boolean input as one wire label, evaluate the garbled circuit, and decode outputs to C(x) except with negligible probability; their security notions include privacy, obliviousness, and authenticity.The leakage Φ(C) may include circuit size, input and output lengths, or topology, depending on the scheme and application.Source: §3 · pp. 4–5

Practical Byzantine Fault Tolerance

  • PBFT tolerates up to f Byzantine replicas among n ≥ 3f + 1 and provides safety and liveness under its standard assumptions; CRSF adapts its quorum and phase structure for submission agreement.Under partial synchrony, view changes let honest replicas move past a faulty primary while preserving previously prepared information.Source: §3 · p. 5

Shamir Secret Sharing

  • A (t, n)-threshold Shamir scheme reconstructs a secret from any t shares, while fewer than t shares are statistically independent of it.The secret is the constant term of a random polynomial of degree at most t − 1 over a finite field larger than n.Source: §3 · p. 5

The PG Baseline and Its Limitations

  • PG separates client-generated circuit garbling from sensor-generated submissions, using checking gates to detect malformed inputs and filter gates to derive fusion labels or maximum-value defaults [13].The client releases filter-gate labels based on whether a sensor’s submission passed checking.Source: §3 · p. 6
  • Under stronger collusion and server-adversary assumptions, PG can expose FreeXOR offsets and let a Byzantine server exclude honest sensors, undermining privacy and correctness [13].The offset exposure can compromise honest-sensor privacy and circuit-evaluation integrity; manipulating participation can push the faulty-sensor share beyond the fusion algorithm’s tolerance threshold.Source: §3 · pp. 6–7

4 The CRSF Protocol

CRSF combines PBFT-based agreement on sensor submissions with status-dependent label release and checked reconstruction of circuit inputs. Its four-server protocol addresses both Byzantine manipulation of participation and exposure of input labels.

4 The CRSF Protocol

  • Unlike OT-based label selection, CRSF avoids per-sensor client OT while also addressing Byzantine manipulation of which submissions enter fusion.OT-based selection increases online costs for sensors and the client, and does not prevent a Byzantine server from manipulating admission; CRSF instead combines PBFT agreement with server-specific filter-gate shares.Source: §4 · p. 7

4.1 Setup and Offline Preparation

  • Offline preparation distributes the garbled fusion circuit and checking gates to all servers, but gives each server only its server-specific filter gates.Sensors and servers hold signing keys whose verification keys are shared with the relevant parties; sensors also share pairwise secret keys with the client for deriving sensor-side input labels.Source: §4.1 · pp. 7–8, Figure 1 · p. 8

4.2 Agreement on Sensor Submissions

  • With four servers and one Byzantine fault, 3-of-4 PBFT agreement derives each sensor’s outcome from evidence and prevents exclusion of a delivered honest submission.The evidence rule accepts a submission when at least two of three reports contain the same valid input-label vector; otherwise, it derives Mal. Servers decide only after three matching commit messages.Source: §4.2 · pp. 9–10

4.3 Status-Dependent Label Release and Reconstruction

  • Status-dependent release exposes one Hon or Mal label branch; servers reconstruct checked circuit-input labels from three shares, evaluate fusion, and the client accepts matching outputs from three servers.Each server first derives a status from checking-gate outputs; the client accepts a status vector only when three servers report the same vector. Three valid shares reconstruct a candidate label set, which must pass second-layer checking gates.Source: §4.3 · pp. 10–11

5 Security Analysis

CRSF’s security analysis establishes privacy up to coalition leakage, correctness with explicit abort, and eventual output or abort, under stated cryptographic and PBFT assumptions.

5 Security Analysis

  • The guarantees assume honest client setup and correctly distributed verification keys, specified cryptographic security properties, and PBFT liveness conditions including authenticated communication, partial synchrony, and eventual message delivery among honest parties.The cryptographic assumptions cover collision-resistant H, EUF-CMA-secure Sig, pseudorandom PRG, garbling privacy, obliviousness and authenticity, and correctness and privacy of byte-wise (3, 4) Shamir sharing.Source: §5 · p. 11
  • Theorem 1 shows that a simulator can reproduce the corrupted coalition’s view from its leakage, so the coalition learns neither honest sensors’ measurements nor the plaintext fusion output beyond that leakage.Coalition leakage includes corrupted parties’ inputs and randomness, only Hon/Mal outcome types, and public abort information. The proof relies on Shamir privacy, PRG security, garbled-circuit obliviousness and authenticity, signature unforgeability, and collision resistance.Source: §5 · pp. 12–13
  • Theorem 2 guarantees that the honest client either outputs ⊥ or accepts the correct output-label vector for the uniquely determined circuit-input label vector, except with negligible probability.PBFT safety and deterministic evidence rules align honest servers’ outcomes; majority-gated label release, reconstruction checks, and garbled-circuit authenticity ensure incorrect results are rejected or cause abort.Source: §5 · p. 13
  • Theorem 3 guarantees that, under PBFT liveness conditions, the honest client eventually outputs either a decoded fusion result or ⊥.Agreement eventually decides an evidence-supported outcome or aborts; subsequent finite protocol phases either complete or trigger explicit abort.Source: §5 · p. 13

6 Evaluation

On Google Cloud, CRSF is slower online than PG but scales approximately linearly with sensor count; its measured runtime can be lower in the evaluated faulty setting than in fault-free runs.

6 Evaluation

  • Across all five fusion circuits, PG remains faster than CRSF, whose runtime grows approximately linearly with sensor count in a fixed four-server deployment.CRSF adds inter-server PBFT agreement and threshold share reconstruction, unlike PG’s single evaluator.Source: Figure 2 · p. 14, §6 · p. 14
  • CRSF’s measured online runtime can be lower in the evaluated faulty execution than in the corresponding fault-free run.The scenario omits submissions from the maximum tolerated faulty sensors and makes one backup non-responsive; the primary and two responsive backups form the 2f+1 = 3 quorum. This is one adversarial scenario, not an exhaustive fault-injection campaign.Source: Figure 2 · p. 14, §6 · p. 15
  • The evaluation measures online protocol costs using software-emulated sensors, not physical sensing time, wireless variability, or embedded-device energy.Runtimes include authenticated submission processing, PBFT agreement, label reconstruction, and garbled-circuit evaluation, and exclude offline preparation; the study uses five Marzullo-style circuits with 16-bit inputs and up to 261 sensors.Source: §6 · pp. 13–14
  • At the largest tested instances, PBFT agreement used about 8.9–9.7 MB and under 0.51 seconds, versus reconstruction’s about 1.2–1.5 MB and under 0.14 seconds in fault-free runs.PBFT agreement accounts for the largest communication volume; reconstruction still contributes measurable wall time before circuit evaluation.Source: §6 · p. 15, Table 1 · p. 15

7 Related Work

Prior work addresses collusion-resistant sensing, secure aggregation, and federated learning, but CRSF differs in its three-role sensor-fusion setting and its protection against sensor–server collusion and Byzantine participation.

Collusion-resilient sensing and aggregation

  • PriSense, PEPSICo, and PDACAS address collusion or privacy in sensing and aggregation, but target different functionality and leakage surfaces.PriSense protects against threshold collusion while supporting statistical queries; PEPSICo adds collusion resistance to participatory sensing; PDACAS protects readings even if the cell header and sink collude while allowing SUM computation.Source: §7 · p. 16
  • Verifiable aggregation work addresses correctness or summation, whereas CRSF combines garbled-circuit sensor fusion with sensor–server collusion protection and Byzantine-robust participation agreement.The cited sensing protocols primarily hide individual readings while allowing an aggregation server or sink to compute an intended aggregate.Source: §7 · p. 16

Secure aggregation and federated learning

  • Federated-learning secure aggregation typically reveals the aggregate to a two-role server, unlike CRSF’s three-role setting, where servers should learn neither measurements nor fusion output.Dropout-resilient aggregation uses secret sharing mainly to recover masks and lets the server learn the sum; FLock uses multiple aggregators for richer functionality with greater system complexity.Source: §7 · p. 16

8 Conclusion

CRSF combines PBFT-based submission agreement with status-dependent label release and threshold sharing to resist Byzantine participation manipulation and sensor–server collusion. The authors prove privacy, correctness with explicit abort, and liveness, and report predictable scaling with moderate online overhead in their Google Cloud evaluation.

8 Conclusion

  • CRSF combines PBFT-based submission agreement, status-dependent label release, and byte-wise (3, 4) Shamir sharing to protect participation integrity and honest-sensor privacy.The design prevents a Byzantine server from unilaterally controlling participation and an admissible sensor–server coalition from reconstructing complementary circuit-input labels.Source: §8 · pp. 16–17
  • The authors prove privacy, correctness with explicit abort, and liveness under the stated assumptions.Source: §8 · p. 17
  • CRSF adds online runtime for agreement and reconstruction but retains predictable scaling across evaluated fault-tolerant fusion circuits, with moderate online overhead.The implementation was evaluated on Google Cloud.Source: §8 · p. 17

A Security Proofs · A.1 Proof of Theorem 1

Theorem 1 is proved by simulating the coalition’s view and linking it to the real view through two indistinguishable hybrids. The proof combines threshold-share privacy with cryptographic guarantees for labels, agreement, and garbling.

A.1 Proof of Theorem 1

  • The simulator builds honest-sensor submissions from fresh pseudorandom labels and reuses each label consistently across reports, evidence, checking gates, and filter inputs.Corrupted-sensor and corrupted-server messages are induced by running the adversary.Source: §A.1 · p. 19
  • The simulated PBFT transcript binds derived outcomes and evidence, while client-side filter labels released to the corrupted server match the accepted majority status vector.Honest prepare and commit messages are generated over the outcome and evidence digests.Source: §A.1 · p. 19
  • The simulator shares fusion-circuit input labels using byte-wise (3, 4) Shamir sharing and makes visible shares of complementary labels independent uniform field-element strings.Reconstruction is arranged to yield the simulated labels, relying on below-threshold Shamir privacy for complementary-label shares.Source: §A.1 · p. 19
  • When abort information specifies an abort, the simulator outputs only the transcript prefix visible up to that abort point.This conditions the simulated view on the protocol’s abort point.Source: §A.1 · p. 19
  • In H0 to H1, replacing visible below-threshold shares of complementary labels with uniform byte-wise shares preserves evaluation and checking, by Shamir privacy.The passage states H0 ≈s H1.Source: §A.1 · p. 20
  • In H1 to H2, PRG security, collision resistance, garbling obliviousness, and gate authenticity justify replacing honest-side labels, agreement, and evaluator views.Surrounding filter outputs, reconstruction shares, and checking gates are regenerated coherently; the passage states H1 ≈c H2.Source: §A.1 · p. 20
  • The real coalition view is indistinguishable from the simulator’s output, establishing Theorem 1.The proof links the real distribution H0 to H1 statistically and H1 to H2 computationally; H2 is the simulator’s output.Source: §A.1 · p. 20

B Detailed Analysis of the Limitations of PG

PG is secure under its original model without sensor–server collusion and with prescribed participation; under the stronger model, collusion can break input privacy and a Byzantine server can manipulate sensor admission.

B Detailed Analysis of the Limitations of PG

  • PG’s security applies under its original threat model, where the server neither colludes with sensors nor deviates from the prescribed participation procedure.Source: B Detailed Analysis of the Limitations… · p. 20
  • A Byzantine server–corrupted sensor coalition can obtain both labels, recover FreeXOR offset ∆, derive complementary labels, and violate input privacy; ∆ also permits output-semantic flips.In the illustrative circuit, the coalition uses alternative valid labels on another sensor’s wires to learn their truth values and can flip the third AND gate’s output.Source: B Detailed Analysis of the Limitations… · pp. 20–21
  • Because PG relies on one server to admit submissions, a Byzantine server can exclude honest sensors while retaining corrupted ones, potentially violating the fusion algorithm’s fault-threshold premise.Source: B Detailed Analysis of the Limitations… · p. 21
Loading 2609.01096v1…