I've set up full-disk encryption on my Google Nexus One running CynanogenMod 7 using LUKS, and I've been wondering if it is vulnerable to a cold-boot attack (CITP research). My phone, with its open bootloader and USB “fastboot” mode, is roughly comparable to a PC that can be reset and then booted from an attacker-controlled PXE image.
I prepared an Android boot image with the LiME forensics module configured to acquire the RAM image to the PC over TCP/IP tunneled through adb. I'll call this boot image the Image Acquisition Program (IAP). I usually had my system waiting for the phone to appear on USB in fastboot mode, ready to push out an image to boot from. (I messed up a few times and the phone sat idle in fastboot mode for a few seconds longer, but this probably doesn't affect memory retention.) I used my hacked up version of Torbjörn Pettersson's keysearch program (original) to look for keys. I didn't try CITP's AESKeyFinder or AESFix because the key was longer than they supported. The key I was searching for was the LUKS master key, which I believe is just the raw lower-level dm-crypto key. I'm not trained in experiments like this, so these results should be taken with a grain of salt.
The target system was not taking any precautions to flush the key on shutdown or reboot. In all experiments, the phone started booted and decrypted, at the lockscreen. adb was enabled except as noted.
With the phone plugged in to USB, use adb to reboot into fastboot mode, boot IAP: Full key recovered.
Disconnected from USB, adb disabled, use the reboot menu to do normal reboot while holding fastboot key, boot into IAP: Full key recovered.
With the phone plugged in to USB, use the reboot menu to reboot straight into fastboot, boot into IAP: Full key recovered.
With the phone plugged in to USB, use the reboot menu to do normal reboot while holding fastboot key, boot into IAP: Full key recovered.
Disconnected from USB, use the reboot menu to reboot, boot into IAP: Full key recovered.
Soft reset (Trackball + Volume down + Power), hold fastboot key, boot into IAP: Inconclusive. In one out of 3 tries, the full key was recovered. It seems this reset isn't as soft as a normal reboot, but it may not be consistent in that either.
With the phone plugged in to USB, use the shutdown menu to turn off, turn back on, boot into IAP: Key not found. (Tried twice.)
With the phone plugged in to USB, pull the battery momentarily (long enough for screen to turn off), turn back on, boot into IAP: Inconclusive. On first try, two garbled copies of key found. One had about 8 bits corrupted (from 1 to 0). Tried 3 more times, and nothing looking like the key was found. I may have accidentally changed a variable when I tried again the next day, or perhaps some speed or just "luck" (in uncontrollable variables in the state of the electronics) is needed to get the result I got the first time.
Disconnected from USB, pull the battery momentarily (long enough for screen to turn off), turn back on, boot into IAP: Key not found.
Conclusions: 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.
Recommendations: Make the phone unable to reboot itself when the phone is locked. If possible disable soft reset keychord. Attempt to flush key by luksClose'ing (or perhaps wiping all RAM) in case of software reboot. Even with these precautions, it may be possible to force a reboot anyway (the soft reset keychord may not be software-based, exploits at the lockscreen or over USB connection), and the key may still be in RAM. The only defenses that come to mind involve patching the early boot firmware: to either wipe all RAM before any boot image takes control, and/or only accept cryptographically trusted images. Even these would probably be insufficient against a determined, resourceful attacker, so the best scenario would be to pull the battery (and perhaps boot again and wipe RAM) long before they have a chance at it.
Edit 6 Dec 2012: I realized a couple of problems with my tests. I was using my "IAP" to boot the system normally after acquiring the image. Since I didn't take any precautions to wipe RAM between tests, each acquisition potentially had remnants of several instantiations in it. This might explain some of the inconsistent results. Even if my exact conclusions are potentially flawed from this, I think the general point, that a coldboot attack is plausible, still stands.