Technical architecture, cryptographic stack, and implementation guide for privacy-preserving medical AI.
Overview
Zkure functions as a "Trustless Sidecar"—a secured software container that sits inside the hospital's firewall. It acts as a cryptographic notary: it observes the AI running on patient data and stamps a mathematical seal of approval (the Proof) on the result.
This architecture solves the fundamental tension between hospitals (who can't share patient data) and AI vendors (who need to bill for their models). The proof cryptographically guarantees the computation happened correctly—without revealing the underlying data.
Key Insight
A 50MB CT scan never leaves the hospital. Only a 4KB proof travels to the vendor—yet the vendor can still verify the AI ran correctly and bill accordingly.
The Three Pillars
1
The Prover (Hospital)
A local server (Docker container) that holds the patient data and runs the AI model. Generates ZK proofs for each inference.
2
The Verifier (Vendor)
A lightweight cloud API that receives the Proof + Result. Checks validity before issuing a bill or insurance claim.
3
The Circuit (Math)
The pre-compiled "map" of the AI model that ensures the computation was performed correctly on authentic inputs.
Cryptographic Stack
EZKL (Easy Zero-Knowledge Learning)
Acts as a "Transpiler"—takes a standard AI model (ONNX format) and converts it into a Halo2 Circuit. EZKL handles "Quantization" automatically, converting floating-point math into the integer math required for cryptography.
Halo2 with KZG Commitments
The underlying mathematical engine. Uses KZG (Kate-Zaverucha-Goldberg) Commitments, allowing the vendor to "commit" to a model polynomial. The proof asserts:
"The execution trace matches the committed polynomial (Model) and the private witness (Data)."
ONNX Model Format
Universal file format for neural networks. PyTorch, TensorFlow, or Scikit-Learn all export to .onnx, making Zkure compatible with most ML frameworks.
Data Flow
Phase A: The Handshake (One-Time Setup)
Model Commitment
AI Vendor hashes their FDA-approved model weights using KZG scheme. Hash is published to a smart contract or public bulletin.
Circuit Generation
Vendor generates two keys: Proving Key (PK) (large, sent to hospital) and Verification Key (VK) (tiny, kept by vendor).
Phase B: Patient Encounter (Hospital Premise)
Ingestion
Hospital PACS sends image via DICOM. Sidecar intercepts, strips PII (name, ID), extracts raw pixel array.
Normalization
Pixels resized/normalized to model input tensor shape (e.g., 256x256x1).
Private Inference
Container runs AI model on pixel array. Result: "Nodule Probability: 94%"
Proof Generation
Prover wraps the execution trace into a ZK-SNARK proving: "I know a private input which yields this output."
Vendor API runs Verify(proof, output, vk)—checks if proof fits the verification key.
Settlement
If valid: log billable event. If invalid: reject request (tampering detected).
Hospital IT Integration
Imaging (Radiology)
Act as DICOM Node
Hospital configures our IP as "Destination"
Listen on Port 104 (standard DICOM port)
Compatible with all major PACS systems
Tabular Data (Labs/EMR)
Act as HL7/FHIR Listener
Listen for ORU (Observation Result) messages
Parse JSON/XML payload for values (Hemoglobin, WBC, Glucose)
Compatible with Epic, Cerner, and other major EMR systems
Security & IP Protection
The Challenge
To generate a ZK Proof, the Prover (Hospital) needs access to the circuit—which includes model weights. A sophisticated adversary could potentially extract weights from the Proving Key.
Enterprise Solution: TEE + ZK Hybrid
Combine ZK with Trusted Execution Environment (TEE):
Intel SGX, AMD SEV, or AWS Nitro Enclaves
Hospital runs an encrypted "Black Box" (TEE)
Model decrypted only inside CPU's secure enclave
ZK Proof generated inside enclave
Result: Hospital admin sees the proof but cannot see model weights or raw patient data during computation.
MVP Specifications
15-20
LogRows (Circuit Size)
<2s
Tabular Data Latency
~30s
Image Latency
16GB
RAM Requirement
~4KB
Proof Size
$0.50-5
Per Inference
Using the Demo
Our interactive demo simulates the complete Zkure workflow in your browser.
What the Demo Shows
Hospital View (Left) — Enter patient health metrics (glucose, blood pressure, age, BMI). This data stays local.
ZK Proof Animation (Center) — Watch the cryptographic proof travel from hospital to vendor.
Vendor View (Right) — See verification logs and billing. Note: patient data appears as ████████ (redacted).
Demo Limitations
The browser demo uses SHA-256 hashing to simulate proof generation. In production: