Use Android Keystore to secure a database encryption key
Tests Android Keystore key generation and hardware trust boundaries. Strong answers: KeyGenParameterSpec with AES/GCM, TEE vs StrongBox isolation, setIsStrongBoxBacked on API 28+ with fallback, wrapping the database key. Red flag: claims Keystore encrypts DBs.
What's really being asked
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
When configuring a StrongBox-backed key for database encryption on API 28+, what is the correct fallback strategy if the device lacks dedicated secure hardware?
- a.Catch InvalidAlgorithmParameterException and fall back to generating a software-backed key in application memory.
- b.Check KeyInfo.isInsideSecureHardware before calling setIsStrongBoxBacked and skip the flag if it returns false.
- c.Catch UnsupportedOperationException during key generation and rebuild the spec without StrongBox to obtain a TEE-backed key.Correct
- d.Verify Build.MODEL against a whitelist of StrongBox-capable devices before attempting key generation.
Why? this is the answer
The correct approach is to request StrongBox and catch UnsupportedOperationException, then rebuild the KeyGenParameterSpec without the flag to fall back to TEE. Option B is tempting but wrong because KeyInfo requires an already-generated key, so it cannot be checked before generation to decide on StrongBox backing.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles