Keystore Key Invalidated After Biometric Enrollment
An Android field-service app stores a 200 MB SQLite database offline. It encrypts sensitive columns with AES-256-GCM. The data key is generated once in AndroidKeyStore under alias db_key with setUserAuthenticationRequired(true), setInvalidatedByBiometricEnrollment(true), and setUnlockedDeviceRequired(true). On a test Pixel, after enrolling a new fingerprint, opening the app throws KeyPermanentlyInvalidatedException. The crash handler catches this exception and calls a native method that derives a fallback AES key from a hardcoded string in libcrypto_helper.so, then decrypts the database so users do not lose data. The GCM nonce is 12 bytes from SecureRandom and stored in a nonce column next to the ciphertext. No nonce reuse has been observed in 8,000 test records. The team asks whether the fallback is acceptable because it only triggers after biometric enrollment, which is a legitimate user action.
1. Assess the fallback key path. Does the invalidation trigger make it acceptable?
Read the worked answer
No. The trigger, a new biometric enrollment, is a normal and attacker-inducible event if the attacker has brief device access, and the fallback key is in the native library. A hardcoded key is extractable with static analysis or dynamic instrumentation; it converts hardware-backed encryption into obfuscation. The fallback also means any user who can trigger invalidation can cause the app to decrypt with a globally shared key. The correct response to KeyPermanentlyInvalidatedException is a recovery or re-enrollment flow, not silent decryption. If data loss is unacceptable, design a wrapped-DEK backup before enrollment changes.
2. Evaluate the AES-GCM nonce handling. Is it safe to store the nonce with the ciphertext?
Read the worked answer
Storing the GCM nonce with ciphertext is normal; the nonce is not secret. Safety depends on uniqueness per key. A 96-bit random nonce has a low but non-zero collision probability; for many records under one long-lived key, use a counter or nonce sequence, or rotate keys. Never reuse a nonce with the same key. Bind metadata such as record ID and user ID as AAD so ciphertext cannot be swapped between rows. Verify the authentication tag on every read and fail closed on tag mismatch. The 8,000-record test is not proof of safety at 200 MB or over years.
3. Design a safe key-invalidation recovery flow that preserves offline access where possible.
Read the worked answer
Generate a random DEK, encrypt records with AES-GCM, and wrap the DEK with a Keystore key. Keep one wrapped copy protected by biometrics and one recovery copy encrypted to a server public key or stored in a server-side KMS. If the Keystore key is invalidated, require the user to re-authenticate online, unwrap or reissue the DEK, and rewrap under a new Keystore key. For offline mode, allow read-only access to a limited cache until online recovery; do not fall back to a hardcoded key. Use setUserAuthenticationParameters with device credential if biometric invalidation is too disruptive, and document the threat model.