[FEAT] Biometric-gated keyfile storage via Android Keystore (app-managed, encrypted at rest)

Brief Summary

When using a keyfile as part of a composite master key, it currently sits as a plaintext file on the device with no protection beyond standard filesystem/storage-scoping. Fingerprint/biometric unlock in KeePass2Android substitutes for typing the master password, but doesn't change how the keyfile itself is stored — anything with access to that file location (another app with matching permissions, a device backup, a compromised process) can read it directly, independent of whether biometric unlock is enabled at all.

I'd like to propose that KeePass2Android optionally manage the keyfile the way Android's platform primitives already support for other secrets: encrypted at rest using a key held in the Android Keystore, decrypted only transiently in memory and gated by a fresh biometric prompt on each access, rather than existing as a permanently readable plaintext file.

Motivation

This pattern is already established and shipping in the adjacent SSH-key space, just not yet applied to KeePass-style keyfiles:

• Secretive (macOS) generates SSH keys directly inside the Secure Enclave — key material never exists as a plaintext file and can't be exported; every use requires Touch ID.
• fssh (macOS) takes the more directly relevant "wrap an existing secret" approach: encrypts existing SSH keys and stores the decryption key in the Keychain, gated by Touch ID, decrypting transiently per use rather than leaving plaintext on disk.
• Android's own Keystore + BiometricPrompt (with setUserAuthenticationRequired/CryptoObject) provides the equivalent primitive natively — a key that can be bound to require biometric authentication before it can be used to decrypt data, with the key material itself never leaving the secure hardware (TEE/StrongBox where available).

Given KeePass2Android already integrates biometric authentication for master-password unlock, extending an equivalent Keystore-backed wrapping to the standalone keyfile seems like an incremental extension of infrastructure that's already in place, rather than new platform work.

Proposed behavior

• Opt-in setting alongside existing biometric unlock options, e.g. "Protect keyfile with biometrics."
• On enabling: the app generates a Keystore key with biometric-authentication-required, encrypts the keyfile content with it, and stores the ciphertext (app-private storage is fine — the security comes from the Keystore-gated key, not file location).
• The original plaintext keyfile is removed/overwritten, with a clear warning that this ties the wrapped keyfile to this specific device/Keystore and it can't be casually copied to another device afterward (same tradeoff as Android's existing Keystore-backed secrets generally).
• On each unlock requiring the keyfile, the app triggers a biometric prompt to authorize decryption in memory, rather than reading a plaintext file from disk.

Alternatives considered

• Storing the keyfile in app-private storage only (already possible in some configurations) — protects against other apps reading it via shared storage, but not against anything running with root, a compromised backup, or Android's own backup/restore flow if not explicitly excluded.
• Full-device encryption — protects at-rest/offline theft but not a live compromised session, which is the threat this addresses.

Additional context

I have raised this as a feature request in KeePassXC: https://github.com/keepassxreboot/keepassxc/issues/13637 and the same idea would be relevant and useful in other clients such as KeepassDX and KeePassium (iOS)

(Disclosure: I used Claude AI to help draft this feature request - some of the deep technical content is a little beyond me ;-)

Start by locating KeePass2Android's existing biometric authentication integration and the Android Keystore/BiometricPrompt entry points. The work is done when keyfile protection is opt-in, encrypted at rest with a Keystore-gated key, decrypted only in memory after biometric authorization, and the plaintext original is removed with the device-binding warning described.