XVault is designed under a zero-trust, offline-first security model. The assumption is that attackers may have access to the app binary, source code, and even the device filesystem — but not the user’s biometrics or recovery secrets.

• Randomly generated 256-bit AES key
• Used to encrypt all vault data
• Never written to disk in plaintext
• Exists only in memory during an active session

• MVK is encrypted (“wrapped”) using a Keystore-managed AES key
• Key is:
  • Hardware-backed (if supported)
  • Bound to biometric authentication
  • Invalidated if biometrics change

• Required to unwrap the MVK
• Uses Android BiometricPrompt
• Strong biometric authenticators only

• User-defined security question & answer
• Answer is processed via:
  • PBKDF2WithHmacSHA256
  • 100,000 iterations
  • Random salt
• Allows MVK recovery if biometric access is lost
• Recovery data itself is encrypted

• Algorithm: AES/GCM/NoPadding
• Tag Length: 128-bit
• Ensures confidentiality and integrity

• Vault data is verified before decryption
• Prevents silent corruption or manipulation

Vault access is automatically locked if:

• Biometrics are changed
• Device security state changes
• App goes to background
• Idle timeout is reached

• File system access
• App reverse engineering
• APK extraction
• Device theft (without biometrics)
• Memory scraping after vault lock

• Compromised OS
• Kernel-level malware
• Hardware exploits
• User willingly sharing recovery answers

If you discover a security issue, please report it responsibly by opening a private issue or contacting the maintainer.

Security is not a feature — it’s the foundation.