20

On the Android 4.0 (Samsung Galaxy Nexus) there is a posibilty to encrypt the phone. I found this about the encryption on Android 3.0, is the same algorithms used in Android 4? http://source.android.com/tech/encryption/android_crypto_implementation.html

My main question concerns the use of a PIN code to decrypt your phone. Why am I forced to use the same password to unlock my screen and to decrypt my phone? This restriction will only allow me to use a password of low complexity (like a PIN number) since it would be to hard to write in i.e. 17 characters to unlock my phone for a simple phone call.

Brute force attempts against the screen unlock could be prevented i.e. by a force reboot every 5 tries. So there is not any need for a very strong password there, a PIN might be good enough.
This type of protection can not be used on the disc, thus there is a greater need for stronger passwords here. (It doesn't help much that the entropi of passwords have increased since there will be very few users with a complex password, so an attacker could simply try most passwords with low complexity). What is the reasoning behind being forced to use the same password for both features?

Improve this question
13
  • I says you must use a lockscreen PIN or password. The password can be up to 17 characters long and can contain any letters, numbers or symbols (based on a quick test). That's much more entropy. Of course it would be more secure with no maximum limit, but still.
    – eldarerathis
    Commented Dec 17, 2011 at 16:51
  • 3
    Yes, but if I use the password I would need to use that to simply unlock my screen. Not very handy to type in 17 characters to give a quick call. Thus most users will make due with the PIN numbers and that would be the first thing an attacker would try. A better approache would perhaps be to allow passphrases for the disk encryption and allow simple PIN numbers on the lock screen. To avoid bruteforce attempts on the lockscreen there could be a force reboot after 3 failed attempts resulting in a request for the password.
    – Christopher
    Commented Dec 18, 2011 at 1:37
  • 1
    I don't know that anyone other than Google could tell you the reasoning, unfortunately. You could try the Android bug tracker to file a feature request, probably. This seems like a sensible thing to file there.
    – eldarerathis
    Commented Dec 18, 2011 at 19:48
  • 2
    Yes, against login attempt on the unlock screen, but not against decrypting the harddrive. That is what I am trying to say, the screen unlock doesn't need to be as long as the harddrive encryption (which needs to be much longer than 4 numbers) and thus one shouldn't be forced to use the same for both.
    – Christopher
    Commented Feb 19, 2012 at 21:14
  • 1
    @Christopher: but you're basing your decision on incorrect premise, the on-disk encryption was 128-bit AES, not the 4 digit PIN. Determining whether this scheme is secure or inherently faulty, is not the expertise of Android.SE.
    – Lie Ryan
    Commented Nov 8, 2012 at 22:23

5 Answers 5

Reset to default
2

You can use this command on a root shell to change the encryption password:

su -c vdc cryptfs changepw <new_password>

Where <new_password> should be replaced by your password.

Source: http://nelenkov.blogspot.be/2012/08/changing-androids-disk-encryption.html

Improve this answer
1

By using a password/phrase vs four digit pin, you are increasing the security of your device. The trick of it is, even by having a four character password, you've just increased your security for two reasons:

  • You've increased the available characters.
  • You've taken away the attackers knowledge of your pw length.

If an attacker knows your password is 14 characters, it is more secure than a four or eight character password, but typical statistics use ranges (1-4, 1-8, 1-14) and not the reality (which would be simply calculating one length's available combinations).

Currently, it is simply WAY TO EASY to access your phone's data. Your grandmother has the capability of doing so (No offense to you or your family :P). So, while you're right that there are limitations of this encryption, the 'broken' version works A LOT better than non-encrypted data currently practiced.

It is up to you to judge how sensitive and private your data is, as well as how much of a target you are for such data to be stolen. Choosing an appropriate password is your responsibility once you've assessed these risk.

Improve this answer
1
  • 2
    Yes, but I feel like it would be a simple solution to the problem to have different passwords for unlocking screen and for decrypting the device (as I mentioned here android.stackexchange.com/questions/17086/…) since they are used in different senarios and need to have different attributes.
    – Christopher
    Commented Feb 21, 2012 at 23:00
1

If you're trying to crack the disk encryption, independent of the rest of the device in a scenario where you have a powered off device, or just the memory chips, then this is a different attack vector than that used on a powered-on password protected device where the decryption key may be held in memory (leading to vulnerabilities used by things like the Firewire encryption key stealers prevalent on PCs using older FDE encryption software and not a TPM-type module), or the unlock screen could be brute-forced (or have its own vulnerabilities).

If you're attacking the disk directly then in this case you're not attacking the 4-digit PIN or user password that's encrypting the device, what you're attacking is the 128 bit AES key:

The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password.

From point 4 under "Enabling encryption on the device" of the Notes on the implementation of encryption in Android 3.0 that you linked to.

(was going to be a comment but ended up far too long)

Improve this answer
6
  • 1
    Thank you for this nice comment! One thing though; am I not looking for the user password (which most probably will be a 4 digit pin, because you are forced to share key with screen unlock and anything else will be a hassle to type in to make a phone call) to decrypt the 128 bit AES key? (instead of searching for the key directly). If I hash all 10000 pins with the PBKDF2 function + salt, isn't there just 10000 decryption attempts for me to try then?
    – Christopher
    Commented Feb 21, 2012 at 22:50
  • @Melpomene The "rainbow table attack" that they talk about is where you pre-encrypt all 10,000 combinations to see what they look like encrypted and then just compare what's on disk to what's in your rainbow table. The "random salt" is what's used to help prevent this by creating far more than 10,000 combinations that you'll have to guess through (unless you manage to work out the "salt" first).
    – GAThrawn
    Commented Feb 22, 2012 at 14:23
  • 1
    A rainbow is a smart way of storing encrypted passwords yes. And if a salt is used it would probably need to be specially constructed just for cracking passwords with that salt. This is not a very hard operation when there are only 10,000 passwords to choose from. Note that the Salt is always considered known to the attacker (since it seems to be read from /dev/urandom in the docs this is most likley stored either in clear text or encrypted with the user password). Either way the the user password is the weak link.
    – Christopher
    Commented Feb 24, 2012 at 8:48
  • But I wouldn't even need to construct a rainbowtable since storing (or calculating) 10,000 hashes is not that hard on my memory (processor).
    – Christopher
    Commented Feb 24, 2012 at 8:50
  • Using a key derivation function like PBKDF2 does seem like good news, but a typical 4 digit pin is still only 10000 possible combinations.
    – João Portela
    Commented Sep 10, 2012 at 19:07
1

One possible solution for this is to use whispercore, but it requires you to root your device.

I have also filled a feature request at the android project page.

Improve this answer
0
0

If you have remote wipe enabled (assuming it still works with encrypted device), the PIN may not secure your device forever, but it may do so long enough to give you time to wipe your device.

Improve this answer
3
  • 2
    The problem is that a short PIN can only secure the device when it is on. Therefore switching a stolen device off prevents the device from being wiped and additionally the PIN can be broken in an offline brute-force attack. Hence a short PIN doesn't help you in this situation.
    – Robert
    Commented Feb 23, 2012 at 15:04
  • @Robert, I'm not too familiar with how remote wipe works. If it's done via Exchange, does the phone have to be on the same moment the remote wipe command is issued? My thought is that if I can issue a remote wipe within 30 minutes or so of losing my phone that's good enough for me, but I don't have any financial data, my main concern is my GMail work email.
    – Chance
    Commented Feb 23, 2012 at 16:09
  • 2
    The phone has to be on and on-line some time after you have issued the remote wipe command. If the phone has been switched off (and stays off) the wipe command is useless.
    – Robert
    Commented Feb 24, 2012 at 8:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .