ABSTRACT
While solutions for file system encryption can prevent an adversary from determining the contents of files, in situations where a user wishes to hide even the existence of data, encryption alone is not enough. Indeed, encryption may draw attention to those files, as they most likely contain information the user wishes to keep secret, and coercion can be a very strong motivator for the owner of an encrypted file system to surrender their secret key.
Herein we present DEFY, a deniable file system designed to work exclusively with solid-state drives, particularly those found in mobile devices. Solid-state drives have unique properties that render previous deniable file system designs impractical or insecure. Further, DEFY provides features not ordered by any single prior work, including: support for multiple layers of deniability, authenticated encryption, and an ability to quickly and securely delete data from the device. We have implemented a prototype based on the YAFFS and WhisperYaffs file systems. An evaluation shows DEFY performs comparatively with WhisperYaffs.
BACKGROUND
Pushed by demand for mobile devices, solid-state memory has become a popular alternative to hard disk drives, due to its low power consumption, high speed, low noise, and lack of moving mechanical parts (increasing durability). The evolution of ash memory technology has been a balancing act between cost, capacity, performance, lifespan, and granularity of access/erasure. The most recent generation of flash is NAND flash.
DEFY: OVERVIEW
Figure 3.1: A high-level system view of the DEFY kernel module
DEFY is a Linux kernel module, and as such it implements the Virtual File System (VFS) interface. The VFS interface allows the operating system to ask for a plethora of information from DEFY. This can include file, directory, or general file system information. It also allows the operating system to instruct DEFY to perform certain actions-like mounting and unmounting.
DEFY: DESIGN
Figure 4.3: An example of how metadata (stubs) and data are stored in DEFY
As previously discussed (4 & 4), stubs are used in DEFY to support authenticated encryption and secure deletion. They are stored both in the metadata of objects and in a separate stub storage area, as shown in figure 4.3. The metadata of an object is used to store stubs for its child objects: data chunks in the case of a file object, or file objects in the case of a directory object.
Figure 4.5: This is an example of current allocation blocks from various levels
Unlike YAFFS, chunks and blocks are associated to a particular level in DEFY (as shown in figure 4.5). As such, the chunk allocator will only assign chunks from a particular level’s current chunk allocation block. When an allocation block is fully written another block must be selected.
EVALUATION
Figure 5.1: The performance of a number of file systems as measured by FFSB
That is, it reads and writes data until a timer expires, instead of reading and writing a finite amount of data. We limited our runs to 1 second due to the higher speed file systems. If the time was set any longer the emulated drive would run out of space. Our results from FFSB are shown in figure 5.1.
FUTURE WORK
We maintained the YAFFS design of storing all metadata in memory while adding greatly to the size of that metadata with stubs. As a result, DEFY can only handle les up to 2 megabytes in size. This number could be drastically increased by decreasing the number of stubs in memory. DEFY already stores all of the needed stubs on the device and in the stub storage area, so the only necessary modification is adding a better memory manager that manages which stubs are in memory at all times.
RELATED WORK
The idea for a plausibly deniable file system was introduced by Anderson et al in 1998. They presented two competing constructions. The first was steganographic, it hid data inside of other valid data. The second hid data inside of a large amount of random data. Time has shown the second option to be more popular, it is emulated by the majority of deniable file systems-including DEFY.
CONCLUSION
In this work we proposed the design for a new deniable file system dubbed DEFY. DEFY is strong against both the snapshot and the single-view adversaries. It provides wear-leveling, secure deletion, authenticated encryption, multiple deniable levels, and mitigated data loss. The deniability of DEFY resides in the undecryptable blocks that are created by the combination of the forward-writing nature of a log-structured file system and normal user interactions.
We built a prototype version of DEFY and found that it performed comparably to WhisperYaffs-its closest competitor-when benchmarked with both the FFSB and the IOZone test suites. We believe that this is a valuable contribution to the existing collection of deniable file systems, and we propose that it is even strong enough to defend against the snapshot adversary. To our knowledge there is only one other deniable file system that reaches this level of security.
Source: California Polytechnic State University
Author: Timothy M. Peters