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.
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.
The user-mode part of disk encryption is implemented in the
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
The implementation is quite straightforward: it simply invokes the
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.
Comments
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.
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?
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!
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?
$ su -c vdc cryptfs changepw newpass
& it worked flawlessly.
I was able to change the disk encryption password.
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.
learn how to root your android tablet and phone
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.
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.
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.
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?
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.
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 :)
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?
Can the screen lock be reverted back to pattern unlock (or basically anything other than password/PIN) after using Cryptfs Password?
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
root@android:/ # su -c vdc cryptfs changepw password
su -c vdc cryptfs changepw password
xxxxxxx
200 0 -1
i noticed my results ended in -1 where as yours ended in 0
why??
So why are you trying to change the encryption password anyway? Does it sync when you change the lockscreen password?
I have a Galaxy S5, with 4.2.2 (http://imgur.com/a/q5MJE see for full version) stock that is now rooted and encrypted. I really need and want to change the password for only 16 characters. Not to mention having the password and PIN for screenlock seperated......
But it won't work with your appfix, neither the adb command. I receive the same message as Ricky above with -1.
PLEASE help me out. I really need this!!
Thanks in advance
$ su -c vdc cryptfs changepw insertymynewpasswordhere
su -c vdc cryptfs changepw insertmypnewasswordhere
200 0 0
When I reboot, it says "password is correct, but the data is corrupted."
The OnePlus One uses hardware encryption, that is likely to be the issue.
cryptfs works fine with CM-12 on my Nexus 4 and Nexus 7 devices.
Now I'm considering the next step for a gain in convenience without sacrificing security, and I'd like to profit from your expertise and get your opinion about it.
(Known) facts:
- You should use a strong encryption password, as described here, to protect against "cold" attacks (e.g. after losing your phone).
- You should use a display lock to protect against "hot" attacks, but it does not necessarily need to be as strong.
- You should use a SIM PIN lock to prevent people getting access to your phone number / connection.
As of now (I'm on Android 4.4.4), this means I have to enter three passwords on boot - first SIM PIN, then encryption pw, then display lock. I have a faint idea that there might be ways to avoid display lock right after boot, but what really bothers me is the SIM lock.
Is there any reason not to store the SIM PIN on the encrypted part of the phone, and have it entered automagically after mounting the cryptfs? (For a production version, probably a table which identifies the SIM card and chooses the appropriate password from a list of selected entries.)
AFAIU, there already are ROMs which keep the SIM PIN in memory to avoid connection losses after a crash of some software part followed by a soft reboot - e.g., I experienced this (or a similar) workaround for the infamous RIL bug of the Motorola Defy+ with its stock ROM. Also, there's a "soft reboot" feature enabled by some mods for rooted ROMs, which only restarts the software, but does not require unlocking the cryptfs once again; I'm not sure if the SIM is re-locked and re-unlocked during that process.
And if such an approach causes no security concerns, can you imagine an easy way of enabling it? Where "easy" for the time being means possible using the Xposed framework or the like on a rooted phone, but with some stock ROM. There is a module which avoids the need for unlocking the SIM after coming back from flight mode, but this seems to work by not locking the SIM in the first place.
Of course, integrating such a functionality for Cyanogenmod et al. might also be worthwhile, but is left as an exercise to the interested reader...
Back to the drawing board...
some example logcat for the -1 error on changing pw:
D/VoldCmdListener( 239): cryptfs changepw password {}
W/Cryptfs ( 239): Password not correctly hex encoded.
D/QSEECOMAPI: ( 239): QSEECom_get_handle sb_length = 0x2000
D/QSEECOMAPI: ( 239): App is already loaded QSEE and app id = 2
D/QSEECOMAPI: ( 239): QSEECom_dealloc_memory
D/QSEECOMAPI: ( 239): QSEECom_shutdown_app, app_id = 2
I/Cryptfs ( 239): Using scrypt with keymaster for cryptfs KDF
E/Cryptfs ( 239): Trying to convert ascii string of odd length
E/Cryptfs ( 239): Failed to convert passwd from hex
E/Cryptfs ( 239): scrypt failed
E/Cryptfs ( 239): Error encrypting master key
also the usage of changepw seem to have slightly changed:
500 0 Usage: cryptfs changepw default|password|pin|pattern [newpasswd]
Ciao!
Now, would you mind if I use your expertize? My phone woke up one day asking for a key to decrypt storage (upon a reboot)... needless to say that I never tried to encrypt it.
I have tried to do a factory reset but I can't access recovery menu. I also tried volume up/down + power key combination to do recovert but no luck.
Am I left with a bricked phone?
Model is Sony Xperia M
Any help would be welcome!
Thank you in advance