Using Cryptography to Store data safely [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

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:

1. what would apps do for older versions of Android?

2. how would such apps handle updating of the android OS to the new way it should work (API post 17 to API 17)?

3. 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?

4. 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?

5. 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).

Answer 1

what would apps do for older versions of android ?

Not this, since it is useless on all versions of Android, as the blog post indicates.

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 ?

Precisely. Quoting the blog post: "Note that the security of this approach relies on safeguarding the generated key, which is is predicated on the security of the internal storage. Leaving the target file unencrypted (but set to MODE_PRIVATE) would provide similar security."

To be honest, I have no idea why the blog post was written the way it was. The only form of encryption that has significant value is where the user provides a passphrase (or advanced forms of that, such as two-factor authentication).

what does it mean? that the whole key generation is not needed, as android already encrypt everything?

No, it means that anyone who can get to the encrypted file can also get to the encryption key, making the encryption largely pointless.

Note that Android will "already encrypt everything" on those devices where the user has turned on full-disk encryption.