End-to-end encryption.
Experience it live.

Type any text below to see it encrypted client-side using the same AES-256-GCM algorithm we use for patient records. Your input never leaves your browser in plaintext.

PLAINTEXT INPUT
AWAITING INPUT

Encrypted output will appear here…

This demo uses a simplified single-pass XOR + base64 for illustrative purposes. Production uses AES-256-GCM via Web Crypto API with unique IVs per record.

The complete security flow.

From first keypress to vault storage — every step in the MediVault data pipeline.

01

Authentication

Multi-factor authentication via TOTP and hardware key. Session tokens expire after 30 minutes of inactivity.

02

Key Derivation

Your session key is derived from your identity token using PBKDF2 with 310,000 iterations. Never stored server-side.

03

Client-Side Encryption

Data is encrypted in your browser using Web Crypto API before any network transmission. AES-256-GCM with unique IV per record.

04

Encrypted Transmission

TLS 1.3 with HSTS strict transport. Certificate pinning in native apps. All payloads are opaque blobs to our infrastructure.

05

HSM Storage

Encrypted blobs are stored in sharded vaults backed by hardware security modules in Zurich. Shard reconstruction requires quorum.

06

Integrity Verification

HMAC-SHA512 tag checked on every read. Audit event written atomically. Any tampered record is quarantined automatically.

Developer-first API.

Full FHIR R4 REST API with OpenAPI 3.1 specification. SDKs available for TypeScript, Python, and Java. Webhook support for real-time audit events.

FHIR R4OpenAPI 3.1TypeScript SDKPython SDKJava SDKWebhooks
TypeScript · vault-write.ts
// Write encrypted patient record
import { MediVault } from "@medivault/sdk"

const vault = new MediVault({
  apiKey: process.env.VAULT_KEY,
  region: "ch-zurich-1"
});

await vault.records.write({
  patientId: "pat_7f2a9c",
  data: record,
  encrypt: true,
});