Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Hi I am trying to understand how encrypting an Android based phone works compared to a GNU/Linux host which relies on LUKS dm-crypt.

Here is what I understand: Encrypted LVM on GNU/Linux is an option only available at initial install, so there is no opportunity to do that at a system level later on, if it isn't done in the beginning. Removing FDE would need a full reformat of the drive after data backup. The only way to be safe while using FDE is to completely turnoff the device and not leave it in a suspend to RAM mode. Password screen savers are useless in this event because a memory dump can retrieve the key. Hibernation is OK as SWAP is encrypted by default. Please feel free to correct me on any of this if I am wrong.

What I am puzzled about: How can Android perform post install encryption of the system when it relies on LUKS too? Does it only encrypt the internal storage and not the SD card? What is the point of encrypting if the cellphone is left in an ON state for most of its life, shouldn't a thief be able to bypass the swipe screen encryption by dumping the phone RAM and extracting the master key?


share|improve this question
up vote 6 down vote accepted

Android implements the device encryption in a module of Vold (Volume Daemon) called cryptfs that makes the calls to the kernel which actually encrypt the device. When a user encrypts the device, Vold reboots the device and begins encrypting the data partition. During the encryption process Vold disables everything that is not a core service on the device. Android requires that the user create a passcode if they have not already set one at the beginning of the encryption process, which is one of the criticisms of the implementation since the decryption process is tied to the users screen unlock passcode which isn't super complex. Once the device is encrypted, according to the documentation at the AOSP page, the encrypted master key is stored in the footer of the data partition. As far as I know Android's implementation only encrypts the data partition, which would be user and app data. Once the device is encrypted the user will have to enter their passcode whenever the phone is locked. Before they can access their data, the kernel mounts a tmpfs/data that reads from the actually encrypted block devices. Your screen unlock passcode hashed and used to decrypt the master key. This is the description on the Notes on the encryption implementation.

The crypto footer contains details on the type of encryption, and an encrypted copy of the master key to decrypt the filesystem. 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. Also, the flag CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure to complete the encryption process. See the file cryptfs.h for details on the crypto footer layout. The crypto footer is kept in the last 16 Kbytes of the partition, and the /data filesystem cannot extend into that part of the partition.

Once the device is encrypted, the only way to undo it is to wipe data. I don't think that the default implementation you get in the AOSP source encrypts the SD card since not all android devices have a removable card, like the Galaxy Nexus, but I guess device manufacturers could add support in for that. The AOSP documentation on the FDE implementation is available here, Android Notes on Encryption Implementation. It's pretty thorough compared to some of the other AOSP docs. You might be interested to check out this blog post, Cold-boot encryption key recovery on an Android phone that has some information on attempting key recovery with CyanogenMod7.

His conclusions were:

The key is fully recoverable if the phone reboots itself. It may be recoverable if the soft reset keychord is used. It may be partially recoverable if rebooted by power-pull (there may be an error in the experiments here.) It appears to not be recoverable if the phone powers itself off. Variables such as rebooting directly to fastboot or doing a normal reboot while holding the fastboot key, or leaving it connected to USB or not, appear to be irrelevant.

But he was running CyanogenMod7 so I don't know if that is generally applicable to stock ROMs on devices or ROMs built straight from AOSP, but maybe there is some more information and research out there about the potential for key recovery.

Hope this helps some.

share|improve this answer
Thank you for your response, it clarifies a lot. – Mazigard Feb 15 '13 at 14:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.