实施和优化android上的加密文件系统毕业论文外文翻译.docx

《实施和优化android上的加密文件系统毕业论文外文翻译.docx》由会员分享，可在线阅读，更多相关《实施和优化android上的加密文件系统毕业论文外文翻译.docx（16页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、外文原文Implementing and Optimizing an Encryption Filesystem on AndroidZhaohui Wang, Rahul Murmuria, Angelos StavrouDepartment of Computer ScienceGeorge Mason UniversityFairfax, VA 22030, USAzwangegmu.edu, rmurmurigmu.edu, astavrougmu.eduAbstractThe recent surge in popularity of smart handheld devices,

2、including smart-phones and tablets, has given rise to new challenges in protection of Personal Identifiable Information (PII). Indeed, modern mobile devices store PII for applications that span from email to SMS and from social media to location-based services increasing the concerns of the end user

3、s privacy. Therefore, there is a clear need and expectation for PII data to be protected in the case of loss, theft, or capture of the portable device. In this paper, we present a novel FUSE (Filesystem in USErspace) encryption filesystem to protect the removable and persistent storage on heterogene

4、ous smart gadget devices running the Android platform. The proposed filesystem leverages NIST certified cryptographic algorithms to encrypt the data- at-rest. We present an analysis of the security and performance trade-offs in a wide-range of usage and load scenarios. Using existing known micro ben

5、chmarks in devices using encryption without any optimization, we show that encrypted operations can incur negligible overhead for read operations and up to twenty (20) times overhead for write operations for I/Ointensive programs. In addition, we quantified the database transaction performance and w

6、e observed a 50% operation time slowdown on average when using encryption. We further explore generic and device specific optimizations and gain 10% to 60% performance for different operations reducing the initial cost of encryption. Finally, we show that our approach is easy to install and configur

7、e across all Android platforms including mobile phones, tablets, and small notebooks without any user perceivable delay for most of the regular Android applications. Keywords-Smart handheld devices, Full disk encryption, Encrypted filesystem, I/O performance. I. BACKGROUND & THREAT MODELA. Backgroun

8、dGoogles Android is a comprehensive software framework for mobile devices (i.e., smart phones, PDAs), tablet computers and set-top-boxes. The Android operating system includes the system library files, middle-ware, and a set of standard applications for telephony, personal information management, an

9、d Internet browsing. The device resources, like the camera, GPS, radio, and Wi-Fi are all controlled through the operating system. Android kernel is based on an enhanced Linux kernel to better address the needs of mobile platforms with improvements on power management, better handling of limited sys

10、tem resources and a special IPC mechanism to isolate the processes. Some of the system libraries included are: a custom C standard library (Bionic), cryptographic (OpenSSL) library, and libraries for media and 2D/3D graphics. The functionality of these libraries are exposed to applications by the An

11、droid Application Framework. Many libraries are inherited from open source projects such as WebKit and SQLite. The Android runtime comprises of the Dalvik, a register-based Java virtual machine. Dalvik runs Java code compiled into a dex format, which is optimized for low memory footprint. Everything

12、 that runs within the Dalvik environment is considered as an application, which is written in Java. For improved performance, applications can mix native code written in the C language through Java Native Interface (JNI). Both Dalvik and native applications run within the same security environment,

13、contained within the Application Sandbox. However, native code does not benefit from the Java abstractions (type checking, automated memory management, garbage collection). Table I lists the hardware modules of Nexus S, which is a typical Google branded Android device. Androids security model differ

14、s significantly from the traditional desktop security model 2. Android applications are treated as mutually distrusting principals; they are isolated from each other and do not have access to each others private data. Each application runs within their own distinct system identity (Linux user ID and

15、 group ID). Therefore, standard Linux kernel facilities for user management is leveraged for enforcing security between applications. Since the Application Sandbox is in the kernel, this security model extends to native code. For applications to use the protected device resources like the GPS, they

16、must request for special permissions for each action in their Manifest file, which is an agreement approved during installation time. Android has adopted SQLite 12 database to store structured data in a private database. SQLite supports standard relational database features and requires only little

17、memory at runtime. SQLite is an Open Source database software library that implements a self-contained, server-less, zeroconfiguration, transactional SQL database engine. Android provides full support for SQLite databases. Any databases you create will be accessible by name to any java class in the

18、application, but not outside the application. The Android SDK includes a sqlite3 database tool that allows you to browse table contents, run SQL commands, and perform other useful functions on SQLite databases. Applications written by 3rd party vendors tend to use these database features extensively

19、 in order to store data on internal memory. The databases are stored as single files in the filesystem and carry the permissions for only the application that created the file to be able to access it. Working with databases in Android, however, can be slow due to the necessary I/O. EncFS is a FUSE-b

20、ased file-system offering file-system encryption on traditional desktop operating systems. FUSE is the supportive library to implement a fully functional filesystem in a userspace program 5. EncFS uses the FUSE library and FUSE kernel module to provide the filesystem interface and runs without any s

21、pecial permissions. EncFS runs over an existing base file-system (for example,ext4,yaffs2,vfat) and offers the encrypted file-system. OpenSSL is integrated in EncFS for offering cryptographic primitives. Any data that is written to the encrypted filesystem is encrypted transparently from the users p

22、erspective and stored onto the base file-system. Reading operations will decrypt the data transparently from the base filesystem and then load it into memory. B. Threat Model Handheld devices are being manufactured all over the world and millions of devices are being sold every month to the consumer

23、 market with increasing expectation for growth and device diversity. The price for each unit ranges from free to eight hundred dollars with or without cellular services. In addition, new smartphone devices are constantly released to the market which results the precipitation of the old models within

24、 months of their launch. With the rich set of sensors integrated with these devices, the data collected and generated are extraordinarily sensitive to users privacy. Smartphones are therefore data-centric model, where the cheap price of the hardware and the significance of the data stored on the dev

25、ice challenge the traditional security provisions. Due to high churn of new devices it is compelling to create new security solutions that are hardware-agnostic. While the Application Sandbox protects applicationspecific data from other applications on the phone, sensitive data may be leaked acciden

26、tally due to improper placement, resale or disposal of the device and its storage media (e.g. removable sdcard). It also can be intentionally exfiltrated by malicious programs via one of the communication channels such as USB, WiFi, Bluetooth, NFC, cellular network etc. Figure 1. Abstraction of Encr

27、yption Filesystem on AndroidFor example, an attacker can compromise a smartphone and gain full control of it by connecting another computing device to it using the USB physical link 33. Moreover, by simply capturing the smartphones physically, adversaries have access to confidential or even classifi

28、ed data if the owners are the government officials or military personnels. Considering the cheap price of the hardware, the data on the devices are more critical and can cause devastating consequences if not well protected. To protect the secrecy of the data of its entire lifetime, we must have robu

29、st techniques to store and delete data while keeping confidentiality. In our threat model, we assume that an adversary is already in control of the device or the bare storage media. The memory-borne attacks and defences are out of the scope of this paper and addressed by related researches in Sectio

30、n II. A robust data encryption infrastructure provided by the operating system can help preserve the confidentiality of all data on the smartphone, given that the adversary cannot obtain the cryptographic key. Furthermore, by destroying the cryptographic key on the smartphone we can make the data pr

31、actically irrecoverable. Having established a threat model and listed our assumptions, we detail the steps to build encryption filesystem on Android in the following sections. V. PERFORMANCEA. Experimental Setup For our experiments, we use the Googles Nexus S smartphone device with Android version 2

32、.3 (codename Gingerbread). The bootloader of the device is unlocked and the device is rooted. The persistent storage on Nexus S smartphones is a 507MB MTD (Memory Technology Device). MTD is neither a block device not a character device, and was designed for flash memory to behave like block devices.

33、 In addition to the MTD device, Nexus S has a dedicated MMC (MultiMediaCard, which is also a NAND flash storage technique) device dedicated to system and userdata partition, which is 512MB and 1024MB respectively. Table II provides the MTD device and MMC device partition layout. In order to evaluate

34、 this setup for performance, we installed two different types of benchmarking tools. We used the SQLite benchmarking application created by RedLicense Labs - RL Benchmark Sqlite. To better understand finegrained low level file I/O operations under different I/O patterns, we use IOzone 7, which is a

35、popular open source filesystem micro benchmarking tool. It is to be noted that these tools are both a very good case study for real-use as well. RL Benchmark Sqlite behaves as any application that is database-heavy would behave. IOzone uses the direct file I/O intensively just like any application w

36、ould, if it was reading or writing files to the persistant storage. All other applications which run in memory and use the CPU, graphics, GPS or other device drivers are irrelevant for our storage media tests and the presence of encrypted filesystem will not affect their performance. IOzone is a fil

37、esystem benchmark tool 7. The benchmark generates and measures a variety of file operations and has been widely used in research work for benchmarking various filesystems on different platforms. The benchmark tests file I/O performance for the generic file operations, such as Read, write, re-read, r

38、e-write, read backwards, read strided, fread, fwrite, random read, pread ,mmap, aio read, aio write. IOzone has been ported to many platforms and runs under various operating systems. Here in our paper, we use ARM-Linux version (Android compatible) of latest IOzone available and focus on the encrypt

39、ion overhead. The cache effect is eliminated by cold rebooting the device for each run of IOzone and RL Benchmark Sqlite. The device is fully charged and connected to external USB power while in experiments. We collect the data and plot the average results of the 5 runs in the figures in all the fol

40、lowing experiments. A. Throughput Performance of EncFS In this section, we present the IOzone performance results for random read and write operations on userdata partition. The benchmark is run for different file sizes and for each file size, with different record lengths. The maximum file size Tab

41、le IIISQLITE PERFORMANCE ON GOOGLE NEXUS Sis selected as 4MB due to the observation that 95% of the user data files are smaller than 4MB on a typical Android system. Fig 3 compares the throughput for four typical file I/O operations, namely read, random read, write and random write. The IOzone exper

42、iments are run on the original ext4 file system and EncFS with different AES key lengths. Fig 3 shows for read operation, EncFS performs the same with original ext4. However, for random read, write, random write, EncFS only gives 3%, 5%, 4% of the original throughput respectively. Our analysis shows

43、 the encryption/decryption contributes the overhead and is the expected trade-off between security and performance. The buffered read in EncFS makes the read operation only incur marginal overhead. However, for random read, the need for the data blocks alignment during decryption results in slower t

44、hroughput. For different key length, the 256-bits key only incurs additional 10% overhead comparing to 128-bits key for better security. In particular, AES-256 runs 12866KB/s,8915KB/s, 9804KB/s at peak for random read,write and random write respectively while AES-128 runs 14378KB/s, 9808KB/s, 10922K

45、B/s. The performance loss of a longer key length trading better security properties is only marginal to the performance loss of the encryption scheme. Optimizations can compensate such key-length overhead as illustrated in Section V-D. Based on this observation, AES-256 is recommended and used as de

46、fault in the following subsection unless otherwise mentioned explicitly. Similarly, sdcard partition gives the identical pattern with slightly different value. Due to the fact that the sdcard partition shares the same underlying physical MMC device with userdata partition as listed in Table II, our

47、experiment results demonstrates the original vfat filesystem performs 16% faster than ext4 filesystem for read and random read operation while ext4 outperforms vfat 80% and 5% for write and random write operations respectively. However, comparing different filesystems is out of our focus in this pap

48、er. We observed different throughput values and overhead patterns on other devices such as Nexus One, HTC Desire and Dell Streak which use a removable sdcard as separate physical medium to internal NAND device. Both AES-128 and AES-256 throughput on sdcard are statistically identical to the ones on

49、userdata partition given a 95% confidence interval. Such results show that the scheme of encryption in EncFS(e.g. internal data block size, key length) and its FUSE IO primitives are the bottleneck of the performance regardless of the underlying filesystems. We suggest corresponding optimizations in Section V-D. In addition to the basic I/O operations, we look at the read operation in detail under different file I/O record size before and after encryption. In particular, we plot the 3D s