Implementér Private Set Intersection (PSI) til kundematching

Hvad nu hvis din virksomhed kunne identificere fælles kunder med en samarbejdspartner - uden nogensinde at afsløre hele din kundedatabase?

I en tid hvor GDPR-bøder truer, og hvor kundedata er det nye guld, bliver evnen til at dele så lidt som muligt, men få så meget som muligt, afgørende

Løsningen hedder Private Set Intersection (PSI), en kryptografisk metode, der lader to (eller flere) parter finde de overlappende entries i deres datasæt - og intet andet. Ingen ekstra PII på afveje, ingen hemmeligheder lækket.

I denne artikel viser vi, hvordan du implementerer PSI til kundematching i praksis. Vi tager dig fra den strategiske beslutning om hvorfor, gennem de teknologiske valg om hvordan, til de operationelle detaljer om hvornår løsningen er klar til drift.

Lyder det stadig teoretisk? Forestil dig følgende scenarier:

  • Retail-partnerskaber: To detailkæder vil lancere en fælles loyalitetskampagne, men må ikke dele hele deres kundelister.
  • Finansielle samarbejder: Banker vil undersøge kreditrisiko på tværs - uden at bryde bankhemmeligheden.
  • Adtech & attribution: Et brand vil måle, om deres kampagne gav salg i en e-commerce-platform - uden at nogen ser hinandens rå data.

Kunne din organisation drage fordel af samme superkraft? Så læn dig tilbage - vi guider dig igennem fremtidens sikre kundematching, trin for trin.

Hvorfor PSI til kundematching?

Forestil dig to virksomheder - f.eks. et stort supermarked og en medieplatform - som begge ligger inde med værdifulde kundedatabaser. De vil gerne vide, hvor kundelisterne overlapper, så de kan målrette kampagner og måle fælles ROI. Men ingen af dem er interesseret i at blotlægge hele kundebasen for den anden part. Det er netop dette paradoks, Private Set Intersection (PSI) løser: to (eller flere) parter kan beregne det fælles snit af deres kundesæt, uden at øvrige kundedata kommer på afveje.

Typiske use cases

  1. Retail-partnerskaber
    Samkør loyalitets- eller e-commerce-data mellem detailkæder og brands for at analysere fælles kunderejser og optimere kampagner.
  2. Finansielle samarbejder
    Banker, fintechs og forsikringsselskaber kan finde fælles kunder for at tilbyde kombinerede produkter eller bekæmpe svindel - under fuld respekt for bankhemmelighed og regulatoriske krav.
  3. Adtech & attributtion
    Medie- og reklameplatforme kan måle annonceeffekt (purchase lift, conversion) uden at udveksle rå cookies, MAIDs eller e-mails, hvilket mindsker risikoen for datalæk og strammer GDPR-compliance.

Fordele kontra traditionelle matchmetoder

Dimension Traditionel share-&-compare PSI-baseret match
Privatliv Delvise eller komplette kundelister skal udveksles, med høj risiko for datalæk. Kun snittet (eller endda kun antallet) bliver kendt - intet ekstra afsløres.
GDPR-overholdelse Kræver tungt juridisk apparat, fælles dataansvar & altid DPIA. Dataminimering & purpose limitation er indbygget; færre juridiske benspænd.
Nøjagtighed CSV-upload og manuelle matchregler giver fejl og dårlig skalerbarhed. Deterministisk kryptografisk match; mindre menneskelig fejlmargin.
Operationel kompleksitet Filudveksling, kryptering, manuel sletning, gensidig tillid. Automatiseret API eller batch-flow med klart audit-spor.

Centrale begreber

  • PII (Personally Identifiable Information) - f.eks. e-mail, telefon, adresse; beskyttet af GDPR.
  • Identifikatorer - de værdier, man hasher/salter, inden de indgår i PSI: lowercased e-mail, SHA-256 af telefonnummer, kundekode m.m.
  • Klient / Partner - betegnelsen for de to (nogle gange flere) parter, der udfører protokollen. Rollen kan have betydning for, hvem der får resultatet.
  • Matchmål - hvad ønsker man ud af snittet? Full reveal (listen over fælles kunder), cardinality (kun antal), eller labeled (snit + attributter som købsværdi).

Sammenfattet giver PSI mulighed for at samkøre data sikkert, målrettet og compliant, hvilket baner vejen for mere effektive partnerskaber og bedre datadrevet beslutningskraft - uden at gå på kompromis med kundernes privatliv.

Teknologier og arkitekturvalg

De fem dominerende psi-varianter

Variant Kort beskrivelse Styrker Typiske use cases
ECDH-baseret PSI Parterne udveksler elliptiske-kurve-punkter (Elliptic Curve Diffie-Hellman) og dobbelthasher resultaterne. • Enkel
• Velafprøvet kryptografi
• Gode open-source-biblioteker		 Retail- og e-commerce-partnerskaber med < 10 mio. rækker pr. side
OPRF-baseret PSI Anvender en Oblivious Pseudo-Random Function, ofte med elliptiske kurver eller RSA-blinding. • Færre rundrejser
• Understøtter batch-streaming
• Let at kombinere med udvidelser (labeled, cardinality)		 Adtech-attribution, finansielle datadelingstjenester
Unbalanced PSI Optimeret til meget store asymmetrier (fx 1 mio. ↔ 20 mrd.). • Radikalt reduceret båndbredde for “lille” part
• Kan kombinere Bloom-filtre for yderligere kompression		 Kreditbureaudata, anti-hvidvask hvor myndigheder modtager små forespørgsler
Cardinality-only PSI Returnerer kun antallet af matches - ingen identiteter. • Minimal datalækage
• Lav CPU- og netværksomkostning		 Kampagnemåling, auditor-rapporter, compliance-kontrol
Labeled PSI Leverer både matches og tilhørende attributter (labels) som fx købsvolumen. • Eliminér efterfølgende “lookup join”
• Understøtter on-line personalisering		 Loyalitetsprogrammer, real-time recommendations

Valget af variant bør afvejes efter datasetstørrelse, latencykrav, regulatoriske forventninger og implementerings­modenhed.

Driftsarkitekturer

  1. Ren kryptografisk udførelse
    Al behandling foregår som distribueret protokol, hvor kun krypterede/blindede værdier bevæger sig mellem parterne.
    • Fordele: Ingen tredjepart, mindre TCB (Trusted Computing Base).
    • Ulemper: Betydelig netværkstrafik ved store datamængder, CPU-tung.
  2. TEE-baseret (Trusted Execution Environment)
    Input sendes til en SGX-, SEV- eller Nitro-baseret enclaverodet instans, som udfører match lokalt.
    • Fordele: Få netværksrundrejser, simpel klientside.
    • Ulemper: Tillid til hardwareleverandør/cloud, side-channel-risici.
  3. Hybrid-model
    ECDH/OPRF bruges til at kryptere identifier-felter, hvorefter data lægges i en TEE til aggregat-post-processing.

On-prem vs. Cloud clean rooms

Parameter On-prem Cloud Clean Room
Startomkostning Høj (hardware, HSM, strøm) Lav til medium (pay-as-you-go)
Skalerbarhed Vertikal; capex-tunet Horisontal; auto-scaling
Compliance-kontrol Fuld intern kontrol Deles med cloud-leverandør
Latency til partnere Ofte højere (VPN/MPLS) Lav - datacenter-nærhed
Krav til personale Crypto-/DevOps-specialister in-house Managed service

Netværks- og dataflow

  1. Pre-processing - hver part normaliserer, salter og hasher sine identifikatorer.
  2. Krypteret udveksling - afhængigt af protokol én eller to rundrejser; transportlag TLS 1.3.
  3. Matchfase - krypteret join, evt. i TEE-enclaves eller via batchede OPRF-kald.
  4. Post-processing - dekrypter labels / udregn cardinality, generér rapport eller API-output.

Tip: Hold payload-størrelser < 64 KB pr. HTTP-request for at undgå packet-fragmentering og udnytgRPC-strømme ved kontinuerlig datatillæg.

Skalerbarhed og kompleksitet

  • Batch-størrelse er den største driver for både CPU og netværk. Overvej sharding og bloom-filter-komprimering.
  • En CPU-/RAM-ratio på ~1 core pr. 2 GB RAM giver et godt pejlemærke for OPRF-baserede biblioteker.
  • Stateless microservices gør roll-out lettere, men kræver delt cache eller message bus til koordination.
  • Anvend versionerede skemaer for at kunne rotere hash-salt og ekspandere nøglesæt uden downtime.

Nøglen til en succesfuld udrulning er at samstemme protokolvalg, driftsmodel og regulatorisk risiko tidligt i projektet.Dermed undgår organisationen at ende med en dyr løsning, der enten ikke skalerer eller ikke kan godkendes af compliance.

Implementering trin-for-trin

  1. Normalisering af identifikatorer
    E-mail: trim, lowercase, fjern “+”-aliasser.
    Telefon: fjern whitespace/”+”, konverter til E.164.
    Customer-ID: aftal fælles namespace (fx SHA-256(customer_id‖issuer)).
  2. Deduplikering
    Kør deterministisk hash (fx SHA-256) på den normaliserede værdi og benyt UNIQUE-constraint eller Bloom­filter til at fjerne dubletter før kryptering.
  3. Salting, pepper & hashing
    • Salt: Parti-specifikt, offentlig; minimer korrelation på tværs af kørsel.
    • Pepper: Hemmelig, roteres via KMS; beskytter mod rainbow-tables.
    • Hash herefter med SHA-256/512 eller BLAKE3 afhængig af performancemål.
  4. Formatvalidering
    Afvis ugyldige rækker tidligt (regex / libphonenumber). Log antal fejl uden at logge værdier.

2. Nøglehåndtering & versionsstyring

Komponent Best practice
EC- eller OPRF-nøgler Generér med HSM/KMS, gem versions-tag i metadata.
Roter halvårligt eller ved mistanke om kompromittering.
API-tokens RBAC + short-lived OAuth2/JWT. Adskil upload og compute-roller.
Git-repo Mærk kode, Docker-images og protokolparametre med vX.Y.Z. Automatisk CI-signering af artefakter.

3. Protokolvalg & biblioteker

  • ECDH-PSI - hurtig, velegnet til <10 M rækker. Open-source: Google PJC.
  • OPRF-PSI - mindre datalækage, god til op til 100 M rækker. Lib: Private-ID (Meta).
  • Unbalanced PSI - million vs milliard. Brug OpenMined PSI med Bloom-filtre.
  • Labeled PSI - hvis attributter (fx LTV) skal returneres. Kommercielt: Incremental, Evervault.
  • Clean-room-tjenester - AWS Clean Rooms, Azure Confidential Ledger; reducerer DevOps-byrde men øger vendor lock-in.

4. Api-, batch- og stream-design

  1. Upload-fase: REST-endpoint POST /v1/dataset (multipart + checksum). Under 5 GB? ‑> single call; ellers multipart/S3-presigned.
  2. Compute-fase: POST /v1/match/{job_id}. Idempotent; returnér 202 Accepted + polling-URL.
  3. Result-fase: Streaming via Kafka topic psi.matches for near-real-time kampagner eller ZIP-fil til SFTP for batch.
  4. Husk back-pressure: brug token-bucket rate limiting og exponential backoff i klient-SDK.

5. Test med syntetiske datasæt

  • Generér 1 M falske e-mails/telefoner med Faker.js + samme normaliseringspipeline.
  • Indsæt kontrollerede overlap (fx 5 %, 20 %, 50 %) for præcisionstest.
  • Benchmark: CPU/GPU-udnyttelse, netværkstrafik, wall-clock tid.
  • Fuzz-test edge cases: tom fil, 100 % overlap, 0 % overlap, specialtegn.

6. Validering & kvalitetssikring før produktion

  1. Integritets-check: sammenlign antal input-rækker med server-log. Afvigelse >0,1 % ‑> blokér release.
  2. Match-rate sanity: definer tolerance pr. partner (expected ± 3σ). Alarmér i Prometheus.
  3. Security dry-run: kør OWASP ZAP på API, review IAM-politikker og KMS-log for uautoriserede calls.
  4. Go/No-go-møde: deltagere: DPO, CISO, Data-Engineer. Kræver sign-off i Jira-ticket.
  5. Rollback-plan: hold seneste stabile container-tag. Automatisér kubectl rollout undo.

Når alle trin er bestået, kan løsningen promoveres til prod, og KPI’er som match-rate og latency bør begynde at blive rapporteret til ledelsen fra dag ét.

Sikkerhed, compliance og drift

Når to eller flere parter kører en PSI-protokol, antager man typisk én af følgende modeller:

  1. Semi-honest (honest-but-curious)
    Parterne følger protokollen korrekt, men prøver bagefter at udlede ekstra information af de modtagne beskeder.
  2. Malicious (aktiv fjende)
    En eller flere parter kan afvige fra protokollen, indsætte manipulerede inputs eller forsøge at lære modpartens hele datasæt.

Lækager kan opstå i begge modeller og deles ofte op i:

  • Mængdelæk - modparten slutter sig til størrelsen på dit datasæt.
  • Metadata-læk - fx timing, IP-adresser eller mønstre i flere kørseler, der kan deanonymisere brugere.

Mitigationer og bedste praksis

Risikofaktor Afværgning
Mængdelæk Tilføj padding - dummy-records så datasættet altid har minimum X eller afrundes til nærmeste 10⁴.
Rate-angreb / rekonstruktion over tid Rate limiting, session-nøgler og frequency caps pr. dag/partner.
Intern misbrug Rolleadskillelse (SoD), 4-eyes review af job-konfigurationer, begrænset adgang til rå output.
Manipuleret protokolkørsel Audit-log af alle kryptografiske materialer & versioner, zero-trust deployment pipelines.

Gdpr og øvrig compliance

  • DPIA (Data Protection Impact Assessment) - dokumentér risici og rest-risiko ved PSI-løsningen.
  • DPA (Databehandleraftale) - fastlæg roller (dataansvarlig vs. databehandler) og life-cycle for data.
  • Dataminimering - kun de felter, der er nødvendige for matching (hash af e-mail, tlf. osv.).
  • Slettepolitikker - auto-purge af transient data < 30 dage, kryptografisk shredding af nøgler.
  • Samtykke - tydelig informering om formålet “krydsmatching”, mulighed for opt-out.

Logging uden pii & observability

Brug structured logging med ID’er som job_id og partner_id i stedet for rå e-mails. Eksponer kun hashed identifikatorer i metrics, fx:

{ "job_id": "845ef", "phase": "encrypt", "records_processed": 2_350_120, "duration_ms": 4178}

Integrér tracing (OpenTelemetry) for end-to-end latency, og opret red lines i dashboards for CPU/ram-spikes der kan indikere DoS-forsøg.

Performance- og omkostningsstyring

  • Autoskalering og kortvarige spot-instanser til de tunge kryptografiske faser.
  • Caching af OPRF-evalueringer ved re-match med samme partner.
  • Nøje valg af batch-størrelse; for store batches øger hukommelsesforbruget, for små øger netværksomkostninger.

Kpi’er og governance

Etabler et PSI-scorecard som minimum bør indeholde:

  1. Match-rate (antal hits / antal input-records)
  2. Latency (P95 kørsels-tid pr. job)
  3. Cost per match (cloud-regning / antal matches)
  4. Security incident count (incl. near-misses)

Lav kvartalsvis review af protokolversioner, trusselslandskab og regulatoriske ændringer. Brug et Change Advisory Board til at godkende opgraderinger, fx overgang fra ECDH-PSI til OPRF-PSI eller introduktion af malicious-sikker variant.

Kontinuerlig forbedring

Indsaml feedback fra forretnings-teams om falske negativer/positiver, mål retention på parternes brug af servicen, og planlæg privacy budget per partner så der er balance mellem datanytte og risiko.

Indholdsfortegnelse