Hvordan bruger man ZKP'er i data cleanrooms?

Begrebet data cleanroom stammer fra behovet for at samarbejde om data-drevne indsigter, uden at deltagerne deler deres rå, personhenførbare data direkte med hinanden. I et cleanroom uploader hver part typisk sine pseudonymiserede datasæt til et neutral, kontrolleret miljø, hvor kun foruddefinerede analyser - f.eks. konverteringsrater, overlappende målgrupper eller forecasting-modeller - må køres. Ingen enkelt part kan frit forespørge de andre parters databorde, og output er som regel aggregeret eller støjtilføjet for at forhindre identifikation.

Organisationer vælger denne model af tre hovedgrunde:

1. Forretningsværdi: Fælles analyser øger præcisionen af reklame-, retail- og risiko­modeller, uden at kostbar first-party data skifter hænder.
2. Kommerciel fortrolighed: Man afslører ikke forretningskritiske segmenter eller algoritmer for konkurrenter.
3. Compliance: GDPR, databeskyttelsesloven og Datatilsynets praksis kræver dataminimering og formålsbegrænsning - krav som cleanrooms kan operationalisere.

Fra beskyttet miljø til zero-knowledge proofs

Selv om et traditionelt cleanroom reducerer risikoen for datalæk, er der stadig to svage punkter:

• Cleanroom-operatøren er en trusted third party, der kan se alt, hvis den kompromitteres.
• Parterne skal stole på, at de begrænsede queries faktisk overholder de aftalte regler.

Her kommer zero-knowledge proofs (ZKP’er) ind i billedet. Med en ZKP kan en prover matematik­sk bevise over for en verifier, at en given udtalelse er sand - f.eks. at en aggregeret konverteringsrate er korrekt beregnet - uden at afsløre de underliggende data eller beregningstrin.

Zkp’er i en cookieløs, reguleret virkelighed

Når tredjeparts­cookies udfases, stiger efterspørgslen efter alternativer, der både respekterer privatliv og bevarer måle­evnen. ZKP-baserede cleanrooms giver:

• Bevisbar brugsbegrænsning: Beviset viser, at kun den tilladte logik blev kørt.
• Minimal dataudelæggelse: Kun statistiske resultater (eller endda kun selve beviset) forlader miljøet.
• Automatisk revision: Gemmer man beviser og verifier-logs, har man et krypteret auditspor klar til Datatilsynet.

Sådan adskiller zkp’er sig fra andre privacy-tech

Gdpr: Hvorfor zkp’er flytter compliance-kurven

ZKP-drevet databehandling rammer direkte ind i de tre mest centrale GDPR-principper:

1. Dataminimering (art. 5(1)(c)): Kun de datafelter, som indgår i kredsløbet (circuit), behandles, og intet udtrykkes eksternt ud over beviset.
2. Formålsbegrænsning (art. 5(1)(b)): Kredsløbet kan låses til ét formål; alt andet vil fejle verifikation.
3. Ansvarlighed (art. 5(2)): Kryptografiske auditspor dokumenterer objektivt, at reglerne blev fulgt - en game-changer, hvis Datatilsynet banker på.

I dansk kontekst tolker Datatilsynet ofte højrisiko­behandling stramt; ZKP’er kan derfor være et afgørende element i både DPIA og privacy by design. Ved at integrere bevis-generering i ETL-pipelines kan man demonstrere compliance uden at henvise til tillid eller kontraktuelle klausuler alene.

Resultatet er en fremtidssikret model, hvor data cleanrooms ikke blot er black boxes, men kryptografisk transparens med begrænset indsigt - og det er præcis den kombination, der skal til i en cookieløs, reguleret verden.

I et zero-knowledge proof (ZKP) er der to logiske aktører:

1. Prover - typisk den organisation, der ejer eller hoster data cleanroom’et og udfører beregningen.
2. Verifier - den part (kunde, partner, tilsynsmyndighed), som skal stole på resultatet uden at få adgang til de underliggende rådata.

Modellen sikrer tre egenskaber:

• Rigtighed: Hvis prover’en snyder, opdages det med høj sandsynlighed.
• Zero-knowledge: Verifier’en får ingen ekstra information ud over sandheden af udsagnet, fx “Det samlede reach er 24 612 unikke brugere”.
• Kompletheden: Hvis udsagnet er sandt, kan det bevises.

Snarks vs. Starks - To veje til det samme mål

Valget afhænger af latency-krav, kvantesikkerhed og governance. Flere cleanroom-leverandører tilbyder i dag begge muligheder: SNARKs til realtime-dashboards, STARKs til revisions-beviser eller åbne dataanmodninger.

Typiske beviser i et data cleanroom

1. Private Set Intersection (PSI) - kun kardinalitet
   Prover beviser, at antallet af fælles brugere mellem to ID-sæt er fx 3 274 uden at afsløre hvilke brugere. Circuit’en implementerer en hashing-baseret oblivious sortering efterfulgt af tælling.
2. Korrekt join uden ID-lækage
   Når to parter vil korrelere kampagnedata med konverteringer, beviser prover’en, at hvert join sker på pseudonymiserede HMAC-nøgler med samme salt, og at de rå e-mail-hashes aldrig forlader RAM.
3. Aggregerede metrikker under tærskler (k-anonymitet)
   Circuit’en beregner f.eks. visninger pr. aldersgruppe, men forkaster grupper < k=50. ZKP’et viser, at alle publicerede tal overholder tærsklen, så ingen mikrogrupper slipper igennem.
4. Bevis for policy-compliance
   Organisationen modellerer sine GDPR-regler som logiske constraints: Formål == “marketing” AND Samtykke == sand. ZKP’et beviser, at hver post opfylder politikken før den indgår i analysen.
5. Korrekt tilføjelse af differential-privacy-støj
   For at modstå rekonstruktionsangreb adderes Laplace-støj. Beviset demonstrerer, at ε og δ ligger inden for kontraktuelle grænser (fx ε ≤ 1.0) og at random-seedet stammer fra en FIPS-valideret DRBG.

Trusted setup - Når ceremonien betyder alt

Ved SNARKs er key-ceremonien kritisk: Leak af den giftige deltager-nøgle (toxic waste) kan muliggøre falske beviser. Praksis:

• Multicloud HSM-baseret MPC-ceremoni med video-log.
• Offentlig dokumentation & on-chain transcript.
• Tredjeparts revisionsattest, fx ISAE 3000.

Auditspor og verification-as-a-service

For at kunne tilbagevise datamanipulation bevares følgende artefakter:

• Commitment-hashes (Merkle-rødder) på alle input-filer.
• Selve proof-objektet (SNARK/STARK).
• Off-chain metadata: query-string, tidsstempel, brugers rolle.

En VaaS-endpoint udstilles som /verify/<proof_id>. Her kan:

1. Kunder henvende sig programmatisk og få svar (true/false) på <10 ms.
2. Revisorer hente hele transcriptet som JSON + CSV-bilag.
3. Tilsynsmyndigheder vælge at køre egen verifier-kode (frit open-source).

Performance og skalerbarhed

Proof-generation er stadig den største omkostning. Kendte optimeringer i praksis:

• Parallel circuit-splitting på GPU-clustre.
• Incremental proofs: der genereres mikro-proofs for datapartitioner og et overordnet aggregations-proof.
• Recursion og folding: især i STARK-baserede setups reduceres bevisstørrelsen fra O(n) til O(log n).

Et moderne cleanroom beviser i dag 1 milliard records på < 20 minutter (16 × A100 GPU’er) med et proof på ~ 45 kB.

Til sammen giver disse mekanismer et kontrollerbart, efterprøveligt miljø, hvor troværdigheden i hver måling ikke kræver tillid til modpartens ord - kun til matematikkens uafviselige logik.

2. Ingestion & pseudonymisering

• Saltede HMACs: Identificerende felter (fx e-mails, CPR-hash) transformeres som HMAC_SHA256(value, tenant_salt). Saltene roteres typisk kvartalsvist og opbevares i et HSM.
• Field-level encryption for følsomme attributter, så kun circuits med de rette nøgeltilladelser kan dekryptere under provingen.
• Schema-locking: Event-skemaer versioneres i GitOps-flow; enhver ændring kræver nyt compliance-bevis.

3. Fra rådata til kommitments & merkle-rødder

For hver batch genereres en Merkle-root over de saltede rekord-hashes:

1. Record Hash = Pedersen/SHA-256 hash af hele rekorden.
2. Hashes arrangeres i et fuldt binært træ; roden gemmes i en immutabel root_store (kan lægges på block­chain eller blot i S3 + Sign-as-Merkle-root).
3. Circuit’en får roden som public input; under verifikation kan en revisor nøjes med roden og et Merkle proof for at sikre, at data­punktet var en del af det godkendte datasæt.

4. Circuit-design & proof-generation

• Modulære sub-circuits: Policy-check, Aggregation-logic, Differential-privacy noise.
• Trusted setup vs. setup-fri:
  • SNARKs (Groth16, Plonk) kræver ofte Powers-of-Tau ceremony; kør flerparts-ceremoni med revisor som deltager.
  • STARKs eller Halo2 (PLONKish) kan undgå trusted setup, men har større beviser - vælg efter behov.
• Proof-pipeline:
  1. Compiler DSL → R1CS/PLONKish constraints.
  2. Chunk-deling for parallel GPU-generering.
  3. Post-processing: bevis-komprimering (FRI, recursion) og signering.

5. Verifikation, audit-spor & nøglestyring

Alle beviser sendes gennem en Verify-as-a-Service (VaaS), som returnerer kun OK|FAIL + metrikker. Audit-events logges i:

• EventStore (append-only) m. hash-linkede blokke for uforanderlighed.
• eIDAS-kvalificeret tidsstempling for dansk/EU compliance.

Nøgler håndteres af et HSM eller KMS (fx HashiCorp Vault). Adgangen styres af least-privilege og rotate+re-seal-procedurer ved incident.

6. Query-governance, rate-limiting & resultattærskler

• Intent-registrering: Hver bruger udfylder en query manifest (SQL + purpose) der ligger til grund for DPIA & samtykker.
• Rate-limiter: Global token-bucket pr. partner for at dæmpe differencing-angreb.
• Resultattærskler: K-anonymitet (typisk 50/100) håndhæves i circuit’en; hvis count<k genereres et null-bevis, og ingen rå output returneres.
• Differential privacy: Støjparameter (ε, δ) gemmes som public input i beviset, så revisor kan se, hvor meget støj der faktisk blev tilføjet.

7. Trusselsmodeller & afbødning

8. Hybride designs & platform-integrationer

Ofte kombineres teknikker for at få det bedste fra flere verdener:

• MPC/TEE pre-processing: Partnere kan anvende MPC til at normalisere data eller TEEs (Intel SGX, AWS Nitro) til at køre tunge joins. ZK-laget beviser så kun det endelige privacy-sikrede resultat.
• Snowflake / BigQuery connectors:
  • Data ligger i tabel-form; external functions kalder proof-generatoren og returnerer resultat + bevis som ekstra kolonne.
  • Udløste MERGE/INSERT triggers opdaterer Merkle-root automatisk.
• Event-drevne pipelines på Kafka + Flink kan også generere beviser i near-real-time, fx til anti-fraud use-cases.

9. Værktøjer & biblioteker til zkp-udvikling

• Circom + SnarkJS - JavaScript-venlig, god til prototyper.
• Halo2 / Zebra - Rust-økosystem, ingen trusted setup.
• RISC Zero - Kør vilkårlig WASM-kode som ZK-circuit.
• Lurk & zkLLVM - Gør det muligt at skrive circuits i high-level sprog (C/C++, Rust).
• zk-SQL (open source) - Parser SQL-queries og kompilér dem til PLONK-cirkler, særligt egnet til cleanrooms.
• OpenZL - Bibliotek for PSI-C og ZK-friendly hashing.
• Commercial suites: Inpher Secret-Compute, Decentriq, Duality, som tilbyder kombineret MPC + ZK stack.

Med ovenstående arkitektur kan en dansk organisation bevæge sig fra teoretisk idé til driftsmodent cleanroom, der leverer revisionérbare analyser uden at kompromittere borgernes privatliv - og samtidig stå stærkt over for fremtidig EU-regulering.

• Annoncemåling uden rådata
  To mediehuse opretter et fælles cleanroom, hvor annoncørens hashed kunde-ID’er matches mod udgivers hashed impressions. Et ZK-bevis dokumenterer, at kun kardinaliteten af overlappet og en løft-koefficient udleveres, mens ingen enkelt-cookies eller MAID’er forlader miljøet.
• Retail-samarbejder
  En dagligvarekæde og en FMCG-producent beregner kampagneresultater pr. butik × uge. ZKP’er beviser korrekt join mellem POS-data og loyalitets-profiler, og at ingen segment indeholder < 100 husholdninger (k-anonymitet).
• Finansielle risikomodeller
  Flere banker deler misligholdelsesstatistikker for at træne en fælles kredit-modell. ZKP’er sikrer, at kun aggregerede koefficienter publiceres, og at de underliggende lån ikke kan identificeres. Modellen kan derefter auditeres af Finanstilsynet uden fuld dataadgang.
• Sundhedsrelaterede analyser
  Hospitaler udfører outcome-research på tværs af EPJ-systemer. Et ZK-bevis garanterer, at patient-ID’er er pseudonymiseret med saltede HMACs, og at GDPR-kravet om dataminimering overholdes. Lægemiddelstilsynet kan verificere beregningen eksternt.
• Antifraud & AML
  Betalingsgateways deler signaturer på mistænkelige transaktioner. Private-set-intersection med ZKP’er afslører kun overlap af kortnumre under efterforskning - ikke hele kundebasen.
• Supply-chain-sporing
  Produktions- og logistikpartnere publicerer kommitments til sensor-data (temperatur, CO₂), men afslører kun beviser for, at værdier lå inden for SLA-grænser under transport. Forbruger- brandet kan derfor dokumentere ESG-overholdelse uden at se konkurrentens rådata.

Typiske faldgruber

1. Datakvalitet & semantik - Hash-kolliderende felter, uens tidszoner eller manglende normalisering kan få beviser til at fejle; “garbage in, zero-knowledge out”.
2. Omkostninger ved proof-generation - STARK-beviser kan kræve > GB RAM og mange minutters genereringstid; budgettér GPU/FPGA-kapacitet.
3. Trusted setup - SNARK-ceremonier skal dokumenteres rigoristisk; ellers risikerer man “toxic waste” og brist på tillid fra partnere eller Datatilsynet.
4. Policy-huller - For brede queries, manglende rate-limitering eller lave anonymitetstærskler kan give rekonstruktionsangreb, selv om beviset er korrekt.

En praksisnær køreplan for danske organisationer

Tip: Start småt - ét use case, få partnere - og lad ZKP-modenhed vokse sammen med organisationens risikotolerance og hardware-kapacitet.