Deniable Storage Encryption for Mobile Devices

Publications:

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:

• Deniable file systems, based on hidden encrypted volumes, with limited impact on throughput.
• Efficient storage use with no data expansion.
• Intuitive user experience, as the functionality is transparent to the user and applications.
• Mobiflage PDE is an optional feature (i.e., a user can encrypt without hidden volumes).
• Countermeasures for known attacks against desktop PDE systems.
• Challenges specific to a mobile environment are addressed, including: collusion between cellphone carriers and adversaries; the use of flash-based storage as opposed to traditional magnetic disks; and file systems such as Ext4 that are not favorable for PDE.
• In the paper, we present recommendations to restrict sources of leakage, disclosure, and collusion which could compromise deniability.
• To the best of our knowledge, this is the first such PDE scheme designed for mobile systems.

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:

• Mobiflage ICS (4.0.x) source code patch
  MD5: 6ab27494c4791a9ce0e71ae9148309f5
  


• Mobiflage JB (4.1.x and 4.2.x) source code patch
  MD5: 7f55e5fb284fc930af6460c5a1b1163c
  


• Nexus S ICS kernel image (with gf128mul and xts support)
  MD5: 13f07be522c54899a0698c69e3ad3fb7
  


• Nexus S JB kernel image (with gf128mul and xts support)
  MD5: fe8a2aeddd4938454a51cc6e6a17c458
  

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: http://source.android.com/source/building.html

Mobiflage for devices with MTP:

• Mobiflage MTP (4.2.x) source code
  MD5: 9cf13d72c5138cfe2a97d83fa9863d73
  


• Nexus S MF-MTP kernel image
  MD5: 79bd524c97951e956cd8a6d56c5cf355
  


• Nexus 4 MF-MTP kernel image
  MD5: fb655e58da3e26cfb8e4257e79bb77a4
  


• Nexus 7 MF-MTP kernel image
  MD5: dc4a9488aaf9c88c1fe80d70b036fa4d
  

WARNING:

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:

• We implemented Mobiflage deniable encryption by hiding volumes in empty space on a mobile device’s (removable or emulated) external storage (i.e., an SD card or eMMC partition mapped to the SD card mount point).
• We store all hidden volumes in the external storage, due to the file system layout of Ext4 that is used for internal storage.
• We first fill the storage with random noise, to conceal the additional encrypted volumes.
• The entire disk is then encrypted with a decoy key and formatted for regular day-to-day use; we call this the outer volume.
• Then two additional file systems are created at an offset within the external storage, and encrypted with a different key; these are referred to as the hidden volumes.
• We store two adjacent volumes in this way: a userdata volume for applications and settings, and a larger auxiliary volume for accumulating documents, photos, etc.
• The exact location of the hidden volumes in the external storage is derived from the user’s deniable password. See Figure 1 for the storage layout.

Usage:

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).

vdc cryptfs pde <inplace|wipe> <outer_pwd> <hidden_pwd>

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).


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.


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.


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).

Contributors:

Adam Skillen
CCSL - Carleton University
Homepage: https://www.ccsl.carleton.ca/~askillen/

Mohammad Mannan
CIISE - Concordia University
Homepage: http://www.encs.concordia.ca/~mmannan

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.

TrueCrypt
FreeOTFE
BestCrypt
cryptsetup + stlth
StegFS

Obsolete Projects:
RubberhoseFS
PhoneBookFS
ScramDisk 4 Linux
MagikFS
scubed
DataMuleFS