Vault (E2EE)
End-to-End Encrypted Storage
The Vault is a private, per-user encrypted file area accessed through Drivebase. Because Drivebase is a self-hosted solution, it's important to understand how your data is protected from the server infrastructure itself.
In the Vault, all files are encrypted client-side (on your device) before they are sent to your storage provider. Providers like Google Drive, S3, and Dropbox receive encrypted files (ciphertext), not plaintext.
Even as the administrator of your own Drivebase instance, you cannot access files stored in a user's vault without their passphrase.
Security Architecture
Zero-Knowledge Design
Drivebase uses a zero-knowledge architecture for Vault. Files are encrypted before they are sent to your storage provider, so providers only receive encrypted data (ciphertext), not plaintext.
Key Hierarchy
Your Vault is secured by a Passphrase-derived Key Encryption Key (KEK).
- The KEK is derived from your Passphrase using PBKDF2 (310,000 iterations, SHA-256, random 16-byte salt). This KEK is never stored.
- The KEK encrypts your Private Key (AES-GCM 256-bit). The encrypted private key is stored in the database.
- Your Public Key (P-256 ECDH) is used to generate an Encrypted File Key (ECIES) for every file you upload.
- The File Key encrypts the actual File Content (AES-GCM 256-bit) before it leaves your device for the provider upload path.
Session Security & Non-extractable Keys
After you enter your passphrase to unlock the Vault, the decrypted P-256 private key is imported into your browser's Web Crypto API with extractable: false. This means the raw key cannot be exported or leaked by malicious scripts.
Furthermore, the decrypted key lives only in volatile memory. Closing or refreshing the browser tab clears it instantly, requiring you to re-enter your passphrase to access the Vault again.
User Workflows
Vault Setup
When accessing the Vault for the first time, you will be guided through a setup wizard:
- Explanation: Understanding the implications of End-to-End Encryption.
- Passphrase Creation: Choosing a strong, memorable passphrase.
- Backup Key: Downloading a JSON backup file.
Recovery & Backups
Because the server does not know your passphrase or possess your private key, a lost passphrase cannot be reset by the server administrator.
During setup, you are prompted to download a Backup JSON file. This file contains your encrypted key material. If you forget your passphrase, you can restore access to your Vault using this backup file and the password you set for it.
Locking/Unlocking
The Vault remains unlocked only while the browser tab is open. This "in-memory" session ensures that if you walk away from your device and the browser is closed, your Vault is immediately secured.
Technical Implementation
Encryption Algorithms
| Purpose | Algorithm |
|---|---|
| KEK derivation | PBKDF2, SHA-256, 310,000 iterations |
| Asymmetric keypair | P-256 ECDH (Web Crypto API) |
| Private key encryption | AES-GCM 256-bit |
| File key wrapping | ECIES: ephemeral P-256 + HKDF-SHA-256 + AES-GCM |
| File encryption | AES-GCM 256-bit, random 12-byte IV |
Chunked File Encryption
For large files (greater than 50 MB), the file is split into 50 MB plaintext chunks before encryption. Each chunk is encrypted with the same per-file AES-GCM key but with a deterministic IV based on the chunk index. This means no per-chunk IV needs to be stored separately. Drivebase records the original chunk size as metadata so the client can deterministically reconstruct IVs during decryption.
Provider Visibility
Files are encrypted before they are sent to your storage provider, so providers only see encrypted file data.
Vault Isolation
Vault files are completely isolated from regular files.
- Database: Standard file queries explicitly exclude rows associated with a Vault.
- UI: Vault files never appear in regular file views. They are strictly contained within the dedicated
/vaultroute.