Security

AES-256-GCM encryption for every digital identity

Zero-Knowledge Architecture

ByteGuard is built on a zero-knowledge security model. We never see, access, or store your encryption keys.

• Master Password: Your personal key to unlock the app. Never transmitted, never stored remotely.
• Secret Key: A 12-word recovery phrase (BIP39) generated when you create your vault. Combined with your Master Password for maximum security.
• Local Key Derivation: Argon2id with 64MB memory cost and 3 iterations derives your master key locally. HKDF-SHA256 creates the key hierarchy.
• No Backdoors: We cannot recover your data if you lose both your Master Password and Secret Key. This is by design.

Encryption Details

A five-tier key hierarchy from your Master Password down to the field ciphertext, with explicit isolation at every layer.

• Master Key: Argon2id(Master Password ‖ Secret Key, salt) derived locally. OWASP-recommended parameters: 64MB memory × 3 iterations, sufficient to defeat GPU brute-force. Never leaves the device.
• Auth Hash: HKDF-SHA256(Master Key, info="vault-auth-v1"). Used solely for password verification. Constant-time byte comparison defeats timing attacks.
• KEK (Key Encryption Key): HKDF-SHA256(Master Key, info="vault-kek-v1"). Dedicated to unwrapping the Vault DEK; never touches user data directly.
• Vault DEK (vault-wide): A 256-bit randomly generated key. **The plaintext DEK never leaves the device's RAM**; the wrapped DEK (AES-256-GCM ciphertext under KEK) is stored alongside vault metadata and syncs through CloudKit Private DB when iCloud is enabled — only ciphertext ever leaves the device. Changing the Master Password only requires re-deriving KEK and re-wrapping the DEK — the entire vault is never re-encrypted.
• Item Key (per-entry): HKDF-SHA256(Vault DEK, info="type-{T}-item-{ID}-v1") derived from type + entry ID. Each record uses an independent key — leaking one does not affect others.
• Field Ciphertext: AES-256-GCM(Item Key, plaintext) encrypts sensitive fields per type: login passwords, secondary passwords, PINs, security question answers, custom secret fields, and card numbers (PAN). Account names, usernames, URLs, expiry dates, and tags are stored as plaintext metadata for search and indexing. A unique IV per encryption ensures identical plaintext yields different ciphertext.

Device-Level Protection

The biometric quick-unlock boundary is maintained jointly by iOS Keychain and Secure Enclave. The application never holds any Face ID/Touch ID-derived key.

• iOS Keychain ACL: A copy of the Vault DEK is stored in Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly + kSecAccessControlBiometryCurrentSet. Unreadable when the device is locked or Face ID has not authenticated.
• Secure Enclave Takes Over: The Keychain entry is encrypted by a device key inside Secure Enclave. When the app calls SecItemCopyMatching, iOS triggers Face ID; on success SE decrypts and returns the plaintext DEK — the app never touches any SE key.
• Auto-Invalidation on Face ID Re-enrollment: biometryCurrentSet semantics: when the user removes/re-enrolls Face ID in system settings, iOS automatically deletes the Keychain entry. ByteGuard detects the invalidation at launch and forces Master Password re-entry.
• Strict Mode (No Fallback): If biometryCurrentSet is unavailable (simulators, no enrolled biometrics), the DEK cache simply fails — never falls back to a less-protected Keychain entry. Fallback would be weaker than not enabling Face ID at all and would violate user intent.
• Memory Zeroing (Vault DEK): On lock, suspension, or vault switch, the Vault DEK is overwritten three times (zero → random → zero) with a memory barrier defeating compiler optimization. Master Key / KEK are local variables inside the unlock function, released by Swift ARC (not explicitly zeroed). Argon2 internal buffers are zeroed by libsodium via sodium_memzero.

Data Storage

Your data stays on your device. Cloud sync is optional and always encrypted.

• Local First: All data is stored in an encrypted local database on your device.
• Optional iCloud Sync: When enabled, data is encrypted on-device before uploading to your private iCloud container via CloudKit.
• Biometric Protection: Face ID and Touch ID via the Secure Enclave. Biometric data is handled by iOS, never accessed by the app.

What We Cannot Do

Our zero-knowledge architecture means:

• We cannot view, access, or decrypt your stored data
• We cannot reset your Master Password
• We cannot recover your vault without your Secret Key
• By design, neither I nor any third party (including legal authorities) can decrypt your data without your master password
• We cannot insert backdoors into the encryption

Device Security Compatibility

ByteGuard is designed to work seamlessly with Apple's built-in security features.

• Apple Lockdown Mode: Compatible with iOS Lockdown Mode. All features — including AutoFill, iCloud sync, and widgets — continue to work when Lockdown Mode is enabled.
• No WebView Dependency: ByteGuard does not use any web rendering engine. Your vault data is never processed through WebKit, eliminating an entire class of browser-based attack vectors.
• Secure Enclave Integration: Biometric authentication is handled entirely by the iOS Secure Enclave. ByteGuard never accesses or stores biometric data.

Download on the App Store