Disco protegido contra o futuro
Drive Guard encapsula a tua chave de BitLocker, FileVault ou LUKS com Kyber768+X25519 híbrido + AES-256-GCM. O servidor nunca vê a chave em claro. Nem hoje, nem quando chegar o quantum.
O problema com BitLocker «à antiga»
FDE moderna (BitLocker, FileVault, LUKS) usa AES-256 — isso sobrevive ao quantum. Mas o recovery key e o key escrow usam RSA-2048 ou ECC P-256. Um atacante que copia o disco hoje e rompe a KEM clássica em 2030 decifra tudo retroativamente. A isso chama-se “harvest now, decrypt later”.
Sem Drive Guard
- • DEK protegida por RSA-2048 no AD/DS ou iCloud
- • Recovery key exportada em texto claro no BitLocker
- • Sem controlo centralizado de risco ou rotação
- • Backup recovery exposed to quantum rupture
Com Drive Guard
- • DEK encapsulada em Kyber768+X25519+AES-256-GCM
- • Chave privada no TPM / Secure Enclave — nunca exportável
- • Console unificado com risk score e policies
- • Recuperação split-knowledge (URL+código)
Integração nativa por sistema operativo
O agent fala com as APIs nativas de cada OS — não substitui a criptografia AES de hardware, apenas blinda as chaves de recuperação.
Windows
BitLockerIntercepta PIN e recovery password BitLocker; encapsula em Kyber768+X25519. Hardware: TPM 2.0 obrigatório.
macOS
FileVaultGera chaves personal e institutional recovery; arma-se com Secure Enclave para guardar a PQ private key.
Linux
LUKS / LUKS2Usa LUKS2 tokens para associar key-slots PQ; fallback com software TPM quando não há hardware.
Como funciona — 5 passos
Enrol
Agent gera par de chaves Kyber768+X25519 no dispositivo, armazena private key em TPM/Secure Enclave. Envia pública para servidor.
Intercept
Na criação de chave FDE (BitLocker/FileVault/LUKS), o agent intercepta o DEK (Data Encryption Key) via API nativa de cada OS.
Wrap PQ
DEK é cifrada com AES-256-GCM usando chave derivada do KEM pós-quântico. Blob resultante nunca deixa o dispositivo em claro.
Escrow
Blob encapsulado é enviado para servidor PosQuantum (cifrado em trânsito com mTLS). Servidor só guarda metadata + blob opaco.
Fleet + Recovery
Admin vê frota + estado de risco. Em recuperação, gera-se link+código (canais separados) e o agent faz decap com a chave privada local.
FDE nativo vs Drive Guard
| Capacidade | BitLocker/FileVault/LUKS | Drive Guard |
|---|---|---|
| Protege DEK contra "harvest now, decrypt later" | — | |
| Chave escrow em KMS cloud | — | |
| Recuperação multi-canal (URL+código) | — | |
| Console de frota com risco e compliance | — | |
| Rotação programática de DEK | — | |
| Criptografia FDE nativa ao OS |
Normas e conformidade
Drive Guard mapeia-se contra controlos reconhecidos. Certificações formais são alvo de Gate γ — não fazemos claims que não podemos provar.
Criptografia de storage
ML-KEM (Kyber) — KEM pós-quântica
Gestão de chaves criptográficas
Controlos criptográficos
Alvo (certif. em Gate γ)
Acompanhe o desenvolvimento
A arquitetura, servidor, console de frota e fluxos de recuperação estão prontos. O agent desktop está em construção. Quer ser informado quando estiver disponível para teste? Use o formulário de contacto.
Quero ser informado