Keys are not encrypted at rest about secured-preference-store

[iamMehedi]

Keys still get deleted in API levels lower than 21. But on API level 21+ we might be able to enforce key encryption at rest. Some testing is required and if everything seems ok then I'll set the library's minSDK level to be 21 and turn on key encryption at rest.

[StuStirling]

In API 21+, do keys not get deleted? It was my understanding that not every device can provide the hardware-backed keystore and in those cases, if the keys are encrypted at rest, they are encrypted using the device lock and I would assume they would have to be deleted upon a change? Did you get round to testing this?

[iamMehedi]

In API 21+ if there is a hardware backed store available then the keys aren't supposed to get deleted. But keys are still reported to be lost or rendered unrecoverable on some devices. That's why the library now has a recovery mechanism (actually a notifying mechanism) to handle that kind of an event.

[StuStirling]

Also see the comment from a Google engineer who says the following about the setEncryptionRequired method in API < 21:

(in the opinion of the Android security team) unnecessary encryption

and justifies it with the following argument:

it provides very little security, because you have to root the device to get at the encrypted keys, and once you've done that you have all sorts of options to get at the plaintext.