Background
According to a new Android developers blog post (available here), you should use a new technique in order to encrypt and decrypt sensitive data (for example passwords) stored in either the database or the sharedPreferences, so that even people with root permissions would have a hard time reading it.
The new way is:
public static SecretKey generateKey() throws NoSuchAlgorithmException {
// Generate a 256-bit key
final int outputKeyLength = 256;
SecureRandom secureRandom = new SecureRandom();
// Do *not* seed secureRandom! Automatically seeded from system entropy.
KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
keyGenerator.init(outputKeyLength, secureRandom);
SecretKey key = keyGenerator.generateKey();
return key;
}
The questions
According to the article (and to what i've tried), this code creates a new different key every time you call it, so I have some questions regarding this matter:
what would apps do for older versions of Android?
how would such apps handle updating of the android OS to the new way it should work (API post 17 to API 17)?
since it's not deterministic, it means that decryption can't re-create the same key , so does it mean that the key is also stored in order to use it for decryption (and also later encryption)? wouldn't such a thing miss the whole point?
suppose I have the key generated by the code, how would i use it in order to encrypt&decrypt data from the DB and the sharedPreferences?
in the article, they said that :
The fact is, Android's existing security model already provides plenty of protection for this kind of data. User credentials should be stored with the MODE_PRIVATE flag set and stored in internal storage
What does it mean? That the whole key generation is not needed, as Android already encrypt everything? My device is rooted , and I can easily say that the data is never encrypted and that it's easy to read (especially sharedPreferences which are just xml).