
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 <latexit sha1_base64="qyKLrfeuHx+zQREtin+3Dsc5MJU=">AAACGXicbVDJSgNBEO1xN25Rj14ag+DFMCOKHkUvggoKZoFMCD09laSxp3vorhHDkN/w4q948aCIRz35N3aWg9uDgsd7VVTVi1IpLPr+pzcxOTU9Mzs3X1hYXFpeKa6uVa3ODIcK11KbesQsSKGgggIl1FMDLIkk1KKbk4FfuwVjhVbX2EuhmbCOEm3BGTqpVfRDpYWKQWGIcIeIeZzscNNLsU/PhcruwrBwBkaBpBc6ziS0iiW/7A9B/5JgTEpkjMtW8T2MNc8St4JLZm0j8FNs5syg4BL6hTCzkDJ+wzrQcFSxBGwzH37Wp1tOiWlbG1cK6VD9PpGzxNpeErnOhGHX/vYG4n9eI8P2YTMXKs0QFB8tameSoqaDmGgsDHCUPUcYN8LdSnmXGcbRhVlwIQS/X/5LqrvlYK+8f7VbOjoexzFHNsgm2SYBOSBH5JRckgrh5J48kmfy4j14T96r9zZqnfDGM+vkB7yPL7eMoVY=</latexit> dm-crypt Kernel Module ume, he/she may conduct the fill-to-full attack Physical Disk to explore the real capacity of the outer volume by writing arbitrary data to the outer volume and filling it until full. After filling the outer Figure 4: Encrypted logical volume and physical storage. Applications use the normal system call to read or write data volume, the attacker gets the audited informa- to the encrypted logical volume. The dm-crypt Linux mod- tion and conducts the capacity comparison at- ule automatically encrypts and decrypts the data between tack. If the real capacity is different from that the encrypted logical volume and the physical disk. of the physical disk, the hidden volume will be compromised. Management (LVM) into the Android system Existing solutions cannot solve the three prob- and implementing a TriggerApp to use hid- lems simultaneously, and they cannot defend the den volume on-demand secretly. We conduct two attacks. To this end, we present MobiGyges in experiments to evaluate MobiGyges's storage this paper. MobiGyges is a hidden volume based utilization, performance overhead, and experi- PDE system. It introduces the Volume Manage- mental results show that MobiGyes reaches all ment module and FDE module, which prevents sen- our design goal and improves storage utiliza- sitive data loss by restricting each storage block us- tion by over 30% compared with current solu- able by solely one volume, and improves the stor- tions. age utilization by eliminating the \reserved area" (as shown in Figure 2b), and avoids rebooting The rest of the paper is organized as follows. the device to use the hidden volume by introduc- Section 2 introduces related works, and Section 3 ing the Dynamic Mounting service that mounts presents the threat model and assumptions. In Sec- the hidden volume on-demand. MobiGyges also tion 4, we introduce our newly identified PDE ori- uses the Shrunk U-disk method (detailed in Sec- ented attacks. Section 5 presents the design of Mo- tion 5.3.1(3)) and multi-level deniability (detailed biGyges. In Section 6, we present the implemen- in Section 5.3.2(3)) to jointly defend the aforemen- tation of MobiGyges with LineageOS 13 on Google tioned attacks.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages19 Page
-
File Size-