Drives protected against the future
Drive Guard wraps your BitLocker, FileVault or LUKS key with hybrid Kyber768+X25519 + AES-256-GCM. The server never sees the plaintext key. Not today, not when quantum arrives.
The problem with legacy BitLocker
Modern FDE (BitLocker, FileVault, LUKS) uses AES-256 — that survives quantum. But recovery key and key escrow use RSA-2048 or ECC P-256. An attacker who copies the disk today and breaks classical KEM in 2030 decrypts everything retroactively. That's called "harvest now, decrypt later".
Without Drive Guard
- • DEK protected by RSA-2048 in AD/DS or iCloud
- • Recovery key exported in plaintext in BitLocker
- • No centralized risk or rotation control
- • Backup recovery exposed to quantum rupture
With Drive Guard
- • DEK wrapped in Kyber768+X25519+AES-256-GCM
- • Private key in TPM / Secure Enclave — never exportable
- • Unified console with risk score and policies
- • Split-knowledge recovery (URL+code)
Native OS-level integration
The agent talks to each OS native API — does not replace hardware AES crypto, only hardens recovery keys.
Windows
BitLockerIntercepts BitLocker PIN and recovery password; wraps with Kyber768+X25519. Hardware: TPM 2.0 required.
macOS
FileVaultGenerates personal and institutional recovery keys; pairs with Secure Enclave for PQ private key storage.
Linux
LUKS / LUKS2Uses LUKS2 tokens to associate PQ key-slots; software TPM fallback when no hardware available.
How it works — 5 steps
Enroll
Agent generates Kyber768+X25519 keypair on device, stores private in TPM/Secure Enclave. Sends public key to server.
Intercept
On FDE key creation (BitLocker/FileVault/LUKS), agent intercepts DEK (Data Encryption Key) via each OS native API.
Wrap PQ
DEK is encrypted with AES-256-GCM using key derived from post-quantum KEM. Resulting blob never leaves device in plaintext.
Escrow
Wrapped blob is sent to PosQuantum server (encrypted in transit via mTLS). Server only stores metadata + opaque blob.
Fleet + Recovery
Admin sees fleet + risk state. On recovery, link+code generated (separate channels) and agent decaps with local private key.
Native FDE vs Drive Guard
| Capability | Native FDE | Drive Guard |
|---|---|---|
| Protects DEK against "harvest now, decrypt later" | — | |
| Key escrow in cloud KMS | — | |
| Multi-channel recovery (URL+code) | — | |
| Fleet console with risk and compliance | — | |
| Programmatic DEK rotation | — | |
| Native OS-level FDE |
Standards and compliance
Drive Guard maps to recognized controls. Formal certifications are target for Gate γ — we make no claims we can't prove.
Storage encryption guideline
ML-KEM (Kyber) — post-quantum KEM
Cryptographic key management
Cryptographic controls
Target (cert at Gate γ)
Follow the development
The architecture, server, fleet console and recovery flows are ready. The desktop agent is under construction. Want to be notified when it becomes available for testing? Use the contact form.
Notify me