Traditional computer operating systems have been around for a while, long enough that concerns around physical security have been well addressed. We understand the value and power that the information on our computers can provide to an attacker, so we have locked them down with features such as disk encryption, passphrase protected lock screens and techniques to prevent unwanted DMA attacks via high speed buses.
Yet despite the massive development of mobile devices technology in the past several years, a number of these features didn’t manage to make their way into the mobile operating systems as defaults. Whilst we take the time to setup disk encryption on our laptops and maybe desktops, we tend not to bother securing our mobile devices, possibly due to the perception of them being less risky to have exposed, or that they are less attractive targets.
Even a relatively paranoid IT geek like myself with an encrypted laptop, secure passphrases, and VPNs, still had a mobile phone that was protected with nothing more than it’s physical proximity to myself. Anyone gaining physical access to my phone could unlock it, whether it be by guessing a trivial unlock pattern, or by attaching it to another computer and reading the unencrypted filesystem.
And as these mobile devices have increased in functionality, so has the risk of an attacker getting hold of the device. When a mobile phone did nothing but phone calls and txts, having someone gain access would be more of a annoyance when they rack up a bill or prank call your contacts, than a serious risk.
But rather than leave it there, we started adding other productivity features – email, so we could keep in touch on the go. Instant messaging. Fully featured web browers that sync account details, bookmarks and history with your desktop. Banking applications. Access to shared storage solutions like Dropbox. Suddenly a mobile device is a much more attractive target.
And even if we decide that the mobile apps are too limited in scope, there’s the risk of an attacker using the information such as credentials stored on the device to gain full access to the desktop version of these services. Having an email application that limits the phone to the inbox can reduce risk by protecting your archives, but not if the attacker can obtain your full username/passphrase from the device and then use it to gain full access with some alternative software.
Remember that obtaining credentials from a device isn’t hard – the credentials have to be kept in some decrypted format somewhere on disk, so even if they’re hashed/obfuscated in some form, they’ll still have the key that enables them to be exposed somewhere on disk.
A quick grep through the /data/ volume on my phone revealed numerous applications that had my passphrases in plain text, extremely easy pickings for an attacker.
Mmmm plain text passwords. :-)
I was getting increasingly concerned with this hole in my security, so recently having replaced my Galaxy Nexus with a Samsung Galaxy Note II, I decided to set it up in a more secure fashion.
Android added disk encryption in Android 3, but it’s suffered two main issues that limits it’s usefulness:
- The disk encryption only covers the data volumes (/data, /sdcard) which is good in that it protects the data, but it still leaves the application volumes open to be exploited by anyone wanting to install malware such as key loggers.
- Turning on Android disk encryption then forces the user to use either a PIN or a passphrase to unlock their device as swipe or pattern unlock is disabled. For a frequent phone user this is too much of an usability issue, it makes frequent locks/unlocks much more difficult, so users may chose not to use encryption altogether, or choose a very easy/weak passphrase.
The first point I can’t do much about without digging into the low guts of Android, however the second is fixable. My personal acceptable trade-off is a weaker lock screen using a pattern, but being able to have a secure disk encryption passphrase. This ensures that if powered off, an attacker can’t exploit my data and the passphrase is long and secure, but if the phone is running, I take a compromise of security for convenience and ease of use.
There’s still the risk of an attacker installing malware on the non-encrypted OS portion of the mobile device, however if I lose physical access of my phone in an untrusted environment (eg border security confiscation) I can reload the OS from backup.
To setup disk encryption on Android 4 without losing pattern unlock, instead of adjusting via the settings interface, you need to enable it via the shell -easiest way is via the ADB shell in root mode.
Firstly you need to enable developer mode in Settings -> About Phone by tapping the build number multiple times, until it tells you that the developer mode has been unlocked. Then inside Settings -> Developer options, change the “Root Access” option to “Apps and ADB”.
Enable ADB root for all the fun stuff!
Secondly, you need a workstation running the latest version of ADB (ships with the Android ADK under platform-tools) and to connect your phone via USB. Once done, you can enable disk encryption with the following commands (where PASSWORD is the desired encryption passphrase).
user@laptop # adb root user@laptop # adb shell root@phone:/ # root@phone:/ # /system/bin/vdc cryptfs enablecrypto inplace PASSWORD
Your Android device will then restart and encrypt itself. This process takes time, factor up to an hour for it to complete it’s work.
Android phone undergoing encryption; and subsequent boot with encryption enabled.
Once rebooted, your existing pattern based unlock continues to work fine and all your private data and credentials are now secured.
What’s the battery and performance penalty of turning on Android encryption?
It makes use of Linux’s dm-crypt. Assuming no hardware crypto acceleration there will be additional CPU usage and slower throughput, but full speed seek performance. Seeing as its all small bits of data rather than anything major, I presume very minor impact for my use case.
It certainly would be interesting to do a benchmark before and after with bonnie++ , just requires porting it over to Android
Having been forced to encrypt my Motorola DROID hd maxx for corporate use, I can say with assurance that you will feel the pain of encryption and hate it. My phone was buttery smooth before encryption and laggard unresponsive after. Once in a program (like typing this) it is OK but things like moving in the launcher, switching programs, or even bringing up a keyboard after clicking on a cell bring delays and pauses. Loved my phone before encryption. Hate it after, but even with lags Android is still better than moving to iOS (which has hardware encryption built in and is a more responsive device with encryption enabled) .
Personally I’m finding the Galaxy Note II with disk encryption pretty good, however it does feature a much higher spec CPU (quad-core 1.6ghz vs dual-core 1.5gz) so that may well be the reason why performance is so different. Have been using it for about a month now with no ill effects.
THANK YOU!
SO MUCH FOR WRITING ABOUT THIS. I was able to install adb onto my linux box and then use the commands you provided. And it allows me to have a pattern to unlock the screen, but requires a long password for the boot up to decrypt. Exactly as it should be. The really need to fix this (enable this ability) soon…
YOUR ARE WONDERFUL!
-Paul
Do you know how to get this to work on Android 4.4.4? I’m trying to get this to work on my Nexus 5 running rooted Android 4.4.4, but the command:
root@hammerhead:/ # /system/bin/vdc cryptfs enablecrypto inplace PASSWORDprints
ecrypto inplace PASSWORDin the command prompt and causes the phone to reboot without being encrypted (the phone is fully charged). Do you know how to get around this?I got it to work! I ran cryptfs, but unplugged my phone when it restarted, and it started encrypting. I’ve rebooted it a couple times and it prompts for my encryption password at boot and uses pattern unlock after that.
Thanks for this guide!
so this is how it went down for me. Using a pretty exotic mediatek octa core phone with 4.4… After the commands the phone reboots and then shows an android loading logo (simular to windows 7 boot screen ;-) ), after 10 minutes it kinda reboots again, but the screen stays black. I waited shortly, but then I always pressed power putton, and a screen came up saying encryption failed , and i had to wipe and reflash everything…
Turns out, the state when the screen was black was when the phone was actually encrypting. So I didnt see a nice screen like on the screen shots, showing percentage etc. I waited some more minutes with black screen, and tadaa! all working fine!
Hope I could help somebody! thx for the good tutorial!
btw, is there a way to change keyboard layout of the encryption password?
Dear Jethro Carr,
i tryed to encrypt Oppo Find 7 and was not successful even the above method
C:\Windows\system32>adb root
adbd cannot run as root in production builds
C:\Windows\system32>adb shell
shell@X9070:/ $ /system/bin/vdc cryptfs enablecrypto inplace 2580
/system/bin/vdc cryptfs enablecrypto inplace 2580
502 0 No permission to run cryptfs commands
Any further help?
regards Rajaram
I had that problem too with Galaxy S3
First type “adb devices” and see if it detects your device
Than I solved typing “adb shell” and then “su”
After that command prompt should look “root@phone:/ #”
If so you can directly type the encryption command
hi, after I used this tutorial several times and always freaked out on the same step, i feel like i should share thi ;-)
if your pw has an empty space in it, use ‘…’ these little guys!
So instead of
… inplace PWwith Space
use
… inplace ‘PWwith Space’
otherwise youll get an error!
Great Tutorial, thanks!
Any idea if this works as described on Android 5.0, CM11, CM12? Would like to know before I try it and irreversibly get stuck with a long password to unlock my screen. Thanks!
It works!! Thanks very much
But it won’t encrypt micro SD card :-(
Hi,
Was your phone rooted? If so it may be a prerequisite to this procedure (I couldn’t do it on an unrooted N4).
Thanks for the post! What happens if you try to change the PIN after this? With other processes, I have seen, this is a problem because Android tries to always use the same password for the unlock and the encryption. Also, are you able to change the encryption password by repeating the above command?
Can the encryption process be reversed and if so: how?
Is there a way to encrypt SD Card with this command?
Dear author can you please update the article to include a method to encrypt the sd card too? thank you
Decrypting the disk when going to sell the phone was a bit tricky. If using Cyanogenmod, the best solution seems to be rebooting into the recovery manager, then connecting to it via ADB to run:
adb shell
recovery –wipe_data –set_filesystem_encryption=off
This disabled disk encryption and erased ALL data in a way that the general “factory reset” option in settings didn’t do.