Use Android Keystore to secure a database encryption key

WHAT THIS TESTS: Whether you understand the Android Keystore as a key storage and usage system rather than a general encryption API, and whether you know the practical differences between TEE isolation and dedicated StrongBox hardware.

A GOOD ANSWER COVERS four things in order. First, key generation: use KeyGenerator.getInstance with AES, initialize it with a KeyGenParameterSpec built with KeyProperties.PURPOSE_ENCRYPT and KeyProperties.PURPOSE_DECRYPT, typically using AES/GCM/NoPadding for authenticated encryption. Second, the encryption architecture: the Keystore key does not encrypt the database directly. Instead, you generate or receive a database encryption key, encrypt that key with the Keystore key, and store the ciphertext in SharedPreferences or a file; at runtime you decrypt the database key and pass it to your database library. Third, hardware versus software: a TEE-backed key has its key material generated and stored inside the Trusted Execution Environment, so the Android OS and your app never see the raw key bytes, though cryptographic operations still invoke the TEE through the kernel. A StrongBox-backed key goes further by residing in a dedicated secure hardware chip with its own CPU and storage, resistant to physical extraction. Fourth, specifying preference: on API level 28 and above, call setIsStrongBoxBacked(true) on the KeyGenParameterSpec.Builder, then catch UnsupportedOperationException if the device lacks StrongBox and fall back to TEE by rebuilding the spec without the flag. On older APIs, you can check KeyInfo.isInsideSecureHardware after generation to confirm TEE backing.

COMMON WRONG ANSWERS: Saying Android Keystore encrypts the database file itself. Hardcoding an encryption key and only using Keystore as a wrapper after the fact without proper random generation. Failing to mention that StrongBox requires API 28 and throws if unavailable. Claiming software-backed keys are safe because the Keystore stores them; in reality software keys are encrypted at rest but decrypted into app process memory during use, making them extractable on rooted devices.

LIKELY FOLLOW-UPS: How would you handle Keystore key invalidation when the user adds a fingerprint? What happens if the user clears the lock screen or changes biometric enrollment? How do you rotate a database encryption key without re-encrypting the entire database? How do you test StrongBox behavior on an emulator that lacks it?

ONE CONCRETE EXAMPLE: On a Pixel device running API 34, you build a KeyGenParameterSpec for AES with GCM, call setIsStrongBoxBacked(true), and the key material is generated inside the Titan M2 chip. Your app receives only a reference handle. When SQLCipher needs the database key, you decrypt the wrapped key using Cipher initialized with the StrongBox key, receive the plaintext database key in a ByteArray, pass it to the database layer, and then zero the array. If you run the same code on an API 26 device without StrongBox, the UnsupportedOperationException causes you to rebuild the spec without StrongBox, falling back to TEE, and KeyInfo confirms isInsideSecureHardware returns true.

Source: developer.android.com