Version 1.1 — July 1, 2026
1. Overview
Drive Dot is a zero-knowledge encrypted storage platform. This document describes the cryptographic architecture, threat model, and security design of the Drive Dot protocol. Our goal is to provide end-to-end encrypted file storage where the server never has access to plaintext file contents, filenames, or metadata.
All encryption and decryption occurs on the client device. Encryption keys are derived from the user's PIN and are never transmitted to the server. Files are encrypted individually with unique AES-256-GCM keys, and those per-file keys are wrapped (encrypted) by a device-bound master key derived from the user's PIN. The server stores only opaque ciphertext and has zero ability to decrypt or inspect stored data.
2. Threat Model
Drive Dot's security design defends against the following adversary models:
- Passive network adversary: Can observe all network traffic between client and server.
- Active network adversary: Can intercept, modify, delay, or drop network traffic; can perform man-in-the-middle attacks.
- Server compromise: Full compromise of Drive Dot's servers; attacker has access to all stored data, file blobs, and infrastructure.
- Device theft: Physical access to a user's locked device.
- Legal compulsion: Drive Dot is legally compelled to hand over user data.
The following are explicitly out of scope:
- Compromise of a trusted device after the user has entered their PIN (device is unlocked)
- Side-channel attacks on the device hardware
- Defeats of the device secure enclave by the OS vendor
- Quantum cryptanalysis (post-quantum upgrade is planned)
- Brute-force attacks against weak user PINs (mitigated by PBKDF2 iteration count and account lockout)
3. Cryptographic Primitives
| Function | Algorithm | Standard |
|---|---|---|
| File encryption | AES-256-GCM | NIST SP 800-38D |
| Key wrapping | AES-256-KWP | NIST SP 800-38F |
| Key exchange (device pairing) | X25519 | RFC 7748 |
| Key derivation (PIN → master key) | PBKDF2-HMAC-SHA256 | RFC 2898 |
| File authentication | HMAC-SHA256 | RFC 4868 |
| Hashing | SHA-256 / BLAKE2b | FIPS 180-4 |
| Digital signatures | Ed25519 | RFC 8032 |
| Integrity verification | SHA-256 | FIPS 180-4 |
| Random number generation | /dev/urandom / SecureRandom | — |
| Transport security | TLS 1.3 | RFC 8446 |
All cryptographic operations are performed using platform-provided secure implementations (Apple CryptoKit, Android Conscrypt, or BoringSSL). We do not implement cryptographic primitives from scratch.
4. PIN-Based Key Derivation
4.1 Master Key Derivation
When the user creates or unlocks their account, they provide a numeric PIN. This PIN is never transmitted to the server. The client derives a 256-bit Master Key using PBKDF2-HMAC-SHA256:
MasterKey = PBKDF2(PIN, salt, iterations=600000, dkLen=32)
The salt is a random 32-byte value generated at account creation and stored on the server alongside the encrypted vault. The high iteration count (600,000) provides brute-force resistance against PIN guessing. The Master Key never leaves the client device and is held only in volatile memory during the session.
4.2 Device-Bound Key
Each authorized device generates a persistent X25519 key pair at enrollment. The private key is stored in the device's secure enclave (Keychain on iOS, Keystore on Android). The device's public key is registered with the server. When the Master Key is derived, it is further wrapped with the device's secure-enclave-bound key:
DeviceWrappedMasterKey = Seal(MasterKey, DevicePublicKey)
This ensures that even if an attacker obtains the PBKDF2 salt and a PIN guess, they cannot decrypt files without access to the private key in the device's secure enclave.
5. File Encryption Key Management
5.1 Per-File Key Generation
Each file uploaded to Drive Dot is encrypted with a unique, randomly generated 256-bit AES-GCM key. File keys are generated using a cryptographically secure random number generator:
FileKey = SecureRandom(32)
No two files share the same encryption key. This limits the blast radius of any key compromise to a single file.
5.2 Key Wrapping
Per-file keys are encrypted (wrapped) using the Master Key before being stored in the file's encrypted header:
WrappedFileKey = AES-256-KWP(FileKey, MasterKey)
The wrapped key is stored alongside the encrypted file on the server. Since the wrapping uses AES-256-KWP (AES Key Wrap with Padding, per NIST SP 800-38F), the server cannot unwrap the file key without the Master Key. This creates a two-layer encryption scheme:
- Per-file layer: AES-256-GCM encrypts the file plaintext with a unique random key.
- Master key layer: The per-file key is wrapped with the PIN-derived Master Key using AES-256-KWP.
5.3 Key Hierarchy Summary
| Key | Derivation | Lifetime | Storage |
|---|---|---|---|
| Master Key | PBKDF2(PIN, salt, 600k) | Session | Volatile memory only |
| Device Key | X25519 key pair | Permanent | Secure enclave |
| File Key | SecureRandom(32) | Per-file | AES-KWP-wrapped on server |
6. File Encryption
Each file is encrypted client-side using AES-256-GCM before upload. The encryption process produces three outputs: the ciphertext, a 12-byte random nonce, and a 16-byte GCM authentication tag.
6.1 File Payload Encryption
Ciphertext, Nonce, Tag = AES-256-GCM-Encrypt(Plaintext, FileKey, Nonce, AAD)
The authenticated encryption includes associated data (AAD):
- Protocol version number
- Encrypted file size (padded to nearest block)
- File ID and upload timestamp
- Original filename hash
Files are padded to a multiple of 4,096 bytes before encryption to obscure the true file size (traffic analysis mitigation). The padding is random bytes that are discarded after decryption.
6.2 File Format
Each stored file on the server has the following structure:
[Header] [Nonce (12 bytes)] [Ciphertext (padded)] [GCM Tag (16 bytes)]
The header contains:
- Protocol version (2 bytes)
- Encrypted file metadata (filenames, MIME type, timestamps — all encrypted with the file key)
- Wrapped file key (AES-256-KWP output, 48 bytes)
- PBKDF2 salt (32 bytes)
The encrypted metadata block ensures that the server cannot read filenames, file types, or any other metadata. The server sees only opaque blobs and size-padded ciphertext.
7. File Decryption
Decryption proceeds in reverse:
- Client derives Master Key from PIN using PBKDF2 with the stored salt.
- Client unwraps the File Key from the file header using AES-256-KWP with the Master Key.
- Client decrypts the ciphertext using AES-256-GCM with the File Key, nonce, and AAD.
- GCM authentication tag is verified. If verification fails, the file is rejected (tamper detection).
- Encrypted metadata is decrypted with the File Key, revealing filenames and attributes.
8. File Sharing
When a user shares a file with another Drive Dot user, the sharing protocol uses a mediated key exchange:
- The sender unwraps the File Key using their Master Key.
- The sender fetches the recipient's device public key (X25519) from the server.
- The sender performs an X25519 key exchange and derives a shared ephemeral key.
- The File Key is re-wrapped with the shared ephemeral key and uploaded to the server.
- The recipient performs the corresponding X25519 exchange to unwrap and decrypt.
The original file ciphertext is never re-encrypted. Only the wrapped File Key in the sharing header is replaced. The server has no access to the decrypted file key at any point.
9. Folder and Metadata Encryption
Folder structure, filenames, MIME types, and file sizes are encrypted client-side before being stored. The folder hierarchy is represented as an encrypted Merkle tree:
- Folder nodes contain the encrypted list of child file IDs and subfolder IDs, along with their encrypted names.
- File nodes contain encrypted metadata (filename, extension, MIME type, original size, modification timestamps).
- Root node is encrypted with the Master Key directly and stored in the user's encrypted vault.
The server stores the Merkle tree as encrypted blobs and cannot determine the directory structure, number of files, file types, or any naming information.
10. Transport Security
All client-server communication occurs over TLS 1.3 with certificate pinning. The pinned certificate fingerprints are embedded in the application binary and verified on every connection. In addition to TLS:
- All API requests include a bearer token derived from the session key.
- Upload and download endpoints verify content hashes server-side for integrity.
- Rate limiting and account lockout are enforced after repeated failed PIN attempts.
11. Server Architecture
The server is designed to be zero-knowledge:
- Stores only encrypted file blobs, encrypted metadata, and public key material
- Has no access to encryption keys, PINs, or passwords
- Can never decrypt files or read filenames
- Cannot determine folder structure or file relationships from stored data
- Implements strict access controls and audit logging for administrative actions
- File deduplication uses content-hash comparison of ciphertext only (no cross-user dedup)
12. Future Roadmap
- Post-quantum cryptographic key agreement (Kyber) for file sharing
- Encrypted file preview thumbnails (blurhash-style, encrypted)
- Multi-device synchronization with CRDT-based encrypted metadata merge
- Shamir's Secret Sharing for PIN recovery without server trust
- Hardware security key (WebAuthn) integration for second factor
13. Security Claims
Drive Dot guarantees the following properties:
- Confidentiality: File contents and metadata are encrypted end-to-end. The server cannot read plaintext under any circumstances.
- Integrity: AES-GCM authentication tags detect any tampering with ciphertext. Each file includes a SHA-256 hash verified on download.
- Zero-knowledge: The server has no access to encryption keys, filenames, folder structure, or file contents.
- Key separation: Each file has a unique encryption key. Compromising one file key does not compromise other files.
- PIN protection: The Master Key is derived from the user PIN with 600,000 PBKDF2 iterations and is never persisted insecurely.
14. Contact
For questions about this whitepaper:
Email: crypto@drivedot.cloud