MobiGyges: A Mobile Hidden Volume for Preventing Data Loss, Improving Storage Utilization, and Avoiding Device Reboot
Wendi Fenga, Chuanchang Liua, Zehua Guob,c, Thar Bakerd, Gang Wangb,c, Meng Wanga, Bo Chenga, and Junliang Chena
aBeijing University of Posts and Telecommunications, 10 Xitucheng RD, 100876, Beijing, China bBeijing Institute of Technology, 5 Zhongguancun ST South, 100081, Beijing, China cUniversity of Minnesota Twin Cities, 117 Pleasant ST, 55455, Minneapolis, USA dLiverpool John Moores University, James Parson Building, Liverpool, L3 3AF, UK
Abstract Sensitive data protection is essential for mobile users. Plausibly Deniable Encryption (PDE) systems provide an effective manner to protect sensitive data by hiding them on the device. However, existing PDE systems can lose data due to overriding the hidden volume, waste physical storage because of the “reserved area” used for avoiding data loss, and require device reboot when using the hidden volume. This paper presents MobiGyges, a hidden volume based mobile PDE system, to fill the gap. MobiGyges addresses the problem of data loss by restricting each storage block used only by one volume, and it improves storage utilization by eliminating the “reserved area”. MobiGyges can also avoid device reboot by mounting the hidden volume dynamically on-demand with the Dynamic Mounting service. Moreover, we identify two novel PDE oriented attacks, the capacity comparison attack and the fill-to-full attack. MobiGyges can defend them by jointly leveraging the Shrunk U-disk method and multi-level deniability. We implement the MobiGyges proof-of-concept system on a real mobile phone Google Nexus 6P with LineageOS 13. Experimental results show that MobiGyges prevents data loss, avoids device reboot, improves storage utilization by over 30% with acceptable performance overhead compared with current works. Keywords: data loss preventing, hidden volume, improving storage utilization, sensitive data protection, avoiding reboot
1. Introduction tive data on both stationary systems and mobile systems by providing deniability for the sensitive Mobile devices (e.g., smartphones) have become data. Deniability means that sensitive data owner prevalent in recent years, especially in the era of 5G can deny the existence of the data. Modern PDE hidden volume mechanism and the Internet of Things (IoTs) [1]. Hence, pro- systems use the to im- tecting private and sensitive data on mobile devices plement the deniability. The hidden volume based are very important to users [2, 3]. One existing solu- PDE system stores the sensitive data on the hidden volume, yet the hidden volume itself is concealed arXiv:2004.10849v1 [cs.CR] 22 Apr 2020 tion is to use Full Disk Encryption (FDE) [4]. FDE uses an encrypting key to encrypt user data before inside the device. Logically, the storage space on storing it on a device and decrypt the data before the hidden volume based PDE systems can be di- hidden volumes outer volume applications using it [5]. Nonetheless, FDE is not vided into and an . secure because sensitive data can be compromised The outer volume is visible to all users for daily when the encryption key is exposed, since the en- purposes and will be used automatically as the sys- crypted data can be easily decrypted with the only tem starts up, while hidden volumes are concealed encryption key. in the device and store the sensitive data. Such hidden volume based solutions have the fol- Recent works [6–10] propose Plausibly Deniable lowing limitations: Encryption (PDE) to enhance the security. PDE is a data protection paradigm that protects sensi- • Data loss. Hidden volumes are concealed in-
Preprint submitted to Journal of LATEX Templates April 24, 2020 Outer Hidden Wasted Hidden Hidden volume volume volumes storage volume’s view blocks blocks blocks Hidden volume writes to Outer volume capacity shown to users Reserved for hidden volume Outer volume Hidden volumeUser’s vie w
Outer volume writes to Waste storage blocks Waste storage blocks Outer Outer volume volume’s view (a) Previous works solution.
Outer volume capacity shown to users Figure 1: Data loss caused by data override. The outer volume writes data on hidden volume occupied blocks.
side the outer volume [7–11], but the outer vol- Physical disk capacity
ume does not know the existence of hidden vol- (b) MobiGyges solution. umes. Therefore, it is likely to write data on the storage blocks that are occupied by hidden Figure 2: Hidden volume is placed into a reserved area volumes. Thus, sensitive data stored on the to avoid data override. Large amount of storage space is hidden volume will be lost. Figure 1 shows an wasted. MobiGyges can fully utilize almost all the storage space. example of data overriding between the outer volume and the hidden volume. In the figure, the outer volume considers all the storage space two modes in their system, namely, the nor- (red space) to be usable. When the outer vol- mal mode and the PDE mode [7–11]. The ume writes data on the space of the hidden normal mode uses the outer volume while the volume (purple space), the data on the hidden PDE mode uses the hidden volume, respec- volume will be lost. tively. When users want to use the hidden volume, they have to use the PDE mode. How- • Storage waste. Studies [7–10, 12] attempt ever, device reboot is required to switch modes. to solve the data loss problem by placing the Rebooting the device to use the PDE mode hidden volume into a “reserved area”, and the wastes time and is not convenient for users es- outer volume will not write data to that area. pecially those who want to use the hidden vol- The size of the “reserved area” is bigger than ume urgently. the capacity of the hidden volume. As depicted in Figure 2a, in previous works, the right part Apart from the drawbacks, we identify two pos- (green blocks plus the blue block) of the phys- sible PDE oriented attacks (detailed in Section 4) ical volume is reserved for the hidden volume. that might compromise the sensitive data, and cur- Since the capacity of the hidden volume (the rent solutions fail to defend. blue block) is much smaller than that of the “reserved area”, the hidden volume can “float” • The capacity comparison attack. The at- inside the “reserved area”. Hence, the exact tacker may discover the hidden volume by com- starting position of the hidden volume can be paring the capacity of the outer volume and arbitrary, hidden volumes are thus protected. the hidden volume. If their capacities are dif- However, this mechanism could waste a large ferent, the attacker can doubt the device is par- amount of storage space (green blocks). We ticularly designed, which is prone to expose the find in these solutions [7–9], up to 45%1 of the hidden volume and hence compromises the sen- total storage space is wasted, which is huge for sitive data. For example, a 32GB device uses the resource-limited mobile devices. 5GB for the hidden volume, so the capacity of the outer volume is 27GB. The attacker can • Device reboot. State-of-the-art works use doubt about the 5GB capacity difference, and conduct further investigation. 1Including storage space taken up by the structure of a file system. The calculation of the utilization is detailed in • The fill-to-full attack. If the attacker iden- Section 7. tifies the potential existence of the hidden vol- 2
Encrypted Logical Volume read() write() Linux Figure 3: Data protection systems classification. Encrypt & Application Decrypt
(4) Defending the novel PDE oriented at- reboot. The dynamic mounting service can mount tacks. The capacity comparison and the fill-to-full the hidden volume without rebooting the device, attacks result from the capacity inconsistency issue. and TriggerApp can secretly trigger the use of hid- The challenge is how we defend the fill-to-full and den volumes and mount the hidden volume on-de- capacity comparison attacks. mand using the dynamic mounting service with- out rebooting the device. iii) We use the Shrunk U-disk method and multi-level deniability jointly in 5.2. Design Overview the Volume Management module to defend the ca- MobiGyges is a mobile hidden volume based PDE pacity comparison and the fill-to-full attacks. In system. In this subsection, an overview of Mobi- terms of fill-to-full attack, we leverage multi-level Gyges design, starting with a general description of deniability by recording the size of data that has its components, is presented. Then, we propose a already been written and redirecting the extra at- so-called Shrunk U-Disk method to defend the ca- tack IO requests to other places that will not take pacity comparison attack, and we also leverage the up the physical storage space and finally making the multi-level deniability to defend the fill-to-full at- size of the attack IO plus the used capacity before tack. Next, we introduce our design solution asso- the attack equals the physical capacity. Moreover, ciated with the design consideration introduced in we employ the Shrunk U-disk method to defend Section 5.1. Finally, we describe the user steps. the capacity comparison attack by intentionally la- beling the capacity of the outer volume capacity 5.2.1. Solutions equivalent to the physical capacity. We detail the With the design considerations discussed in Sec- Shrunk U-disk method and multi-deniability in Sec- tion 5.1, we propose our PDE system design so- tion 5.3.1(3) and Section 5.3.2(3). lutions. i) We introduce an independent compo- nent called the Volume Management module to 5.2.2. Key Components manage the outer volume and hidden volume(s) MobiGyges consists of four main components. rather than having the volumes themselves han- Volume Management module, FDE module, physi- dle the hidden volume concealing. It flexibly allo- cal volume module, and TriggerApps module. i) The cates separate storage blocks for volumes and avoids Volume Management module is the most important the override of the same storage space. The mod- module of MobiGyges, and it manages the life-cy- ule also eliminates the “reserved area” and thus cle of all the outer volume and hidden volumes. mitigates data loss and improves storage utiliza- ii) FDE module is the encryption layer on top of tion. We use a FDE component to encrypt the the physical storage to protect the Volume Man- Volume Management module and the file system agement module, and iii) physical volume module structure, which protects the system. ii) We de- is the physical storage of the device provided by the sign a userspace application called TriggerApp and device vendor. iv) TriggerApp module is an appli- the dynamic mounting service to mitigate device cation, which is designed for the user to utilize the 8 Dynamic Mounting Level 0 Level 1 Level 2 Level n
Password 0 Password 1 Password 2 Password n
App calculate /dev/null
Figure 8: Multi-level deniability. Level 0 is used to defend the fill-to-full attack. Hidden /hidden volume 5.3. The Volume Management Module
Hidden volume mounting This subsection details the design of the key part of MobiGyges, the Volume Management module. Figure 7: The Dynamic Mounting service structure. Autho- The Volume Management module leverages Thin rized App can mount the hidden volume on-demand. Provisioning and Device Mapper by converting the physical storage into a Thin Pool and using the vir- hidden volume securely and conveniently without tual logical volume to manage the physical storage requiring entering the detailed system commands. in a fine-grained manner. In the rest of this sub- section, we show how fine-grained storage blocks Figure 5 depicts the data-flow in the entire Mo- used by the Volume Management module solves the biGyges workflow and the inner data-flow between aforementioned problems and defends the attacks, MobiGyges components. As per the mentioned fig- and we then anatomize each services in the module. ure, (a) users first manipulate TriggerApps, and (b) TiggerApps then generates data and exchanges data between the Volume Management. (c) Next, 5.3.1. Volume Management Module Circumvention the Volume Management module processes the data (1) Data Loss and Low Storage Utilization Device Mapper Thin Provisioning with and , and Elimination sends Input/Output (IO) redirections to the FDE. (d) PDE finally encrypts or decrypts data with the MobiGyges avoids data loss and improves the low dm-crypt kernel module and communicates with storage utilization using the Volume Management the physical volume and commits data on the phys- module with the following steps as shown in Fig- ical volume or reads data from it. ure 6. i) The Volume Management module splits the 5.2.3. User steps whole physical disk into fine-grained storage blocks (i.e., 64KB), and then, ii) the module allocates each Steps for using MobiGyges: fine-grained storage block only for one volume, so the storage space of each volume is independent, 1. Boot the device with MobiGyges. The outer and the data on each fine-grained storage block can- volume is mounted automatically. After boot- not be override by other volumes. Hence, the data ing up the device, the user can start using it loss problem is avoided. iii) The module tracks the as an ordinary device for daily purposes. usage of each fine-grained block, and stores volumes and the storage block mapping information (meta- 2. When using hidden volumes, open TriggerApp data) in a special format and encrypts the meta- and enter a level (level of deniability is detailed data with FDE on the physical disk. The meta- in Section 5.3.2) of the password to mount the data is stored in the metadata logical volume as corresponding hidden volume without reboot- shown in Figure 9. When allocating storage space ing the device. for the metadata logical volume, the available stor- age blocks are first sorted from big to small, and the 3. If an attacker suspects that PDE exists on the least storage block that is larger than the needed device and conducts the fill-to-full attack, the storage size is used. In the figure, we can see that user can use level 0 before then (detailed in iv) no “reserved area” is used because of the exclu- Section 5.3.1(4)) to defend the attack. sive access of the same storage block from volumes, and hence the storage utilization is improved. 9 (2) Device Reboot Avoidance demands. This is called Thick Provisioning, but MobiGyges avoids device reboot when using the the physical storage cannot reach its capacity up- hidden volume by leveraging the Dynamic Mount- per limit before replacing the disk with a larger one. ing service in the Volume Management module. Hence, a large amount of storage space is wasted. The Dynamic Mounting service first filters the Thin Provision allows operators to flexibly precon- mounting request by identifying the owner of the figure a bigger capacity of virtual volumes than the request, and it only allows authorized applications physical capacity, and physical storage spaces are (e.g., the TriggerApp) to mount the hidden volume. not be used until data commit on them. When the The mounting request is sent associated with a to- physical storage exhausts, the operator can install ken generated by using OAuth [28], and thus if the new physical disks without modifying any previous token is not valid, the Dynamic Mounting service settings. We employ the flexibility of Thin Provi- rejects the request. Then the Dynamic Mounting sioning and set the capacity of the outer volume to service calculates the name of the hidden volume be the physical capacity to mitigate the capacity based on the given PDE password and mounts the comparison attack. hidden volume on the mounting point. The proce- (4) Fill-to-Full Attack Defense dure is shown in Figure 7. It is natural to conduct the fill-to-full attack when (3) Capacity Comparison Attack Defense the attacker suspects the existence of the hidden The attacker may conduct the capacity compar- volume(s). We leverage multi-level deniability to ison attack and the fill-to-full attack to expose the defend the attack. Multi-level deniability allows hidden volume and compromise the sensitive data. users to define different levels of importance of sen- sitive data, and each level of sensitive data is asso- MobiGyges leverages the Shrunk U-disk method ciated with one hidden volume. To defend the fill- to defend the capacity comparison attack. Shrunk to-full attack, we introduce a special level (level 0) U-disk is a kind of disk labeled with a bigger capac- of deniability, which is associated with /dev/null. ity, and operating systems also display the labeled As shown in Figure 8, when the attack discovers capacity to users. However, the real capacity of the hidden volume and tries to conduct the fill-to- the disk is smaller than the labeled capacity. For full attack, the user uses the level 0 deniability and example, a memory stick is labeled to have 32GB gives the device to the attacker to perform the fill- storage, and the operating system also shows the 2 to-full attack. Attack data will first be written to capacity is approximately equal to 32GB, but its the outer volume and recorded by the Volume Man- actual capacity is only 8GB. Only when exhausting agement module. When the physical disk exhausts, more than 8GB storage space on it, can the user new attack data will be directed to /dev/null, and find out the trick. However, users usually would the Volume Management module will occur a full not do that and cannot discover the “trick”. We storage error when the recorded size of attack data can exploit this “trick” to defend the capacity com- plus the used capacity of the outer volume before parison attack by simply modifying the capacity of the attack equals physical capacity. the outer volume to be the same as the physical capacity, which protects the hidden volume. The implementation choice of Shrunk U-disk method is 5.3.2. Volume Management Module Composition detailed in Section 5.3.2. In this subsection, we bring the technical de- sign details of the Volume Management module and The challenge is how we can modify the volume present how the Volume Management module man- capacity. We leverage Thin Provisioning to fill the ages the physical disk. gap. Thin Provisioning is a novel technology de- The Volume Management module leverages Thin signed to address the storage waste problem in the Provisioning and Device Mapper to convert the Cloud data center (DC). Because the servers are physical disk into a Thin Pool, which is a resource usually installed with larger physical storage ca- pool consists of fine-grained storage blocks. The pacity than the actual size of data usage for future Volume Management module then create virtual logical volumes as the outer volume and hidden vol- 2It is a convention that storage hardware vendors using umes. The storage spaces of the virtual logical vol- 1k=1000 rather than 1k=1024 to calculate the capacity. umes are allocated from the Thin Pool, and each 10 Virtual logical volume Virtual logical volume Reaching timeout The outer volume The hidden volume Busy in Thin Pool use or Mounted Unmounted not reaching timeout Mount
Metadata Data Figure 10: Dynamic mounting state management. device device
Volume group the hidden volumes allocate storage space from the pool on demand. When one storage block in the Physical disk Thin Pool is allocated by one virtual logical vol- ume, the storage block will be marked as used, and Figure 9: The creation of the outer volume and hidden vol- it will not be allocated for other virtual logical vol- ume. The outer volume and the hidden volume are virtual logical volumes. umes. Hence the overriding problem is addressed. The mapping of fine-grained storage blocks and vir- tual logical volumes is stored in the metadata de- virtual logical volumes allocates storage blocks dis- vice in Figure 9. In our case, each block is 64KB tinctly from others.As depicted in Figure 9, i) the in size. Since each block is exclusively used by the Volume Management module converts physical disk hidden volume or the outer volume separately, the into a volume group with Device Mapper. Each vol- “reserved area” is needless. Thus, the storage uti- ume group consists of one or more physical disks. lization also improves. ii) Then, the Volume Management module creates When creating the data and metadata logical vol- two logical devices using the created volume group umes, the relationship between the size of the meta- with Device Mapper, namely, the data device and data volume and data volume can be formalized as the metadata device. The data device is the stor- follows. age space of Thin Pool, and the metadata device Sp Sm = × 64, (2) records the usage of each fine-grained storage block. Sc Device mapper is used to map existing block devices into another logical block device. Device mapper where Sm denotes the size of metadata volume. Sp redirects or filters IO requests from logical block denotes the size of pool volume, and Sc denotes the devices to the mapped device (physical disk in our chunk size of pool volume. case). The process can be formalized by a 5-tuple, (2) Virtual logical volume is the final logi- hOl,Sl,T,Dp,Opi, where Ol denotes the sector off- cal volume used as an outer volume or a hidden set of mapping logical volume block, and Sl is the volume. The reason it is called “virtual” is when number of sectors of the original volume block. T creating the virtual logical volume, its storage re- denotes the type used to describe the way of map- sources is not allocated until data commit on it. ping. Dp denotes the mapped device, and Op de- The capacity assigned at the creation time is only notes the offset of mapped physical volume block. a label, and it does not indicate the actual capacity iii) Next, the Volume Management module converts it possesses. The topmost part of Figure 11 shows the the two devices into a Thin Pool. iv) Finally, the architectural level in the MobiGyges system. the Volume Management module creates two vir- In MobiGyges, the capacity of the outer volume is tual logical volume by using fine-grained storage configured as big as the physical volume to defend blocks in Thin Pool with Device Mapper. the capacity comparison attack. Device mapper is We anatomize each components in the Volume used to create the virtual logical volume from Thin Management module in the rest of this subsection. Pool. For applications, the usage of the virtual log- ical volume has no differences between a physical (1) Thin Pool is the resource pool used for vir- volume. tual logical volumes and created atop the encrypted logical volume. As shown in Figure 11, it virtual- (3) Multi-deniability allows users to define izes the encrypt logical volume as a resource pool by different levels of importance for their sensitive data carefully splitting the whole storage space into fine- and put them into different hidden volumes corre- grained storage blocks, and the outer volume and sponding to different levels of deniability. Mobi- 11 The Virtualized storage block (4) … Outer … …Hidden… IO redirects between thin volumes and thin pool
(3) …Thin Pool… IO redirects between thin pool and encrypted logical volume, encrypted virtual volume and physical volume (2) Encrypt logical volume Virtualized logical volume
Thin pool (1) Userdata (Physical Volume) Volumes
Figure 11: Disk layout of MobiGyges. (1) The userdata is the physical volume that used for storing user-generated data. (2) FDE is applied to encrypt both data and the structure on top of it. (3) all the userdata storage is virtualized as a Thin Pool. (4) virtual logical volumes are created as outer volume and hidden volume, respectively.
Gyges provides multi-deniability by creating mul- needed to validate the application, and if the to- tiple hidden volumes. Each hidden volume is re- ken is not valid, the mounting request is rejected. served for providing a specific level of deniability. Android is a UNIX-like system, and in a UNIX- To this end, even if the hidden volume is exposed, like system, devices are presented as block device users may still deny the existence of sensitive data files. Each block device file has its own name. because the attacker fails to know the number of Therefore, when using a hidden volume, users first deniability the system provides, and which hidden enter the password of the wanted hidden volume at volume is used to store the sensitive data. Each authenticated application such as TriggerApp and hidden volume has its name and password, and the MobiGyges will mount the correct hidden volume name is calculated from the password. Without the based on Equation 3. As depicted in Figure 10, password, the system cannot find the correct name when the hidden volume is mounted, a timer is of the hidden volume and cannot mount the hidden started, and the hidden volume will be automat- volume and thus fails to fetch the sensitive data ically unmounted as the timer times out. This stored on it. The name of each hidden volume is mechanism protects the hidden volume from being calculated with Equation 3. discovered by examining the currently mounted de- vices. N = T (h(passwd + salt), b), (3) 5.3.3. TriggerApp where, N is the final name. T (s, b) is a trim func- TriggerApp is the interface among the users and tion that trims s into a b-length string. h(x) is MobiGyges’s hidden volumes. Users have to use a hash function that hashes x into a hash value. TriggerApp to trigger the special operations and passwd is the user password towards a hidden vol- dynamically mount the hidden volume for storing ume, and salt is used for counter rainbow table at- sensitive data. TriggerApp functionality should tack [29]. be secret to prevent MobiGyges from exposing. Therefore, TriggerApp is recommended to be im- (4) Dynamic Mounting mounts the hidden plemented inside a system built-in application. volumes on demand. Unlike previous solutions, which requires rebooting the device and logging into the PDE mode to use the hidden volumes. Mo- 6. Implementation biGyges can use hidden volume on demand need- less device rebooting to switch to the PDE mode. We implement our MobiGyges prototype sys- Therefore, authenticated applications can use dy- tem on LineageOS 13 for Google Nexus 6P. We namic mounting to mount the needed hidden vol- choose LineageOS rather than original Android ume instantly. Due to the confidentiality of the Open Source Project because LineageOS provides hidden volume, operations of authenticated appli- necessary vendor specific hardware adaptation like cations should be cautious. When requesting for camera and baseband driver supports. For the Vol- mounting the hidden volume, an access token is ume Management component of MobiGyges, we 12 add about 500 lines of C code to LineageOS, and we We implement our TriggerApp into the Android port Logical Volume Management (LVM) and Thin system built-in Calculator. Apart from the ba- Provisioning tools (pdata tools) [30] and some sys- sic calculation functionality, our tailored Calcula- tem building scripts to Android. For TriggerApp, tor has the extra functionality like secret record- we add approximately 500 lines of Java code. In ing, filming, and picturing. The calculator could this section, we present the implementation chal- still make calculations, and otherwise, the system is lenges and considerations of MobiGyges. prone to expose the special design and thus compro- mise sensitive data. As we all know, dividing any (1) Manipulating the userdata partition is number by 0 is an illegal operation. When users hard on Android. MobiGyges initialization re- attempt to do such an illegal operation, the sys- quires mounting and unmounting the userdata tem will throw an exception and prompt an alert partition. However, the userdata partition can- to users to indicate the calculation is not allowed. not be unmounted while the system is running be- Thus, we change the exception processing behavior cause some system files are stored on the userdata of the calculator by modifying it to display a special partition, and these files are busy in use [31]. For operation Use Interface (UI) according to what the system stability and data integrity, the operating user enters. Identifying the divided by 0 operation system does not allow the userdata partition to can be done by parsing the input String every time be unmounted while busy. However, the creation when the user presses the ’=’ button. However, of Thin Pool and virtual logical volume requires a users usually just conducts normal calculations op- free (not in used) partition. To this end, we put the erations, and the input parsing is worthless un- Thin Pool and virtual logical volume creation pro- der such condition. Android applications are writ- cedure executing at the system booting stage before ten in Java3. Java has an ArithmeticException mounting the userdata partition. We put the code that whenever an illegal operation occurs, it throws right after the FDE procedure in Android Volume an ArithmeticException. We put our parsing Daemon (VOLD) located at cryptfs.c. The code code into the catch {} code block. When an executes lvm toolset by forking a child process. ArithmeticException is triggered, the code will (2) Running toolsets on Android is another analyze the input and process the operations ac- challenge for us because the toolsets are usually for cordingly. desktop and server that are x86 platforms rather (4) Dynamic mounting is implemented as than the ARM-based mobile platforms. Luckily, SystemService. Normally, all kinds of Android sup- Android is based on Linux kernel and has the kernel porting hardware has the SystemServices and Hard- modules needed by Thin Provisioning and Device ware Abstract Layer (HAL) definition pair. Apart Mapper, and the system calls are the same as desk- from that, lightweight Service and lightweight HAL top and server versions. Therefore, porting LVM are also provided as pairs in Android. For example, and pdata tools that are used to build logical vol- the WiFi module has both Service and HAL defi- umes, Thin Pool, and virtual logical volumes does nitions. But the HAL definition is needless in our not require much code and building system modi- system because no new physical hardware devices fication. We use gcc-arm-linux-androideabi to are added to the system. We implement the Mobi- conduct the cross-compile. We first intended to Gyges SystemService by using the method provided compile the source directly, but these tools require by [32]. Inside the dynamic mounting SystemSer- libraries that should be cross compiled in advance vice, it i) calculates the trimmed hash value with and made them Android runnable. Apart from the input password and salt by using Equation 3. that, -enable-static link and LDFLAGS=-static The salt, uses the crypto footer of the userdata flags should be set to ensure the compilation tar- partition in our case, and ii) it mounts the corre- get is statically executable. Otherwise, the toolsets sponding hidden volume with the calculated device cannot run when pushing to Android because An- name and the access token. If either the password droid lacks of these libraries. We also modified the or the access token is incorrect, the mounting re- code in the Android build system to compile the quest is rejected. toolsets into the final installation package.
(3) TriggerApp implementation is an impor- 3C/C++ can also be applied to Android application to tant part of the work of implementing MobiGyges. improve the running efficiency 13 (5) Full Disk Encryption (FDE) is used to 79.81 protect the Volume Management module. Mobi- 80 78.38 Gyges first performs FDE by creating an encryp- tion layer on the userdata partition, which makes 70 it easy to encrypt all data on the userdata par- tition. MobiGyges uses 128-bit Advanced Encryp- 60 tion Standard (AES) [33] with cipher-block chain- 55.0 ing (CBC) and ESSIV:SHA256 to perform the en- Disk utilization (%) 50 cryption. The master key is encrypted with 128-bit AES via invocations to the OpenSSL library. It is 40 recommended that users use 128 bits or more for the MobiGyges MobiMimosa Mobiflage∗ key (with 256 being optional) to improve the secu- rity. Figure 11(2) represents the encrypted logical Figure 12: Disk utilization result of MobiGyges (1 hidden volume created atop the physical volume. It also volume) and Mobiflage. Mobiflage∗ represents all the sys- shows the logical position in MobiGyges. FDE is tems uses the same mechanism as Mobiflage. created using the Device Mapper technology.
and is closely correlated with the storage perfor- 7. Evaluation mance.
In this section, we describe experiments on stor- 7.2. Storage Utilization Evaluation age utilization and performance overheads by com- paring MobiGyges with state-of-the-art works. We MobiGyges creates the Thin Pool using Equa- conduct experiments on Google Nexus 6P mobile tion 2 to calculate the size of metadata volume. phone with 3GB LPDDR4 DRAM and an octa- Hence, the capacity of Thin Pool equals to the size core CPU with 4 [email protected] cores and of the data volume, so the size of the data volume is 4 Cortex-A57@2GHz cores. We use dd [34], bon- the actual capacity that allows users to store their nie++ [35], and AndroBench [36] to conduct the data on the device. To this end, physical storage experiments. utilization η can be calculated with Equation 4. The definitions of the notations used in Equation 4 7.1. Performance Evaluation Tools are the same as that of Equation 2 that can be found in Table 2. dd copies blocks of data from one file to another and is provided by most UNIX platforms. It allows Sp η = parameters like r/w buffer size that can be easily Sp + Sm used for IO performance study. We also use the S (4) = p × 100% = 99.9024%. fsync parameter in dd because it does not bypass Sp × 64 + Sp the kernel disk caches, and when it writes data to Sc the device, the data may still not be committed on We compare disk utilization of Mobiflage and the device upon dd completion. MobiMimosa with MobiGyges because most of the We use Bonnie++ in our experiments: an IO related state-of-the-art works [8–10, 12] use the benchmark tool suite that aims to perform several same method as Mobiflage. For all experiments, simple tests of hard drive and file system perfor- we use dd to conduct experiments, and each has 50 mance. It has 2 types of tests. The first is to trials4. test the IO throughput. The second is to test cre- As shown in Figure 12, the average disk uti- ation, reading, and deleting operations on many lization of MobiGyges is 79.81%. The 20% loss small files. We use the second type in our test. is mainly because each Ext4 file system takes up AndroBench is a popular benchmark tool for An- about 10% of the storage for its metadata use [37, droid. It is an Android application, which provides 38], and we have two volumes formatted with Ext4, sequential/random r/w tests and SQLite bench- marks. Since Android uses SQLite as its built- in database for applications, the performance of 4Results are stable in the first 20 trials, and we conduct SQLite is trivial for Android Apps user experience another 30 trials to decrease the errors. 14 one for the outer volume and the other for the hid-
den volume. Therefore, the storage space utiliza- 231.68 Baseline 208.55
tion of MobiGyges is 99.76%, which is equivalent 203.05 to the theoretical result shown in Equation 4. 200 192.43 Outer 172.76 170.69 Hidden 150 Offset = b0.75 × vlenc 135.46 118.58 116.3 (5) 114.17 107.33 104.58 − (H(pwd||salt)modb0.25 × vlenc). 100
Mobiflage [7] proposes Equation 5 to calculate 50 the offset of placing the hidden volume, and this
equation indicates the capacity of the hidden vol- Sequential read and write speed0 (MB/s) ume is between 25-50% of the total disk capacity. bonnie-RD bonnie-WR dd-RD dd-WR Therefore, Mobiflage introduces up to 25% of the storage waste. Since each file system takes another Figure 13: Bonnie++ and dd IO performance test. Base- line is the original Android FDE. Outer is the MobiGyges’s 10% of the capacity for metadata, and there are two outer volume, and Hidden is the MobiGyges’s hidden vol- file system instances used (one used for the outer ume. volume and the other used for the hidden volume), there is 20% of inevitable waste on each device. Thus, the total storage waste for Mobiflage is 45%. Android FDE (Baseline in the figures) because An- We want to get the improvement purely benefitting droid FDE is enabled by default, and MobiGyges from our MobiGyges design, so we add 20% for each uses Android FDE as a foundation. In the rest of the experimental results, and hence, MobiGyges of this subsection, we use different IO benchmark increases the storage utilization by over 30%5. tools to evaluate the performance of the system and MobiMimosa [11] achieves storage utilization im- analyze the overhead. (1) Bonnie++ test: We run 50 trials7 of se- provement by using the dm table to record the stor- 8 age block used by the hidden volume for the outer quential block tests on a 6GB file on each system. volume. Therefore, the only waste is the dm table. Figure 13 shows that the outer volume outperforms MobiMimosa uses the Ext4 file system, and the de- approximately 10% over Android FDE in terms of fault block size of the Ext4 file system on Android reading. The reason for MobiGyges’s outer vol- is 4KB. Consequently, if a hidden volume has 5GB ume performs better is because of the IO request capacity, the size of the dm table file can be up to batching mechanism. When reading sequentially, 64MB6, which means the size of dm table is 1.25% the system can merge different IO requests, cache of the capacity of the hidden volume. Since the them, and read a bunch of adjacent storage blocks maximum size of a hidden volume is usually smaller together [39]. However, the write performance is re- than a half of the total physical disk capacity, the duced by about 12%. We analyze the impact of the size of the dm table file can take up to 0.625% of performance overhead by considering the user ex- the total physical storage space. We test the stor- perience. With the same 1GB file, we calculate the age utilization on Google Nexus 6P, with the same time difference between MobiGyges and the base- setting as MobiGyges. The results show that the line (Android FDE). Therefore, in terms of reading, overall storage utilization of MobiMimosa that has MobiGyges reduces about 500ms compared with one 5GB hidden volume is 78.375%. the original Android FDE. Similarly, MobiGyges takes 600ms longer than the original Android FDE. 7.3. Performance Overhead Evaluation We believe the performance penalty is acceptable. Comparing the hidden volume and outer volume of Performance overhead on the PDE system is crit- MobiGyges, the write performance is only reduced ical because the attack may compromise the PDE by 3%. The reduction results from the extra en- system if the performance overhead is significant. cryption over the hidden volume. We evaluate the IO performance overhead of Mobi- Gyges (Outer and Hidden in the figures) by compar- ing the IO performances of MobiGyges with that of 7The results are very stable, we run 50 trials to minimize the error. 8Bonnie++ requires to test on a file whose size is twice 5((79.81% + 20%) (55% + 20%))/55% + 20%) 30% as big as the device RAM to decrease the influence of system 6Each dm table item− is 80 byte. ≈ cache. 15 338.24 SQL-D 311.74
307.85 SQL-U 283.07
234.33 SQL-I 213.77
13.53 RND-W 10.55
21.03 RND-R 20.83
131.34 SEQ-W 125.93
230.78 SEQ-R Outer 231.58 Baseline
0 50 100 150 200 250 300 350 SQL performance (Queries/s)
Figure 14: Sequential read and write speed and random read and write speed comparing between outer volume and original Android FDE. Tested with AndroBench. The unit of SQL operations is Q/s (query per seconds). Outer is the MobiGyges’s outer volume and Baseline is the original Android FDE.
(2) dd test: We use the dd command to gen- device mapping. In the sequential read (SEQ-R) erate data from /dev/zero and write data on the test, MobiGyges outperforms the baseline because volume with buffer size 600MB for once9 to test of merged IO requests and batch fetching mecha- writing performance of MobiGyges and the original nism. For SQL queries, MobiGyges reduces about Android system. Then, we use dd to read data from 8% of the performance compared with the baseline. the volume and write the output to the /dev/null However, in terms of modifying data, which writes ”blackhole”10, to test the reading performance of data on the volume, the performance penalty can be MobiGyges and the original Android system. Nor- up to 22%. SQLite uses VDBE (Virtual Database mal dd version prints the statistical data after each Engine) as its background engine, and VDBE uses command finishes. However, Android system uses the B-Tree data structure to store data on a file sys- the busybox [40] version dd tool that prints noth- tem. VDBE also adopts the concept of paging as a ing after completion. Thus, we use time command unit to allocate space for the value of a key, which to count the execution time. Moreover, we clear is similar to pages in the operating system virtual the cache in RAM before every tests11, which elim- memory mechanism. The size of a page is fixed, inates the error caused by operating system caching so if the record is bigger than a page, it has to be mechanism. As shown in Figure 13, dd shows equiv- stored into several pages that are linked together alent results as that of bonnie++. using pointers. To this end, it has to first read (3) AndroBench test: Due to the permission all the pages associated with the key before VDBE control of AndroBench, we fail to test the perfor- can finally update the record. Consequently, the mance of the hidden volume, but comparing the multiple writes downgrade the performance of SQL performance differences between the Android FDE queries, but We believe the performance penalty for and MobiGyges’s outer volume is still sufficient to the SQL operations is acceptable [41]. show the performance overhead of MobiGyges. Fig- ure 14 depicts the result of the AndroBench tests. 7.4. Performance Overhead Comparison In the random r/w (RND-W and RND-R) and se- quential write (SEQ-W) tests, MobiGyges has a In this subsection, we compare the performance performance penalty due to the Thin Pool and overhead between MobiGyges and some recent re- lated works. Note that MobiGyges is not optimized 9 dd if=/dev/zero of=disk.img bs=600M count=1 for improving the IO performance. We post our IO conv=fsync 10dd if=disk.img of=/dev/null bs=600M count=1 performance overhead comparison experimental re- 11echo 3 > /proc/sys/vm/drop caches sults here for the further optimization target. 16 120 (1) Password guessing is the attack by try- Read Write ing all possible password characters repeatedly in 100 a brute force way to identify the correct password.
80 MobiGyges provides both salt and retrial timeout mechanism that can efficiently defend the password 60 guessing attack and the rainbow table attack.
40 (2) Raw data parsing is conducted by parsing 20 the physical disk raw data and try to reconstruct Ratio to the FDE performance (%) the files. MobiGyges uses FDE to defend the raw 0 Mobiflage MobiHydra MobiMimosa MobiCeal MobiGyges data parsing attack, in which all data are encrypted before committing to the physical disk.
Figure 15: Performance overhead. the lower, the better. We use FDE (LUKS [19] on Linux) as the baseline. (3) Encryption primitive leakage means the type of encryption or data protection is leaked. In the hidden volume based PDE, it refers to hidden We implement disk management part of Mob- volumes are exposed and is generally conducted iflage [7], MobiHydra [8], MobiMimosa [11], Mo- from parsing the raw physical disk data. Mobi- biCeal [12] on Linux desktop PC and evaluate their Gyges allocates fine-grained storage blocks from performance with dd. The experimental results are Thin Pool for the outer volume and hidden vol- shown in Figure 15, and the baseline system is the umes on demands, which stores data in a striped Android FDE12. Mobiflage, MobiHydra and Mo- way. Thus, attackers cannot tell the belonging of biMimosa are native solutions, and their outer vol- each data block and fail to distinguish from volume ume and the hidden volume are implemented in to volume. Moreover, MobiGyges applies FDE for the same way as Android FDE. Hence, they have Thin Pool, which increases the complexity and pro- the equivalent performance to the Android FDE. tects hidden volumes. MobiCeal and MobiGyges leverage storage virtual- ization mechanisms, which introduce performance (4) Flash storage leakage refers to the NADN overheads. MobiGyges outperforms MobiCeal on flash storage structure used by mobile devices could the performance overhead. leak sensitive data because flash storage executes writing or wiping data in the unit of page, and can only change some bits in the page to 0 or change all 8. Discussion bits in the page to 1. Hence, writing happens only on an empty page (with all 1s). Thus, data needs In this section, we discuss counter-measurements another temporary page for saving the current un- of MobiGyges towards defending common attacks, changed data in the original page. This tempo- and we then discuss the drawback and possible fu- rary page can leak the sensitive data if not erased ture works. in time. MobiGyges addresses this problem with FDE, and data on flash pages is not the plain data but cipher data, which mitigates the flash storage 8.1. Security Discussion leakage. Common attacks are identified by the existing literature and can be solved by existing counter- (5) Mobile carrier leakage represents the pos- measurements. MobiGyge’s mechanism of defend- sible inconsistent record from the mobile device and ing these attacks makes no difference to existing the mobile carrier provider. The existing literature ones, and the discussion is to show that MobiGyges separate working modes into two, and PDE can considers defending common attacks by design. Ex- only be used under the PDE mode. At the time periments of validating these mechanisms have been using the PDE mode, carrier informations (e.g., listed as part of our future works. phone call history, cellular traffic usage) are stored on the hidden volume, and attackers will find that these informations recorded by the carrier provider 12We implement Android FDE by using LUKS on Linux. are more than that recorded by the outer volume. 17 Thus, this is prone to expose hidden volumes. Mo- and the China Scholarship Council. We would also biGyges eliminates mobile carrier leakage by remov- like to thank the editors and anonymous reviewers ing the design of two modes, and all the informa- for their valuable comments and suggestions. tions are stored on the outer volume. Thus, carrier information records are consistent between the car- References rier provider and the outer volume, which mitigates the leakage. [1] Q. Zhang, G. Wang, J. Chen, G. B. Giannakis, Q. Liu, Mobile energy transfer in internet of things, IEEE In- ternet of Things Journal 6 (5) (2019) 9012–9019. doi: 8.2. Drawbacks and Future Works 10.1109/JIOT.2019.2926333. Although MobiGyges brings new hope to the [2] F. Al-Turjman, Intelligence and security in big 5g- oriented iont: An overview, Future Generation Com- PDE community, it falls short when the attacker puter Systems 102 (2020) 357–368. can record the fill-to-full attack data and tries to [3] M. Xiong, Q. Liu, G. Wang, G. B. Giannakis, C. Huang, retrieve the filled data from the device. One pos- Resonant beam communications: Principles and de- sible remedy is to employ data compression tech- signs, IEEE Communications Magazine 57 (10) (2019) 34–39. doi:10.1109/MCOM.001.1900419. niques to mitigate this issue. MobiGyges also opens [4] J. G¨otzfried,T. M¨uller,Analysing android’s full disk up several interesting directions for future research. encryption feature., JoWUA 5 (1) (2014) 84–100. For example, theoretically evaluating the mathe- [5] Android Open Source Project, Full-disk encryption, matically model of MobiGyges and existing works, https://source.android.com/security/encryption/ full-disk/, [Online; accessed 28-Aug-2019] (2019). reducing the performance overhead by replacing [6] R. Canetti, C. Dwork, M. Naor, R. Ostrovsky, Deni- the Linux Thin Provisioning module with newly able encryption, in: Annual International Cryptology proposed high-performance Thin Provisioning tools Conference, Springer, 1997, pp. 90–104. [7] A. Skillen, M. Mannan, Mobiflage: Deniable storage en- (e.g., ThinStore [42]), and conducting further ex- cryptionfor mobile devices, IEEE Transactions on De- periments in terms of defending common attacks pendable and Secure Computing 11 (3) (2014) 224–237. (e.g., rainbow table attack). [8] X. Yu, B. Chen, Z. Wang, B. Chang, W. T. Zhu, J. Jing, Mobihydra: Pragmatic and multi-level plausibly deni- able encryption storage for mobile devices, in: Inter- 9. Conclusion national conference on information security, Springer, 2014, pp. 555–567. [9] B. Chang, Z. Wang, B. Chen, F. Zhang, Mobipluto: This paper has presented MobiGyges, a PDE File system friendly deniable storage for mobile devices, system that addresses the problems of data loss, in: Proceedings of the 31st annual computer security storage waste, and device reboot on existing PDE applications conference, ACM, 2015, pp. 381–390. systems by splitting the physical storage into fine- [10] B. Chang, Y. Cheng, B. Chen, F. Zhang, W. T. Zhu, Y. Li, Z. Wang, User-friendly deniable storage for mo- grained storage blocks, and each storage block bile devices, Computers & Security 72 (2018) 163–174. is used only by one volume, and using Dynamic [11] S. Hong, C. Liu, B. Ren, Y. Huang, J. Chen, Personal Mounting service to mount the hidden volume with- privacy protection framework based on hidden technol- out rebooting the device. We have also identi- ogy for smartphones, IEEE Access (2017). [12] B. Chang, F. Zhang, B. Chen, Y. Li, W. T. Zhu, fied the capacity comparison attack and fill-to-full Y. Tian, Z. Wang, A. Ching, Mobiceal: Towards se- attack targeted at PDE systems, and MobiGyges cure and practical plausibly deniable encryption on mo- can jointly leverages the Shrunk U-disk method bile devices, in: 2018 48th Annual IEEE/IFIP Inter- and multi-level deniability to defend them. We national Conference on Dependable Systems and Net- works (DSN), 2018, pp. 454–465. have implemented a proof-of-concept system on [13] J. John, C. Raju, Design and comparative analysis of LineageOS 13 for real mobile devices. Experimen- mobile computing software framework, in: 2018 Sec- tal results show that MobiGyges achieves over 30% ond International Conference on Inventive Communica- storage utilization improvement with an acceptable tion and Computational Technologies (ICICCT), IEEE, 2018, pp. 1639–1644. performance overhead. [14] L. Catuogno, H. L¨ohr,M. Winandy, A.-R. Sadeghi, A trusted versioning file system for passive mobile storage devices, Journal of Network and Computer Applications Acknowledgement 38 (2014) 65–75. [15] Team, TrueCrypt, Truecrypt-free open-source disk en- This work was supported in part by the Na- cryption software for windows vista/xp, mac os x, and tional Key Research and Development Program of linux, sept 2019, http://www.truecrypt.org/.[accessed 20 Sept-2019]. China under Grant 2018YFB1003804, Natural Sci- [16] A. Czeskis, D. J. S. Hilaire, K. Koscher, S. D. Gribble, ence Foundation of China under Grant 61921003, T. Kohno, B. Schneier, Defeating encrypted and deni- 18 able file systems: Truecrypt v5. 1a and the case of the A. Tomas, L. Vivier, The new ext4 filesystem: current tattling os and applications., in: HotSec’08, 2008. status and future plans, in: Proceedings of the Linux [17] The Windows Team, Bitlocker drive encryption symposium, Vol. 2, 2007, pp. 21–33. overview, https://technet.microsoft.com/en-us/ [38] T.-Y. Chen, Y.-H. Chang, S.-H. Chen, N.-I. Hsu, H.- library/cc732774(v=ws.11).aspx (2019). W. Wei, W.-K. Shih, On space utilization enhance- [18] N. Kumar, V. Kumar, Bitlocker and windows vista ment of file systems for embedded storage systems, (2008). ACM Transactions on Embedded Computing Systems [19] C. Fruhwirth, Luks–linux unified key setup (2009). (TECS) 16 (3) (2017) 83:1–83:28. [20] X. OS, About filevault 2, Apple inc. Viitattu 22 (2014). [39] Linux Kernel Organization, The kernel documentaion [21] M. J. Dworkin, Recommendation for block cipher of thin provisioning, https://www.kernel.org/doc/ modes of operation: The xts-aes mode for confidential- Documentation/device-mapper/thin-provisioning. ity on storage devices, Tech. rep. (2010). txt, [Online; accessed 7-Aug-2019] (2019). [22] A. D. McDonald, M. G. Kuhn, Stegfs: A steganographic [40] Erik Andersen, Busybox, https://busybox.net. [ac- file system for linux, in: International Workshop on In- cessed 20 Dec-2019]. formation Hiding, Springer, 1999, pp. 463–477. [41] N. Tolia, D. G. Andersen, M. Satyanarayanan, Quanti- [23] A. Barker, S. Sample, Y. Gupta, A. McTaggart, E. L. fying interactive user experience on thin clients, Com- Miller, D. D. E. Long, Artifice: A deniable stegano- puter 39 (3) (2006) 46–52. graphic file system, in: 9th USENIX Workshop on Free [42] K. Qian, L. Yi, J. Shu, Thinstore: Out-of-band virtu- and Open Communications on the Internet (FOCI 19), alization with thin provisioning, in: 2011 IEEE Sixth USENIX Association, Santa Clara, CA, 2019. International Conference on Networking, Architecture, URL https://www.usenix.org/conference/foci19/ and Storage, 2011, pp. 1–10. doi:10.1109/NAS.2011. presentation/barker 39. [24] S. Dean, Freeotfe, https://en.wikipedia.org/wiki/ FreeOTFE/.[accessed 18 Sept-2019]. [25] W. Feng, C. Liu, B. Ren, B. Cheng, J. Chen, Trust- gyges: A hidden volume solution with cloud safe storage and TEE, in: Proceedings of the 16th Annual Interna- tional Conference on Mobile Systems, Applications, and Services (MobiSys’18), 2018, p. 511. [26] W. Feng, C. Liu, Z. Guo, T. Baker, B. Cheng, J. Chen, Data loss prevention and storage utilization improve- ment of the hidden volume on mobile devices, in: 2019 IEEE Symposium on Computers and Communications (ISCC), 2019, pp. 1–6. [27] S. Jia, L. Xia, B. Chen, P. Liu, Deftl: Implement- ing plausibly deniable encryption in flash translation layer, in: Proceedings of the 2017 ACM SIGSAC Con- ference on Computer and Communications Security, ACM, 2017, pp. 2217–2229. [28] B. Leiba, Oauth web authorization protocol, IEEE In- ternet Computing 16 (1) (2012) 74–77. doi:10.1109/ MIC.2012.11. [29] A. Narayanan, V. Shmatikov, Fast dictionary attacks on passwords using time-space tradeoff, in: Proceedings of the 12th ACM conference on Computer and commu- nications security, ACM, 2005, pp. 364–372. [30] jthornber, Thin provisioning tools, https://github. com/jthornber/thin-provisioning-tools (2019). [31] Y. Shao, X. Luo, C. Qian, Rootguard: Protecting rooted android phones, Computer 47 (6) (2014) 32–40. [32] K. Yaghmour, Embedded Android: Porting, Extending, and Customizing, ” O’Reilly Media, Inc.”, 2013. [33] E. Miles, E. Viola, The advanced encryption standard, candidate pseudorandom functions, and natural proofs, in: Electronic Colloquium on Computational Complex- ity (ECCC), 2011, p. 226. [34] Wikipedia, dd (unix), https://en.wikipedia.org/ wiki/Dd_(Unix). [accessed 20 Sept-2019]. [35] Coker, Russell, Bonnie++ file-system benchmark, http://www.coker.com.au/bonnie+ (2019). [36] J.-M. Kim, J.-S. Kim, Androbench: Benchmarking the storage performance of android-based mobile devices, in: Frontiers in Computer Education, Springer, 2012, pp. 667–674. [37] A. Mathur, M. Cao, S. Bhattacharya, A. Dilger,
19