Preprint — Not Peer Reviewed
← Back to OBERISK

OBERISK: A Post-Quantum Privacy-Preserving Healthcare Protocol

Authenticated Encrypted Governance for Immutable Health Systems
Arushi Mallarapu
New York University
March 2026 · Preprint
Abstract

We propose OBERISK, a post-quantum healthcare protocol design that combines encrypted computation, transparent integrity proofs, anonymous credentials, and healthcare-scoped governance. OBERISK composes four cryptographic primitives — STARKs with FRI polynomial commitments, TFHE fully homomorphic encryption, lattice-based anonymous credentials, and a sovereign rollup over a modular data availability layer — into a unified architecture whose intended security reduces to standard lattice and hash-based hardness assumptions. We provide a formal threat model, outline the composition-soundness problem, present preliminary benchmark results from a working TFHE micro-demo (completed March 2026), define an implementation roadmap, and analyze the political economy of adoption by incumbents (Epic, UnitedHealth, pharma, insurers).

1. Problem Statement

1.1 The Crisis

In February 2024, the BlackCat (ALPHV) ransomware group breached UnitedHealth's Change Healthcare platform, exposing the protected health information of approximately 100 million Americans. The attack disrupted claims processing for weeks, delayed patient care nationwide, and triggered cascading identity theft and insurance fraud. UnitedHealth paid a $22 million ransom. This was not an anomaly; it exposed structural weaknesses in the current architecture.

The U.S. healthcare data ecosystem is built on a contradiction: it demands both universal accessibility (any authorized provider, insurer, or pharmacist must access records quickly) and absolute confidentiality (unauthorized disclosure violates HIPAA, causes material harm, and erodes human dignity). Current systems resolve this contradiction badly — they encrypt data at rest and in transit, then decrypt it completely the moment any authorized party needs access. The security boundary is a password, a session token, a VPN. Once inside, everything is plaintext.

1.2 Why Existing Solutions Fail

ApproachFailure Mode
Perimeter security (firewalls, MFA)BlackCat entered via stolen credentials — perimeter was intact
Encryption at rest (AES-256)Data must be decrypted for every query, creating plaintext windows
Access control listsStaff share passwords routinely; healthcare consistently has the highest rate of insider-involved breaches of any industry (Verizon DBIR)
Audit logsDetect breaches after they happen; do not prevent exfiltration
Blockchain (existing projects)MedRec, Medicalchain, BurstIQ — none use post-quantum crypto, none compute on encrypted data, none provide anonymous credentials

1.3 The Core Insight

The problem is not who can access the data. The problem is that access requires decryption. If we can compute on encrypted data, verify integrity without trusted setup, and authenticate identity without revealing it — all under assumptions that survive quantum computers — then we eliminate the plaintext window entirely.

This is now technically feasible. The primitives matured between 2021 and 2025, and as of March 2026 we have a working TFHE micro-demo validating the narrower computation-on-ciphertext claim. We are not aware of a prior healthcare proposal that combines these elements in this exact way, but that prior-art claim should be treated as provisional pending deeper review.

2. Background & Related Work

2.1 STARKs and the FRI Protocol

Scalable Transparent Arguments of Knowledge (STARKs) were introduced by Ben-Sasson et al. (2018) and have undergone rapid maturation through ethSTARK (2021), eSTARK (2023), and Circle STARKs (2024).

Relevance to OBERISK: STARKs prove that state transitions on the health record ledger are correct — every update, access, and modification is verifiable without re-executing the computation. Quantum resistance is native, not bolted on.

2.2 TFHE: Fully Homomorphic Encryption

TFHE (Torus Fully Homomorphic Encryption) was advanced by Chillotti et al. (2021-2024) with programmable bootstrapping, enabling arbitrary computation on encrypted data.

Relevance to OBERISK: Patient records are encrypted under TFHE. When a doctor queries "does this patient have a penicillin allergy?", the query executes on ciphertext. The doctor receives the decrypted answer ("yes" or "no") but never sees the full record. The record is never in plaintext on any server, at any time. — validated experimentally in Section 5.

2.3 Lattice-Based Anonymous Credentials

Anonymous credential systems allow a holder to prove possession of attributes (age > 18, has_condition = diabetes) without revealing their identity or enabling cross-session linkability.

Relevance to OBERISK: A patient presents a credential proving "I have been diagnosed with Type 2 diabetes and my A1C is above 7.0" to a pharmaceutical company's smart contract, without revealing their name, hospital, doctor, or any other medical history. The pharma company's Ozempic eligibility contract verifies the proof and approves the prescription. The patient's identity is never linked between presentations.

2.4 Sovereign Rollups and Modular Data Availability

Modular blockchain architecture separates three functions that monolithic chains bundle together:

  1. Data Availability (DA): Guarantee that transaction data is published and retrievable. (Celestia, EigenDA — Al-Bassam et al., 2023)
  2. Consensus/Ordering: Agree on transaction order.
  3. Execution: Compute state transitions.

A sovereign rollup handles its own execution and consensus, posting data to a DA layer for availability guarantees. Unlike L2 rollups (which settle on an L1), sovereign rollups define their own fork-choice rules — they are not subject to the governance of an external chain.

Relevance to OBERISK: Healthcare governance must be sovereign — upgrade decisions, validator admission, and privacy rules should be controlled by a healthcare consortium (hospitals, patient advocates, regulators), not Ethereum's validator set or Solana's foundation. The DA layer provides cryptographic availability guarantees without governance coupling.

2.5 NIST Post-Quantum Cryptography Standardization

In August 2024, NIST finalized the first wave of post-quantum cryptographic standards:

These standardizations validate the lattice and hash-based hardness assumptions on which OBERISK relies. The Module-LWE/SIS assumptions underlying our anonymous credential layer are the same assumption family that underpins ML-KEM and ML-DSA, now NIST-standardized. This significantly de-risks OBERISK's foundational cryptographic assumptions.

2.6 Alternative FHE Libraries and Compilers

Several FHE frameworks exist beyond Zama's Concrete/tfhe-rs. For context:

The choice of Concrete for OBERISK is driven by its compiler abstraction — healthcare developers should write eligibility logic in Python, not hand-craft FHE circuits. However, OpenFHE provides a viable alternative backend if Concrete's licensing or performance characteristics change.

3. OBERISK Architecture

3.1 System Overview

STAKEHOLDERS
Patient  ·  Doctor  ·  Pharma  ·  Insurer  ·  Researcher
▼
LATTICE-BASED ANONYMOUS CREDENTIALS
Selective disclosure · Unlinkable presentations · Module-LWE / Module-SIS · Post-quantum
▼
TFHE COMPUTATION LAYER
Encrypted queries · Programmable bootstrapping · Records NEVER decrypted · LWE-based
▼
STARK VALIDITY PROOFS
State transition integrity · FRI commitments · No trusted setup · Hash-based (quantum-safe)
▼
SOVEREIGN ROLLUP (OBERISK CHAIN)
Healthcare-specific execution · Consortium governance · Custom state machine · Validator admission
▼
DATA AVAILABILITY LAYER (Celestia/EigenDA)
DAS verification · Namespace Merkle Trees · Availability without governance coupling

3.2 Data Flow: Patient Record Update

  1. Doctor authenticates via lattice-based credential → proves "board-certified cardiologist at Hospital X." The doctor's identity is verified and logged.
  2. Patient grants consent — the doctor requests access to the patient's aggregated record. The patient approves via biometric, passphrase, or pre-authorized consent policy.
  3. Full aggregated record accessible — the doctor can view the complete record, aggregated from all providers, labs, and specialists. X-rays, specialist notes, and lab results from different institutions appear in a single unified profile.
  4. Every access is timestamped — the doctor's name, what they viewed, and the exact time are permanently logged on-chain. The patient can see the full audit trail at any time.
  5. Doctor submits encrypted update — the new record entry (e.g., echocardiogram results) is encrypted under the patient's TFHE public key before leaving the doctor's device.
  6. OBERISK chain validates — a STARK proof verifies that the state transition (old_record → new_record) follows the protocol rules (authorized updater, valid schema, correct timestamp).
  7. Insurance query — insurer submits an encrypted query against the patient's encrypted record. TFHE computation returns "patient qualifies for coverage tier 2" without the insurer ever seeing the underlying diagnosis, test results, or treatment history.

3.3 Data Flow: Pharmaceutical Drug Eligibility (Smart Contract)

  1. Pharma company deploys eligibility contract — "Patient must have: (a) diagnosis of Type 2 diabetes, (b) A1C > 7.0, (c) BMI > 30, (d) no contraindicated conditions."
  2. Patient's credential issuer (their hospital) issues a lattice-based anonymous credential attesting to these attributes.
  3. Patient presents selective disclosure proof — reveals only "meets criteria (a), (b), (c), (d) = true" without revealing actual A1C value, BMI, or any other data.
  4. Smart contract verifies the ZK proof on-chain, marks the patient as eligible, and issues a prescription authorization token.
  5. Pharmacy fills prescription — verifies the authorization token (also a credential presentation), dispenses medication.

At no point did the pharmaceutical company learn the patient's name, specific A1C level, BMI, hospital, or doctor.

4. Security Analysis

4.1 Threat Model

AdversaryCapabilityOBERISK Defense
External attacker (BlackCat-class)Compromises server, exfiltrates databaseData is TFHE-encrypted; exfiltrated ciphertext is computationally indistinguishable from random under LWE
Malicious insider (staff with credentials)Authorized access, attempts to exfiltrate beyond scopeTFHE queries return only authorized function outputs; full record never decrypted
Colluding verifiersMultiple parties attempt to correlate patient across interactionsLattice-based credentials are unlinkable; presentations are rerandomized
State-level quantum adversary (2035+)Runs Shor's algorithm on captured ciphertextsAll primitives (STARKs, TFHE, lattice credentials) are post-quantum; no elliptic curves in the stack
Malicious validatorAttempts to censor or reorder transactionsBFT consensus with f < n/3 tolerance; DA sampling ensures availability
Compromised keyPatient's TFHE secret key is stolenKey rotation protocol: patient issues re-encryption request; old ciphertext is re-encrypted under new key via proxy re-encryption (lattice-based, Polyakov et al. 2022)

4.2 Composition Soundness

The critical research question: do these primitives compose securely, or does combining them introduce vulnerabilities absent from each individually?

Theorem (informal): If STARKs are sound (collision-resistant hash), TFHE is IND-CPA secure (LWE), and anonymous credentials are unforgeable + unlinkable (Module-LWE/SIS), then OBERISK provides:

  1. Integrity: No computationally bounded adversary can forge a valid state transition proof (STARK soundness).
  2. Confidentiality: No adversary learns anything about patient data beyond authorized function outputs (TFHE IND-CPA + circuit privacy).
  3. Anonymity: No adversary can link two credential presentations by the same patient (credential unlinkability).
  4. Post-quantum security: All guarantees hold against quantum adversaries with polynomial quantum resources.

Proof sketch: By hybrid argument. Assume adversary A breaks OBERISK. We construct adversary B that either:

Since the primitives operate on independent inputs (STARK proves over commitments, TFHE encrypts data, credentials authenticate identity), their security games are separable. The composition does not introduce cross-primitive attack surfaces because:

Formal proof is the core research deliverable of this project.

4.3 Formal Security Definitions (Stubs)

The following formal definitions will be fully developed as part of the core research deliverable. We provide stubs here to clarify the precise security properties we aim to prove.

Note: Full formal treatment of these definitions and their composition is the core research deliverable.

4.3.1 IND-CPA Security Game for TFHE (in literature for individual primitive)

Game IND-CPA_TFHE(A, λ):
  1. (pk, sk) ← TFHE.KeyGen(1^λ)
  2. b ←$ {0,1}
  3. (m₀, m₁, state) ← A₁(pk)            // Adversary chooses two messages
  4. c* ← TFHE.Encrypt(pk, m_b)            // Challenger encrypts m_b
  5. b' ← A₂(c*, state)                    // Adversary guesses b
  6. Return (b = b')

  Advantage: Adv^{IND-CPA}_{TFHE}(A) = |Pr[b' = b] - 1/2|

  Security requirement: For all PPT adversaries A,
    Adv^{IND-CPA}_{TFHE}(A) ≤ negl(λ)

  Reduction: Adv^{IND-CPA}_{TFHE}(A) ≤ Adv^{LWE}_{n,q,χ}(B)
    where B is a PPT adversary against the LWE problem with
    dimension n, modulus q, and error distribution χ.

OBERISK extension: We must additionally show that TFHE circuit privacy holds — i.e., that the evaluated ciphertext TFHE.Eval(pk, C, c₁,...,cₖ) reveals nothing about the circuit C beyond its output. This is critical because healthcare queries (the circuit) may themselves be sensitive.

4.3.2 STARK Soundness Definition (in literature for individual primitive)

Definition (Computational Soundness of STARK):
  A STARK system (P, V) for language L with relation R is
  computationally sound if for all PPT adversaries A:

  Pr[ V(x, π) = accept ∧ x ∉ L : (x, π) ← A(1^λ) ] ≤ negl(λ)

  Equivalently, for the FRI-based instantiation:
  Pr[ V accepts π for statement x :
      ∄ w such that R(x, w) = 1 ∧
      (x, π) ← A(1^λ) ] ≤ negl(λ)

  Soundness error: ε = O(1/|F|) per round, with ℓ rounds of
  FRI folding giving total soundness error ε^ℓ + δ_hash
  where δ_hash is the collision probability of the hash function.

OBERISK extension: We must prove that STARK soundness holds when the statement being proved involves commitments to TFHE ciphertexts — i.e., the STARK proves "this state transition on encrypted records was computed correctly" without the prover knowing the plaintext.

4.3.3 Credential Unlinkability Game (in literature for individual primitive)

Game Unlinkability(A, λ):
  1. (ipp, isk) ← Issuer.Setup(1^λ)
  2. (upk₀, usk₀) ← User.KeyGen(1^λ)
     (upk₁, usk₁) ← User.KeyGen(1^λ)
  3. cred₀ ← Issue(isk, upk₀, attrs₀)
     cred₁ ← Issue(isk, upk₁, attrs₁)
     // where attrs₀ = attrs₁ (same attributes, different users)
  4. b ←$ {0,1}
  5. π* ← Present(usk_b, cred_b, disclosure_policy)
  6. b' ← A(ipp, π*, attrs₀)
  7. Return (b = b')

  Advantage: Adv^{Unlink}(A) = |Pr[b' = b] - 1/2|

  Security requirement: For all PPT adversaries A,
    Adv^{Unlink}(A) ≤ negl(λ)

  Reduction: Adv^{Unlink}(A) ≤ Adv^{MLWE}_{n,q,χ}(B)

OBERISK extension: We must show that unlinkability holds even when the credential presentation is combined with a TFHE encrypted query — i.e., an adversary who sees both the credential proof and the TFHE query cannot link them across sessions.

4.4 Security Assumptions (Consolidated)

AssumptionPrimitiveQuantum StatusNIST Status
Collision-resistant hashing (SHA-256/Poseidon)STARKs/FRISecure (Grover gives √ speedup, mitigated by doubling output)Standardized
Learning With Errors (LWE)TFHESecure (best quantum algorithms are exponential)NIST PQC Round 4 finalist basis
Module-LWEAnonymous credentialsSecure (same family as CRYSTALS-Kyber/Dilithium)NIST standardized (Kyber=ML-KEM FIPS 203, Dilithium=ML-DSA FIPS 204, finalized Aug 2024)
Module-SISAnonymous credentialsSecure (dual of Module-LWE)Implicitly standardized via ML-DSA

The entire OBERISK stack reduces to two assumptions: hash collision resistance and lattice hardness (LWE/SIS family). This is a minimal and well-studied assumption set.

5. Preliminary Benchmarks: TFHE Micro-Demo

5.1 Overview

As of March 2026, we have completed a working micro-demo that supports a narrower claim: selected healthcare-style boolean queries can be executed on fully homomorphic encrypted data using Zama's Concrete library (Python frontend). The demo implements three representative computations of increasing complexity, all executing on TFHE-encrypted patient data.

All benchmarks were collected on a single-machine setup using concrete-python. Keygen is a one-time cost per circuit (amortized across all queries using that circuit). The execute time is the per-query cost — the time a server spends computing on encrypted data for each request.

5.2 Benchmark Results

QueryDescriptionCompile (s)KeyGen (s)Encrypt (s)Execute (s)Decrypt (s)Total (s)
Allergy LookupIs patient allergic to penicillin? (boolean match)0.5300.8810.0050.8730.0022.291
Age Range CheckIs patient age between 18 and 65? (range comparison)2.2926.1910.0052.2610.00210.751
Ozempic EligibilityA1C > 7 AND BMI > 30 AND has T2D diagnosis (compound boolean)2.45026.4940.0082.1010.00331.056

5.3 Analysis

All three queries returned correct results on real TFHE-encrypted data.

Key observations:

  1. Encrypt/Decrypt are negligible (~2-8ms). The patient-side cost of encrypting data and decrypting results is effectively instant. This means the UX burden falls on the server (compute) side, not the patient side.
  2. KeyGen scales with circuit complexity. The jump from 0.88s (simple boolean) to 26.5s (compound boolean with multiple comparisons) reflects the growth in bootstrapping key material. However, keygen is a one-time cost — once keys are generated for a circuit, they are reused for all queries against that circuit. In a production OBERISK deployment, keygen would occur during circuit deployment, not at query time.
  3. Execute time is the critical metric. Per-query latency ranges from 0.87s (allergy lookup) to 2.26s (age range check). For non-emergency healthcare workflows (prior authorization, eligibility checking, claims processing), sub-3-second latency is operationally acceptable. For emergency lookups (e.g., allergy check in an ER), the 0.87s allergy lookup approaches feasibility.
  4. Compile time is a one-time cost. The Concrete compiler translates Python to optimized TFHE circuits once; the compiled circuit is then reused. Compilation cost is irrelevant to runtime performance.
  5. Gap to real-time requirements. Emergency medical lookups ideally require ~100ms latency. Our allergy lookup at 873ms is ~9x slower than this target. Hardware acceleration (GPU-based TFHE, e.g., Zama's forthcoming Concrete GPU backend) and circuit optimization are expected to close this gap.

5.4 Implications for OBERISK

These benchmarks support a narrower technical thesis: it is possible to compute selected healthcare-style boolean queries on TFHE-encrypted data today, with latency that may already be usable for some non-emergency workflows. They do not yet validate broader clinical workloads, multi-record queries, or emergency-room response targets.

The Ozempic eligibility query is particularly significant because it implements the exact compound boolean described in Section 3.3 (A1C > 7 AND BMI > 30 AND has Type 2 diabetes). This demonstrates that the eligibility logic itself is implementable at micro-demo scale under current TFHE tooling. It does not yet validate a production prior-authorization or smart-contract deployment.

6. Failure Modes and Limitations

6.1 Key Loss Scenarios

If a patient loses their TFHE secret key, all data encrypted under that key becomes permanently inaccessible. This is the most catastrophic failure mode in a patient-sovereign system.

Mitigations:

Residual risk: All mitigation strategies introduce additional trust assumptions. Threshold schemes require that fewer than the threshold number of custodians collude. Social recovery requires that guardians remain available and honest. These are fundamental tradeoffs in patient-sovereign systems.

6.2 TFHE Performance Degradation with Complex Queries

Our benchmarks (Section 5) show that keygen time grows from 0.88s to 26.5s (30x) as query complexity increases from a simple boolean match to a compound three-condition check. This trend will worsen for more complex queries.

Projected scaling concerns:

Mitigations: Circuit optimization, batched bootstrapping (Zama's ongoing research), GPU acceleration, and limiting TFHE to targeted queries while using STARKs for aggregate computations.

6.3 Lattice Credential Proof Sizes

Current lattice-based anonymous credential constructions (Jeudy et al. 2023, Boschini et al. 2023) produce proofs approximately 100x larger than classical BBS+ signatures:

For a mobile-first healthcare application where patients present credentials at pharmacies, clinics, or via smartphone, this is a significant practical limitation. A 200 KB proof transmitted over a cellular connection adds latency; repeated presentations (e.g., multiple credential checks during a hospital visit) compound the overhead.

Mitigations: Ongoing research into more compact lattice-based credentials, proof compression techniques, and the possibility of using hash-based accumulators for certain attribute proofs. This remains an active area of cryptographic research.

6.4 Cross-Primitive Leakage Points

While our composition soundness argument (Section 4.2) claims that the primitives operate on independent inputs, there are potential information flow points that require careful analysis:

Mitigation: Traffic analysis protections (mix networks, batched submission), constant-size ciphertext padding, and formal analysis of the cross-primitive information flow. This is an open research question.

6.5 Validator Collusion Threshold

The sovereign rollup's BFT consensus tolerates at most f < n/3 Byzantine validators (where n is the total validator count). In a healthcare consortium context:

Mitigation: Diversify validator set across stakeholder types (hospitals, patient advocacy groups, academic medical centers, regulators, insurers). Require supermajority across categories, not just total count. Implement slashing conditions for detectably Byzantine behavior.

6.6 UX Challenges for Non-Technical Patients

Patient sovereignty requires patients to manage cryptographic keys, understand selective disclosure, and make informed decisions about data sharing. This creates significant UX challenges:

Mitigation: Invest heavily in UX research. Design guardian/custodian models where a patient can delegate key management to a trusted party (family member, primary care physician) without surrendering sovereignty. Use plain-language consent interfaces with visual representations of what is and is not being disclosed.

7. Interoperability with Existing Systems

7.1 FHIR Compatibility

FHIR (Fast Healthcare Interoperability Resources) is the dominant standard for health data exchange, mandated by the 21st Century Cures Act (2016) and the ONC Interoperability Rule (2020).

OBERISK does not replace FHIR. It encrypts it.

This means OBERISK is a privacy layer on top of FHIR, not a replacement. Existing EHR systems (Epic, Cerner, Allscripts) that already support FHIR R4 can integrate OBERISK as middleware without rearchitecting their data models.

7.2 Regulatory Alignment

RegulationOBERISK Compliance
HIPAA Privacy RulePatient controls all credential presentations; minimum necessary standard is mathematically enforced by TFHE (query returns only the function output, not the full record)
HIPAA Security RuleEncryption: TFHE (post-quantum). Access controls: anonymous credentials. Audit trail: STARK-verified on-chain log.
21st Century Cures ActInteroperability: FHIR-native. Information blocking: patient holds decryption keys, not providers.
HITECH ActBreach notification: moot — exfiltrated data is TFHE ciphertext, computationally useless without patient's key. Arguably, a TFHE-encrypted database theft is not a "breach" under HITECH's safe harbor provision.
EU GDPR (Art. 17, Right to Erasure)Patient revokes credential + rotates TFHE key → old ciphertext is undecryptable. Functional erasure without modifying the immutable ledger.
FDA 21 CFR Part 11Electronic signatures: lattice-based credentials provide non-repudiation. Audit trails: STARK-verified, immutable.

7.3 The Epic Question

Epic Systems holds ~38% of the U.S. acute care EHR market and a majority of U.S. patient records pass through Epic systems at some point. OBERISK does not require Epic's cooperation — but benefits enormously from it.

Three adoption vectors:

  1. Compliance coercion: ONC's HTI-1 rule (2024) tightens interoperability requirements. If CMS or ONC mandates post-quantum encryption or patient-controlled access, Epic must comply. OBERISK provides a compliance pathway.
  2. Middleware integration: OBERISK positions as a FHIR-compatible privacy layer. Epic's App Orchard marketplace already supports third-party FHIR apps. OBERISK could initially deploy as an Epic-compatible app that encrypts data flowing through FHIR APIs — no Epic source code changes required.
  3. Bypass via patient sovereignty: Under the Cures Act, patients have the right to access their data via FHIR APIs. A patient-facing OBERISK app could pull records from Epic via existing APIs, encrypt them under the patient's TFHE key, and store them on the OBERISK chain. Epic becomes a data source, not a gatekeeper.

8. Stakeholder Incentive Analysis

8.1 Why Would Incumbents Allow This?

This is the hardest question. Technical elegance is irrelevant if no one adopts it. The honest answer is that incumbents will resist — unless the incentive structure makes resistance costlier than participation.

Insurance Companies

Current incentive: Information asymmetry benefits insurers. More data = better risk pricing = more profit. Why accept a "limited access view"?

OBERISK counterargument:

Pharmaceutical Companies

Current incentive: Pharma wants maximum patient data for R&D, clinical trial recruitment, and targeted marketing.

OBERISK counterargument:

Hospitals and Providers

Current incentive: Data lock-in = patient retention. If your records are trapped in Epic, you stay with Epic-using providers.

OBERISK counterargument:

9. Implementation Roadmap

Phase 1: Formal Foundations (Months 1-6)

Status: In progress (as of March 2026, TFHE micro-demo completed)

Deliverables:

Phase 2: Prototype Implementation (Months 6-12)

Deliverables:

Phase 3: Healthcare Testnet (Months 12-18)

Deliverables:

Phase 4: Governance & Adoption (Months 18-24)

Deliverables:

10. Current Differentiators and Claimed Contributions

PropertyMedRec (MIT)MedicalchainBurstIQOBERISK
Patient data sovereigntyPartialPartialNoDesign goal (patient holds TFHE key)
Data encrypted during computationNoNoNoMicro-demo only (TFHE)
Post-quantum ZK proofsNoNoNoPlanned (STARKs)
Post-quantum encryptionNoNoNoMicro-demo only (TFHE/LWE)
Post-quantum identityNoNoNoPlanned (lattice credentials)
Anonymous, unlinkable accessNoNoNoPlanned
FHIR-native interoperabilityPartialNoNoPlanned
Sovereign governanceNoNoNoPlanned
Formal composition proofNoNoNoIn progress

We are not aware of another healthcare proposal that aims to combine all of these properties in one design, but this differentiation claim should be treated as provisional until the related-work survey is expanded further.

11. Open Research Questions

  1. TFHE performance at scale: Can programmable bootstrapping meet the latency requirements of emergency medical lookups (~100ms)? Our benchmarks (Section 5) show 873ms for a simple allergy lookup — ~9x the target. GPU acceleration and circuit optimization are expected to close this gap, but this remains unvalidated.
  2. Lattice credential proof size: Current constructions produce proofs ~100x larger than BBS+. Can we reduce this to practical sizes for mobile-first healthcare apps? See Section 6.3 for detailed analysis. (size measurements); (reduction path)
  3. Cross-primitive optimization: Can we share lattice parameters across TFHE and credential systems to reduce key material and improve efficiency?
  4. Regulatory classification: Is TFHE-encrypted data legally "de-identified" under HIPAA's Safe Harbor? This has major implications for consent requirements.
  5. Key management UX: How does a patient manage TFHE keys without creating a single point of failure? Threshold key management (Shamir secret sharing) is one approach, but the UX must be accessible to non-technical patients. See Section 6.6.
  6. Validator economics: What is the incentive model for running an OBERISK validator? Healthcare consortiums have different economic models than PoS chains. Staking may be replaced by institutional commitment + regulatory mandate.

12. References

  1. Ben-Sasson, E., et al. "Scalable, transparent, and post-quantum secure computational integrity." IACR Cryptology ePrint Archive (2018).
  2. Chillotti, I., et al. "TFHE: Fast Fully Homomorphic Encryption over the Torus." Journal of Cryptology (2021).
  3. Jeudy, C., Roux-Langlois, A., et al. "Lattice-Based Anonymous Credentials." IACR Cryptology ePrint Archive (2023).
  4. Al-Bassam, M., et al. "LazyLedger: A Lazy Blockchain for Modular Data Availability." arXiv (2019).
  5. Spiegelman, A., et al. "Bullshark: DAG BFT Protocols Made Practical." ACM CCS (2022).
  6. Kothapalli, A., Setty, S., Parno, B. "Nova: Recursive Zero-Knowledge Arguments from Folding Schemes." CRYPTO (2022).
  7. Gabizon, A., Williamson, Z., Ciobotaru, O. "PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge." IACR ePrint (2019).
  8. Polyakov, Y., et al. "Lattice-Based Proxy Re-Encryption." IEEE Access (2022).
  9. Zama. "Concrete: TFHE Compiler for Encrypted Computation." (2023-2024). https://github.com/zama-ai/concrete
  10. W3C. "Decentralized Identifiers (DIDs) v1.0." (2022).
  11. W3C. "Verifiable Credentials Data Model v2.0." (2024).
  12. Boschini, C., et al. "Efficient Lattice-Based Anonymous Credentials." PKC (2023).
  13. Tessaro, S., Zhu, C. "Revisiting BBS Signatures." EUROCRYPT (2023).
  14. StarkWare. "ethSTARK Documentation." (2021-2024).
  15. Verizon. "2024 Data Breach Investigations Report." (2024).
  16. IBM Security. "Cost of a Data Breach Report 2023." (2023).
  17. NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)." (2024).
  18. NIST. "FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)." (2024).
  19. NIST. "FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)." (2024).
  20. Haböck, U., et al. "Circle STARKs." IACR ePrint (2024).
  21. Zama. "tfhe-rs: A Pure Rust Implementation of TFHE." (2023-2025). https://github.com/zama-ai/tfhe-rs
  22. Microsoft Research. "Microsoft SEAL: Fast and Easy-to-Use Homomorphic Encryption Library." (2018-2025). https://github.com/microsoft/SEAL
  23. Palisade/OpenFHE Consortium. "OpenFHE: Open-Source Fully Homomorphic Encryption Library." (2022-2025). https://github.com/openfheorg/openfhe-development

Acknowledgments

The author would like to thank Dr. Ravinder Mallarapu for guidance and mentorship on this work. Dr. Mallarapu brings 25 years of experience in financial research technologies, cybersecurity, and applied machine intelligence, including published work on cybersecurity data breach prevention systems.