1

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

halfer
  • 19,824
  • 17
  • 99
  • 186
android developer
  • 114,585
  • 152
  • 739
  • 1,270
  • "According to a new android developers blog post" and you forget to link to the post. Then you show a very generic piece of code to generate a randomized key and ask 5(!) questions about it, most of which are dependent on the use case/type of application that is developed. – Maarten Bodewes Feb 23 '13 at 23:07
  • sorry , updated the question with the new link. – android developer Feb 23 '13 at 23:08
  • There is definitely *nothing* wrong with the block post. Two things have been pointed out: the new default `SecureRandom` implementation, the wrong method to generate keys (often criticized by myself on Stackoverflow) and how to generate keys correctly, and that you in general don't need to encrypt user data if you store it on persistent memory using that private flag. – Maarten Bodewes Feb 23 '13 at 23:14
  • Deleted my answer as it quickly lead into discussion about all 5 questions. – Maarten Bodewes Feb 24 '13 at 00:39
  • @owlstead about the private flag , i've written that as a rooted device, i can just copy the xml (or db file) into the sdcard and read it using an appropriate app , and that it's not encrypted. does android 4.2 have it automatically encrypted from now on? – android developer Feb 24 '13 at 06:52

1 Answers1

3

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.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • so in short , they provide a way to encrypt the data , but they also say that it's still very possible to hack things because the key needs to be stored and you can get it easily. Only for end users who turned on data encryption, it has some sort of protection. Does this sum up the article? – android developer Feb 24 '13 at 06:54
  • @androiddeveloper: To me, what sums up the article is the paragraph that I quoted in the answer. – CommonsWare Feb 24 '13 at 11:46
  • but was i correct with what i've written? – android developer Feb 24 '13 at 18:17
  • @androiddeveloper: I disagree with the sentence: "Only for end users who turned on data encryption, it has some sort of protection.". If the user has full-disk encryption enabled, your additional encryption is pointless. Anyone who can break the full-disk encryption can get the generated key, and if they cannot break the full-disk encryption, your additional encryption does not add to the security. – CommonsWare Feb 24 '13 at 18:20
  • yes , this is true . it's an open source OS , so encrypted internal storage can still be cracked by finding out where the OS stores the key .however, that's why i call it "some sort of protection" .it's only a bit better than no security at all. for devices that don't have root permission, you can't reach the internal storage so it doesn't matter much if the data is encrypted, but for people who only know how to root their phones and open the internal storage files, the encryption adds some kind of security. for the hardcore hackers , nothing can stop them (but that's true everywhere, no?) . – android developer Feb 24 '13 at 18:45
  • @androiddeveloper: "but for people who only know how to root their phones and open the internal storage files, the encryption adds some kind of security" -- personally, I do not worry about that particular segment. I assume that anyone who roots their phone is either capable of reverse-engineering the app or is capable of finding the work of somebody else who already *did* reverse-engineer the app. You only need one person to document how to decrypt the files for anyone with root access to be able to do it. – CommonsWare Feb 24 '13 at 18:51
  • Thank you for your help. I think i've got the general idea and i also agree with you. – android developer Feb 25 '13 at 19:52