Deniable Storage Encryption for Mobile Devices


See the TDSC 2014 article for specifics on MF-MTP,
and the NDSS 2013 paper (Slides) for general implementation details.

Description and Motivation:

Data confidentiality can effectively be preserved through encryption. In certain situations this may not be adequate, as the user may be coerced into disclosing their decryption key. In this case, the data must be hidden so the user can deny its very existence. Steganographic techniques and deniable encryption algorithms have been devised to address this specific problem.

Due to the sensitive nature of data stored on mobile devices, all major mobile OS manufacturers now include some type of storage encryption. Given the recent proliferation of smart phones and tablets, we examine the feasibility and efficacy of Plausible Deniable Encryption (PDE) for mobile device storage. We present Mobiflage for the Android OS, allowing users to provide a decoy password in a plausible manner if they are coerced to give up their encryption keys. We leverage lessons learned from deniable encryption in the desktop environment and assess new threats specific to mobile systems that can compromise deniability.

There are many scenarios in which PDE is desirable: for example a journalist or human rights worker operating in a region of conflict or oppression. Mobile phones have been extensively used to capture and publish many images and videos of recent popular revolutions and civil disobedience. PDE-enabled storage on mobile devices can protect a user from punishment, if they are caught smuggling such data. One example where PDE may have been useful recently occurred when an individual risked his life to smuggle evidence of atrocities across international borders.

Some key features of Mobiflage include:

Legal Aspects:

Some countries require mandatory disclosure of encryption keys in certain cases. Failure to do so may lead to imprisonment and/or other legal actions. Cryptography can be used for both legal and illegal purposes and governments around the globe are trying to figure out how to balance laws against criminal use and user privacy. As such, laws related to key disclosure are still in flux and vary widely among countries/jurisdictions.

Some of our recommendations, such as spoofing the IMEI or using an anonymous/"burner" SIM card, may be illegal in certain regions. Please consult local laws before taking such steps.

Mobiflage is proposed here not to encourage breaking laws; we want to technically enable users to benefit from PDE, but leave it to the user’s discretion how they will react to certain laws. Our hope is that Mobiflage will be predominantly used for good purposes.

Source Code:

The kernel images were produced with unmodified source code found here:

Build Instructions:

  1. Place the patch file in the [ANDROID-SRC]/system/vold directory. Depending on your target system (ICS or JB), execute the following to apply the patch:

    ICS: $ patch < mobiflage_ics.patch

    JB: $ patch < mobiflage_jb.patch

  2. Make sure you have compiled a kernel with xts and gf128mul crypto support. Consult your device manufacturer for device specific kernel source. Place the kernel image in the [ANDROID-SRC]/device/[VENDOR]/[PRODUCT]/ directory. The file must be named "kernel". For example, the Nexus S kernel binary should be placed at [ANDROID-SRC]/device/samsung/crespo/kernel

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

Mobiflage for devices with MTP:

The following implementation of Mobiflage is for use with newer devices that rely on internal storage and the Media Transfer Protocol (MTP) to emulate removable storage (e.g., the Nexus 4). Tested on Android 4.2.2


Android 4.3 now enables the allow_discards dm-crypt parameter, which issues the TRIM command to underlying flash storage (see the commit message here). This feature has serious implications for deniability, and should be disabled before attempting to use Mobiflage with Android 4.3

Overview of Mobiflage:

Mobiflage Storage Layout
Figure 1: Mobiflage SD-Card Storage Layout


We define two use cases for Mobiflage:

  1. Standard mode is used for day-to-day operation of the device. It provides storage encryption without deniability. The user will supply their decoy password at boot time to enter the standard mode. In this mode the storage media is mounted in the default way (i.e., same configuration as a device without Mobiflage).

  2. PDE mode is used only when the user needs to store data and later deny it exists. The user will supply their deniable password during system boot to activate the PDE mode. In the PDE mode, we mount the hidden volumes onto the file-system mount-points where the physical storage would normally be mounted (e.g., /data, /mnt/sdcard).

Step 1: Enable Mobiflage PDE
Currently, the user can activate PDE through the underlying command-line tool: vdc. When a user wishes to encrypt with PDE they can issue the following shell command:
vdc cryptfs pde <inplace|wipe> <outer_pwd> <hidden_pwd>
In-place encryption will only be applied to the internal storage. Unlike the Android in-place encryption, Mobiflage must initialize the external storage with random data for the sake of deniability.

The system will perform the encryption, create the hidden volumes, and reboot when complete. This step is time consuming and will erase existing data in the external storage. The external storage is filled with random data twice to ensure all physical Flash cells have been wiped. This additional requirement makes Mobiflage much slower than the default Android encryption (almost twice as long on our test devices).

Encrypting Device
Figure 2: Encrypting Device with PDE

Step 2: Day-to-day Use of the Mobile Device
For normal day-to-day use of their mobile device, the user will supply the decoy password at boot time. This will activate the standard mode, where the user can perform all their normal activities on the device, such as making calls and browsing the web. All data saved to the device in the standard mode will be encrypted but not hidden. It is favorable to use the PDE mode only when necessary and the standard mode at all other times.

Step 3: Hiding Files and Apps
When the user requires the added protection of deniable storage, they will reboot the device and provide their deniable password when prompted. In the PDE mode, they can transfer documents from another device, or take photos and videos. After storing or transferring files to the deniable storage, the user should immediately reboot into the standard mode. The files are hidden as long as the device is either off, or booted in the standard mode.

Enter Password
Figure 3: Enter Password; the password you provide determines which mode is activated.

Step 4: Denying the Hidden Files
If the user is apprehended with their device and forced to reveal their password, they can supply the adversary with the decoy password. The adversary can examine the storage but will not find any record of the hidden files, apps, or activities. All mutable storage volumes are either hidden or ephemeral (e.g., cache, persistent logs, etc.) while in the PDE mode.

Decrypt Decoy Volume
Figure 1: When faced with coercion: divulge the decoy password and deny the hidden volume exists.

Maintaining Deniability:

To maintain deniability in Mobiflage, we expect users to follow certain precautions. Please see the paper for details concerning carrier collusion and information leakage. We recommend the user reads the extensive TrueCrypt documentation concerning deniable encryption: Hidden Volume Precautions and Security Requirements and Precautions

We also recommend reading the advice from the Tor Project concerning online anonymity.

We rely on the user to choose a strong password to protect their hidden volumes. An offline attack is possible against the encryption key and the user should choose a password with high entropy (see the Myphrase system which can be used to create passwords for use with Mobiflage).


Adam Skillen
CCSL - Carleton University

Mohammad Mannan
CIISE - Concordia University

Desktop Solutions:

There exist several solutions supporting full disk encryption with plausible deniability for regular desktop and laptop operating systems. The tight coupling between hardware and software, as well as intricacies with the system boot procedure, do not lend themselves to simply porting such systems to mobile devices.

cryptsetup + stlth

Obsolete Projects:
ScramDisk 4 Linux

Last Updated: 17-Dec-13