PrivFuzz: Privacy-Preserving Distributed Fuzzing for CPS-Facing Parsing Components on Untrusted Clients

Abstract

Cyber–physical systems (CPSs) increasingly rely on complex software components whose vulnerabilities may affect both digital services and physical processes. Fuzzing is a practical technique for discovering such vulnerabilities in CPS-facing parsers, protocol handlers, and edge services. Distributed fuzzing improves throughput, but outsourcing fuzzing tasks to multiple untrusted nodes introduces privacy risks: valuable seeds, especially crash-triggering samples, may reveal vulnerability information before affected users are protected. In this paper, we propose PrivFuzz, a privacy-preserving collaborative fuzzing framework. PrivFuzz allows organizations and individuals to collaborate and receive rewards while keeping fuzzing seeds confidential and enabling controlled encrypted seed reuse among untrusted fuzzing nodes. The key idea is to combine trusted execution environments (TEEs) with blockchain-based smart contracts to support confidentiality and fair reward settlement. We give game-based definitions and reduction-style arguments for seed confidentiality, worker soundness, outsourcer atomicity, and duplicate-claim resistance under an attested execution model. We implement a PrivFuzz prototype and evaluate it on four open-source parsing targets. Separately, native AFL++ sanity checks suggest that CPS-facing industrial protocol parsers such as Modbus and OPC UA fall within the same fuzzable target domain. Demonstrating end-to-end PrivFuzz on CPS control programs is left as future work. Using PrivFuzz, we discovered nine bugs and reported them to the developers.

1. Introduction

Cyber–physical systems (CPSs), including industrial control systems, smart manufacturing platforms, connected vehicles, and intelligent IoT infrastructures, increasingly depend on complex software to parse inputs, process sensor data, coordinate control logic, and communicate with external services. Many deployable CPS products contain CPS-facing software components such as industrial protocol parsers, edge gateways, data converters, media/configuration parsers, and control-support services. Vulnerabilities in these components may propagate from cyberspace to physical processes, making efficient vulnerability discovery an important part of CPS security assurance.

Fuzzing is a popular and effective vulnerability discovery technique for such software-intensive systems. It explores program execution paths by repeatedly running the target program with mutated inputs, thereby triggering potentially vulnerable states. Parallel fuzzing can increase the number of executions within a fixed time budget and thus improve the probability of discovering vulnerabilities. Many companies (e.g., Google and Microsoft) have proposed the fuzzing-as-a-service (FaaS) paradigm to reduce the burden of distributing fuzzing tasks across multiple machines.

However, this paradigm raises serious privacy concerns because developers must trust both the cloud provider and the underlying infrastructure. Since fuzzing can uncover high-value zero-day vulnerabilities, curious or compromised cloud providers may have incentives to monetize such vulnerabilities without disclosing them to software developers.

Fuzzing@Home [1] is the first attempt to enable collaborative fuzzing on multiple untrusted nodes. It builds a blockchain network to connect software developers with computing-power providers. However, Fuzzing@Home relies on sharing fuzzing corpora, which may cause crash samples to be leaked for profit. Because developers still need time to locate and fix vulnerabilities, users who continue to run affected versions face substantial security risks. Even when crash-triggering samples are not shared directly, sharing ordinary but informative seeds may allow malicious participants to rediscover the same vulnerability within a short period of time. Therefore, the confidentiality of the seed set must be protected.

A straightforward solution is to let each node encrypt seeds with the task issuer’s public key and store the ciphertext on the blockchain. However, this approach has two major limitations. First, the fairness between workers (fuzzing nodes) and the task publisher (the program developer) must be addressed. Workers should not submit valuable seeds unless the publisher pays the corresponding reward, and the publisher should receive seeds of the claimed value after payment. However, if seeds remain confidential, blockchain nodes other than the task publisher cannot independently reach consensus on seed value, which makes fair settlement difficult. Second, encrypted seed files cannot be shared among fuzzing nodes, wasting computing resources and reducing fuzzing efficiency.

To address these issues, we introduce PrivFuzz—a privacy-preserving collaborative fuzzing outsourcing framework, motivated by and applicable to CPS-facing parsing components, that does not require changes to the underlying blockchain consensus protocol. PrivFuzz protects valuable seeds from leakage and abuse while still enabling seed sharing among multiple fuzzing nodes. Specifically, our design follows a widely adopted off-chain processing approach and uses trusted execution environments (TEEs) to enable privacy-preserving fuzzing crowdsourcing. In our scheme, all seeds are stored on the blockchain as ciphertext and are encrypted, decrypted, mutated, and consumed inside off-chain enclaves throughout the fuzzing process. Workers cannot access plaintext seeds at any stage. To support fair exchange, we devise an off-chain seed value evaluation mechanism. Before submitting a newly discovered valuable seed to the blockchain, a worker inputs the seed into an off-chain value evaluation enclave to generate an immutable value proof, which is calculated from the seed’s contribution to code coverage and the difficulty of the discovered crash. With this value proof, consensus nodes can transparently determine the seed price through an on-chain smart contract and thereby enforce fair exchange.

To support the security and fairness claims of our scheme, we give game-based definitions and reduction-style arguments for four properties under the stated attested execution and blockchain consensus assumptions: seed confidentiality, worker soundness, outsourcer atomicity, and duplicate-claim resistance.

To evaluate the practicality of our scheme, we implement PrivFuzz on the Hyperledger Fabric blockchain and deploy four real-world parsing-oriented applications for fuzzing. We evaluate the overhead, node-count behavior, and seed synchronization behavior of PrivFuzz, including a comparison with Fuzzing@Home-style real-time synchronization. We further run native AFL++ sanity checks on CPS-facing protocol parsers only to clarify the target domain; these checks are not an end-to-end evaluation of PrivFuzz. A dedicated microbenchmark campaign on a second host additionally characterizes each pipeline component, the settlement path, the library-OS software layer, and cryptographic kernel alternatives, and a matched seed-sharing ablation isolates the coverage-level effect of encrypted seed reuse. The prototype evaluation exercises the full PrivFuzz workflow under the tested settings. Meanwhile, we found nine bugs in the original prototype evaluation and reported them to the project maintainers.

In summary, the main contributions of our work are as follows:

• We build a secure distributed collaborative fuzzing outsourcing framework, motivated by and applicable to CPS-facing parsing components, based on blockchain and TEEs. The framework protects the confidentiality of valuable seeds while still permitting seed sharing among fuzzing nodes.
• We design an off-chain seed value evaluation mechanism that enables worker nodes to generate unforgeable seed value proofs. By verifying these proofs, blockchain nodes can reach on-chain consensus on seed prices.
• We formalize seed confidentiality, worker soundness, outsourcer atomicity, and duplicate-claim resistance using game-based definitions, and give reduction-style arguments based on attestation integrity, encryption security, hash collision resistance, and blockchain consensus. Moreover, we implement a prototype on Hyperledger Fabric, evaluate its performance on four real-world parsing-oriented projects, and separately use native AFL++ sanity checks to illustrate that industrial protocol parsers belong to the intended fuzzing target domain.

2. Preliminaries and Related Works

2.1. Coverage-Guided and Hybrid Fuzzing

Fuzzing is a vulnerability discovery technique that repeatedly executes the target program with generated or mutated inputs and monitors abnormal behaviors such as crashes and hangs. Modern greybox fuzzers use lightweight program feedback to guide input generation. American Fuzzy Lop (AFL) [2], libFuzzer [3], and AFL++ [4] represent widely used coverage-guided fuzzing engines: they record path or edge coverage, retain test cases that trigger new coverage, and mutate the evolving corpus to explore deeper program states.

A large body of work improves the search efficiency of greybox fuzzing. AFLFast models coverage-guided fuzzing as a Markov chain and prioritizes low-frequency paths [5]; FairFuzz focuses mutation effort on rare branches [6]; CollAFL refines path sensitivity to reduce path collisions in AFL-style feedback maps [7]; Angora uses taint tracking and search-based mutation to solve path constraints without full symbolic execution [8]; and NEUZZ applies neural program smoothing to guide input generation [9]. Other systems combine fuzzing with program analysis. Driller uses selective symbolic execution when fuzzing gets stuck [10], QSYM optimizes concolic execution for hybrid fuzzing [11], and VUzzer uses application-aware evolutionary guidance [12]. These techniques substantially improve bug-finding capability, but they mainly optimize how a fuzzer explores a target program. They generally assume that the corpus, crashes, and coverage information are available to the party running the fuzzer, which is unsuitable when fuzzing is outsourced to economically motivated and potentially malicious participants.

2.2. Distributed and Service-Oriented Fuzzing

An important direction to improve fuzzing efficiency is to expand concurrency through distributed computing. Industrial fuzzing infrastructures such as ClusterFuzz [13], OSS-Fuzz [14], and Microsoft OneFuzz [15] automate large-scale fuzzing, crash triage, minimization, and regression testing. FuzzBench further provides a reproducible service for comparing fuzzers under shared benchmarks [16]. These systems demonstrate that large-scale automation is practical and effective, but the usual fuzzing-as-a-service (FaaS) model requires developers to trust the cloud provider and its infrastructure. This trust assumption is problematic because fuzzing may uncover high-value zero-day vulnerabilities before the developer can patch and disclose them.

Several works study fuzzing in less trusted outsourcing settings. P2FAAS explores privacy-preserving fuzzing-as-a-service [17], while Fuzzing@Home realizes distributed fuzzing on untrusted heterogeneous clients by using blockchain-based incentives and game-theoretic mechanisms [1]. Fuzzing@Home is the closest work to PrivFuzz in terms of decentralized participation. However, its collaborative efficiency comes from sharing fuzzing corpora among participating nodes. Once crash-triggering seeds or highly informative non-crashing seeds are exposed to malicious participants, attackers may reproduce or rediscover the corresponding vulnerabilities before affected users are protected. PrivFuzz therefore focuses on a complementary problem: enabling useful corpus sharing and reward settlement while keeping valuable seeds confidential from FPs, FOs before payment, cloud storage, and blockchain nodes.

Recent work further clarifies the boundary of this contribution. SPDS studies secure and auditable private data sharing for smart grids using blockchain, but it does not address fuzzing-specific seed valuation, confidential corpus reuse, or worker reward settlement [18]. TEEFuzzer targets the security testing of TEE systems themselves through feedback-guided mutation and coverage collection, whereas PrivFuzz uses an attested TEE to protect the execution and evaluation of an outsourced fuzzing task [19]. SyzTrust targets state-aware fuzzing of resource-constrained IoT trusted operating systems with hardware-assisted feedback; it is complementary to our outsourcing and settlement problem [20].

Work from 2024 to 2026 sharpens the same boundary. On the TEE side, emulator-based trusted-application fuzzing continues to test the TEE stack itself: TÄMU interposes at the GlobalPlatform API layer [21], and Qualcomm trusted applications are fuzzed through partial emulation [22], whereas PrivFuzz uses an attested TEE to protect an outsourced fuzzing workload. Confidential-computing systematizations cover heterogeneous CPU–GPU enclaves [23] and the trust relationships of confidential virtual machines in public clouds [24], but they do not address fuzzing workloads or seed markets. In collaborative fuzzing, BandFuzz coordinates multiple fuzzers with bandit-based resource allocation [25] but assumes honest participants and provides neither seed confidentiality nor verifiable settlement. In our target domain, specification-guided protocol fuzzing such as AFL-ICP [26] fuzzes the same CPS-facing parser class locally rather than through outsourcing. On the settlement side, privacy-preserving data trading with auditable fair exchange [27] trades generic data bilaterally rather than fuzzing-specific work with TEE-attested value proofs. Our search of the 2024–2026 literature across these five component areas—TEE security testing, confidential computing, collaborative and distributed fuzzing, CPS/ICS security testing, and blockchain privacy—identified no system that outsources fuzzing to untrusted workers with confidential corpus reuse and on-chain reward settlement; the works above are the nearest neighbors in each component dimension rather than direct competitors.

Table 1. Comparison with closely related systems. TEE denotes trusted execution environment; “Seed conf.” denotes seed confidentiality; “Verif. value” denotes verifiable seed value; “Atomic settle.” denotes atomic settlement; and “Dup. check” denotes duplicate-claim checking.

System	Plain Corpus	Seed Conf.	Verif. Value	Atomic Settle.	Dup. Check	Decentralized	Fuzzing-Specific
Fuzzing@Home [1]	Yes	No	Partial	Partial	Partial	Yes	Yes
P2FAAS [17]	No	Yes	No	No	No	No	Yes
SPDS [18]	N/A	Partial	No	No	No	Yes	No
TEEFuzzer [19]	Yes	No	No	N/A	N/A	No	Yes
Town Crier [28]	N/A	Partial	No	N/A	No	No	No
Ekiden [29]	N/A	Partial	No	N/A	No	No	No
PrivFuzz	No	Yes	Yes	Yes	Yes	Yes	Yes

Note: Entries use Yes/No/Partial/N/A to answer the column property directly. For Fuzzing@Home, Partial under atomic settlement and duplicate checking reflects incentive and game-theoretic mechanisms rather than confidential seed value exchange with on-chain duplicate-claim resistance. Town Crier and Ekiden are included to compare general TEE–blockchain capabilities; they are not fuzzing systems. SPDS provides blockchain-based auditable private data sharing for smart grids and protects shared data confidentiality (Partial), but it addresses neither fuzzing-specific seed valuation nor reward settlement; TEEFuzzer applies feedback-guided fuzzing to TEE systems themselves and involves neither outsourced confidential corpora nor on-chain settlement.

summarizes the design differences between PrivFuzz and closely related systems. The comparison highlights that the novelty of PrivFuzz is not the isolated use of TEEs or blockchains. Instead, PrivFuzz combines encrypted corpus reuse, fuzzing-specific seed value proofs, duplicate-claim checks, and atomic reward settlement for decentralized fuzzing on untrusted participants.

2.3. Trusted Execution Environments and Confidential Smart Contracts

TEE is a widely used processor functionality that achieves hardware-assisted runtime isolation [30,31,32]. In PrivFuzz, we use Intel Software Guard Extensions (SGX) [33] as the TEE. SGX provides instructions to create secure memory spaces called enclaves. Applications executed in an enclave are isolated from the outside world, including the operating system, hypervisor, and other enclaves. SGX has been used to shield applications and containers from untrusted platforms in systems such as Haven [34], SCONE [35], and Occlum [30], and to support privacy-preserving computation in systems such as VC3 [36], Opaque [37], and Ryoan [38].

TEE-backed computation has also been combined with blockchains and smart contracts. Hawk studies privacy-preserving smart contracts in a formal blockchain model [39]; Town Crier uses SGX to provide authenticated data feeds to smart contracts [28]; and Ekiden separates consensus from TEE-backed contract execution to improve confidentiality and performance [29]. These systems show that trusted hardware can bridge private off-chain execution and public on-chain verification. PrivFuzz adopts this design philosophy for fuzzing outsourcing: fuzzing and seed evaluation are performed inside attested enclaves, while smart contracts verify value proofs and settle rewards without learning the plaintext seeds.

Homomorphic encryption and secure multi-party computation provide alternative privacy-preserving computation paradigms, but they have different fit for this workload. Homomorphic evaluation can protect inputs while computing selected functions, yet stateful fuzzing repeatedly executes complex native programs with branch-dependent coverage, sanitizer behavior, and large mutable state. MPC can distribute trust across parties, but its communication and synchronization costs are difficult to reconcile with high-volume, feedback-driven fuzzing. We therefore treat these paradigms as conceptual alternatives for the privacy kernel; Section 6.6.2 quantifies their per-operation cost relative to the TEE-resident kernel, while the deployed prototype measures a TEE-based design only.

We adopt the model of Pass et al. [40] to formally describe PrivFuzz, which abstracts enclaves as an ideal functionality denoted by ${\mathcal{G}}_{\mathrm{att}}$.

Table 2. Main notations used in the scheme. TEE denotes trusted execution environment; SGX denotes Software Guard Extensions.

Notations	Descriptions
$\mathcal{SE}(\mathsf{KGen},\mathsf{Enc},\mathsf{Dec})$	Symmetric encryption scheme
$\mathcal{AE}(\mathsf{KGen},\mathsf{Enc},\mathsf{Dec})$	Asymmetric encryption scheme
$\Sigma (\mathsf{KGen},\mathsf{Sig},\mathsf{Verify})$	Digital signature scheme
$\mathsf{eid}$	Identifier of an enclave (random nonce)
${\mathcal{G}}_{\mathrm{att}}$	Ideal functionality of SGX defined in [40]
$\mathcal{S},\mathcal{C}$	Cleartext and ciphertext of a seed set, respectively
$\mathcal{I}$	Unique index of a fuzzing toolchain
$\mathcal{H}$	Hash function
$m_{\mathrm{TEE}}$	Expected enclave measurement of the fuzzing/evaluation toolchain
${\mathsf{prog}}^{FT}$	Fuzzing toolchain program

summarizes the key notations used in this paper. SGX supports remote attestation, which proves an enclave’s identity to a remote client and establishes a secure communication channel between them. An enclave can generate a proof ${\sigma }_{\mathrm{TEE}}$ of its content using a group signature scheme ${\Sigma }_{\mathrm{TEE}}$; this proof is called a quote. Remote clients can then verify the quote with the help of the Intel Attestation Service (IAS).

2.4. Digital Twins and CPS Security Testing

Digital twins can provide a useful complementary testing environment for CPSs by maintaining a synchronized virtual representation of a physical system and allowing security analysis without directly perturbing the deployed process [41]. They can improve repeatability, support state reconstruction, and reduce the operational risk of injecting malformed inputs into a live control system. However, a digital twin does not by itself protect fuzzing seeds from an untrusted worker, provide an attested execution boundary, or make reward claims and seed value contributions auditable across independent participants. Its security benefit also depends on model fidelity, synchronization quality, and protection of the twin itself. Accordingly, a digital twin could be used as a CPS target or pre-deployment validation layer for PrivFuzz, but it is not a replacement for the confidential execution and settlement mechanisms studied here.

3. Problem Formulation

3.1. System Architecture

As shown in Figure 1, PrivFuzz adopts a distributed collaborative architecture consisting of four types of components: fuzzing outsourcers (FOs), fuzzing participants (FPs), cloud storage (CS), and blockchain network (BN). Their roles are as follows:

• Fuzzing Outsourcer: FOs are developers who outsource fuzzing tasks to accelerate vulnerability discovery for their products. They are responsible for preparing and uploading fuzzing toolchains.
• Fuzzing Participant: FPs are blockchain-network nodes that monetize their computational resources. In PrivFuzz, each FP controls at least one SGX-enabled server for deploying fuzzing toolchains.
• Blockchain Network: BN provides a common interface for FOs to publish fuzzing tasks and for FPs to discover and join tasks through smart contract invocations. BN also stores encrypted fuzzing seeds and maintains consistency between off-chain and on-chain seed data.
• Cloud Storage: CS stores fuzzing toolchains provided by FOs and serves download requests from other entities.

Main Workflow. As shown in Figure 1, PrivFuzz has two main phases: task outsourcing and monetization. In the task outsourcing phase, an FO publishes a fuzzing task, including its reward policy and fuzzing-toolchain file index, through the task management contract (①). This task may target CPS-related software components such as parsers, gateways, protocol handlers, or control-support services. FPs then join the task through smart contract invocations, provide the fuzzing toolchain to a fuzzing enclave, and start fuzzing (②). In the monetization phase, the fuzzing enclave interacts with an evaluation enclave to generate a publicly verifiable work value proof, which is then submitted to the monetization contract (③–④). The monetization contract transparently determines the reward according to the work value proof and transfers the reward to the FP (⑤). Section 4 presents the detailed design of these two phases.

The architecture is intended to support multiple deployment layers rather than require every IoT sensor or actuator to run the complete prototype. A lightweight device may remain a target or data source, while an edge gateway, fog node, or cloud worker runs the SGX-enabled fuzzing and evaluation toolchain.

3.2. Threat Model

In our threat model, cloud storage is honest-but-curious: it correctly stores and returns data but may try to infer sensitive information from its observations and background knowledge. FOs and FPs are untrusted and may deviate from the protocol to maximize their own interests. We introduce two active adversaries ${\mathcal{A}}_{FO}$ and ${\mathcal{A}}_{FP}$ in our model. The goal of ${\mathcal{A}}_{FO}$ is to obtain valuable seeds discovered by FPs without providing the corresponding rewards. The goal of ${\mathcal{A}}_{FP}$ is to obtain the plaintext of valuable fuzzing seeds or receive rewards from FOs without providing the corresponding seeds. The capabilities of ${\mathcal{A}}_{FO}$ are itemized as follows:

• ${\mathcal{A}}_{FO}$ can compromise some blockchain nodes to reject a valid seed value proof, but cannot control enough nodes to break consensus.
• ${\mathcal{A}}_{FO}$ may compromise FOs and interact with cloud storage or FPs to obtain fuzzing seeds without providing the corresponding rewards.

The capabilities of ${\mathcal{A}}_{FP}$ are itemized as follows:

• ${\mathcal{A}}_{FP}$ can compromise some blockchain nodes and attempt to forge value proofs, but cannot control enough nodes to break consensus.
• ${\mathcal{A}}_{FP}$ can compromise cloud storage and attempt to infer unencrypted fuzzing seeds.
• ${\mathcal{A}}_{FP}$ may have full control over the operating system, applications, and memory outside the enclave on FP machines, and may attempt to extract seeds from the enclave.

Our security assumptions are as follows:

• We assume that SGX enclaves preserve the confidentiality of their contents under a no-side-channel model and that the secure channel established after remote attestation is reliable.
• We assume that the implementation of blockchain clients, smart contracts, and the fuzzing toolchains (except the target program) are free of software vulnerabilities.
• We assume that the fuzzing toolchain and evaluation enclave are auditable artifacts: their source code, build configuration, and enclave measurement can be checked by FPs, auditors, or an on-chain allowlist before a task is joined. This assumption is necessary because an enclave protects execution from the host but cannot make malicious enclave code benign.
• We assume that malicious blockchain nodes do not control enough voting power or computational power to disrupt distributed consensus.

The scope of visible information under this threat model is summarized in

Table 3. Information exposed to each entity under the threat model.

Entity	Visible Information	Protected Information
FO	Task state, registered FPs, accepted value proofs, and encrypted seed submissions	Seeds discovered by FPs before valid monetization and settlement
FP	Its own local execution metadata, encrypted global seed corpus, task policy, and public chain state	Plaintext seeds generated by other FPs and seed decryption keys outside the enclave
CS	Toolchain files, file indexes, object sizes, and access timing	Plaintext fuzzing seeds and enclave-internal coverage/crash state
BN	Task metadata, participant identifiers, encrypted seeds, value proofs, and reward transfers	Plaintext seed contents and enclave-local mutation state
Host OS	Enclave creation, I/O sizes, timing, and non-enclave memory	Enclave memory, seed keys, plaintext seeds, and value evaluation state

. The table distinguishes metadata exposure from seed exposure: PrivFuzz does not hide the existence of a fuzzing task, the identity of registered participants, synchronization timing, or the size of encrypted submissions. Instead, it aims to prevent parties outside attested enclaves from learning the plaintext contents of valuable seeds before the intended disclosure process.

This threat model does not cover microarchitectural side-channel attacks against SGX, rollback attacks not prevented by the underlying blockchain state, denial-of-service attacks, bugs in enclave code or smart contracts, or intentionally malicious toolchains whose measurements are not audited before deployment. These attacks are important in deployment, but they require defenses orthogonal to the protocol-level confidentiality and fairness mechanisms studied in this paper.

The blockchain layer also creates deployment risks. Task identifiers, participant activity, ciphertext sizes, synchronization timing, accepted value proofs, and reward transfers remain observable metadata; ledger immutability can make correction and key revocation difficult; smart contract or chain-client bugs can affect settlement; consensus and ordering services can become availability bottlenecks; and permissioned-network governance determines which organizations can operate validating nodes. The prototype mitigates part of this exposure by storing seed contents as ciphertext and using Hyperledger Fabric rather than a public permissionless chain, but it does not eliminate metadata leakage, denial of service, key-management failures, or governance risk.

3.3. Design Goals

Our goal is to create a confidential and fair fuzzing outsourcing framework that enables FOs, including CPS software developers and operators, to use the computational resources provided by FPs to accelerate vulnerability discovery while keeping valuable seeds confidential. FPs earn rewards by submitting seeds discovered during fuzzing. Thus, PrivFuzz should be designed to achieve the following security goals:

• Confidentiality. Fuzzing seeds should not be obtained by any untrusted parties.
• Fairness. PrivFuzz should ensure that FPs receive corresponding rewards after submitting valuable seeds, and that seed values are publicly verifiable and cannot be forged.
• Efficiency. Since distributed fuzzing aims to improve fuzzing efficiency, PrivFuzz should increase explored code coverage as more computational resources participate, within the evaluated synchronization settings.

4. Materials and Methods: PrivFuzz Design

This section presents the detailed design of the task outsourcing stage and the monetization stage.

4.1. Task Outsourcing Stage

The task outsourcing stage covers the publication of and participation in confidential fuzzing tasks. Specifically, this stage consists of three phases: outsourcing preparation, on-chain fuzzing outsourcing, and off-chain confidential fuzzing.

4.1.1. Outsourcing Preparation

To outsource a fuzzing task, an FO prepares a fuzzing toolchain that provides the intended fuzzing functionality. The fuzzing toolchain includes the target program, a fuzzer, an in-memory seed management module, and a work evaluation program. These programs are implemented and compiled according to SGX programming practices. The seed management module decrypts, manages, and re-encrypts fuzzing seeds in enclave memory, avoiding frequent OCalls. The FO also prepares a reward policy that specifies how participating nodes are rewarded for their contributions. Section 4.2 introduces the reward policy in detail. To make remote attestation meaningful when the FO is not fully trusted, the task descriptor should bind the toolchain file index to an enclave measurement and, in deployment, to an auditable source/build configuration or allowlist entry. FPs can then reject tasks whose measurements do not match the expected fuzzing and evaluation logic.

To improve blockchain scalability and reduce storage overhead on blockchain nodes, the FO uploads the fuzzing toolchain to cloud storage and stores only descriptive information, such as the file index, enclave measurement, and reward policy, on the blockchain.

4.1.2. On-Chain Fuzzing Outsourcing

In PrivFuzz, fuzzing task outsourcing is realized through invocations of the task management smart contract (TM-Contract). Algorithm 1 shows the pseudocode of TM-Contract, which consists of four functions: RegisterTask(), JoinTask(), QuitTask(), and RevokeTask(). It is presented as Algorithm 1, and the corresponding work-settlement procedure below is presented as Algorithm 2.

• RegisterTask(): An FO invokes RegisterTask() with the unique fuzzing-toolchain file index $\mathcal{I}$, expected enclave measurement $m_{\mathrm{TEE}}$, reward policy $policy$, and encrypted initial seed set $\mathcal{C}$ to register a fuzzing task.
• JoinTask(): After finding a fuzzing task of interest, an FP invokes JoinTask() with $taskid$ to participate in the task. If $taskid$ is valid, the contract returns a participant identifier $pid$; otherwise, the request is rejected.
• QuitTask(): An FP invokes QuitTask() with $taskid$ to quit the fuzzing task.
• RevokeTask(): An FO invokes RevokeTask() with $taskid$ to revoke a fuzzing task and withdraw all tokens locked in the work monetization contract.

Algorithm 1: Task Management Smart Contract

Algorithm 2: Work Monetization Smart Contract

In this phase, an FO invokes RegisterTask() to register a fuzzing task, and an FP invokes JoinTask() to obtain a valid participant identifier $pid$. The FP then sends the toolchain file index $\mathcal{I}$ to cloud storage to retrieve the toolchain program ${\mathsf{prog}}^{\mathrm{FT}}$ and downloads the encrypted seed set $\mathcal{C}$ from the blockchain. Finally, the FP provisions ${\mathsf{prog}}^{\mathrm{FT}}$ to SGX enclaves and enters the off-chain confidential fuzzing phase.

4.1.3. Off-Chain Confidential Fuzzing

PrivFuzz enters the off-chain confidential fuzzing stage after the FP obtains $pid$. In this stage, the FP provisions ${\mathsf{prog}}^{\mathrm{FT}}$ and the encrypted seed set $\mathcal{C}$ to SGX enclaves to perform confidential fuzzing. This stage includes the following three steps:

• Loading of fuzzing toolchains. The FP loads the fuzzing toolchain ${\mathsf{prog}}^{\mathrm{FT}}$ into the enclave and obtains the enclave instance identity $\mathsf{eid}$. The FP checks the attested measurement of $\mathsf{eid}$ against the task measurement $m_{\mathrm{TEE}}$ before accepting the toolchain. To minimize OCall overhead, PrivFuzz uses an in-memory seed management module to keep the seed set and coverage map inside the enclave. When the seed set must be updated, the management module synchronizes with the blockchain. Ultimately, the management module retains the seeds that maximize code coverage. To enable multi-processing, the enclave program is built using the Occlum libOS [30], which provides a multi-domain Software Fault Isolation (SFI) scheme to isolate processes. The FP then inputs $pid$ and its digital signature $\Sigma .\mathsf{Sig}(s{k}_{FP},pid)$ to $\mathsf{eid}$. The management module verifies the authenticity of $pid$ and checks whether it is consistent with the on-chain record. If $pid$ is valid, the management module waits for the seed key k from the FO.
• Key Provision. The FO uses remote attestation to verify the execution integrity and authenticity of the fuzzing enclave $\mathsf{eid}$ and provides the seed key k to it through the secure channel. The seed management module then uses k to decrypt $\mathcal{C}$.
• Confidential Fuzzing. After $\mathcal{C}$ is decrypted in the enclave, the seed management module informs the fuzzer to start. During fuzzing, the fuzzer and target program continuously exchange data through pipes. Specifically, the fuzzer generates inputs and passes them to the target program for execution, while the target program returns feedback to the fuzzer (e.g., coverage feedback and crashes). When interesting seeds are discovered (e.g., seeds that expand code coverage) or after a fixed time interval, the seed management module encrypts the seeds and delivers them to the work evaluation enclave to generate value proofs before entering the monetization stage.

4.2. Monetization Stage

The monetization stage is responsible for fairly settling the work performed by FPs for a fuzzing task during a period of time.

In this process, the main challenge is enabling blockchain nodes to reach consensus on each FP’s contribution without learning plaintext seeds. To address this challenge, we devise a TEE-based work evaluation mechanism that generates publicly verifiable value proofs. According to these proofs, an FP can obtain transparent compensation for work performed during a given period through the monetization smart contract.

4.2.1. Work Evaluation

In PrivFuzz, the reward of a node is calculated from three types of contributions: (i) CPU resource consumption, (ii) globally new code coverage, and (iii) previously unseen crashes. A reward policy is represented as

$$policy=(r_{\mathrm{cpu}},r_{\mathrm{cov}},r_{\mathrm{crash}},B),$$

(1)

where $r_{\mathrm{cpu}}$, $r_{\mathrm{cov}}$, and $r_{\mathrm{crash}}$ are the unit rewards for the three contribution types, and B is the remaining task budget locked in the monetization contract. Equation (1) defines the policy fields. For an FP with a verified work proof $\mathsf{workproof}$, the contract computes

$$reward=min(B,r_{\mathrm{cpu}}{q}_{\mathrm{cpu}}+r_{\mathrm{cov}}{q}_{\mathrm{cov}}+r_{\mathrm{crash}}{q}_{\mathrm{crash}}),$$

(2)

where $q_{\mathrm{cpu}}$, $q_{\mathrm{cov}}$, and $q_{\mathrm{crash}}$ are the proof-verified quantities. Equation (2) gives the corresponding capped transfer. The concrete values of the unit rewards are selected by the FO when a task is registered; PrivFuzz specifies how the quantities are measured and verified, rather than imposing a universal pricing policy. We discuss these reward components below.

• CPU resource consumption. The CPU resource consumption reward provides stable benefits to participants and encourages nodes to contribute computational resources. In the simplest case, the fuzzing enclave generates a proof for the fuzzing iterations performed within a time window. The proof includes the task identifier, participant identifier, enclave identity, time window, iteration count, and a digest of the encrypted seed state. PrivFuzz also supports existing TEE-based CPU consumption measurement schemes (e.g., T-Counter [42]) to measure program CPU consumption at a finer granularity.
• New code coverage and crashes. Seeds that expand coverage or trigger crashes are also evaluated inside the enclave. For coverage, the evaluation enclave compares the submitted seed’s coverage bitmap with the current global coverage digest and rewards only edges that are new to the task state. This prevents a participant from repeatedly claiming rewards for the same coverage increase. For crashes, de-duplication is essential to prevent malicious users from repeatedly claiming rewards for the same bug. Currently, PrivFuzz uses AddressSanitizer reports for crash de-duplication. The evaluation enclave derives a crash signature from the sanitizer error type, faulting function, and top stack frames, then checks this signature against the task’s committed crash-signature set. Specifically, an FP loads the corresponding evaluation programs and executes them inside the enclave. The work monetization contract (WM-Contract) only verifies the attested report, the task-state digest, and the signature-set update, avoiding complex on-chain computation.

The resulting $\mathsf{workproof}$ contains $(taskid,pid,\mathsf{eid},q_{\mathrm{cpu}},q_{\mathrm{cov}},q_{\mathrm{crash}},h_{\mathrm{old}},h_{\mathrm{new}},h_{\mathrm{seeds}})$ and an enclave attestation signature over these fields. Here $h_{\mathrm{old}}$ and $h_{\mathrm{new}}$ bind the proof to the previous and updated task states, and $h_{\mathrm{seeds}}$ binds the proof to the encrypted seeds submitted with the transaction. This binding is important for fairness: a proof cannot be reused for a different seed submission, and a submitted encrypted seed batch cannot be rewarded without the corresponding enclave-generated proof.

4.2.2. WM-Contract

To achieve fair trading, the submission of valuable seeds and reward monetization must be atomic; that is, both operations must be completed in a single step. Based on this principle, we design WM-Contract. Algorithm 2 shows its pseudocode. An FP monetizes work performed during a period by invoking the $Monetize\left(\right)$ function in WM-Contract. Based on Town Crier [28], which can provide authenticated responses to a smart contract from an HTTPS-enabled IAS server, WM-Contract verifies the authenticity of the value proof and transparently determines the reward for the submitted work.

4.3. Security Analysis

We analyze PrivFuzz with respect to the design goals in Section 3.2. The analysis focuses on seed confidentiality, fair reward settlement, and resistance to duplicate reward claims. Throughout this section, $\lambda$ denotes the security parameter, $\mathsf{negl}(·)$ denotes a negligible function, and all adversaries are probabilistic polynomial-time (PPT) machines.

4.3.1. Cryptographic and System Model

PrivFuzz uses the primitives listed in Table 2: a symmetric encryption scheme $\mathcal{SE}(\mathsf{KGen},\mathsf{Enc},\mathsf{Dec})$, an asymmetric encryption scheme $\mathcal{AE}(\mathsf{KGen},\mathsf{Enc},\mathsf{Dec})$, a digital signature scheme $\Sigma (\mathsf{KGen},\mathsf{Sig},\mathsf{Verify})$, and a collision-resistant hash function $\mathcal{H}:{\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$. We assume that $\mathcal{SE}$ is IND-CPA secure, $\mathcal{AE}$ is IND-CCA secure, $\Sigma$ is existentially unforgeable under chosen-message attacks, and $\mathcal{H}$ is collision-resistant.

As in the threat model, the SGX enclave is represented by the attested execution functionality ${\mathcal{G}}_{\mathrm{att}}$. On input (“install”, $\mathsf{prog}$), ${\mathcal{G}}_{\mathrm{att}}$ creates an enclave with identity $\mathsf{eid}$. On input (“resume”, $\mathsf{eid},\mathsf{inp}$), it executes the installed program and returns an output together with a publicly verifiable attestation quote. We use this abstraction only for the protocol-level argument: enclave state and inputs are hidden from parties outside the enclave except through explicit outputs, and valid quotes cannot be forged without breaking the SGX attestation mechanism. The secure channel established after remote attestation is modeled as an authenticated confidential channel.

A PrivFuzz instance consists of an FO, a set of FPs, CS, and BN. BN maintains an append-only task state through its smart contracts. The consensus protocol remains safe and lives as long as the corrupted blockchain nodes stay below the consensus threshold stated in Section 3.2.

Assumption 1

(Trust boundary). The following conditions hold except with negligible probability: (i) SGX enclaves preserve confidentiality and integrity of enclave state under a no-side-channel model, and the attested secure channel is confidential and authenticated; (ii) the implementations of $\mathcal{SE}$, $\mathcal{AE}$, Σ, $\mathcal{H}$, the smart contracts, and the audited fuzzing/evaluation toolchain except the target program are correct; (iii) the toolchain source, build configuration, and enclave measurement correspond to an audited or allowlisted artifact; and (iv) corrupted blockchain nodes do not control enough voting or computational power to violate BN consensus.

We consider the two adversaries defined in Section 3.2. The FO-side adversary ${\mathcal{A}}_{FO}$ controls a malicious FO and a sub-threshold set of blockchain nodes, and tries to obtain valuable seeds without paying the corresponding rewards. The FP-side adversary ${\mathcal{A}}_{FP}$ controls malicious FPs, may compromise CS and non-enclave host software, and controls a sub-threshold set of blockchain nodes. Its goals are to learn plaintext seeds generated by honest participants or to receive rewards without submitting corresponding useful work. Neither adversary is allowed to break SGX attestation, extract enclave memory directly, or violate BN consensus.

4.3.2. Seed Confidentiality

Seed confidentiality requires that parties outside attested enclaves learn nothing about plaintext seed contents beyond the metadata deliberately exposed by PrivFuzz, such as task existence, participant identities, ciphertext lengths, synchronization timing, value proofs, and reward transfers.

Definition 1

(Seed indistinguishability). Let $\mathcal{A}={\mathcal{A}}_{FP}$ be a confidentiality adversary. In experiment ${\mathbf{Exp}}_{PrivFuzz,\mathcal{A}}^{\mathsf{conf}}\left(\lambda \right)$, the challenger initializes a PrivFuzz task and gives $\mathcal{A}$ control over CS, non-enclave host software on corrupted FP machines, and a sub-threshold set of blockchain nodes. The adversary outputs two seed sets ${\mathcal{S}}_0$ and ${\mathcal{S}}_1$ with the same number of seeds and the same per-seed lengths. The challenger samples $b\leftarrow \{0,1\}$, encrypts ${\mathcal{S}}_b$ as $\mathcal{C}\leftarrow \mathcal{SE}.\mathsf{Enc}(k,{\mathcal{S}}_b)$, and runs the protocol so that decryption, mutation, evaluation, and re-encryption occur only inside attested enclaves. The adversary observes ciphertexts, quotes, on-chain metadata, and allowed protocol outputs, and then outputs a bit $b^{\prime }$. The advantage of $\mathcal{A}$ is

$${\mathbf{Adv}}_{PrivFuzz,\mathcal{A}}^{\mathsf{conf}}\left(\lambda \right)=\left|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right|.$$

(3)

PrivFuzz provides seed confidentiality if the advantage in Equation (3) is negligible for every PPT $\mathcal{A}$.

Theorem 1

(Seed confidentiality). Under Assumption 1 and the IND-CPA security of $\mathcal{SE}$, PrivFuzz provides seed confidentiality against ${\mathcal{A}}_{FP}$.

Proof. 

We use a sequence of games. Game 0 is the real experiment in Definition 1. Game 1 replaces the real enclave with the ideal functionality ${\mathcal{G}}_{\mathrm{att}}$. By Assumption 1, the adversary cannot distinguish this replacement except by breaking enclave confidentiality or attestation integrity. Game 2 replaces the attested key provisioning channel with an ideal confidential delivery of the seed key k to the enclave, which is indistinguishable unless the secure channel is broken. At this point, every seed value visible to the adversary is either an encryption under a key it never obtains or metadata that is identical for ${\mathcal{S}}_0$ and ${\mathcal{S}}_1$ by construction. Any distinguisher in Game 2 therefore yields an IND-CPA distinguisher against $\mathcal{SE}$ by embedding the encryption challenge as $\mathcal{C}$. Hence the adversary’s advantage is bounded by the sum of the probabilities of breaking SGX confidentiality or attestation, the attested secure channel, and IND-CPA security, which is negligible under the stated assumptions.    □

Remark 1.

The theorem protects seed contents from parties outside attested enclaves. It does not cover SGX microarchitectural side channels, rollback attacks outside the committed BN state, denial-of-service attacks, or implementation bugs in enclave code and smart contracts; these residual assumptions are discussed in Section 6.9.

4.3.3. Fair Reward Settlement

Fairness has two directions. First, an FP should not receive rewards for work it did not perform. Second, an FO should not obtain submitted valuable seeds without paying the corresponding reward. Recall that the work value proof contains

$$\mathsf{workproof}=(taskid,pid,\mathsf{eid},q_{\mathrm{cpu}},q_{\mathrm{cov}},q_{\mathrm{crash}},h_{\mathrm{old}},h_{\mathrm{new}},h_{\mathrm{seeds}},{\sigma }_{\mathrm{TEE}}),$$

(4)

where $h_{\mathrm{seeds}}=\mathcal{H}\left(\mathsf{encseeds}\right)$ binds the proof in Equation (4) to the encrypted seed batch, and $h_{\mathrm{old}}$ and $h_{\mathrm{new}}$ bind it to the previous and updated task states. WM-Contract accepts a monetization transaction only if the attestation signature ${\sigma }_{\mathrm{TEE}}$ is valid, the seed-batch hash matches the submitted $\mathsf{encseeds}$, and $h_{\mathrm{old}}$ equals the current committed task-state digest.

Definition 2

(Worker soundness). Let $\mathcal{A}={\mathcal{A}}_{FP}$. The adversary wins ${\mathbf{Exp}}_{PrivFuzz,\mathcal{A}}^{\mathsf{F}\mathsf{1}}\left(\lambda \right)$ if it produces an accepting $(\mathsf{workproof},\mathsf{encseeds})$ that causes WM-Contract to transfer a reward, while at least one of the following is true: (i) the attestation signature was not produced by an attested evaluation enclave for the claimed task execution; (ii) $h_{\mathrm{seeds}}\ne \mathcal{H}\left(\mathsf{encseeds}\right)$; or (iii) $h_{\mathrm{old}}$ does not match the task state at settlement time. PrivFuzz is worker-sound if this probability is negligible for every PPT $\mathcal{A}$.

Theorem 2

(Worker soundness). Under Assumption 1, the unforgeability of SGX attestation quotes, and the collision resistance of $\mathcal{H}$, PrivFuzz is worker-sound.

Proof. 

For condition (i), an accepting proof whose attestation signature was not produced by the evaluation enclave is a forged SGX quote. This contradicts the attestation integrity assumption. For condition (ii), WM-Contract recomputes $\mathcal{H}\left(\mathsf{encseeds}\right)$ and compares it with the signed $h_{\mathrm{seeds}}$ field. An accepting mismatch would therefore imply either a forged attestation signature or a collision in $\mathcal{H}$. For condition (iii), WM-Contract checks that $h_{\mathrm{old}}$ matches the currently committed task-state digest. Since BN state transitions are append-only under the consensus assumption, a stale or replayed proof is rejected unless the adversary breaks BN consistency. Thus a successful worker-soundness attack would break attestation integrity, hash collision resistance, or BN consensus, all of which are excluded by Assumption 1.    □

Definition 3

(Outsourcer atomicity). Let $\mathcal{A}={\mathcal{A}}_{FO}$. The adversary wins ${\mathbf{Exp}}_{PrivFuzz,\mathcal{A}}^{\mathsf{F}\mathsf{2}}\left(\lambda \right)$ if it obtains access to an honest FP’s submitted encrypted seed batch $\mathsf{encseeds}$ while the corresponding reward transfer does not commit on BN. PrivFuzz is outsourcer-atomic if this probability is negligible for every PPT $\mathcal{A}$.

Theorem 3

(Outsourcer atomicity). Under Assumption 1, PrivFuzz is outsourcer-atomic.

Proof. 

In Algorithm 2, WM-Contract verifies $\mathsf{workproof}$ and then executes seed storage and reward transfer within the same contract invocation. Under the BN consensus assumption, this invocation is committed as a single state transition: either both effects are committed or neither is. Therefore, no reachable ledger state exposes a submitted encrypted seed batch to the FO while omitting the matching reward transfer. Decoupling these effects would require violating the atomicity of contract execution or the safety of BN consensus, both of which are outside the adversary’s allowed capabilities.    □

4.3.4. Duplicate-Claim Resistance

Fairness also requires that the same contribution cannot be repeatedly monetized. The task state therefore maintains a committed global coverage digest and a committed set of crash signatures. The evaluation enclave computes $q_{\mathrm{cov}}$ only from coverage edges absent from the current digest, and computes $q_{\mathrm{crash}}$ only from sanitizer-derived crash signatures absent from the committed signature set.

Definition 4

(No duplicate monetization). Let $\mathcal{A}={\mathcal{A}}_{FP}$. The adversary wins ${\mathbf{Exp}}_{PrivFuzz,\mathcal{A}}^{\mathsf{dup}}\left(\lambda \right)$ if it receives a positive $q_{\mathrm{cov}}$ for an already credited coverage edge or a positive $q_{\mathrm{crash}}$ for an already credited crash signature. PrivFuzz is duplicate-resistant if this probability is negligible for every PPT $\mathcal{A}$.

Theorem 4

(Duplicate-claim resistance). Under Assumption 1 and the collision resistance of $\mathcal{H}$, PrivFuzz is duplicate-resistant with respect to the committed coverage digest and crash-signature set.

Proof. 

The evaluation enclave reads the current task-state digest, checks the submitted coverage bitmap and crash signatures against the committed state, and signs the resulting $q_{\mathrm{cov}}$, $q_{\mathrm{crash}}$, $h_{\mathrm{old}}$, and $h_{\mathrm{new}}$ inside $\mathsf{workproof}$. By Theorem 2, a malicious FP cannot forge a proof with inflated novelty counts. By collision resistance, it also cannot equivocate between two different coverage or crash-signature states that share the same committed digest. A re-submission of an already credited edge or crash signature therefore yields zero additional novelty inside the enclave and cannot be increased on chain.    □

Remark 2

(Scope of duplicate-claim resistance). Theorem 4 guarantees uniqueness relative to the committed digest and the sanitizer-derived crash-signature function. It does not establish semantic uniqueness of all underlying vulnerabilities. If the signature function merges distinct bugs or splits one semantic bug into multiple signatures, reward accounting inherits that imprecision.

4.3.5. Economic and Reward-Abuse Considerations

The formal properties above address proof binding, contract atomicity, and repeated claims against the same committed state. They do not by themselves solve all economic attacks against a reward market. First, a participant may perform coverage farming, generating inputs that increase edge coverage without moving the task closer to exploitable or safety-relevant bugs. A concrete deployment policy can cap coverage-only rewards, assign a larger weight to crash-triggering or sanitizer-confirmed behavior, impose per-task and per-participant budgets, and delay high-value payments until a second enclave or human triage confirms the result. These controls are policy options and were not implemented or measured in the current prototype. Second, a Sybil adversary may register many participant identities to split claims or exhaust task budgets. This can be mitigated through identity registration costs, per-identity deposits, per-task budget caps, and slashing rules for invalid or replayed proofs. Third, FO–FP collusion can distort reward accounting; PrivFuzz does not prevent parties from voluntarily transferring rewards among themselves, but the public ledger makes accepted proofs, reward transfers, and task-budget depletion auditable. Finally, sanitizer-derived crash signatures can be manipulated by perturbing stack frames or execution context. Practical deployments should canonicalize stack traces, ignore unstable frames, combine sanitizer class and faulting location with minimized inputs, and optionally require manual or delayed confirmation for high-value crash rewards.

4.3.6. Efficiency Claim and Residual Assumptions

The efficiency goal is empirical rather than cryptographic. PrivFuzz preserves useful corpus reuse by publishing encrypted seed updates that later attested fuzzing enclaves can decrypt and consume. The node-count behavior of this design is characterized in Section 6.4. Accordingly, the efficiency claim is limited to the prototype and workloads tested in this paper.

The above properties hold relative to Assumption 1. They do not cover SGX side-channel attacks, rollback attacks not prevented by committed BN state, denial-of-service attacks, compromised attestation services, bugs in enclave code, smart contracts, blockchain clients, or non-audited fuzzing toolchains, malicious target behavior, or reward-policy manipulation by an FO. These limitations are discussed in Section 6.9.

5. Implementation

Smart Contract. We implement the task management contract and WM-Contract in Go, with 855 software lines of code (SLoCs). Both contracts are deployed on Hyperledger Fabric.

Fuzzing Toolchains. We port AFL to Intel SGX as the fuzzer in the PrivFuzz prototype toolchain and select four open-source projects as evaluation targets: Gpac, Radare2, Chafa, and Libmobi. The separate target-domain sanity check in Appendix A uses native AFL++ outside SGX and is not part of the SGX prototype. Fuzzing seeds are managed inside the enclave and synchronized with the blockchain when the on-chain state is updated.

Work Evaluation Enclave. To evaluate fuzzing seeds provided by FPs, we use afl-cov to generate seed-level coverage information and AddressSanitizer to de-duplicate crash samples.

6. Results and Discussion

6.1. Experiment Setup

We implement a prototype and conduct a series of experiments to evaluate the performance characteristics of PrivFuzz. Our original SGX prototype experiments are carried out on five workstations running Ubuntu 20.04, each equipped with 32 GB RAM and an Intel Xeon E-2176M CPU. These experiments are intended as prototype feasibility measurements rather than a full fuzzing benchmark suite. Following the caution raised by Klees et al. [43], the coverage-over-time results should be interpreted with care because the original prototype data do not include enough repeated trials to support statistical significance testing.

For replication, the recorded prototype setup is as follows. The SGX experiments use five Ubuntu 20.04 workstations, each with 32 GB RAM and an Intel Xeon E-2176M CPU. The node-count study uses five, 10, and 15 participant nodes; the synchronization study uses no synchronization, 30, 60, and 120 min periodic synchronization, and the Fuzzing@Home-style real-time condition. The evaluated targets and command-line arguments are listed in

Table 4. Evaluation targets and discovered bugs.

Project	Seed Type	Arguments	Unique Crashes
Gpac	.mp4	-info file	1
Libmobi	.mobi	-e file	1
Radare2	.exe	-A -q file	4
Chafa	.png	file	3

; the target seed types are also reported there. The current artifact preserves aggregate measurements and figure PDFs but does not preserve a complete per-run seed corpus, and all harness source versions, or a component-isolated ablation log. These missing records are treated as reproducibility limitations rather than filled by inference.

In addition to the prototype campaign, we conducted a dedicated microbenchmark study on a second host (Tencent CVM SA7, 32-vCPU AMD EPYC, 64 GB RAM, Ubuntu 22.04; AFL++ v4.40c, SEAL v4.4.3, MP-SPDZ v0.4.3, a Hyperledger Fabric test network, and Occlum 0.31.0 in SGX simulation mode; all measurements use pinned cores and $n=10$ repetitions). These measurements characterize individual pipeline components, the settlement path, the library-OS software layer, and cryptographic kernel alternatives; a matched four-condition seed-sharing ablation, reported in Section 6.8, adds coverage-level evidence on the same host. Unlike the prototype experiments, which use the five Xeon E-2176M workstations described above, all of these measurements are taken on this second host.

6.2. Bug Findings

Table 4 summarizes the evaluation targets and the bugs discovered during our fuzzing campaigns. We reported all discovered bugs to the corresponding project maintainers. We report the aggregate counts here and avoid disclosing exploit details in the manuscript.

The four targets above are parsing-oriented open-source applications used to evaluate the prototype under realistic software workloads. They are not claimed to be CPS control programs. Appendix A reports a limited native AFL++ sanity check illustrating how industrial protocol parsers relate to this parsing-oriented target class.

6.3. TEE Overhead

To evaluate the overhead introduced by TEEs, we conduct a fuzzing campaign on a single host under two configurations: with and without SGX. We compare the average executions per second under the two configurations. The results are shown in

Table 5. SGX (Software Guard Extensions) overhead on evaluation targets. Exec/s denotes executions per second.

Fuzzing Mode	Radare2	Libmobi	Chafa	Gpac
Exec/sec (No-SGX)	4.03	201.45	48.38	168.13
Exec/sec (SGX)	2.58	112.81	28.63	99.20
Overhead	35.98%	44.00%	40.82%	41.00%

and Figure 2, indicating that the SGX environment introduces approximately 40% performance overhead. The absolute execution rates are lower than highly optimized persistent-mode fuzzing campaigns because the prototype runs targets through the SGX/libOS execution path and preserves the work evaluation pipeline used by PrivFuzz. Therefore, these numbers are most useful for comparing the two prototype configurations, not for ranking the underlying target programs against native fuzzing benchmarks.

6.4. Scalability

To study how the prototype behaves as more participant nodes are added, we set up three distributed fuzzing environments with different numbers of participant nodes (five, 10, and 15 nodes) and evaluate their performance. The results are shown in Figure 3. We observe a non-decreasing trend in explored coverage as node count grows under the tested settings. Because the original experiment was not repeated enough times for confidence intervals or significance tests, we report this as an empirical observation rather than a statistical scalability claim.

6.5. Synchronization Interval

To understand the performance impact of blockchain confirmation latency, we evaluate the fuzzing performance of 10 nodes under five seed synchronization settings: no synchronization, synchronization every 30 min, synchronization every 60 min, synchronization every 120 min, and real-time synchronization (Fuzzing@Home [1]). The results are shown in Figure 4. In these prototype runs, real-time synchronization performs best, while the gap to periodic synchronization is small. We therefore treat periodic synchronization as a practical engineering choice under the tested settings, not as a general optimum.

Industrial protocol parsers such as Modbus and OPC UA belong to the same parsing-oriented target class as the programs studied above. Appendix A reports a small native AFL++ sanity check showing that such targets can be instrumented and fuzzed, while also documenting why this check is not an end-to-end PrivFuzz evaluation.

6.6. Component-Level Microbenchmarks

To decompose the end-to-end prototype behavior, we characterize each privacy-preserving component of the per-item pipeline in isolation on the microbenchmark host: (i) seed encryption, an AES-256-GCM encapsulation of every exported seed; (ii) coverage evaluation, the bitmap novelty check that admits a seed into the shared pool; (iii) the work proof, the SHA-256 digest computation over the proof fields of Section 4.2.1 (publisher binding and unforgeability come from the enclave attestation signature over the proof, not from the digest itself); and (iv) the chain commit, the batched settlement of accepted seeds (batch size 32). Each configuration runs 5000 iterations per run for $n=10$ runs, both against a mock chain adapter (pure software, an upper bound on settlement throughput) and against the real Hyperledger Fabric test network.

Table 6. Pipeline throughput under component ablation (items/s, median of $n=10$ runs). Single-component rows are relative to the same pass’s base; removal rows are relative to full. Mock rows bound the software cost; Fabric rows include a real commit to the test network. ^† Removing the work proof disables the commit by construction—the proof is the settled artifact—so this mode is ledger-free in both passes.

Mode	Mock	$\Delta$	Fabric
base (no component)	29,420.3	—	29,701.4
+ seed encryption	26,008.1	$-11.6\%$	26,298.4
+ work proof	26,798.3	$-8.9\%$	27,060.5
+ coverage evaluation	3738.5	$-87.3\%$	3743.7
+ chain commit	22,024.3	$-25.1\%$	15.8
full pipeline	3457.4	—	15.7
full w/o seed	3514.7	$+1.7\%$	15.7
full w/o proof †	3674.3	$+6.3\%$	3680.5
full w/o evaluation	18,755.1	$+442.4\%$	15.8
full w/o chain	3629.4	$+5.0\%$	3635.7

reports the resulting medians and Figure 5 the per-component latencies.

Three observations follow. (1) Coverage evaluation dominates the software budget. Enabled alone it costs $-87.3\%$ of base throughput, and removing it from the full pipeline recovers a $5.4\times$ speed-up; per item, the bitmap novelty kernel costs 233.3 µs, versus 4.4 µs for seed encryption and 3.6 µs for the SHA-256 proof—the kernel is 50–$65\times$ more expensive than either cryptographic operation. The design therefore executes this kernel exactly once per seed inside the TEE and reuses the verdict for every subscriber. (2) Cryptographic hygiene is cheap. Removing seed encryption from the full pipeline recovers only $+1.7\%$ (and the work proof $+6.3\%$, with its commit disabled by construction), so AES-256-GCM encapsulation and the SHA-256 digest can remain enabled unconditionally. (3) Ledger commits are wait-dominated, not compute-dominated. With the Mock adapter a batch of 32 settles in 361.5 µs (11.3 µs/item amortized); on real Fabric the same batch takes 2.03 s (≈63 ms/item).

Figure 6 decomposes 100 consecutive real Fabric commits at client concurrency $c=1$ and $c=8$: endorsement and orderer submission complete in single-digit milliseconds (6.1/8.3 ms and 1.2/1.5 ms medians at $c=1$/$c=8$), and more than 99.5% of the end-to-end latency is the commit wait on the orderer’s 2 s block-cut timeout. Because this wait is asynchronous with respect to the fuzzing loop, throughput scales near-linearly with client concurrency—0.49 tps at $c=1$ versus 3.78 tps at $c=8$, with zero errors and a p95 within 12 ms of the median in both settings. This is precisely the regime in which the batched, asynchronous settlement of PrivFuzz operates: a batch of 32 seeds pays one block-cut wait, and the ledger never sits on the fuzzing critical path.

6.6.1. Library-OS Software Path (SGX Simulation Mode)

To separate the libOS software layer from SGX hardware cost, we pair an Occlum 0.31.0 SGX simulation run (A1) with the identical musl-linked binary executed natively in the same container on the same pinned core (A0), with interleaved repetitions and identical seeds; computational equivalence is verified exactly, as the cumulative novel-edge counts agree bit for bit (478,780 edges on both sides). On the syscall-light base path the libOS costs $1.02\times$ in total time (13,556.6 → 13,316.6 items/s, Figure 7). These numbers characterize the libOS software path in simulation mode only; they are neither SGX hardware overhead nor the cost of enclave isolation, EPC paging, or remote attestation. Consistently, the SGX/No-SGX gap of Table 5 is read as an end-to-end configuration comparison (Section 6.8).

6.6.2. Cost of Cryptographic Kernel Alternatives

PrivFuzz evaluates coverage in plaintext inside the TEE. The same novelty kernel (bitmap AND/OR plus popcount) was re-implemented over SEAL BFV homomorphic encryption (polynomial degree 8192) and two MP-SPDZ two-party protocols (semi2k, spdz2k) at four bitmap sizes, with $n=10$ repetitions each and full plaintext-equivalence verification (all 80 MPC runs reproduce the native new_edges counts exactly).

Table 7. Per-bit cost of the novelty kernel across backends (µs/bit, median of $n=10$ runs).

Backend	4 Kb	16 Kb	64 Kb	512 Kb
native C++	0.0004	0.0004	0.0004	0.0004
SEAL BFV (HE)	13.89	6.87	6.87	6.82
MP-SPDZ semi2k	11.85	10.30	9.33	8.93
MP-SPDZ spdz2k	164.55	139.46	124.45	120.22

and Figure 8 quantify the gap: the native kernel costs a flat 0.0004 µs per bit at every size; SEAL BFV costs 13.9 µs/bit at 4 Kb, amortizing to 6.8 µs/bit at 16 Kb and above; semi2k sits in the same band (8.9–11.9 µs/bit); and spdz2k is another order of magnitude out (120–165 µs/bit)—four to five orders of magnitude above native at every bitmap size. The decomposition shows the gap is structural rather than an implementation artifact: SEAL key generation alone is a constant ≈281 ms per context, homomorphic evaluation grows from 56.9 ms to 3.58 s as the bitmap grows from 4 Kb to 512 Kb, and a single semi2k evaluation at 512 Kb moves 1.65 GB (spdz2k: 28.5 GB) over the network. At fuzzing rates of thousands of executions per second, either alternative would exhaust the budget by itself. HE and MPC therefore serve as conceptual privacy-kernel backends that bound the design space, and end-to-end HE/MPC fuzzing remains future work.

6.7. Settlement-Cost Discussion

The prototype uses Hyperledger Fabric rather than a gas-metered public blockchain, so we do not report Ethereum-style gas costs. The settlement path nevertheless has three main costs: remote attestation for establishing trust in the fuzzing and evaluation enclaves, value-proof verification by WM-Contract, and the confirmation latency of the blockchain transaction that stores encrypted seeds and transfers rewards. The synchronization-interval experiment in Figure 4 indirectly captures the performance effect of delayed seed sharing, but it is not a full throughput benchmark for the chain. A production deployment should measure endorsement latency, ordering-service throughput, transaction confirmation time, and task-specific proof-verification cost under the chosen blockchain configuration. The commit microbenchmark of Section 6.6 (Figure 6) now supplies exactly these quantities for our test configuration: endorsement 6.1–8.3 ms, submission 1.2–1.6 ms, and a block-cut-dominated commit wait of ≈2 s, with zero errors across the 7800 commits of the full commit study (Figure 6 instruments a 100-commit consecutive subset at each of the two extreme concurrencies) and near-linear throughput scaling from $c=1$ to $c=8$.

6.8. Component-Level Evidence and Ablation Scope

The SGX comparison in Table 5 is not a component-isolated ablation. The No-SGX configuration executes the native pipeline, whereas the SGX configuration includes the Occlum libOS layer, in-enclave seed management, enclave transitions, and the work evaluation path. The reported 35.98–44.00% difference therefore measures the end-to-end configuration gap for this prototype and should not be interpreted as the overhead of SGX hardware alone. The microbenchmark suite of Section 6.6 supplies the component-isolated counterpart of this gap: the per-component pipeline ablation (Table 6), the settlement-path decomposition (Figure 6), and the libOS software-path characterization (Figure 7) together account for the software side of the gap, while enclave transitions and EPC paging remain unmeasured because they require SGX hardware mode.

The remaining causal question—whether encrypted seed reuse itself improves coverage—is addressed by a dedicated matched campaign: four conditions (independent baselines with no sharing; plaintext sharing; encrypted sharing; and encrypted sharing with batched Fabric settlement) on libmobi and radare2, with $n=10$ repetitions per condition, 2 h per run, paired AFL++ seeds, randomized condition order within each repetition, and disjoint pinned cores per lane.

Table 8. Seed-sharing ablation campaign: final edge coverage, paired difference against the independent baseline S0, and $t_{90}$ saturation time (2 h per run; $n=10$ paired repetitions per condition; four concurrent lanes on disjoint pinned cores; medians with IQR; p from two-sided Wilcoxon signed-rank on paired repetitions).

Target	Condition	Final Edges (IQR)	$\Delta$ vs. S0	p	${\mathit{t}}_{90}$ (s)
libmobi	S0 independent	2303.0 (20.8)	—	—	300.3
	S1 plaintext	2350.5 (35.5)	$+2.28\%$	0.0039	330.3
	S2 encrypted	2360.5 (28.0)	$+2.44\%$	0.0020	300.3
	S3 encrypted + Fabric	2367.0 (30.5)	$+3.06\%$	0.0020	330.3
radare2	S0 independent	82,430.5 (999.0)	—	—	270.3
	S1 plaintext	82,158.5 (662.5)	$-0.16\%$	0.28	270.3
	S2 encrypted	82,135.0 (1348.3)	$-0.30\%$	0.38	270.3
	S3 encrypted + Fabric	82,241.0 (1029.0)	$-0.08\%$	0.70	300.3

reports the outcome. On libmobi, sharing improves coverage under every privacy configuration: final edge counts rise from 2303.0 (IQR 20.8) in the independent baseline to 2350.5, 2360.5, and 2367.0 under plaintext, encrypted, and encrypted-plus-Fabric sharing ($+2.28\%$, $+2.44\%$, and $+3.06\%$; two-sided Wilcoxon signed-rank over the $n=10$ paired repetitions, $p=0.0039$, $0.0020$, $0.0020$), with the same separation in coverage AUC ($p=0.0020$ each) and in edges per million executions ($+1.44$, $+1.59$, $+2.84$; all $p\le 0.020$), so the gain is not a pacing artifact. Under the evaluated two-hour, ten-pair configuration, we observed no statistically detectable degradation from the privacy mechanisms: encryption adds $+0.7\%$ over plaintext sharing ($p=0.39$) and batched Fabric settlement adds $+0.6\%$ over encrypted sharing ($p=0.12$), and $t_{90}$ saturation times likewise do not differ significantly (medians 300–330 s). On radare2 the campaign lands in a saturated regime—the instrumented target holds approximately 82,000 edges at only $1.8\times {10}^5$ executions per run within the 2 h budget (libmobi executes $4.0\times {10}^7$)—and no comparison separates from noise: S1/S2/S3 versus S0 differ by at most $0.30\%$ ($p=0.28$, $0.38$, $0.70$), plaintext-versus-encrypted gives $p=0.85$, and encrypted-versus-settled $p=0.77$. Read together, the two targets bound the answer: where coverage headroom exists, encrypted seed reuse improves coverage by the same margin as plaintext sharing, and neither AES-256-GCM encapsulation nor batched Fabric settlement removes that gain; where the target is saturated, sharing neither helps nor hurts. Every S3 run settled its batches on the real Fabric test network with zero ledger errors (one to two commits per run), confirming that settlement stayed off the fuzzing critical path throughout. The campaign is coverage-level evidence measured natively (AFL++, non-SGX) on the same second host as the microbenchmarks of Section 6.6.

The existing node-count and synchronization experiments are read as workflow-level observations rather than causal component attribution.

6.9. Limitations

PrivFuzz inherits the security assumptions and deployment constraints of TEEs. In particular, our analysis is under a no-side-channel SGX model and excludes rollback attacks not prevented by committed blockchain state, denial-of-service attacks, compromised attestation services, and vulnerabilities in enclave code, smart contracts, blockchain clients, or fuzzing toolchains other than the target program. Fuzzing is a side-channel-sensitive workload because coverage bitmap updates, crash behavior, and seed-dependent control flow can leak information through memory-access and timing patterns. Oblivious coverage-map updates, padding, batching, and constant-shape reports may reduce leakage, but they would add substantial overhead and are left to future work. The toolchain assumption must also be enforced through reproducible builds, public audit, and enclave measurement allowlists; otherwise, a malicious FO could intentionally place seed-leaking logic inside the enclave program.

The original SGX prototype focuses on four open-source parsing-oriented targets, so the measured overhead and node-count trends should be interpreted as prototype observations rather than universal bounds for all CPS software. The CPS-facing protocol-parser sanity checks in Appendix A are non-SGX experiments and therefore do not establish end-to-end PrivFuzz performance, SGX overhead, value-proof cost, or settlement behavior on industrial protocol parsers. Their low coverage also indicates that the minimal harnesses, seed corpora, and lack of protocol dictionaries were insufficient for a mature CPS fuzzing benchmark. The original coverage experiments also do not include the number of repeated runs, confidence intervals, or significance tests recommended for full fuzzing evaluations [43]. The reward policy used by an FO may need to be tuned for different vulnerability classes and disclosure workflows, and the sanitizer-based crash signature may merge distinct bugs or split one semantic bug into multiple signatures. Finally, PrivFuzz protects seed contents, but it does not hide metadata such as task publication time, participant activity, ciphertext sizes, or reward-transfer amounts.

Additional deployment limitations concern trust concentration. The permissioned blockchain reduces open-membership risk but introduces governance assumptions about validator admission and key revocation. Finally, the component-level microbenchmarks of Section 6.6 and the seed-sharing campaign of Section 6.8 are measured on the second host described in Section 6.1 and cover the software pipeline, the settlement path, the libOS layer, cryptographic kernel alternatives, and the coverage-level effect of encrypted seed reuse; hardware-mode SGX enclave transitions and end-to-end digital-twin integration remain future work rather than results of this manuscript.

7. Conclusions

In this paper, we presented PrivFuzz, a confidential collaborative fuzzing framework motivated by outsourced fuzzing of CPS-facing parsing components on untrusted participants. PrivFuzz leverages TEEs for confidential fuzzing and smart contracts for fair work monetization, and its value-proof mechanism makes seed values publicly verifiable without disclosing plaintext seeds. Under the stated no-side-channel SGX, audited-toolchain, and consensus assumptions, our game-based analysis supports seed confidentiality, worker soundness, outsourcer atomicity, and duplicate-claim resistance. Our implementation on Hyperledger Fabric and evaluation on four open-source projects show that the protocol can be instantiated in a working prototype and can support real bug discovery while protecting valuable seeds. Component-isolated microbenchmarks—pipeline ablation, settlement decomposition, libOS software path, and direct HE/MPC kernel comparisons—together with a matched seed-sharing ablation further quantify the software costs of the design and the coverage-level benefit of encrypted seed reuse. Hardware-mode SGX characterization and end-to-end digital-twin integration remain future work.