Friday, August 3, 2012

Changing Android's disk encryption password

We've been discussing some of Jelly Bean's new security features, but this post will take a few steps back and focus on an older one that has been available since Honeycomb (3.0), announced in the beginning of the now distant 2011: disk encryption. We'll glance over the implementation, discuss how passwords are managed and introduce a simple tool that lets you change the password from the comfort of Android's UI.

Android disk encryption implementation

Android 3.0 introduced disk encryption along with device administrator policies that can enforce it, and advertised it as one of several 'enhancements for the enterprise'. Of course Honeycomb tablets never really took off, let alone in the enterprise. Disk encryption however persevered and  has been available in all subsequent versions. Now that ICS is on about 16% of all Android devices and Jelly Bean's share will start to increase as well in the coming months, disk encryption might finally see wider adoption.

Unlike most internal Android features, disk encryption has actually been publicly documented quite extensively, so if you are interested in the details, do read the implementation notes. We'll only give a short overview here, focusing on key and password management.

Android's disk encryption makes use of dm-crypt, which is now the standard disk encryption sybsystem in the Linux kernel. dm-crypt maps an encrypted physical block device to a logical plain text one and all reads and writes to it are decrypted/encrypted transparently. The encryption mechanism used for the filesystem in Android is 128 AES with CBC and ESSIV:SHA256. The master key is encrypted with another 128 bit AES key, derived from a user-supplied password using 2000 rounds of PBKDF2 with a 128 bit random salt. The resulting encrypted master key and the salt used in the derivation process are stored, along with other metadata, in a footer structure at the end of the encrypted partition (last 16 Kbytes). This allows for changing the decryption password quickly, since the only thing that needs to be re-encrypted with the newly derived key is the master key (16 bytes).

The user-mode part of disk encryption is implemented in the cryptfs module of Android's volume daemon (vold). crypfs has commands for both creating and mounting an encrypted partition, as well as for verifying and changing the master key encryption password. Android system services communicate with cryptfs by sending commands to vold through a local socket, and it in turn sets system properties that describe the current state of the encryption or mount process. This results in a fairly complex boot procedure, described in detail in the implementation notes. We are however, more interested in how the encryption password is set and managed.

Disk encryption password

When you first encrypt the device, you are asked to either confirm your device unlock PIN/password or set one if you haven't already, or are using the pattern screen lock. This password or PIN is then used to derive the master key encryption key, and you are required to enter it each time you boot the device, then once more to unlock the screen after it starts. As you can see from the screenshot below, Android doesn't have a dedicated setting to manage the encryption password once the device is encrypted: changing the screen lock password/PIN will also silently change the device encryption password.


This is most probably a usability-driven decision: most users would be confused by having to remember and enter two different passwords, at different times, and would probably quickly forget the less often used one (for disk encryption). While this design is good for usability, it effectively forces you to use a simple disk encryption password, since you have to enter it each time you unlock the device, usually dozens of times a day. No one would enter a complex password that many times, and thus most users opt for a simple numeric PIN. Additionally, passwords are limited to 16 characters, so using a passphrase is not an option.

So what's the problem with this? After all, to get to the data on the phone you need to guess the screen unlock password anyway, so why bother with a separate one for disk encryption? Because the two passwords protect your phone against two different types of attack. Most screen lock attacks would be online, brute force ones: essentially someone trying out different passwords on a running device after they get brief access to it. After a few unsuccessful attempts, Android will lock the screen for a few minutes (rate-limiting), then if more failed unlock attempts ensue, completely lock (requiring Google account authentication to unlock) or even wipe the device. Thus even a relatively short screen lock PIN offers adequate protection in most cases. Of course, if someone has physical access to the device or a disk image of it, they can extract password hashes and crack them offline without worrying about rate-limiting or device wiping. This in fact, is the scenario that full disk encryption is designed to protect from: once a device is stolen or confiscated for some reason, the attacker can either brute force the actual device, or copy its data and analyze it even after the device is returned or disposed of. As we mentioned in the previous section, the encrypted master key is stored on disk, and if the password used to derive its encryption key is based on a short numeric PIN, it can be brute forced in seconds, or at worst, minutes. This presentation by viaForensics details one such attack (slides 25-27) and shows that this is far from theoretical and can be achieved with readily available tools. A remote wipe solution could prevent this attack by deleting the master key, which only takes a second and renders the device useless, but this is often not an option, since the device might be offline or turned off.

Hopefully we've established that having a strong disk encryption password is a good idea, but how can we set one without making screen unlocking unusable?

Changing the disk encryption password

As we mentioned in the first section, Android services communicate with the cryptfs module by sending it commands through a local socket. This is of course limited to system applications, but Android comes with a small utility command that can directly communicate with vold and can be used from a root shell. So as long as your phone is rooted, i.e., you have a SUID su binary installed, you can send the following cryptfs command to change the disk encryption password:

$ su -c vdc cryptfs changepw newpass
su -c vdc cryptfs changepw newpass
200 0 0

This doesn't affect the screen unlock password/PIN in any way, and doesn't impose any limits on password length, so you are free to set a complex password or passphrase. The downside is that if you change the screen unlock password, the device encryption one will be automatically changed as well and you will need to repeat the procedure. This is not terribly difficult, but can be cumbersome, especially if you are on the go. You should definitely start this Android issue to have it integrated in Android's system UI (which will probably require extending the device policy as well), but in the meantime you can use my Cryptfs Password tool to easily change the device encryption password.


The app tries to make the process relatively foolproof by first checking your current password and then displaying the new one in a dialog if the change succeeds. However, you will only be required to use the new password at the next boot, so it is important not to forget it until then, and take a full backup just in case. Short of brute-forcing, the only way to recover from a forgotten encryption password is to factory reset the device, deleting all user data in the process, so proceed with caution. The app will verify that you have root access by checking if you have one of the more popular 'superuser' apps (Superuser or SuperSU) installed, and trying to execute a dummy command with su at startup. If your device is not encrypted, it will refuse to start.

The implementation is quite straightforward: it simply invokes the verifypw and changepw cryptfs command using the passwords you provided. If you are interested in the details, or simply won't let a random app mess with your device encryption password, clone the code and build it yourself. If you are the more trusting kind, you can install via Google Play.

Summary

While Android's disk encryption is a useful security feature without any (currently) know flaws, its biggest weakness is that it requires you to use the device unlock PIN or password to protect the disk encryption key. Since those are usually rather short, this opens to door to practical brute force attacks against encrypted volumes. Setting a separate, more complex disk encryption password using the provided tool (or the directly with the vdc command) makes those attacks far less effective. This does currently require root access however, so you also need to make sure that your device is otherwise secured as well, mainly by relocking the bootloader, as described in this article

47 comments:

  1. This was the most helpful article I've read on android disk encryption yet, thank you

    ReplyDelete
    Replies
    1. Thanks! Glad you find it useful.

      Delete
    2. Do you know if Jelly Bean (Android 4.1) changed anything about this process? Like if the encryption and/or key are now SHA-2 (256-bit) rather than 128-bit?

      Delete
    3. I was looking at Jelly Bean source code while I was writing this, so it should be up-to-date. Also see my comments on the android-security-discuss mailing list :)

      Delete
    4. Already did, just going to say you're awesome, definitely the person I need to be talking to. :D

      Delete
    5. Wow, your blog is very informative. Thanks so much for sharing!

      Delete
    6. First great article!

      A thought of the encryption key is stored locally on the device and could be retrieved by several ways like cold boot attacks.

      In your opinion how effective is actually the android encryption?

      Delete
    7. Thanks. The key is stored encrypted, cold boot, etc. try to read it from memory (RAM). Encryption it just as effective as on desktop PC's, etc. that do not have/use a TPM.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Thanks for the information & for making this utility available to the public!
    Do you know if its possible to change the password for encrypting an external SD card?
    My ICS tablet offers the ability to encrypt the external SD card but it only uses the unlock password. Changing the DE password does not affect the password for mounting/encrypting the SD card.

    ReplyDelete
    Replies
    1. Glad you find it useful.

      Encrypting the SD card is a vendor (or other third party) extension, and is probably different on different devices, so I can't really help. What device are you using? Do you have any third party MDM (device management, etc.) apps/extensions installed?

      Delete
    2. Thanks for your prompt response!
      I'm using a rooted Us Thinkpad Tablet running official stock ICS 4.0.3 ROM.
      I'm under the impression that the SD card encryption is based or dependent on the ICS Device Encryption capabilities.
      Is it possible to use the commands you highlighted to change the password for the SD card?
      What options or perimeters should I use?
      Thanks!

      Delete
    3. It might be an extension of the AOSP code, but I have no idea how it is implemented and I don't have this device either. Maybe try searching on Thingpad Tablet forums on XDA or similar sites, someone might have done this already.

      Delete
    4. Thanks for the reply.
      I think I would have to dig deeper to see if there's a way to do that.
      BTW, I tried your app on a friend's rooted stock ICS 4.0.4 AT&T Samsung Captivate Glide & it kept reporting an invalid password with the warning "The current encryption password is incorrect".
      I've typed the password many times & I'm confident it is correct.
      I even changed the password even after a reboot, I got the same error message.
      Are you aware of anything that could possibly prevent the change of the encryption password?

      Delete
    5. I just ran the ADB command you outlined:
      $ su -c vdc cryptfs changepw newpass
      & it worked flawlessly.
      I was able to change the disk encryption password.

      Delete
    6. If it works from the command line it might be a problem with the app. Does the password have any special characters in it (not letters or digits)? The app does handle does, but the procedure is somewhat tricky so there might be a problem somewhere.

      Delete
    7. Nikolay,

      Thanks for responding.
      I missed your reply & just returned from a trip with my family.
      There are the normal characters & digits along with 1 or 2 special characters like @ & !.
      It seems this is also happening on another Samsung Galaxy S2 Skyrocket running stock rooted ROM.
      It kept saying the current password is invalid no matter how many times I typed it.
      Using ADB, I got Invalid ID: cryptfs when running the commands.
      What do you think is happening?

      Delete
    8. HI there,

      Wondering if you might be able to help. Like konker reported back in March, I'm getting issues when trying to enter my password via TWRP too. I also have to have my device encrypted for my work's MS Exchange access

      I'm using latest TWRP 2.6.3.3 and have had no issues with my encryption password not being recognised with this version of TWRP before (previous TWRP versions, this current TWRP version on a previous ROM)

      Device details - I'm using an international (GSM) HTC One. Recently I have upgraded to Android 4.4/Sense 5.5 via Telstra OTA update. The ROM is entirely stock from Telstra, just unlocked/rooted. Super user is via SuperSU v1.80

      Any help would be awesome! I have also posted on XDA-Developers: http://forum.xda-developers.com/showpost.php?p=47944893&postcount=3

      Delete
    9. Sorry typo... phone is running Android 4.3 and not 4.4 as previously stated.

      Delete
  4. Thank you. Very well and understandable written.
    I'm new to the smartphone world ( I will receive my first one this week) and looking for security issues and your article is very informative and i will use this information to change my encryption password.

    ReplyDelete
    Replies
    1. Thanks, glad you find the post useful. Keep in mind that using this method requires rooting the device, which may void your warranty in some cases. Make sure your device works reliably first and, as usual, proceed with caution.

      Delete
  5. this is a fantastic piece. i am definitely going to have more of my clients experiment with using Android encryption, now that i know it's so easy to set the crypto password as something separate from the screenlock.

    I am VERY curious how android encryption is handled when making nandroid or other similar filesystem backups. For example, i use Team Win Research Project's TWRP Recovery. I have read that this supports and understands encrypted /data partitions but i am very curious as to how well it works.

    I am also wondering how secure the resulting backup files (which often reside on the microSD card) are. Does it just make a raw image of that partition, in its encrypted state?

    And therefore, it must be a requirement that RESTORING from backup should involve restoring /system as well as /data ... since the resultant boot scenario must be one where the android O/S is expecting to see an encrypted /data partition.

    ReplyDelete
    Replies
    1. Thanks, glad you find it useful. Do keep in mind that this requires root and as such is not supported (by Google, carriers, etc.), in case support is important for your clients.

      TWRP works fine with encrypted /data. It will ask for your password on boot and mount /data if you provide the correct one. If you don't it still works, but is not particularly useful. On phones where the 'SD card' (external storage) actually resides in /data that is actually the only way to backup/restore. If you use such a device, the backup images will be in /data and thus encrypted. I haven't looked into the implementation in detail though and don't know whether it takes a raw image of the encrypted partition (probably does).

      Not sure what you mean by the /system comment above? IIRC, Android will check the /data header to see if it is encrypted, and if so present the password prompt so it can decrypt it. There is nothing special in /system, as long as it is a compatible version (3.0+), it should work.

      Delete
  6. hi, When encrypting an Android device, do the certificates installed on the device get encrypted too. Please reply..

    ReplyDelete
    Replies
    1. As explained in the first section, the /data partition is encrypted. Anything stored there will be encrypted on disk.

      Delete
  7. Hi! Rooted my Galaxy S2 with jelly bean, installed cryptfs, changed pin to password and encrypted the SD card. Cryptfs will not work, I get the message that the device is not crypted, which is correct. I assume that cryptfs is not intended to be used when only SD card is encrypted.
    Before I go ahead and encrypt the whole device I would like to know how to enable screen lock print while encryption is active. Do I set password, encrypt, change PW with cryptfs and after that I can disable PW and set screen Pin. If that doesn't work I will have to a full restore to get out of encryption.

    ReplyDelete
    Replies
    1. Encrypting external storage (SD card) is not supported by stock Android, that's a Samsung extension. I have no idea how it works. Not exactly clear what you want to do, but generally after you encrypt, changing the screen lock password/PIN will also change the encryption password. You can use the app (or vdc cryptfs) to change only the device encryption password without affecting the screen lock PIN/password. This is explained in detail in the article.

      Delete
    2. Could you add that statement to the main entry? It's not specified the behaviour respect to both internal and external sdcards.

      Delete
  8. You seem to provide the most help yet:), but here is my situation: I encrypted phone and sd card in October. Couple days ago I changed pin lock screen. Now I cant get into phone with new or old passwords. I've tried several attempts and to no avail. In addition, I contacted service provider and Samsung. No one will help me. If I factory reset I lose all data on phone and encrypted card. I also tried ADB, but to no avail as well. My phone will not provide serial number, as well even acknowledge on my PC. Any suggestions?

    ReplyDelete
    Replies
    1. If you can boot the phone and get to the lock screen, in the standard Google configuration (not sure if Samsung has changed that) and keep trying different PINS, eventually it will ask you for your Google account password. If you provide that, you should be able to login and change the PIN, etc.

      If you cannot boot, but have an unlocked bootloader or custom recovery, you can try extracting the boot sectors and brute force the encryption PIN, there are tools available for this. Since that's only 1000 combinations, it should be done in minutes tops.

      Delete
    2. I've tried 500 attempts, no avail for google, otherwise i would be all good. I truly believe my phone has a serious glitch. But on another note, as it is booting up, i noticed when i tap the home button repeatedly along with the emergency call button, at times i can see inside the phone such as: text messaging, phone dialer, etc., but i know i am not fast enough to overwrite that. I'm thinking the bootloader is locked (not that tech savvy), but i do know that when I hold the down volume key and power button, it goes to a custom os. I have not done anything there because I am nervous of wiping this phone out. With the information given could I still brute force? Or just give up?

      Delete
    3. If it is booting, something could probably be done. Your best bet is find someone to actually look at it, or better yet, contact a company that specialized in data recovery.

      Delete
    4. Yea, I have a guy in town who gives me a 50% chance he may possibly retrieve the data but then I will have to reboot the phone. Taking it to him tomorrow. I appreciate your help. I just feel its unfortunate when the provider nor the manufacturer can assist in their products. I understand legalities, but it is my phone I want in. I did not lose my passwords, I know it is a glitch within my phone because every forum and person I spoke to has no understanding of my situation. And I have even reached out to "experts" and tried several different softwares. It is what it is. Thanks again!

      Delete
  9. That's awesome. Is there a way to decrypt from the command line as well?

    ReplyDelete
    Replies
    1. Decryption is not supported by AOSP, it is most likely a vendor extension. If you want to revert to unencrypted /data on a stock device, you have to reset it. You can use `adb backup` to save/restore same of your data and apps. To backup the entire partition use a recovery that understands encryption, such as TWRP.

      Delete
    2. Could you add that statement to the main entry?

      Delete
  10. I would like to emphasize that "changing the screen lock password/PIN will also silently change the device encryption password.".

    I changed my password and a couple of days later my pin.

    Another couple of days went by and i decided to upgrade my phone to the next release of my most favorite ROM (cyanogenmod).


    Upon my first reboot, i was puzzled which key to use (old pin = old password or my manually updated one) and completely forgot about the above note.

    I even thought that the update might have broken something ... tried to mount my encrypted data via clockworkmod recovery

    I then, by chance, entered my current pin and voila, everything worked again.

    I hope that this may help someone out there too :)

    ReplyDelete
  11. Excellent tool!
    Can the screen lock be reverted back to pattern unlock (or basically anything other than password/PIN) after using Cryptfs Password?

    ReplyDelete
    Replies
    1. No, this requirement is enforced by the system.

      Delete
    2. Nikolay, thanks for this - I just now noticed this post. Very good work. I've also experienced problems decrypting with TWRP (v. 2.6.3.0 for 2012 wifi N7 aka grouper). Any thoughts on what may be causing this?

      Delete
    3. that wasn't supposed to be posted here. Not used to blogger's comment system.

      Delete
    4. Not sure, but the key derivation algorithm has changed in 4.4. If you started an encrypted device with 4.4 at least once it has been updated. Maybe TWRP still does not support the new algorithms (scrypt)?

      Delete
  12. I was wondering, since the key is generated immediately after reboot from /dev/urandom, is there sufficient entropy in the system to guarantee security? I'm not sure whether Android saves any entropy on shutdown, particularly when it reboots automatically to encrypt in place.

    ReplyDelete
    Replies
    1. Android does save entropy periodically and on shutdown and feeds it to /dev/urandom on startup. As of 4.4 this is done pretty early in the boot sequence, so encryption should be OK. You'll have to check the exact sequence for previous versions.

      Delete
  13. Hi do you know if encrypting the sdcard is still a Samsung extension? the built in version doesn't support sd card encryption?

    ReplyDelete
    Replies
    1. It depends on what you mean by 'SD card'. If it is used as external storage, it will be encrypted in 4.4. If it is treated as secondary external storage, it won't in AOSP. I have not idea what exactly Samsung are doing.

      Delete