TrustDefender: Trust & Deepfake Detection

• TrustDefender is a research label covering both a decentralized attestation ecosystem for content credibility and a privacy-preserving deepfake detection framework in XR.
• TRUSTD leverages blockchain, collective signatures, and self-sovereign identities to enable transparent, auditable content verification, while TrustDefender-XR combines a lightweight CNN with zero-knowledge proofs for secure media validation.
• The systems address challenges from misinformation and synthetic media by balancing computational constraints, trade-offs in latency, and limitations in on-chain revocation mechanisms.

Searching arXiv for the cited TrustDefender-related papers and the related 2022 paper. arXiv search query: (Pogonin et al., 2022) OR (Jaroucheh et al., 2020) OR (Islam et al., 22 Jul 2025) TrustDefender denotes a line of work on digital-content trust that appears in at least two distinct forms in the arXiv literature. In 2020, TRUSTD—explicitly described as TrustDefender—was proposed as a blockchain and collective signature ecosystem intended to help content creators obtain community-backed attestations and to help readers judge the credibility and correctness of digital content through a personalized trust policy (Jaroucheh et al., 2020). In 2025, TrustDefender-XR was introduced as a two-stage framework for deepfake detection in extended reality (XR), combining a lightweight convolutional neural network (CNN) with a succinct zero-knowledge proof (ZKP) protocol so that detection results can be validated without disclosing raw user data (Islam et al., 22 Jul 2025). The term should be distinguished from MemoryRanger, which uses hypervisor-level “trust labels” to protect Microsoft Defender kernel structures and is therefore adjacent only in vocabulary rather than in application domain (Pogonin et al., 2022).

1. Naming, scope, and problem domain

The principal ambiguity surrounding TrustDefender is terminological. In one usage, it names an ecosystem for combating misinformation and disinformation on social media platforms and the Web through decentralized attestations, immutable provenance, and user-centric trust computation. In another, it names a privacy-preserving deepfake-detection stack for XR streams. Both systems address the problem of assessing whether digital content should be believed, but they do so at different layers: TRUSTD centers on provenance, community approval, and policy-based credibility judgments, whereas TrustDefender-XR centers on frame-level synthetic-media detection and cryptographic validation of inference outputs (Jaroucheh et al., 2020).

System	Primary objective	Core mechanisms
TRUSTD (TrustDefender)	Help users judge content credibility and correctness	Blockchain ledger, collective signatures, DIDs, personalized trust policy
TrustDefender-XR	Detect deepfake imagery in real-time XR streams without disclosing raw user data	Lightweight CNN, EZKL-based SNARK, succinct proof verification
MemoryRanger	Prevent blinding Windows AV by protecting kernel structures	Tiny Type-1 hypervisor, “trust labels,” per-driver enclaves, EPT protections

This separation matters because the two TrustDefender systems are not variants of a single implementation. They solve related trust problems under different threat models, different computational constraints, and different security assumptions. A plausible implication is that “TrustDefender” is best understood as a recurring research label attached to mechanisms for trustworthy digital-content assessment rather than as a single standardized framework.

2. TRUSTD as a decentralized attestation ecosystem

TRUSTD is motivated by the spread of fake content, repeated exposure and “illusory truth” effects, filter bubbles that narrow each user’s viewpoint, lack of transparency about who approved or originated a story, and the absence of user-centric tools to judge credibility. Its stated goals are to empower end users to assess content correctness based on a personalized “trust policy,” provide traceability of origin and approval via an immutable ledger, offer non-repudiable, revocable attestations from community “Appraiser Actors” (AAs), and remain fully decentralized and open, with self-sovereign identities (DIDs) (Jaroucheh et al., 2020).

The architecture comprises five roles. A Content Creator (CC) publishes a digital artifact such as text, image, or video and solicits attestations. Appraiser Actors are human or organizational validators who “sign off” on correctness. A Collective-Signature Service runs a Schnorr-style threshold or aggregate signature protocol, specifically CoSi. A Blockchain Ledger stores a mapping from content-hash to collective signature and metadata. A User or Content Reader retrieves on-chain attestations and applies a local trust policy to compute content credibility.

The blockchain design is intentionally non-prescriptive. The system does not mandate a single DLT and instead envisions “an open, decentralized platform.” The description allows either a public, permissionless chain such as Ethereum or Cardano/Ouroboros, or a permissioned or consortium chain such as Hyperledger Fabric with PBFT. The candidate consensus mechanisms likewise remain open and include proof-of-work, proof-of-stake, and BFT algorithms. In the PoS example, a block proposer $i$ is selected with probability

$p_i = \frac{stake_i}{\sum_j stake_j}.$

The on-chain transaction record includes at least the content hash, the DID of the content creator, the list of participating AA DIDs, the collective signature, a timestamp, and optional policy references. Block linkage follows a standard hash-chain structure:

$$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$

This establishes provenance and auditability rather than direct semantic truth. That distinction is central: the system records who attested, when, and under what identity, while leaving the ultimate trust judgment to the reader’s policy.

3. Collective signatures, verification, and ledger semantics

The cryptographic core of TRUSTD is a non-interactive Schnorr-style aggregate signature, CoSi, over an elliptic curve of order $L$ with generator $B$. Each Appraiser Actor $AA_i$ has keypair $(a_i, A_i = a_i B)$, and the group public key is

$A = \sum_{i\in P} A_i.$

For a message

$M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$

the protocol proceeds through commitment, aggregation, challenge, response, and final assembly. Each signer chooses random $r_i \in [1, L-1]$ and computes

$p_i = \frac{stake_i}{\sum_j stake_j}.$0

The CC aggregates received commitments into

$p_i = \frac{stake_i}{\sum_j stake_j}.$1

derives the challenge

$p_i = \frac{stake_i}{\sum_j stake_j}.$2

and each participating signer returns

$p_i = \frac{stake_i}{\sum_j stake_j}.$3

The final scalar is

$p_i = \frac{stake_i}{\sum_j stake_j}.$4

and the signature is represented as

$p_i = \frac{stake_i}{\sum_j stake_j}.$5

where $p_i = \frac{stake_i}{\sum_j stake_j}.$6 is a bitmask of absent signers. Verification checks

$p_i = \frac{stake_i}{\sum_j stake_j}.$7

These equations instantiate the paper’s requirement that approval be both collective and non-repudiable (Jaroucheh et al., 2020).

The ledger model binds those signatures to content hashes and metadata. A transaction records $p_i = \frac{stake_i}{\sum_j stake_j}.$8 together with the relevant DIDs and the collective signature. The block header contains $p_i = \frac{stake_i}{\sum_j stake_j}.$9, $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$0, and $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$1, with

$$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$2

In a BFT setting, the stated safety condition is $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$3.

The practical significance of this design is that TRUSTD does not require readers to trust a centralized platform’s moderation pipeline. Instead, readers can retrieve attestations from the ledger and evaluate them locally. This suggests a separation between attestation production and trust consumption: the community signs, the ledger preserves, and the reader decides.

4. Threat model, security claims, and limitations of TRUSTD

The TRUSTD threat model includes dishonest content creators who post false content, malicious or compromised Appraiser Actors provided the subset remains below threshold, Sybil attackers who spin up many AAs, and blockchain adversaries up to the selected consensus fault threshold. Sybil resistance is described as being mitigated by per-AA identity policies based on DIDs, stake, and reputation. For the ledger substrate, the analysis assumes the standard threshold for the chosen consensus, such as $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$4 for PBFT or 50% hashing power for proof-of-work (Jaroucheh et al., 2020).

The paper’s security arguments are explicitly informal. Non-repudiation derives from the binding relation between each signer’s commitment and response together with the immutable ledger. Unforgeability is reduced to solving discrete-log or corrupting at least the required number of honest AAs in CoSi. Censorship resistance follows from the claim that any content creator may write its content hash and signature on an open chain so long as block proposers include the transaction. Revocation is only partial: an AA may “retrigger” signing to produce a new signature, but older on-chain attestations remain as audit history.

Several limitations are stated directly. CoSi’s two-round multi-signature can be replaced by the more secure mBCJ scheme. Revocation of on-chain attestations is not yet fully supported, because only new attestations are appended. Single-dimension trust aggregation may misclassify when untrusted AAs are sole signers. Delays may occur if AAs respond slowly or lack incentives. The prototype implementation consisted of a front-end blog built in Django 2.2.7 and a CoSi protocol in Go 1.13.4 using kyber primitives, but no large-scale benchmarks are reported in the paper.

The listed future work is correspondingly concrete: adopt the provably robust mBCJ two-round multisignature, extend the credibility formula to multiple semantic dimensions such as honest or dishonest and ally or enemy, design on-chain revocation or “re-sign” mechanisms, benchmark performance under different consensus regimes and network sizes, and integrate automated ML or DL fake-content detectors as part of user policies rather than as standalone components. A plausible implication is that TRUSTD was conceived less as a finalized deployment blueprint than as an extensible architectural template for decentralized credibility assessment.

5. TrustDefender-XR: lightweight CNN plus succinct zero-knowledge proofs

TrustDefender-XR addresses a narrower but technically sharper problem: detecting deepfake imagery in real-time XR streams under stringent privacy requirements. Its first stage is a lightweight CNN detector. Each raw XR frame is face-aligned and cropped to $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$5 RGB pixels, with standard augmentations including random horizontal flip and brightness or contrast jitter. The backbone is a four-block “conv–norm–pool” network in which each block uses $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$6 convolutions with stride $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$7 and padding $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$8, Leaky ReLU defined by $$h_0 = genesis, \qquad \forall n>0:\; h_n = H(h_{n-1} \,\|\, root_n \,\|\, ts_n).$$9, batch normalization, and $L$0 max-pooling with stride $L$1. After four blocks, the spatial resolution is reduced from $L$2 to $L$3. The classification head flattens the resulting tensor, applies a fully connected layer with $L$4 hidden units and Dropout(0.5) during training, and ends in a single sigmoid output $L$5 with a hard threshold at $L$6 (Islam et al., 22 Jul 2025).

Training uses approximately $L$7 K frames from FaceForensics++ and UADFV with an $L$8 train, validation, and test split. The optimizer is Adam with $L$9, $B$0, and learning rate $B$1. The loss is binary cross-entropy:

$B$2

where $B$3. The mathematical formulation also gives

$B$4

where $B$5 is a small weight-decay term if used. Grid search yielded batch size $B$6, $B$7 epochs, Leaky ReLU, and $B$8 hidden neurons. Reported convergence took approximately $B$9–$AA_i$0 h on $AA_i$1 V100 GPUs, with final validation accuracy near $AA_i$2 and test accuracy near $AA_i$3.

The second stage is an integrated succinct ZKP protocol using a non-interactive SNARK in the CRS model via EZKL. The NP relation is

$AA_i$4

where $AA_i$5 is the arithmetic circuit encoding one forward pass of the CNN, the public input $AA_i$6 includes the network weights and the claimed verdict bit, and the private witness $AA_i$7 includes the $AA_i$8 pixel values and intermediate activations. Setup generates a proving key $AA_i$9 of $(a_i, A_i = a_i B)$0 GB and a verification key $(a_i, A_i = a_i B)$1 of $(a_i, A_i = a_i B)$2 KB. Prove outputs a succinct proof $(a_i, A_i = a_i B)$3 of approximately $(a_i, A_i = a_i B)$4 KB. Verify checks the proof in time $(a_i, A_i = a_i B)$5 and accepts or rejects the one-bit verdict.

The cryptographic layer is described in terms of a security parameter $(a_i, A_i = a_i B)$6, bilinear pairing groups $(a_i, A_i = a_i B)$7 with pairing $(a_i, A_i = a_i B)$8, and a polynomial-commitment scheme such as KZG over a prime field $(a_i, A_i = a_i B)$9. The CRS contains commitments to powers of a secret trapdoor $A = \sum_{i\in P} A_i.$0, and the circuit is reduced to a QAP:

$A = \sum_{i\in P} A_i.$1

The stated guarantees are perfect completeness, adaptive soundness, zero-knowledge, succinctness, and proof-of-knowledge under standard bilinear-group assumptions. In operational terms, the server learns only the final “real” versus “fake” bit; raw frames and intermediate activations do not leave the client.

6. Evaluation, trade-offs, and relation to adjacent defenses

For TrustDefender-XR, the reported held-out frame-level accuracy on FaceForensics++ and UADFV is $A = \sum_{i\in P} A_i.$2, while training and validation curves stabilized at approximately $A = \sum_{i\in P} A_i.$3 and $A = \sum_{i\in P} A_i.$4. On an HPC cluster baseline, proving time is approximately $A = \sum_{i\in P} A_i.$5 s per frame, verification time approximately $A = \sum_{i\in P} A_i.$6 s per proof, proof size $A = \sum_{i\in P} A_i.$7 KB, proving key $A = \sum_{i\in P} A_i.$8 GB, and verification key $A = \sum_{i\in P} A_i.$9 KB. On optimized prototype XR hardware with GPU acceleration and cached I/O, proving is reported as at most about $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$0 ms per frame and verifying as at most about $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$1 ms per proof. The bandwidth cost is $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$2 KB plus $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$3 bit per frame, compared with roughly $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$4 KB raw frames. Comparisons listed in the paper place XceptionNet at approximately $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$5 accuracy with no ZKP, MesoNet at $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$6 accuracy with no ZKP, FHE-based inference at seconds per frame with no proof succinctness, and Gazebo++ at $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$7 latency reduction but much greater network overhead (Islam et al., 22 Jul 2025).

The trade-offs are explicit. A four-block CNN is described as much smaller than $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$8 MB on-device and yields $M = contentHash \,\|\, DID_{CC} \,\|\, \dots,$9 accuracy, while larger CNNs improve accuracy only marginally but enlarge the proof circuit. A succinct proof of $r_i \in [1, L-1]$0 KB comes with a large proving key and non-trivial proving time, although GPU acceleration and batching can reduce end-to-end latency into the millisecond range. Verification below $r_i \in [1, L-1]$1 ms requires cached verification keys and optimized SNARK libraries. These are standard engineering tensions between model capacity, circuit size, memory footprint, proving latency, and network load.

A common source of confusion is the proximity of the name TrustDefender to unrelated Windows Defender hardening work. MemoryRanger, described in a separate paper, uses a tiny Type-1 hypervisor, per-driver enclaves, EPT protections, and hypervisor-level “trust labels” to restrict illegal access to protected kernel regions such as Microsoft Defender token fields. Its goal is to prevent blinding Windows AV without terminating Defender processes and without triggering security features such as PatchGuard. That objective is distinct from both TRUSTD’s decentralized credibility assessment and TrustDefender-XR’s privacy-preserving deepfake detection (Pogonin et al., 2022).

Taken together, the TrustDefender literature spans two different but complementary conceptions of trust. TRUSTD externalizes trust into decentralized attestations, identity, and reader-controlled policy. TrustDefender-XR internalizes trust into on-device inference whose correctness can be validated cryptographically without revealing the underlying data. This suggests that the term now refers not to a single canonical stack but to a family of trust-oriented mechanisms for content provenance, credibility judgment, and privacy-preserving authenticity assessment.