Locking Down Android Encryption


See the SPSM 2013 paper.


Android devices use volume encryption to protect private data storage. While this paradigm has been widely adopted for safeguarding PC storage, the always-on mobile usage model makes volume encryption a weaker proposition for data confidentiality on mobile devices. PCs are routinely shut down which effectively secures private data and encryption keys. Mobile devices, on the other hand, typically remain powered-on for long periods and rely on a lock-screen for protection. This leaves lock-screen protection, something routinely bypassed, as the only barrier securing private data and encryption keys. Users are unlikely to embrace a practice of shutting down their mobile phones, as it impairs their communication and computing abilities. We propose Deadbolt: a method for maintaining most mobile computing functionality, while offering the security benefits of a powered off device with respect to storage encryption. Deadbolt prevents access to internal storage even if the adversary can exploit a lock screen bypass vulnerability or perform a cold boot attack. Users can gracefully switch between the Deadbolt and unlocked modes in less time than a system reboot. Deadbolt offers the additional benefit of an incognito environment in which logs and actions will not be recorded.

We introduce a method for providing enhanced data protection beyond that which is currently achieved by the combination of Android storage encryption with a lock-screen. Android users are currently forced to decide between functionality and security. If the device remains powered on, the user can receive calls and notifications but the encryption key is in memory. If the device is powered off, users get the full protection of encryption but both lose the functionality and incur the latency of booting up every time they want to use it. Our proposal, Deadbolt, protects the encryption key and encrypted data without losing communication functionality or the need to incorporate additional hardware. Deadbolt gives the protection of a device that is powered off, and the functionality of a device that is powered on, as well as a diminished delay in returning the device to a fully functional state.

Source Code:

Deadbolt source code was written for Android 4.2.2 and tested on a Nexus 7 device.


  1. Copy the files from the archived directories into your AOSP working directory overwriting the original files.

  2. Build the system by following the instructions from the AOSP website:


All Deadbolt functionality is implemented in the Android volume mounting daemon (vold). To enable and disable Deadbolt, we provide a system app that invokes the underlying vold functionality (see Figure 1).

Enable Deadbolt UI Disable Deadbolt UI
Figure 1: Deadbolt UI

The default user experience when enabling Deadbolt is similar to that of setting up a new device: no entries exist in the address book, default wallpapers and notifications are used, wireless network passwords are undefined, etc. While this bare environment is sufficient for receiving phone calls and browsing the web via a data connection, users may wish to have some of their private data available in Deadbolt mode. Likewise, users may wish to export some of the data created in Deadbolt mode back to encrypted volume (e.g., SMS messages received while in Deadbolt). We provide functionality to import/export data between environments when Deadbolt is initialized without safe-mode (see the paper for further details).


Adam Skillen
CCSL - Carleton University

David Barrera
CCSL - Carleton University

Paul C. Van Oorschot
CCSL - Carleton University

Last Updated: 21-Aug-13