MobiGemini: Sensitive-Based Data and Resource Protection Framework for Mobile Device

Shuangxi Hong, Chuanchang Liu, Bo Cheng, Bingfei Ren, Junliang Chen

State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China

* The corresponding author： email： hongshuangxi_2008@126.com

I. INTRODUCTION

In recent years, with the development of scienti fic technology, smartphone is getting more and more powerful than the past, many people use it as a main tool for daily telephone, web browsing, and financial transactions. Therefore, number of smartphone user present exponential increase. According to a statista report[1], user increased from 1.06 billion to 1.76 billion between 2012 and 2014. Especially,fast developing of the mobile internet, mobile payment has been a hot spots. According to statistic of iResearch [2], the scale will reach 1358.4 billion by 2016. These data show it has become a trend using smartphone for payment. For example, AliPay (the most popular payment APP in China). Thus, smartphone as a necessary communication tool to user stores a large amount of sensitive-data of user,smartphone security was naturally focused on by most user. For this, major mobile operating system manufacturers have integrated some protection measures, for instance, screen lock,Biological recognition technology [3] ( fingerprint identi fication and face recognition), full disk encryption (FDE) [4] and so on. Google adds protecting measure of FDE in Android 3.0(only tablet), all version enabling FDE since android 4.0.

Android FDE is an important progress for smartphone security. This solution have very good effect when smartphone was lost or stolen. however, in a certain case, FDE cannot work well for sensitive data protection, for example, Hong Kong kidnaping hostage event,they may coerce hostage to hand over paying password for transferring cash from an account of bank to another if the kidnappers find mobile payment software on smartphone of the victim. Thus, when owner of smartphone is caught and coerced into disclosing his/her PIN or key of screen locker (which is known as coercive attack), simple full disk encryption is not adequate for preventing leakage of privacy data on the mobile device.

Plausibly deniable encryption (PDE) [5] is a better solution which reduces coercive attack by denying existence of sensitive data than FDE. Deniable encryption is a critical feature in a certain environment. Such as, victim may provide a decoy key for the adversary by a reasonable way when it are coerced to hand over decryption key. Originally, deniable encryption is used to network communication among multiple parties at first by Ran Canetti et al [6]. Some existing solutions with PDE function were used to mainline desktop operating system, such as TrueCrypt[7] and Freeotfe[8]. They implement PDE feature by enabling hidden volume. However, there are few solutions with PDE on mobile platforms.For all we know, Mobi flage[9] is the first PDE scheme for smartphone by modifying source codes of android full disk encryption. a smartphone enabling Mobiflage works at one of two modes, standard mode or PDE mode, the former is used to manage daily data generated by owner, and accessing the mode by entering public password which may be disclosed in emergency; the latter is used to supervise sensitive-data which need to be denied existence,such as photo or video took by journalist for forensics of accident, the mode may be entered by inputting another privacy password.Smartphone should be in the standard mode in everyday use to user, however, getting into PDE mode when needing to store sensitive data. MobiHydra[10] is another solution which reduces coercive attack by denying existence of privacy data, it introduces multiple-level deniable function based on Mobi flage design(in other words, MobiHdra has multiple hidden volumes for offering multiple-level deniability).

In order to protect common users and owner of device or forensic workers, the authors propose MobiGemini to help them avoid the coercive attack in this paper.

Although Mobiflage and MobiHydra initiate the relevant research of PDE on the mobile platform, both have some common limitations. First of all, they don’t protect sensitive APP (such as AliPay) in the standard mode,payment APP was usually installed under the standard mode in terms of convenience. The adversary may coerce user to transfer funds from one account to another account when he find mobile payment APP due to in the standard model of smartphone most of the time.Second, Mobi flage and MobiHydra store master key encrypted by LockScreen password at beginning offset of hidden volume. this may incur master key to be overwrited by stored data across boundary of volume When user write data to disk in the standard mode, it will destroy the master key to incur loss of all sensitive data in hidden volume. Third, Mobi flage and MobiHydra implement PDE by building hidden volume into free area of userdata partition, this introduces a new risk that data in the standard mode could corrupt hidden volume data. MobiHydra has a more serious question about across boundary of volume than Mobiflage, since it has multiple hidden volume.

In our works, we consider security of smartphone from two mode based on the existing PDE solutions, and proposing Mobi-Gemini, a more reliable and convenient PDE storage encryption system for android mobile device. Our MobiGemini can prevents sensitive APP from leakage of accounts information of device owner by uninstalling corresponding APP, the feature makes up for defects of previous PDE solutions, we also improve storing way of master key to make it more secure. At the same time, we also take some measures to overcome corrupting data across the boundary of volume.

In this paper, we have done the following some works：

1. We explore some sensitive APP witch increase coercive attacks in the standard mode,and providing an interface of system service(working at framework layer) that implement uninstalling applications. This alleviate coercive attacks when smartphone of owner works in the standard mode.

2. We provide MobiGemini, the more reliable PDE scheme based on existing PDE solution of mobile platforms, it overcomes some limitations that there were corrupting privacy data in previous existing PDE solution and improve storage way of master key of hidden volume. This makes the privacy data more security stored in a hidden volume than previous PDE scheme.

3. We analyze systematically MobiGemini’s security features and reliability, while we perform MobiGemini’s the prototype system on Samsung Galaxy S4 smartphone powered by android 4.4.2 and have evaluated its performance.

II. BACKGROUND AND RELATED WORK

About this section, we explain simply whole android framework and expound data hiding[11] and deniable encryption, giving an overview of encryption built into major desktop operating system and evolution of full disk encryption on mobile platforms.

Android provides an open source platform and applications context for smart device. It is divided into four layers, namely, application layer, application framework layer, HAL layer,Linux kernel layer. The application framework layer is responsible for providing services to the application layer and regulates applications on the android. Especially PackageManager service is in charge of installing or uninstalling of application, and checking permission of application.

The mainline desktop operating system enable the full disk encryption to protect privacy data of user. For example, Windows BitLocker [12] is enabled by major windows system. Famous data hiding software such as Elettra,TrueCrypt and FreeOTFE that provide PDE function[13]. Elettra [14] is a tool that stores a gziped and encrypted version somewhere in the archive. In the archive there is a reserved space for storing header information regarding encrypted data. The header contains information such as the position and size of the encrypted data in the archive. Elettra enables plausible deniability： it allows you to add many files with different password in an archive. The user may input different password to decrypt corresponding file. TrueCrypt is open source program used to encrypt volumes on your computer, enabling only single hidden volume. The volume can be a file (a virtual disk) or a disk partition. It enables plausible deniability： allowing you to create a hidden volume inside a normal TrueCrypt volume’s free space. If the first 512 bytes are not decrypted by the given password, program will try the same operation on another location.FreeOTFE encrypt drive on windows system,similarly TrueCrypt, hidden volumes can be built inside the free space of a normal volume,enabling multiple hidden volumes. However,you must be specify the offset at which the hidden data is to be written. FreeOTFE enables plausible deniability： it enable multiple hidden volumes, you can mount a hidden volume by specifying corresponding the offset of hidden volume.

In addition to data hidden technology based on volume, steganography method is also a hidden data technology (an inefficient method), is to encapsulate sensitive data inside a normal file. For example StegFs[15] filesystem based on steganography technology.

FDE was added into android system since android 3.0 version. On android platform,FDE does not encrypt entire disk as desktop operating system but only encrypting a physical userdata partition. Therefore, it not really a full disk encryption. Until android 4.3 version, android’s FDE use Dm-crypt[16] offered by LINUX kernel to implement transparent encryption. Once encryption is enabled, data writing to disk are automatically encrypted and data reading from disk are transparent decrypted. The encryption key (128-bit, calling master key) is generated randomly and wrapped by the user password. Individual disk sectors are encrypted by master key using AES in the CBC [17] mode. Android used a so called ‘crypto footer’ structure [18] to store encryption parameters, the structure usually lie to last 16 KB at the end of the partition.The smartphone encryption is optional item by user, but FDE defaults to be enable since android 5.0 version.

At present, as far as we know, both Mobiflage and MobiHydra are only two prototype systems that implement PDE on the mobile platforms. They enable PDE by customizing source code of android FDE, and MobiHydra makes up for some faults based on designs of Mobiflage. Both implement to protect sensitive data of user stored on the smartphone.

III. THREAT MODEL AND ASSUMPTIONS

3.1 Threat model

We consider threats from two situations. One is that the adversary is able to capture device,but disable getting into system and access physical disk. For example, the robbers kidnapped hostages, they can take away the victim’s smartphone, but they cannot login system because there is no password, the adversary can force the user for password to access the device; another is the adversary is able to not only controlling device but also getting root permission to access each partition.

3.2 Assumption

1. MobiGemini must be embedded android source code stream, or customizing android ROM (e.g., CyanogenMod[19]) ensure many devices with PDE function and automatic uninstalling service. Therefore, an adversary will be unable to sure whether that device is capable of using PDE and automatic uninstalling service.

2. We assume that APP (such as AliPay) installed in the device are often used in the standard mode, the adversary can coerce user to hand over encryption keys or passwords (e.g.,lockscreen password of the mobile device),owner of the smartphone is asked for trying my best to protect true password, or can pretend scare to provide chance of inputting false password.

3. After user was coerced to hand over encryption key or password, The adversary is not keep to punish owner of the device before finding out indication of the hidden data in the case of rationality, and also indefinitely hold user.

4. We assume the mobile ROM, kernel and BootLoader may be trusted. In the PDE mode,insecure APP will not be started to prevent leakage from the hidden data.

5. We assume mobile device cannot be captured by the adversary under PDE mode, or else the privacy data will be retrieved from the device. Hence, we need user to comply with certain principle.

IV. MOBIGEMINI DESIGN

4.1 Overview

We expatiate our design and explain reason we do in this section. Our design makes up for some deficiencies of other prototype system that enable PDE function for mobile platform.Our prototype system provides automatic uninstalling APP and PDE function. Automatic uninstalling APP was implemented as a system service of framework layer. We implement PDE function by hiding volume in a free area within the partition of flash disk. We first fill random data generated by pseudo random function [20] to mobile device storage, to conceal existence of hidden volume.

We define following operating mode for MobiGemini. (1) The standard mode is used daily work to user. In this mode, owner of device can use full disk encryption and APP automatic uninstall service (additional customizing system service[21]) to protect data and sensitive resource. User may supply decoy password at the boot time to enter the standard mode, userdata partition is normally mounted at /sdcard directory (without PDE function).We use terms “decoy” and “normal” when we refer to password and volume. (2)The scene of using PDE mode is when user needs saving important privacy data (e.g., photos and video for forensics), it need to be denied existence in the case of emergency. User supplies their true password to enter the PDE mode at booting system, and system mount hidden volume to corresponding directory. We use terms “true”and “hidden” when referring to password,keys and volume in the PDE mode.

4.2 Automatic uninstalling service design

Android system provides all kinds of system services (e.g., Media, Surface) for applications at the application framework layer. Package-Manager service [22] implements installing/uninstalling application on the android system.User can pull icon of application to garbage located above of screen to uninstall application after screen locker is unlocked. In the above mentioned scenario, user cannot timely uninstall application following normal operating way in an emergency. For example, the adversary captures device of user to coerce her/him unlocking device, user does not have time to unload sensitive APP on the device. However,on the smartphone with the MobiGemini, user can inputs many time wrong password to trigger uninstalling service for uninstalling one or multiple APP.

The module of automatic uninstall service is demonstrated as shown Fig.1. The module refers to both layers of the application and application framework. Including five parts, the three of them need customizing source code of android marked using light blue. Lockscreen APP implements locking screen after a period of time without any operation, and records times of password failure for triggering automatic uninstall system service. UI application provides a setting view, user can selects application that user wants to uninstall and then pass their package’s name to a configuration file of automatic uninstall service. The service will uninstall applications selected by reading its con figuration file when it is triggered.User can also modifies configuration file by UI application for uninstalling different applications. The service is registered as a system service that working in the framework layer,it has same life cycle as android operating system. The Sensitive APP refer to the application that operate sensitive data of user such as mobile Terminal of bank, AliPay, WeChat,QQ and so on. When user is coerced, these sensitive APP may aggravate punishment user suffers or leak account information of Social software.

The adversary forces her/him to unlock lockscreen when owner of the device is coerced, in this case user pretends afraid to enter error password three times (presetting threshold value by user), this will trigger uninstalling service to read its configuration file that stores name of application that user selects by UI application, uninstalling service then pass name of application to PackageManager service to implement uninstalling the application specified. The adversary would not find any sensitive application after user enter correct lockscreen password. To a certain extent this alleviate that the adversary continues punishing owner of the device.

4.3 PDE function design

Android system implement FDE function by encrypting whole userdata partition. We implement PDE function by enabling hidden volume on mobile device based on FDE of android system. User may input true password to enter PDE mode at booting system. In this mode, user may stores sensitive data to hidden volume, meanwhile data are encrypted by Dm-crypt of Linux during writing to disk, the encryption process is transparent to user.

Fig. 1 Automatic uninstall system service module

Now, there are two ways of implementing PDE function： hidden volumes (e.g.,FreeOtfe) and Steganographic file systems(e.g., StegFs[15]). The latter has some known disadvantages including： inefficient storage space utilization, and a number of extra IO operations. These drawbacks are unacceptable on mobile platform, considering some reasons such as power limitation, and relatively limited storage space and so on. Therefore, we choose hidden volumes for MobiGemini. This hints IO is as efficient as FDE of android.

4.3.1 The key storage way

Android uses a so called ‘crypto footer’structure[17] to store encryption parameters(e.g., master key and initialization vector), the master key is generated randomly by system,and the structure is usually located in the last 16KB of userdata partition or other location according to different android system. True-Crypt that is known encryption software on desktop operating system enable PDE function by enabling one hidden volume, it stores master key at the beginning of the corresponding hidden volume. Mobiflage that is an original system enabling PDE in the android system references to key storage way of TrueCrypt to store its master key at the beginning of hidden volume. The merit of this storage way is easy obtaining key from disk, however, this way has a fatal flaws that the sector of storing key may be overwritten by other data, this may result in losing all sensitive data stored hidden volume.

In our original system, we improve the key storage way of the other original system (e.g.,Mobiflage or MobiHydra) enabling PDE,considering resource limitation and especially power limitation, we don’t extend master key length of hidden volume. Speci fic master key storing way is demonstrated on figure 2.

In the standard mode, user enters decoy password at the booting system, then passing it to PBKDF2[23] (a hash function) to iterate 2000 times for generating a key of AES-128,utilizing this key to decrypt the encrypted master key (randomly generating by android system) stored in the Crypt footer and finally obtaining Decoy master key for decrypting userdata partition. In the PDE mode, user enters true password and then passing it to same PBKDF2 function to iterate 2000 for generating another key of AES-128, decrypting the same encrypted master key (only one encrypted key and initial vector stored in the structure of Crypt footer) and eventually getting true master key for decrypting hidden volume. Here,decoy master key is generated randomly by system, while true master key is not generated randomly by system but generating true master key by decrypting encrypted key stored in Crypt footer structure. Specific principle as shown on figure 3.

keyA is encrypted using decoy password to generate keyB. keyB is decrypted using true password to generate keyC, and vice versa.Here, keyA is equal to decoy master key, keyB is equal to encrypted key stored into Crypt footer structure, keyC is equal to true master key.

Fig. 2 The key decrypting process

Fig. 3 The generating key principle

The way of generating true master key shows as above, this is inspired by deniable encryption. During network communication,deniable encryption[6] indicate that a ciphertext may be decrypted different plaintext depending on different key, thus, unable to prove the existence of a plaintext. This way avoids storing key to disk and prevents the opponent from finding key or destroying key,this increases the security of master key. From the perspective of theory analysis, their keys space is 2128, brute-force difficulty is almost same (1/2128≈1/2128). Consequently, this way of key generation does not reduce the difficulty of brute-force.

4.3.2 Storage layout

The android system has usually multiple partitions [24] (e. g., system partition, recovery partition), and each partition has respective purpose. For instance, android system files and system applications were stored in the system partition. Only cache partition and userdata partition among all partitions are implemented reading/writing operations by applications.Storage layout is as shown in figure 4：

In our prototype system, we embed hidden volume in the cache partition. First, the cache partition is filled with random data before formatting such that there are no distinguishing characteristics between empty blocks and hidden volume. Previous PDE prototype systems that embed hidden volume in the userdata partition have a defect that may incur sensitive data of hidden volume to be corrupted across volume boundary during writing file to disk.However, our system alleviates the risk of across volume boundary. Because cache partition has the following features： first, the partition is only used as cache by system applications (e. g., google play), utilization of cache partition is usually no more than 3%; second,the partition is only used during update of system by OTA way, and user may control time of updating the system. In the PDE mode,mounting hidden volume at /sdcard directory for avoiding altering source code of applications.

4.3.3 Offset calculation

The offset of hidden volume is derived from the password provided by the user at the initiation of PDE function, it is generated as follows： Whereplenis the number of sector of cache partition, F is a PBKDF2 [23] hash function,pwdis the true password,saltis a random salt value for F, the salt value is also used for derivation of userdata partition key(i.e., stored in the crypt footer). Thus, we may avoid to store additional salt value, and limited offset around the middle of cache partition for balancing between cache and hidden partition.We also optimize the formula of generating offset, storing hash result ofH(pwd||salt)at boot android, we may use the result directly of hash for reducing time of computing offset of hidden partition.

Alternatively, the offset of hidden volume may be set in the middle of disk (e.g., appearing at 40 percent). However, generating offset by formula as shown above may complicate dictionary attack. If the offset was known by the adversary, he/she can easily implement dictionary attack.

V. IMPLEMENTATION AND PERFORMANCE EVALUATION

5.1 Model implementation

We focus on implementation of prototype system in this section. Test of MobiGemini was performed on a SAMSUNG Galaxy S4 device and source code of cm11 of Cyanogenmod(the world’s largest third-party compiler team).We add the additional code into source code of framework for implementing automatic uninstalling system service. To enable hidden volume, we customize android volume mounting daemon (vold) and make subtle change to the default kernel configuration. We also discuss current implementation limitations of prototype system.

To implement uninstalling system service,we adopt a simple way for adding a system service to our prototype system, main involving three parts of AIDL (android interface describe language), JNI (java native interface)and HAL (hardware abstract layer). Here AIDL implements an interface for application layer, as bene fit from the AIDL tool’s capability to generate marshaling and unmarshaling code in java for callers and callees. JNI implements java calling C function for manipulation about the underlying data. HAL implements support to a speci fic hardware, instead, uninstalling service don’t have to real support a hardware, only implementing a system service by this way. The service calls PackageManager to implement uninstalling applications,we extend function of the system service by adding corresponding to code to framework.We also modify source code of lockscreen application, and enforcing to trigger uninstalling service by determining the number of input wrong password.

We made three important modifications to the default android FDE encryption scheme that are necessary to protect deniability： (a) we replace CBC-AES by XTS-AES [25,26]; (b)in the PDE mode, enabling mounting hidden volume; (c) filling random data after wiping sensitive data. XTS-AES can defeat some known attack (e.g., copy-and-paste attack[27]). We still use 128 bit key as master key of hidden volume, due to resources limitation of mobile device.

To set up hidden volume in the cache partition, first, we fill random data to the whole cache partition, we then use mke2fs tool(cm11 android system integrate a partition tool) to build a hidden volume at a specified offset, next, we format the volume for ext4 file system. Space size of hidden volume show size of from offset of hidden volume to end of cache partition, while cache presents original partition sizes still.

Limitation： limitations about our prototype include：

1. At present, owner of the device cannot set a very large size of hidden volume,because size of cache partition is relatively small comparing to userdata partition. Now cache partition of android system is usually 2G, Therefore, size of hidden volume is about 1G(around half of cache partition). we may extend size of cache partition and reduce size of userdata partition by modifying corresponding to source code of android, but we only increase space of cache partition limited, otherwise, the adversary can find out some different about layout of android storage.

2. Users cannot change decoy password and true password after storing sensitive data into hidden volume. If users want to change one of decoy password or true password, data stored in hidden volume need to be copied to computer by USB cable or are discard directly.Users may change password arbitrarily when hidden volume is empty.

3. Users need transmitting data between two modes in certain environment; such as taking a sensitive photo in the standard mode cannot be stored into hidden volume when there is no chance switching mode. In this case we don’t currently provide any safe protection. One solution that the sensitive photo is encrypted and stored into cache partition in the standard mode, decrypting and transferring photo to hidden volume from cache partition after switching to PDE mode.

5.2 Performance evaluation

We summarize our tests about prototype system, analyzing influence of the performance through customizing original system, and discussing time of booting system between FDE mode and PDE mode.

We first utilize three APP for testing automatic uninstalling service, threshold of trigger is set three time. In order to evaluate the performance of the service, we input correct password of lock screen after inputting wrong password three times, finding no difference of systems between normal and enabling automatic uninstalling service, because Package-Manager service has already uninstalled three APP after inputting the fourth password(no matter right or wrong ).

Cipher performance. To evaluate the encryption to impact of system performance,we read from and write to hidden volume on SAMSUNG device. We run 5 trails on five files between 64M and 800M using Andro-Bench[28], and using average as criterion of I/O throughput.

We evaluate the performance of Mobi-Gemini scheme under the default android encryption. MobiGemini seems to be lower throughput by roughly 2 percent compared with the android FDE. As shown above Figure 5, the observed decrease in throughput of MobiGemini is due to the selected cipher：XTS-128. The required time to delete the data stored in the hidden volume is increased on account of the two pass random wipe. The exact time rely on type and size of flash storage.Table I summarizes functions and characters of system. The result shows FDE of android system does not enable data-hidden function and auto uninstalling APP function. The adversary can finds all privacy information of owner after login smartphone system. On the contrary, the others provide hidden volume to protect privacy data, and resist copy-to-paste attack. Although Mobiflage and MobiHydra have very high encryption strength, master key and hidden-data of hidden volume are not secure, being liable to overwritten by the file of normal volume. Because master key of hidden volume is stored at beginning address of corresponding hidden volume, there is a great possibility about cross-border pollution. By contrast, MobiGemini set hidden volume on /cache partition (using when OTA) to overcome cross-border pollution, master key of hidden volume is stored in the “crypto footer”, the way is more secure than stored at the beginning offset of hidden volume. Therefore, our prototype system can better protect sensitive data of owner of smartphone than other prototype systems and FDE, and power consumption is same as FDE (key length 128 bits). Further, MobiGemini can achieves protecting sensitive data under two threat model(above mentioned 3.1).

System performance. We list booting time of entering standard mode and PDE mode of Mobiflage and MobiGemini respectively. As shown in Table II.

The results show that MobiGemini consume much less time than Mobiflage during booting system, because Mobi flage always attempt to un-mount a persistent virtual volume when booting a system, and needing additional 2000 iterations of PBKDF2 hash function for computing offset of hidden volume.

We optimize these processes by mounting hidden volume to /sdcard directory and directly obtaining hash value without additional2000 iterations. Initialization time of Mobi-Gemini is also much less than Mobi flage, this should be because they have the lesser key length and space size of hidden volume. In short, our prototype system is more suitable for mobile platform considering resource limitations.

Table I System functions and robustness comparison

Table II Performance comparison

Fig. 5 Flash I/O throughput of performance

VI. CONCLUDING REMARKS

The powerful mobile devices are increasingly used for amusement and working, such as mobile payments and capturing image for forensics. To protect common users and owner of device or forensic workers, we propose MobiGemini to help them avoid the coercive attack. MobiGemini provides a secure frame to protect sensitive data and resources, allowing a user to uninstall quickly multiple sensitive APP at a time. In addition, we improve storage way of master key for enhancing security of key, we mitigate question of across boundary of volume when storing data into hidden volume. Certainly, MobiGemini also has some inherent defects (smaller size of hidden volume in flexible about change of user password), we need user to comply with some requirements.We present MobiGemini here to encourage researcher focus on mobile security.

ACKNOWLEDGEMENTS

The authors would like to thank the reviews for their detailed reviews and constructive comments, which have helped improve the quality of this paper. This work was supported in part by Natural Science Foundation of China under (Grant No. U1536112);National Key Technology Research and Development Program of China (Grant No.2012BAH94F02); National High-tech R&D Program of China (863 Program) under Grant No. 2013AA102301; Project of New Generation Broad band Wireless Network under Grant No. 2014ZX03006003.

[1] Statista. 2015 March, “Report of Global Market Share Held by Smartphone Operating Systems”. [Online]. Available: http://www.statista.com/statistics/263453/global-market-share-held-by-smartphone-operating-systems/.

[2] Mobile payment, 2014 November, “Report of China’s Mobile Payment Users”. [Online].Available: http://www.iresearchchina.com/news/6025.html.

[3] Derawi, Mohammad Omar, et al. “Unobtrusive user-authentication on mobile phones using biometric gait recognition”.Intelligent Information Hiding and Multimedia Signal Processing(IIH-MSP), 2010 Sixth International Conference on. IEEE, 2010.

[4] Full Disk Encryption, 2014. “Android Encryption Technology, Online Document” [Online]. Available: http://source.android.com/devices/tech/security/encryption/.

[5] Sahai, Amit, and Brent Waters. “How to use indistinguishability obfuscation: deniable encryption, and more.”Proceedings of the 46th Annual ACM Symposium on Theory of Computing. ACM,2014.

[6] Canetti, Rein, et al. “Deniable encryption.”Annual International Cryptology Conference.Springer Berlin Heidelberg, 1997.

[7] Czeskis, Alexei, et al. “Defeating Encrypted and Deniable File Systems: TrueCrypt v5. 1a and the Case of the Tattling OS and Applications.”HotSec. 2008.

[8] FreeOtfe. 2005. “FreeOtfe- Free Transparent Disk Encryption Software”. [Online]. Available:Project website: http://sourceforge.net/projects/freeotfe.mirror/.

[9] Skillen, Adam, and Mohammad Mannan. “Mobi flage: Deniable Storage Encryptionfor Mobile Devices.”IEEE Transactions on Dependable and Secure Computing11.3 (2014): 224-237.

[10] Yu, Xingjie, et al. “Mobihydra: Pragmatic and multi-level plausibly deniable encryption storage for mobile devices.”International Conference on Information Security. Springer International Publishing, 2014.

[11] Petitcolas, Fabien AP, Ross J. Anderson, and Markus G. Kuhn. “Information hiding-a survey.”Proceedings of the IEEE87.7 (1999): 1062-1078.

[12] Windows Inc. 2015. BitLocker Driver Encryption,[Online]. Available: http:// windows.microsoft.com/en-us/windows7/products/features/bitlocker.

[13] Fu, Kevin E.Group sharing and random access in cryptographic storage file systems. Diss. Massachusetts Institute of Technology, 1999.

[14] Elettra —plausible deniable file cfyptography.2015. [Online]. Available: http://www.winstonsmith.info/julia/elettra/.

[15] McDonald, Andrew D., and Markus G. Kuhn.“StegFS: A steganographic file system for Linux.”International Workshop on Information Hiding.Springer Berlin Heidelberg, 1999.

[16] Fruhwirth, Clemens. “Hard disk encryption with DM-Crypt, LUKS, and cryptsetup.”ISSUE61(2005): 65-71.

[17] Frankel, Sheila, Rob Glenn, and Scott Kelly.The AES-CBC cipher algorithm and its use with IPsec.No. RFC 3602. 2003.

[18] Google Inc. 2014. dm-crypt: Linux kernel device-mapper crypto target. [Online]. Available:https://code.google.com/p/cryptsetup/wiki/DMCrypt.

[19] Cyanomgenmod. 2015. Free customing android system. [Online]. Available: http://www.cyanogenmod.org/.

[20] Wei, Michael Yung Chung, et al. “Reliably Erasing Data from Flash-Based Solid State Drives.”FAST. Vol. 11. 2011.

[21] Yaghmour, Karim.Embedded Android: Porting,Extending, and Customizing. “O’Reilly Media,Inc.”, 2013.

[22] Sharkey, Jeff. “Coding for life—battery life, that is.”Google IO Developer Conference. Vol. 2009.2009.

[23] Kaliski, Burt. “PKCS# 5: Password-based cryptography speci fication version 2.0.” (2000).

[24] Hoog, Andrew.Android forensics: investigation,analysis and mobile security for Google Android.Elsevier, 2011.

[25] Rogaway, Phillip. “Nonce-based symmetric encryption.”Fast Software Encryption. Springer Berlin/Heidelberg, 2004.

[26] Dworkin, Morris. “Recommendation for block cipher modes of operation: The XTS-AES mode for confidentiality on storage devices.”NIST Special Publication800 (2010).

[27] Fruhwirth, Clemens.New methods in hard disk encryption. na, 2005.

[28] AndroBench. 2015. Android File System Benchmark, version 4.1. [Online]. Available: http://www.androbench.org/wiki/AndroBench/, 2015.