Zero-Knowledge Cryptography & Passkeys
How does ConsentCollect enforce a Zero-Knowledge security architecture?
In clinical research and healthcare operations, protecting Patient Health Information (PHI) is not just a regulatory mandate—it is a core ethical duty. Standard web platforms typically store patient records in databases where server administrators, cloud host operators, or system scripts can view the records in plaintext. If the server is breached, the patient data is fully exposed.
ConsentCollect solves this by operating on a strict Zero-Knowledge Client-Side Cryptographic Architecture. Under this model, all sensitive patient details, consent form disclosures, specific doctor-patient review comments, and signature profiles are encrypted directly in the clinician’s browser before they are sent to the cloud. The platform server only acts as a secure, blind ledger storing encrypted, opaque data blocks.
The Zero-Knowledge Non-Recovery Policy
[!WARNING] Because ConsentCollect operates on pure mathematical zero-knowledge boundaries, plaintext keys, recovery passphrases, and decrypted records are never stored, sent, or logged by our servers.
If a clinical primary administrator or workspace owner loses their 4-word Master Recovery Passphrase and does not have an active passkey set up on their browser:
- The entire workspace is permanently locked and unrecoverable.
- ConsentCollect support staff cannot reset access, reset your master keys, or decrypt your records.
You must write your 4-word Master Recovery Passphrase down physically and store it in a secure location (such as a clinical safe or institutional vault).
How does the key hierarchy secure your workspace?
ConsentCollect secures clinical operations using a multi-tiered cryptographic key hierarchy, generated and managed entirely inside the browser:
4-Word Master Recovery Passphrase
The core clinical administrator passphrase generated client-side during onboarding. Never transmitted online.
Symmetric Passphrase Key
Strong key derived off-thread. Used strictly locally to encrypt and decrypt the user's asymmetric credentials.
RSA Asymmetric Keypair
Unique Public Lock Key (stored on server) and Private Key (stored non-extractable locally). Secures workspace handoffs.
Master Workspace Key
The core symmetric key that encrypts and seals all templates, intake lists, and patient forms.
Clinical Forms & Patient Records
Plaintext PHI, medical histories, and digital signatures encrypted client-side before cloud synchronization.
1. The Master Workspace Key
The core of your organization’s security is the Workspace Key. This is a highly robust, 256-bit symmetric key (AES-GCM) generated client-side the moment your organization is registered. It is used to encrypt and decrypt all clinic templates, draft forms, patient intake lists, and completed consent packages.
2. The Asymmetric Keypair
To share workspace access securely with newly invited clinical coordinators without sharing master passwords, each user generates a unique pair of cryptographic keys:
- The Public Lock Key: Stored openly on the platform server. It allows other authorized workspace members to securely encrypt (wrap) the master Workspace Key for you.
- The Private Key: Secured in the local browser. It is the only key capable of unlocking the master Workspace Key once it has been wrapped.
3. The Passphrase Key
To protect your Private Key when it is stored in the database, the browser derives a strong symmetric key from your 4-word Master Recovery Passphrase:
- One-Way Key Derivation: The system runs your passphrase through a highly resource-intensive, browser-native derivation algorithm that mathematically locks the input, preventing brute-force or pre-computation attacks.
- Per-User Random Salt: A fresh, random cryptographic salt is generated for each user client-side. This ensures that even if two users choose similar passphrases, their derived keys are completely different, neutralizing rainbow table attacks.
What local device sandboxing protections are in place?
Even with strong encryption, keys can be vulnerable if they are exposed in the browser’s memory or cleared unexpectedly. ConsentCollect implements advanced local safeguards:
Off-Thread Cryptographic Workers
All resource-intensive cryptographic math (like strong key derivation and massive file encryption) is offloaded to a background Dedicated Web Worker. This keeps the calculations isolated off the main interface thread, ensuring that clinical coordinators experience a fluid, lag-free dashboard while maximum security is enforced in the background.
Non-Exportable Local Key Sandboxing
To keep the clinical workspace active without forcing coordinators to re-enter their credentials on every page refresh, key handles are cached securely inside the browser’s local sandbox keystore.
- Non-Exportable Security Boundary: The keys are imported into the browser’s cryptographic engine with a strict hardware-backed configuration setting them as non-exportable. Once imported, the raw mathematical bytes of the Private Key and Workspace Key are locked within the browser’s security boundary and can never be read or exported by external JavaScript.
- Even if a malicious browser extension, external script, or compromised library attempts to scan the browser memory or query the local databases, the browser itself mathematically blocks the extraction of the raw key bytes. The keys can only be invoked for on-device encryption or decryption operations.
Guaranteed Storage Persistence
To prevent the browser from randomly erasing these secure key caches during aggressive disk cleanups or low-storage sweeps, the system requests browser-native persistent storage authorization upon workspace initialization. This ensures the cryptographic database remains locked to the authorized workstation.
How are form disclosures and patient envelopes sealed?
When patient data is saved, it is split into highly secure containers:
- Symmetric Form Seals: All clinical form sections, procedural risk matrices, checkboxes, and descriptions are encrypted client-side using AES-256-GCM. The server only receives an opaque base64 string containing a random 12-byte Initialization Vector (IV) and the encrypted payload accompanied by a Galois authentication tag.
- Per-Signer Cryptographic Envelopes (HKDF): Patients entering the signing portal do not have access to the clinician’s master Workspace Key. Instead, the clinician’s browser derives a separate, single-use Signer Session Key using a Hash-based Key Derivation Function (HKDF). This key is mathematically derived from the patient’s unique Access Token (delivered via secure multi-channel OTP) and the Form ID. The clinician encrypts a dedicated copy of the disclosure fields under this key, creating a private “envelope” that the patient can decrypt locally using only their token, without ever exposing the master workspace credentials.
Secure Chats & Active Review Sessions
- Encrypted Peer Reviews: When clinical teams or Institutional Review Boards (IRBs) review a draft form, their comments and any referenced selected text are cryptographically sealed. The encryption keys are derived client-side from a shared clinical PIN and the unique Review ID, keeping internal discussions private.
- End-to-End Encrypted Clinical Chat: Active chats between patients and clinicians are cryptographically sealed off-thread. The system derives a Chat Session Key using the Form ID as salt and the secure PIN. Chat logs are encrypted client-side, and the channel is instantly closed and the keys neutralized once the patient signs the final consent document, preventing any retroactive communication leaks.
Passkey Biometric Vaults & Key Splitting Fallback
To provide a seamless clinic experience without typing the 4-word mnemonic for every session, administrators can set up a Biometric Passkey (WebAuthn). When you perform a biometric scan (TouchID, FaceID, or Windows Hello), the browser creates a local Biometric Vault using one of two secure paths:
Hardware Biometric Key Wrapping
Used on devices with platform biometric hardware key derivation support.
Clinician initiates a biometric gesture scan (TouchID / FaceID).
Secure hardware check derives a unique device-bound key offline.
Hardware key decrypts the local biometric vault to restore session keys.
XOR-Based Key Splitting
Automatic fallback on devices without hardware key derivation capabilities.
Clinician initiates a biometric gesture scan (e.g. platform pin/gesture).
Browser fetches the secure server-side share upon successful biometric validation.
Browser XOR-combines the server share with the local share to reconstruct keys in memory.
Path A: Hardware-Bound Key Wrapping
On modern biometric-enabled devices, the browser utilizes platform-native hardware key derivation.
- The user’s biometric hardware token derives a unique, device-bound cryptographic wrapping key.
- The browser uses this hardware key to encrypt the derived credentials, saving it as a secure biometric vault blob locally on the device.
- During login, a simple biometric gesture generates the hardware wrap key, which decrypts the biometric vault blob locally to recover the credentials and unlock the workspace.
Path B: XOR-Based Key Splitting
For platforms that do not support hardware biometric key derivation, ConsentCollect automatically falls back to an advanced split-key secret sharing protocol:
- The browser generates a cryptographically random local share and saves it securely inside the local hardware keystore.
- The browser computes a second, independent security share using a mathematical one-way split operation.
- This second share is uploaded and stored securely on the platform server.
- The Security Boundary: Neither the server nor the local computer possesses the full credential on its own. When the user logs in and passes the biometric challenge, the server releases the remote share, which the browser mathematically combines with the local share to reconstruct the credential in active memory. Because neither share alone contains sufficient mathematical data to recreate the key, intercepted database records or compromised local storage are completely useless to an attacker.
Onboarding Passkeys vs. Patient Biometric Seals
- Onboarding Passkeys: Clinicians and coordinators register their platform passkeys to establish their local biometric vaults, securing active session keys on their workstation.
- Patient Biometric Seals: At the final step of the sequential signing portal, patients scan their fingerprint or face to lock their unique HMAC Signature Seal. This provides cryptographically solid proof of presence, certifying their active consent and tying the execution state directly to their legal identity.