Description
In Android, you can generate AES keys in secure hardware, in the TEE (trusted execution environment) of the main processor:
KeyGenerator keyGenerator = KeyGenerator.getInstance("AES", "AndroidKeyStore");
KeyGenParameterSpec.Builder builder = new KeyGenParameterSpec.Builder(sKeyAlias, KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockModes(KeyProperties.BLOCK_MODE_CBC)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.setRandomizedEncryptionRequired(true);
keyGenerator.init(builder.build());
SecretKey key = keyGenerator.generateKey();
If you're super paranoid, you can instruct it to generate on the StrongBox on supported devices, which is a TPM chip separated from the rest of the hardware. You wouldn't want to do this, because the StrongBox is painfully slow, but it's doable.
builder.setIsStrongBoxBacked(true);
This is useful from the security perspective, because you generate/use AES keys that never expose the key material to the application process. It also limits the usage modes a key can set. An attacker can still abuse the application process to encrypt/decrypt, but it needs the original device, and extracting the key material for off-site decryption would involve hacking the TEE or the StrongBox, and that's quite a harder feat to achieve.
SQLCipher requires you to provide directly the key material, exposing it to the application process. Using a hardware backed key is a nice idea I think.
Not sure how this goes, but I believe that stripping OpenSSL from the main SQLCipher binary becomes a possibility, if the app is only gonna use hardware backed keys (which require the use of the java crypto API), and bundle OpenSSL if they don't, saving a few MBs from the resulting APK.
Implementing support for java SecretKey that come from the Android KeyStore would also automatically add support from many other HSM sources, like for example NFC smartcards or USB security dongles.