ZK-STIX: Zero-Knowledge Proofs for Threat Intelligence Sharing

Every time you share an IOC with a partner, you reveal something about what you’re investigating. Share a domain from a TAXII feed and your peers now know you’re tracking that infrastructure. Share a file hash and they know you’ve encountered that malware. The act of sharing threat intelligence is itself an intelligence disclosure.

This isn’t hypothetical. Nation-state actors monitor public and semi-public sharing platforms. Adversaries routinely pivot infrastructure within hours of IOCs appearing on platforms like VirusTotal, OTX, and abuse.ch. Threat actors actively consume the same feeds defenders publish to.

For regulated industries under frameworks like DORA, NIS2, and GDPR, the problem compounds. Sharing IP addresses that constitute personal data under GDPR Recital 30, or sharing indicators that reveal ongoing investigations subject to attorney-client privilege, creates legal exposure that most ISACs hand-wave away.

ZK-STIX is a protocol we designed at ThreatFight that applies zero-knowledge cryptography to STIX 2.1 intelligence objects, enabling organizations to answer the question “do we both see this threat?” without revealing what they see.

The sharing paradox

Current threat intelligence sharing mechanisms all have the same fundamental flaw: they require disclosure to function.

TAXII feeds distribute STIX bundles readable by every subscriber. Every subscriber sees every indicator. There’s no way to query whether another organization has seen a specific indicator without publishing it to the entire feed.

ISACs (Information Sharing and Analysis Centers) operate on trust agreements, but the data still moves in the clear. FS-ISAC, H-ISAC, and others rely on TLP (Traffic Light Protocol) markings to control redistribution. TLP is a policy label, not a technical control. There’s no enforcement mechanism beyond trust.

Bilateral sharing between SOC teams typically happens over encrypted email or chat. Better for confidentiality, but it doesn’t scale. You can’t bilaterally share with 200 organizations and maintain operational security.

The result: most organizations either overshare (leaking investigation details) or undershare (missing collaborative defense opportunities). Both outcomes are bad.

Zero-knowledge proofs: a 30-second primer

A zero-knowledge proof (ZKP) lets one party (the prover) convince another party (the verifier) that a statement is true, without revealing any information beyond the truth of the statement itself.

The canonical example: you want to prove you know a password without sending the password. ZKPs make this possible through mathematical protocols where the verifier becomes convinced of the prover’s knowledge through a series of challenges and responses that leak no information about the underlying secret.

The three properties that define a ZKP:

1. Completeness — if the statement is true, an honest prover can convince the verifier
2. Soundness — if the statement is false, no cheating prover can convince the verifier (except with negligible probability)
3. Zero-knowledge — the verifier learns nothing beyond the truth of the statement

Modern ZKP systems like zk-SNARKs (used in Zcash), zk-STARKs (used in StarkNet), and Bulletproofs (used in Monero) have made these proofs practical for real-world applications. ZK-STIX applies this same cryptographic foundation to threat intelligence.

How ZK-STIX works

ZK-STIX is our protocol for zero-knowledge set membership proofs over STIX 2.1 indicator objects. The core operation: prove that your indicator set intersects with another organization’s indicator set, without revealing the contents of either set.

The cryptographic building blocks

Pedersen commitments — Each organization commits to their set of indicators using Pedersen commitment schemes. A Pedersen commitment to value v with blinding factor r is C = g^v * h^r, where g and h are generator points on an elliptic curve. The commitment is binding (you can’t change the value after committing) and hiding (the commitment reveals nothing about the value).

Zero-knowledge set membership — Given a committed set S and a committed element x, prove that x ∈ S without revealing x or S. ZK-STIX implements this using cryptographic accumulators and set membership proofs, adapted for STIX indicator types.

Private set intersection (PSI) cardinality — Before revealing any individual matches, the protocol first computes the cardinality of the intersection (how many indicators overlap) without revealing which ones. This lets organizations decide whether to proceed with full matching or abort if the overlap is too small to be meaningful.

The protocol flow

1. Commitment phase — Both organizations independently hash their STIX indicators and compute Pedersen commitments over the resulting set. The commitments are published to a shared bulletin board (or exchanged directly).

2. Cardinality proof — Using PSI cardinality, both parties learn the size of their overlap. If Organization A has 10,000 indicators and Organization B has 8,000, they might learn that 347 indicators appear in both sets. Neither party learns which 347.

3. Selective disclosure — If the cardinality is sufficient, either party can selectively reveal specific matches using zero-knowledge proofs. For example, Organization A can prove “I have an indicator matching one of your committed indicators, and it is associated with MITRE ATT&CK technique T1059.001” without revealing the indicator value itself.

4. Conditional reveal — Both parties can agree to reveal the actual indicator values for confirmed matches, using a simultaneous disclosure protocol that prevents one party from learning the other’s indicators without reciprocating.

A practical example

Two financial institutions — call them BankA and BankB — both participate in a ZK-STIX sharing arrangement. BankA is investigating a business email compromise campaign. BankB is tracking wire fraud infrastructure.

// BankA's ZK-STIX sharing request
{
  "type": "zk-stix-query",
  "spec_version": "1.0",
  "id": "zk-stix-query--a1b2c3d4-...",
  "created": "2026-03-28T14:30:00.000Z",
  "query_type": "psi-cardinality",
  "indicator_commitment": {
    "scheme": "pedersen-ristretto255",
    "commitment": "RistrettoPoint(compressed:<base64-encoded>)",
    "set_size": 1842,
    "indicator_types": ["ipv4-addr", "domain-name", "email-addr"],
    "timeframe": {
      "start": "2026-03-01T00:00:00Z",
      "end": "2026-03-28T23:59:59Z"
    }
  },
  "proof": {
    "type": "bulletproof-range",
    "proof_data": "<base64-encoded-proof>"
  }
}

// BankB's ZK-STIX response
{
  "type": "zk-stix-response",
  "spec_version": "1.0",
  "id": "zk-stix-response--e5f6a7b8-...",
  "created": "2026-03-28T14:30:12.000Z",
  "query_ref": "zk-stix-query--a1b2c3d4-...",
  "result": {
    "intersection_cardinality": 23,
    "cardinality_proof": "<base64-encoded-proof>",
    "overlap_techniques": [
      {
        "technique_id": "T1566.001",
        "technique_name": "Spearphishing Attachment",
        "match_count_proof": "<base64-encoded>"
      },
      {
        "technique_id": "T1071.001",
        "technique_name": "Web Protocols",
        "match_count_proof": "<base64-encoded>"
      }
    ]
  }
}

BankA now knows: there are 23 indicators in common with BankB, and some are associated with spearphishing and C2 over web protocols. BankA doesn’t know BankB’s other 7,977 indicators. BankB doesn’t know BankA’s other 1,819. Both banks can now decide whether to proceed to selective disclosure of the 23 matching indicators.

Compare this to the TAXII approach, where BankA would publish all 1,842 indicators to the feed, revealing the full scope of their investigation to every subscriber.

ZK-STIX vs. existing sharing mechanisms

Mechanism	Confidentiality	Scalability	Automation	Standard
TAXII 2.1	None (all subscribers see all indicators)	High	Full	OASIS standard
ISAC membership	Policy-based (TLP)	Medium	Partial	Sector-specific
Bilateral (email/chat)	High (point-to-point)	Low	None	Ad hoc
TLP:RED briefings	High	Very low	None	FIRST standard
ZK-STIX	Cryptographic	High	Full	STIX 2.1 compatible

The key distinction: ZK-STIX provides cryptographic confidentiality guarantees, not policy-based ones. TLP:AMBER means “please don’t share this beyond your organization.” ZK-STIX means “you mathematically cannot learn what I haven’t chosen to reveal.”

Why this matters for DORA and NIS2

The EU’s Digital Operational Resilience Act (DORA), which took effect in January 2025, includes Article 45 on information-sharing arrangements for ICT-related threat intelligence. Article 45 explicitly encourages financial entities to participate in threat intelligence sharing while requiring that such arrangements protect the potentially sensitive nature of the information shared.

This creates a tension: regulators want financial institutions to share threat intelligence, but also require them to protect that intelligence. ZK-STIX resolves this tension at the protocol level.

NIS2 Article 29 similarly mandates voluntary cyber threat information sharing while requiring that shared information is protected in accordance with Union and national law. For organizations operating across EU member states with varying data protection interpretations, a cryptographic guarantee of confidentiality is substantially easier to defend in front of a DPA than a TLP marking.

For sectors handling classified or controlled information — defense contractors under CMMC 2.0, ITAR-regulated manufacturers, intelligence community partners — ZK-STIX enables participation in sharing communities that would otherwise be prohibited by data handling restrictions.

Performance and practicality

ZK proofs aren’t free. The commitment phase for a set of 10,000 indicators takes approximately 2-4 seconds on modern hardware (benchmarked on AMD EPYC 7763, single core). PSI cardinality computation scales linearly with set size. For typical enterprise indicator sets (10,000-100,000 indicators), the full protocol completes in under 30 seconds.

This isn’t real-time, but it doesn’t need to be. Threat intelligence sharing operates on minutes-to-hours timescales, not milliseconds. The cryptographic overhead is negligible compared to the analyst time saved by automated matching and the operational security gained by keeping watchlists private.

Proof-of-Observation: The Next Step

The ZK-STIX protocol described above solves private overlap queries: “do we see the same thing?” The next primitive we’re shipping is Proof-of-Observation — a cryptographic proof that your organization observed a specific IOC at a specific time, without revealing the IOC itself.

The original ZK-STIX design uses Bloom filter commitments and SHA-256 hashes to answer set-intersection questions. Proof-of-Observation upgrades the cryptographic machinery to full Groth16 zk-SNARK circuits, built on the gnark proving system, to make a stronger claim: “I saw this IOC at time T, and I can prove it without telling you what I saw.”

How it works

Each participating organization commits to observed indicators using a Poseidon hash over the tuple (IOC, nonce, timestamp):

commitment = Poseidon(IOC ‖ nonce ‖ timestamp)

Poseidon is a SNARK-friendly hash function designed for arithmetic circuits — roughly 8x fewer constraints than SHA-256 inside a Groth16 proof, which is why we chose it over the SHA-256 commitments used in the original overlap protocol.

Commitments are inserted as leaves into an append-only Merkle tree. MalCloud publishes the Merkle root every 10 minutes as a transparency root, available at:

/transparency/roots/{epoch}

These roots are signed, timestamped, and immutable. Think Certificate Transparency logs, but for threat intelligence observations.

When an organization later needs to prove it observed an IOC before a given time, it generates a Groth16 zk-SNARK proving:

1. Knowledge of a pre-image (IOC, nonce, timestamp) such that Poseidon(IOC ‖ nonce ‖ timestamp) equals a leaf in the Merkle tree
2. A valid Merkle path from that leaf to a published root
3. timestamp ≤ T_bound, where T_bound is the claimed observation deadline

The verifier checks the proof against the published root. The verifier learns that some IOC was observed before T_bound by the proving organization. The verifier learns nothing about which IOC, what the nonce was, or the exact timestamp — only that the claim is valid.

Circuit characteristics

The Groth16 circuit for Proof-of-Observation compiles to approximately 15,700 R1CS constraints. The breakdown:

• Poseidon hash pre-image: ~250 constraints
• Merkle path verification (depth 20): ~5,000 constraints
• Timestamp range check: ~250 constraints
• Input marshalling and public input binding: ~10,200 constraints

Proof size is 164 bytes (two G1 points and one G2 point on BN254). Verification is a single pairing check — constant time regardless of tree size.

Proof generation runs under 2 seconds on commodity hardware (benchmarked on a 4-core VM, no GPU). Verification takes <10ms. These numbers hold whether the Merkle tree contains 1,000 leaves or 10 million.

Use cases

Insurance claims. After a breach, cyber insurers want evidence that the policyholder had visibility into the threat before the incident escalated. Proof-of-Observation provides a cryptographic receipt: “we detected indicators associated with this campaign on this date.” The insurer can verify the claim against a published transparency root without the policyholder disclosing their full indicator set or investigative methodology.

Regulatory compliance. DORA Article 17 requires financial entities to detect anomalous activities, including ICT-related incidents, “as early as possible.” NIS2 Article 23 imposes early warning obligations within 24 hours. Proof-of-Observation creates a verifiable, timestamped record of detection that auditors can check without accessing raw telemetry.

Incident attribution. When multiple organizations contribute observations to an attribution effort, Proof-of-Observation lets each participant demonstrate they independently observed infrastructure components at specific times, establishing a convergence timeline without any single party revealing their collection sources.

Peer trust building. In sharing communities, trust is earned by demonstrating consistent, timely observation of relevant threats. Proof-of-Observation lets an organization build a verifiable track record — “we observed 847 indicators later confirmed as APT-linked, with a median lead time of 6 days” — backed by cryptographic evidence rather than self-reported metrics.

Why this matters

“Prove you knew before being told” is a capability no other threat intelligence platform offers. Every existing TIP can show you when an indicator was ingested into its database. None can cryptographically prove that an organization independently observed that indicator at a specific time, without revealing the indicator, in a way that a third-party verifier can check against a public root of trust.

Proof-of-Observation turns threat intelligence from a reputation game into a provable one.

The MalCloud implementation

MalCloud implements ZK-STIX as a core sharing primitive. Every STIX indicator stored in MalCloud can participate in zero-knowledge sharing without modification. The ZK-STIX engine runs locally — your indicator commitments never leave your infrastructure, and proofs are computed on your hardware.

This means air-gapped deployments can still participate in ZK-STIX sharing by exchanging commitment data and proofs through manual transfer or data diodes, without ever exposing raw indicator values.

If you’re evaluating threat intelligence sharing for a regulated environment, or if you’ve been holding back from ISACs because of confidentiality concerns, ZK-STIX changes the calculus. Try MalCloud and see how zero-knowledge sharing works in practice.