Hvordan udruller du homomorfisk kryptering i ML-projekter?

Homomorfisk kryptering (HE) er et krypto-værktøj, der gør det muligt at udføre beregninger direkte på krypterede data og få et resultat, som - når det dekrypteres - svarer til dét, man ville have fået på klar-tekst. Ingen datadeling, ingen indblik i modeller eller inputs, men stadig samme funktionelle output. Det lyder næsten magisk, men teknikken har faktisk været kendt siden 1970’erne; det er først med de seneste 5-10 års teoretiske gennembrud, open-source-biblioteker og hardwareacceleration, at brugen er begyndt at ligne noget, der kan stå på en MLOps-roadmap.

1. PHE - Partially Homomorphic Encryption
   Understøtter kun én type operation (f.eks. enten addition eller multiplikation). Eksempel: RSA (multiplikativ) eller Paillier (additiv). God til simple aggregeringer, men begrænset for ML.
2. SHE/LHE - Somewhat/Leveled Homomorphic Encryption
   Understøtter både addition og multiplikation, men kun et begrænset antal gange, før “støj” i ciphertexten ødelægger signalet. Bruges ofte til inferens, hvor man på forhånd kender antallet af lag/operationer.
3. FHE - Fully Homomorphic Encryption
   Kan køre vilkårligt mange operationer takket være bootstrapping, som “renser” støjen væk. Stadig dyrt, men nødvendigt når man ikke kan garantere et lavt dybdeniveau i beregningen.

Til ML anvendes typisk polynomielle ring-baserede skemaer. De mest udbredte:

• Privacy-bevarende inferens
  F.eks. en hospitalsklient krypterer patientens CT-scan og sender det til en cloud-hostet diagnosemodel. Cloud-udbyderen ser aldrig klare billeder eller resultater - kun krypterede tensors.
• Cross-silo samarbejde
  Banker eller pharma-virksomheder kan dele modeller (eller træne fælles modeller) på data, der aldrig forlader organisationerne i klar form, men stadig får indsigt i hinandens distributionsmønstre.
• Reguleret dataanalyse
  Offentlige myndigheder må analysere borgerdata, men ikke se CP-numre, sundhedsoplysninger eller finansielle transaktioner direkte. HE opfylder GDPR’s krav om “state of the art” pseudonymisering, uden at nedsætte analysekvaliteten.

• Zero-trust cloud: Du antager, at cloud-operatøren eller insideren kan være ondsindet.
• Schrems II / data-lokalisering: Data må ikke forlade EU i klar tekst, men HE tillader beregning på tværs af jurisdiktioner.
• F&U med konkurrenter: Partnere stoler ikke på hinanden, men ønsker fælles model.
• Supply-chain risk: Selv hvis hardware/OS kompromitteres, er data stadig krypteret.

• Biblioteker: Microsoft SEAL (C++), OpenFHE (C++), PALISADE, HElib, TF-Client/Server (TenSEAL), og nystartede Concrete-ML (Zama) med Python-API og ONNX-kompilator.
• Standardisering: ISO/IEC 18033-7 under udarbejdelse; HomomorphicEncryption.org kører referenceparametre og sikkerhedsprofiler.
• Hardware: Intel HEXL, NVIDIA cuFHE, ASIC- prototypes fra Duality/Zama. GPU giver 5-20× speedup på CKKS.
• Dev-tools: ONNX-til-HE kompilatorer, automatiseret støj-analyse, samt Jupyter-plugins til visuel debugging.

Beslutningen handler sjældent kun om ydeevne; den handler om trust-boundary og regulatorisk risiko.

Når giver det forretningsmæssig mening?

• Når regulatorisk bøde eller brand-risiko ved datalæk vægter tungere end (forventelig) performance-impact.
• Når samarbejdspartneres mangel på tillid blokerer et åbenlyst værdiskabende ML-projekt.
• Når modelintelektuel ejendom er sensitiv (f.eks. proprietære pharma-modeller), og du vil forhindre gleaning via queries.
• Når du planlægger langsigtet post-kvante-robusthed og vil undgå TEE-leverandøraffattelse.

Er alle punkter opfyldt, er homomorfisk kryptering ikke bare en akademisk kuriositet - men et konkret værktøj, der kan flytte ML fra “kan ikke på grund af GDPR” til “kan, og vi har stadig datakontrol”. Det er nøglen til næste bølge af datasamarbejde, hvor datarespekt er lige så vigtig som modelpræcision.

Fra rå data til krypteret inferens - Referencearkitektur

Den klassiske HE-pipeline kan inddeles i fire logiske lag:

1. Client-side præparation & kryptering
   Data normaliseres (f.eks. min-max eller z-score), kvantiseres til faste heltals- eller fixed-point-repræsentationer og pakkes derefter i HE-venlige blokke. Brugeren genererer secret key (SK) og afleder heraf:
   • public key (PK) - til kryptering
   • relineariserings-nøgler (RLK) - til at reducere ciphertext-dimension efter multiplikation
   • rotations-/galois-nøgler (Galois keys) - til vector-rotate og sum/dot operationer
   Disse hjælpe-nøgler sendes til serveren, mens SK altid bliver på klientsiden.
2. Sikker datapipeline
   Krypterede batches sendes via TLS til inferens-API’en. Her kan man placere en light-weight pre-processor, der kun arbejder på ciphertext (f.eks. pakkeflytning eller noise-check) - ingen dekryptering forekommer.
3. Server-side inferens
   Selve ML-modellen er gemt i klartekst på serveren, men alle beregninger udføres på ciphertextene. Resultatet er en eller flere krypterede logit/score-værdier.
4. Client-side dekryptering & post-processing
   Kunden modtager krypterede resultater, dekrypterer med SK og udfører endelig aktivering (hvis nødvendig) samt fortolkning.

Hvilke modeller egner sig?

Nyttige designmønstre og teknikker

• Polynomialisering af aktiver: Vælg lav polynomgrad, helst ulige (for ReLU-lignende) og normaliser input til [-1,1] for at minimere approksimeringsfejl.
• Batching / packing: CKKS og BFV tillader SIMD-stil operationer på op til N/2 slots. Udnyt det til at processere hundreder af observationer samtidig og dermed få lineær throughput-forbedring.
• Støjbudget-styring: Hver multiplikation konsumerer log_q(p) bits. Lav et budget-regneark under modeldesign - eller brug bibliotekernes profileringsværktøjer (seal::Ciphertext::invariant_noise_budget()).
• Bootstrapping: Kun nødvendig ved dybe netværk eller streaming-scenarier. Concrete-ML og OpenFHE tilbyder automated bootstrapping; planlæg 50-200 ms overhead pr. call i CKKS.

Biblioteker og frameworks

Parametervalg: Et praktisk udgangspunkt

• Sikkerhedsniveau: Sigter oftest efter 128-bit klassisk sikkerhed (≈ NIST Cat-1), svarer til poly_degree = 8192 og log(q) ≈ 218 i CKKS.
• Polygrad (N): 4096 til latency-følsomme mobilscenarier; 16384 for dybe modeller med bootstrapping.
• Moduli chain: Planlæg [60, 40, 40, 60] bits for en 3-lags MLP så første og sidste niveau har høj præcision.
• Scale: Typisk 240 for at holde rounding-fejl under 1e-3.

Latency vs. Accuracy - Optimeringsprincipper

1. Reducer multiplikationer: Flet vægt-matricer hvor muligt ((W2 ∘ W1)·x) og vælg activation deg ≤ 3.
2. Aggressiv packing: Brug rotate-and-sum-tricket til matrix-vector-produkt i O(log n) roteringer.
3. Profilér nøje: OpenFHEs GEN_CIRCUIT_LATENCY() og SEAL-Profiler hjælper med at finde flaskehalse.
4. Hardware-acceleration: GPU-baseret NTT/FFT giver 3-6x speed-up; FPGA-er kan nå sub-millisekundslatency for inferens-edge-cases.
5. Præcision management: Overvej at lade sidste lag være i plaintext (hybrid) hvis resultatet ikke er sensitivt (ex. klassifikation af allerede anonymiserede labels).

Med denne arkitektur og værktøjskasse kan udviklingsteams gå fra idé til enprivacy-preserving ML-tjeneste på få uger - uden at kompromittere hverkensikkerhed eller brugbarhed.

1. Proof-of-Concept (PoC)
   
   • Opstil plaintext-paritetstests: Sammenlign output fra ukrypteret model og HE-model på et lille datasæt (≈1 000 rækker) for at sikre funktionel ækvivalens.
   • Fastlås kryptoparametre (N, q, sikkerhed >= 128 bit) og ram modelbegrænsninger (maksimal dybde, accepteret MSE).
   • Mål førstehånds-latency (< 500 ms pr. inferens for simple modeller) og memory-footprint, og sæt foreløbige SLO’er.
2. Benchmarking-fase
   
   • Kør syntetiske workloads i container (Docker/Podman) med profileringsflags (--enable-hexl i SEAL, --oblivious i OpenFHE) for at finde bottlenecks.
   • Indsaml metrikker: støjbudgetforbrug pr. operation, ciphertext-expansion ratio, CPU/GPU utilisation.
   • Automatisér via benchmark-stage i jeres CI-pipeline med GitHub Actions eller GitLab CI.
3. Pilot
   
   • Deploy delvis i produktion (fx 5 % af trafikken) med shadow-mode; HE-resultater logges, men svarer ikke brugeren.
   • Opsæt feature flags til hurtig rollback samt A/B-split mellem HE og plaintext.
   • Inddrag DPO/Compliance tidligt for at validere, at krypto-asset inventory og data-flow diagrams afspejler GDPR-krav om pseudonymisering.
4. Production
   
   • Skaler til fuld last bag API-gateway (gRPC/REST). Brug horizontal pod autoscaling baseret på jobs in queue og noise budget headroom.
   • Udrul runbooks (se nedenfor) og definer SLO’er (fx p95-latency < 800 ms, støjbudget ≥ 20 efter inferens).
   • Etabler formel post-incident review proces, hvor tabt støjbudget eller dekrypteringsfejl kategoriseres som P0-hændelser.

Integration i ci/cd & mlops

• Modelversionering: Opbevar både .onnx/.pt-filer og HE-kompilerede artefakter (CKKS graph) i MLflow eller DVC; knyt version til kryptoparameter-hash for reproducerbarhed.
• Reproducerbarhed: Brug container-images med fast base (Ubuntu LTS + clang-version) og deterministisk nøglemateriale i test (~seedede RNG’er).
• Datahåndtering: Krypterede datasæt gemmes som binaries i object storage (S3/MinIO) med server-side AES-GCM; metadata gemmes adskilt.
• Automatiserede sikkerhedstests: Kør statiske analyser (OS-capability scanning) og fuzz-test HE-API’er ved hver merge.

Nøglehåndtering

Monitorering & slo’er

Eksponer Prometheus-metrics via sidecar eller SEAL-instrumentation.

• he_latency_seconds (Histogram)
• he_throughput_ops (Counter)
• he_ciphertext_size_bytes (Gauge)
• he_noise_budget_bits (Gauge) - alarm ved < 10 bit
• he_decryption_error_total

Log kun aggregater (fx gennemsnits-latency) for at undgå datalækage. Krypter logs med server-side KMS-nøgler og anvend tamper-evident storage (WORM).

Teststrategier

1. Unit-tests: Validate ops (addmul, rot, bootstrap) med krypto-rand-testvektorer.
2. Kryptografisk regres-test: Sammenlign støjbudget efter n=10 000 operationer mod baseline.
3. Funktionelle end-to-end: Docker Compose-setup hvor klient krypterer, server infererer, klient dekrypterer.
4. Adversarial tests: Pen-test forsøg på nøgleudtræk fra memory (Cold-boot, Rowhammer) og replay-angreb på ciphertext.

Skalering & hardwareacceleration

• Parallelisering: HE-operationer er data-parallelle. Brug OpenMP/TBB eller Kubernetes-job med map-reduce approach.
• GPU: CUHE, A100 + CUDA 11 giver 3-4× speed-ups ved CKKS-matrix-multiplikation.
• FPGA: Xilinx Alveo med custom RTL-kerneler kan skubbe latency ned til sub-100 ms for real-time scoring.
• ASIC: Overvej kun til >10 k QPS workloads; projekter som Intel HE-Accel (foreslået 2024) peger på 20-40× effektivitet.

3× GPU-noder (A100, on-demand) 3 × 3,2 $/t = 9,6 $/tOrkestrering (K8s + etcd) 0,5 $/tHSM (Azure Managed HSM) 1,1 $/tTotal før reservering ~11,2 $/t

Til sammenligning: plaintext-inferens på CPU-nodes koster ~1,8 $/t; faktor≈6. Vurder om compliance-fordele opvejer merprisen.

Drift & runbooks

• Routine-check hver 15. min: Health-endpoint /he/healthz returnerer støjbudget & seneste dekrypteringsfejl.
• Incident-runbook: Hvis noise_budget_bits < 6, trigges automatisk re-encryption af batch samt skalering +1 pod.
• Backup/Restore: Krypterede batches kan lagres sikkert; secret key lagres kun i HSM, backup via secret-sharing (Shamir, 3-of-5).

Hybrid he + tee/smpc - Hvornår giver det mening?

• Dybe neurale netværk > 5 lag: Overvej TEE (Intel SGX, AWS Nitro) til fuld modelkørsel og HE til output-obfuscation.
• Cross-silo læring: Brug SMPC til model-aggregering mellem institutioner og HE til lokal inferens hos partnerne.
• Regulatoriske asymmetrier: Hvis kun en part er underlagt datalokalisering, placer compute i TEE på partnerens jord og send HE-krypteret resultat retur.

Konklusion: En succesfuld driftsmodel for homomorfisk kryptering kræver, at krypto-ingeniører, MLOps og sikkerhedsteam arbejder tæt sammen om automatiseret nøglestyring, stringent monitorering og løbende performance-optimering. Følg den trinvise plan, og vær klar til at kombinere HE med andre privacy-teknologier, hvor de forretningsmæssige og tekniske krav dikterer det.