DEFY: A Deniable, Encrypted File System for Log-Structured Storage
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
DEFY: A Deniable, Encrypted File System
for Log-Structured Storage
Timothy M. Peters Mark A. Gondree Zachary N. J. Peterson
Cal Poly, San Luis Obispo Naval Postgraduate School Cal Poly, San Luis Obispo
tipeters@calpoly.edu mgondree@nps.edu znjp@calpoly.edu
Abstract—While solutions for file system encryption can pre- In many environments, allowing an adversary to learn that
vent an adversary from determining the contents of files, in a device contains sensitive data may be as damaging as the loss
situations where a user wishes to hide the existence of data, or disclosure of that data. Consider covert data collection in
encryption alone is not sufficient. Indeed, encryption may draw a hostile country, where mobile devices carrying information
attention to those files, as they may likely contain information the might be examined and imaged at border checkpoints. Inspec-
user wishes to keep secret. Consequently, adversarial coercion
may motivate the owner to surrender their encryption keys,
tors may discover the presence of encrypted data, or identify
under duress. This paper presents DEFY, a deniable file system changes to the encrypted file system over time, and demand
following a log-structured design. Maintaining a log-structure is that they be decrypted before allowing passage. This is not a
motivated by the technical constraints imposed by solid-state fictional scenario. In 2012, a videographer smuggled evidence
drives, such as those found in mobile devices. These devices of human rights violations out of Syria. He lacked any data
have consequential properties that previous work largely ignores. protection mechanisms and instead hid a micro-SD card in a
Further, DEFY provides features not offered by prior work, wound on his arm [29]. In another example, the human rights
including: authenticated encryption, fast secure deletion, and group Network for Human Rights Documentation - Burma
support for multiple layers of deniability. We consider security (ND-Burma) collects data on hundreds of thousands of human
against a snapshot adversary, the strongest deniable filesystem rights violations by the Burmese government. They collect
adversary considered by prior literature. We have implemented
a prototype based on YAFFS and an evaluation shows DEFY
testimony from witnesses within the country that the Burmese
exhibits performance degradation comparable to the encrypted government would not want released, putting both activists and
file system for flash, WhisperYAFFS. witnesses in grave danger should the government gain access to
these data [2]. In light of the control exerted by the government
over the Internet within Burma [37], ND-Burma activists carry
I. I NTRODUCTION data on mobile devices, risking exposure at checkpoints and
border crossings. Using a way to hide the encrypted data such
Mobile devices are becoming increasingly ubiquitous and that inspectors cannot reasonably infer sensitive data exist on
powerful. They collect and store large amounts of personal the device, risk to activists and witnesses can be lessened.
or sensitive information. Some users need to protect that
data from unauthorized access just as they would on normal A promising approach to securing data under these condi-
platforms. Evidence of this need can be found on the Google tions is to employ a class of file system known as deniable file
Play store where there are a number of privacy-enhancing systems. Deniable file systems mask information about stored
technology apps, including: ChatSecure [3] (secure texting), data, and allow a user to plausibly deny any storage artifacts
WhisperYAFFS [51] (an encrypted file system), RedPhone [49] on their device, typically by encrypting data with different
(encrypted calls), TextSecure [50] (secure texting), Orbot [4] keys based on the sensitivity of the data. Unfortunately, all
(tor for mobile), Lookout [5] (data backups and anti-virus), known methods to provide deniability from previous designs
and many more. are inapplicable when applied to flash-based storage devices.
In particular, for flash media, strategies that require in-place
The standard method of preventing unauthorized access modification of blocks are unavailable, due to wear-leveling
to information on mobile devices is the same as in general requirements and the special handling required for erasures
secure communication: encryption. While encryption serves to and writes in NAND flash.
limit access to certain files, it does not attempt to hide their In this paper we present DEFY, the Deniable Encrypted
existence. In fact, encryption reveals the existence (and often, File System from YAFFS. DEFY is specifically designed
size) of information that the user does not want others to see. for flash-based, solid-state drives—the primary storage device
found in most mobile devices. The physical properties of flash
Permission to freely reproduce all or part of this paper for noncommercial memory introduce unique challenges to plausible deniability,
purposes is granted provided that copies bear this notice and the full citation requiring us to depart non-trivially from the designs of prior
on the first page. Reproduction for commercial purposes is strictly prohibited deniable file systems. In particular, hardware-implemented
without the prior written consent of the Internet Society, the first-named author wear leveling essentially forces DEFY to embrace a log-
(for reproduction of an entire paper only), and the author’s employer if the
paper was prepared within the scope of employment. structured design. The DEFY file system provides a number
NDSS ’15, 8-11 February 2015, San Diego, CA, USA of features not offered by prior work:
Copyright 2015 Internet Society, ISBN 1-891562-38-X
http://dx.doi.org/10.14722/ndss.2015.23078
• it features a generic design, adaptable to other set- Pang, Tan, and Zhou describe a different implementation,
tings requiring deniability while maintaining a log- also called StegFS [33]. Their implementation uses an unen-
structure; crypted global bitmap to ensure blocks are not accidentally
overwritten. To ensure deniability, “dummy blocks” are oc-
• it supports an arbitrary number of user-defined denia- casionally written; these explain blocks apparently in-use but
bility levels that can be created or removed from the otherwise unreadable by the file system.
system, dynamically;
Gasti et al. describe DenFS, a FUSE leveraging cloud
• it is the first encrypted file system for mobile devices storage and providing deniability in the event the cloud ser-
providing authenticated encryption; vice becomes compromised [22]. DenFS uses cover files and
• it provides a fast and efficient mechanism to securely deniable encryption [16] to protect remote data. In DenFS, the
delete data, allowing individual files or the entire file adversary may intercept messages and request remote files be
system to be deleted in bounded time. What’s more, revealed, but it cannot seize arbitrary snapshots of local storage
it is the first file system to provide secure deletion of (which may reveal local caches, the database of pre-generated
prior allocations by policy; cover files, etc.). Their model is not appropriate for threats
associated with seizure of mobile devices, as considered here
• it is designed to be resistant against the most powerful and in other prior work.
adversary considered by prior work, a snapshotting Skillen and Mannan describe Mobiflage, a deniable filesys-
adversary. tem for Android devices [46]. Their system hides a drive image
in the standard encrypted file system, placing it at a random
DEFY’s design is a significant departure from previous
location, somewhere in the third quarter of the drive’s address
deniable file systems, which require strict control over block
space. This is similar to the design of a “hidden volume” under
placement on the device, and whose security guarantees do
TrueCrypt [6]. Efforts to port TrueCrypt to mobile platforms
not hold when the underlying media re-maps their writes.
also follow this pattern. Each of these systems work at the
For example, for storage using a hardware flash translation
block device layer or higher, ignoring the unique properties
layer (FTL), prior designs are only secure under the addi-
of flash storage; thus, the log-structure below this layer may
tional assumption that the media is effectively tamperproof,
potentially undermine the deniability of the hidden filesystem
i.e. the hardware controller implementing the FTL cannot be
above it, revealing recent activity on the hidden portion of the
bypassed during adversarial analysis (revealing past writes).
device. Further, these systems lack support for more than one
Alternatively, when no FTL is performed, those systems ignore
deniability level, and are not trivially extensible to handle this
the constraints of the underlying media, e.g., they do not wear-
feature.
level appropriately. In contrast, DEFY embraces a logical log-
structure so that its security guarantees hold, especially when WhisperYAFFS is a system providing full disk encryption
the underlying media is also written in a log-structure. Indeed, on flash devices [51]. It provides only confidentiality without
DEFY solution is generalizable, and can be used with devices authenticity and, unlike DEFY and other deniable file systems,
employing hardware FTL (without additional assumptions), does not provide plausible deniability; in particular, its use of
with those requiring FTL logic be implemented by the file plaintext block sequence numbers trivially leaks the history of
system, or with those requiring no FTL logic at all. block updates.
When DEFY is used with only a single deniability level, III. BACKGROUND
it acts like an encrypted file system with additional features
(secure deletion, authenticated encryption) appropriate for Pushed by demand from the growing mobile device market,
mobile devices, making it attractive beyond deniability. We solid-state memory has become a popular alternative to hard
provide a prototype implementation of DEFY and remark on disk drives, due to its small power footprint, lack of moving
the system’s performance, showing performance comparable mechanical parts and high speed. The evolution of flash has
to WhisperYAFFS, the encrypted file system for flash storage. largely been a balancing act between cost, capacity, perfor-
mance, lifespan, and granularity of access/erasure. The most
recent generation of flash is NAND flash. NAND is cheaper
II. R ELATED W ORK to manufacture and denser (bytes per die) than it predecessors,
Anderson et al. propose the first file system with the secu- EEPROM and NOR technologies. Current NAND chip sizes
rity property of plausible deniability [9]. They present schemes are as large as 256GB.
demonstrating two alternate approaches: hiding blocks within NAND offers random-access reads and writes at the page
valid-looking data (“cover files”), and hiding blocks within level, while erasure occurs at the block level. For example, an
random data. DEFY follows this second basic approach. 8GB NAND device with 212 blocks can write a 4KB page but
Writing new data has the possibility of over-writing data must erase at the granularity of a 256KB block. Once pages
at unrevealed levels. Anderson et al. use block replication are programmed, they must be erased before they are written
and random block placement to reduce the probability of again; this is called the program-erase cycle. A per-page Out-
overwriting, of-Bound (OOB) area holds metadata and error correction
codes for the page’s data.
McDonald and Kuhn describe StegFS, an implementation
based on adapting Anderson et al.’s construction to the ext2 Flash memory degrades after many program-erase cycles,
file system [28]. They use a block allocation table to track becoming unreliable after 10,000–100,000 cycles. Many solid-
files, rather than random block placement. state drives employ wear leveling to extend their lifespan
2
within this constraint: drivers attempt to disperse erase/write Every page is assigned a sequence number, stored in the OOB
traffic to avoid media wear. In dynamic wear leveling, data is section of memory. The sequence number is monotonically
written to locations based on availability and a least-written increasing, i.e., the last page written has the highest value,
count. In static wear leveling, some existing, under-utilized making it the new leading edge of the log. The leading edge
(static) block may be moved to distribute wear on the device marks the starting point for the system when searching for the
during a page write request. Most devices implement dynamic next page to allocate.
wear leveling, for its simplicity and speed.
When a page is updated, its corresponding object header
Flash devices can be accessed using Linux’s memory is updated to reference the new page. When an object header
technology device (MTD) subsystem interface, essentially pro- is updated, it too will be written to a new page, and the object
viding a “raw” interface to NAND flash devices. An MTD containing it (e.g. a directory) will also be updated. Therefore,
provides a consistent mapping from logical blocks to physical when a page is modified, the directory path above its object,
blocks, it provides no write leveling, and thus nothing to pre- up to and including the root, is modified on disk.
vent cell overuse. The unsorted block images (UBI) interface
builds on MTD, providing an abstraction comparable to the C. Mounting in YAFFS
Linux Logical Volume Manager for flash storage. UBI tracks YAFFS supports special objects known as checkpoints.
logical blocks in a data structure, deciding to re-map logical These commit information about the state of the file system
blocks based on use, implementing wear leveling. A flash to the drive. On mount, YAFFS searches for the most recent
translation layer (FTL) can be built on top of UBI, providing a checkpoint, using it to reconstruct in-memory data structures.
simplified, block-level interface for flash, in exchange for a loss In the absence of a checkpoint, YAFFS will scan the entire
of low-level control over data placement and strict overwrites. disk, creating a list of blocks and sorting these by sequence
number. Then, in descending order, it examines the contents
A. YAFFS Overview of each block: invalid pages are ignored and valid pages are
YAFFS is a file system designed for use with NAND flash added to an associated in-memory object (creating an object,
memory. Due to its simplicity, portability, and small memory if necessary).
footprint, YAFFS has been used as the default file system in Unlike most disk files systems (e.g., ext2/3/4, NTFS,
many mobile devices, including the Android operating system. HFS+), a YAFFS partition does not need to be formatted
YAFFS is a true log-structured file system [41], [44] in that before being mounted. If no valid objects or checkpoints are
write requests are allocated sequentially within the logical found during mounting, all blocks are marked as available for
address space. Its design is largely motivated by a desire allocation.
to integrate with device-level wear leveling. Next, we briefly
summarize YAFFS’s design; for a more thorough description, D. Garbage Collection in YAFFS
we direct readers to Manning [27] and related resources, e.g.,
Schmitt et al. [42]. Since YAFFS is a log-structured file system, a page is
never updated in place. Thus, when a page is updated, an
The unit of allocation is the page (called a chunk in YAFFS older version of the page likely exists elsewhere on disk. Since
terminology), ranging from 512-bytes to 32KB in size. The NAND requires a page be erased before it can be written and
unit of erasure is the block, each block being composed of 32– offers only block-level erasure granularity, a block may contain
128 pages, depending on the NAND block capacity. YAFFS many obsolete pages that cannot be reclaimed until all pages
uses the OOB space provided by a flash device to store page in the block are obsolete.
metadata and an error correction code.
YAFFS supports two, heuristic modes of garbage collec-
There are two versions of YAFFS: YAFFS1 and YAFFS2. tion: passive and aggressive garbage collection. In general,
The key distinctions between these are: (1) YAFFS1 is de- YAFFS garbage collection proceeds in the following fashion.
signed to work with page sizes up to 1KB while YAFFS2 The system scans the disk looking for a “dirty” block, i.e. a
supports larger pages, and (2) YAFFS2 implements a true log- block with “few” valid pages. The definition of “few” depends
structured file system, performing no overwrites when new on the garbage collection mode. During normal operation, the
data are written. This paper refers to the YAFFS2 design, and collector considers a block to be “dirty” if the number of
we use the terms YAFFS2 and YAFFS interchangeably. valid (active) pages in the block is below some threshold. On
startup, during passive garbage collection, this threshold is
Every YAFFS entity (files, directories, links, etc.) is main- lowest: if no more than four pages are valid, then the block
tained as an object, with an object header. Each object header is dirty. On each unsuccessful scan, the threshold is increased,
stores metadata about its associated object, including its name, beginning with four but never going beyond half the pages in a
its size, and location its pages. A directory’s header contains block. When every block is more than half full, the system will
the location of headers for its children (files and subdirecto- switches to aggressive garbage collection, where a block with
ries). any dirty page is considered dirty. Once a block is identified
for collection, YAFFS re-writes its valid pages to the leading
B. Writing in YAFFS edge and erases the dirty block, making it available for writing.
Write requests are divided into pages, allocated and written
IV. S ECURITY M ODEL
sequentially following the leading edge of the log (the last page
written). If the leading edge is the last page of a block, YAFFS Before describing the design of DEFY, we introduce our
searches for the next block past the leading edge that is not full. adversarial model and security goals.
3
A. Adversaries V. D ESIGN R EQUIREMENTS
A secure, deniable file system hides the existence of Before we describe the details of our design, we provide
information from an adversary. It conceals all indication as an overview of the requirements that we believe should guide
to whether or not there are hidden files or directories, at the the design of any secure, deniable file system.
file system level. It does not, however, enforce a system-wide
information flow policy. Czekis et al. demonstrate how it is Deniability Levels: The concept of a deniability level was in-
possible to infer the existence of hidden files using the content troduced in previous deniable file systems implementations [9],
of revealed files, e.g. indices generated by services for desktop [28], [33]. A deniability level is a collection of files that
search [17]. We assume users, the OS and applications use the form a sensitivity equivalence class (e.g., love letters vs. trade
file system appropriately. secrets). Here, as in previous work, deniability levels form
We define two types of passive adversaries for deniable a total order: `0 ≤ `1 ≤ . . . ≤ `h . A user has some
file systems: those with one-time access to the device (single- secret password to reveal all files at a chosen deniability level.
view adversaries) and those with periodic access (snapshot Following a convenience established in previous work, when
adversaries). In this context, an adversary’s “access” yields a revealing a level, all lower levels should also be revealed.
full copy of the disk and a complete description of the file The system should be flexible enough to accommodate the
system (e.g. through a copy of its source code). Further, the dynamic creation of new deniability levels, rather than pre-
adversary is allowed to force the user to reveal some set of hid- specifying and defining the total set of levels at initialization.
den files. As with previous work, the adversary cannot access An implementation may, of course, elect to restrict users to
the device’s RAM contents nor capture the running state of the some large, fixed number of levels by default; however, we
device while outside of the adversary’s immediate possession, believe this should not be a restriction imposed by design.
e.g. using a Trojan to implement a, so called, “Evil Maid”
attack [18], [43] or extracting cryptographic keys from RAM Secure Deletion: Providing secure deletion is complementary
using a cold boot attack [30]. To help ameliorate these threats, to the setting of deniability. Secure deletion assures that a
DEFY could be enhanced with an interface to immediately deleted object is permanently inaccessible, even if the device
zero RAM data structures (including cryptographic keys) in and keys are later revealed to an adversary. We desire secure
an emergency situation, i.e. a quick lockout feature that may deletion to be efficient, deniable and granular. Granular dele-
result in limited data loss. tion means deleting the entire file system or a set of files is
as complex as deleting an individual file. Finally, to preserve
The single-view adversary is one that is able to access deniability, deleted data should not appear to be deleted: it
the file system and its user only once. This adversarial model should be indistinguishable from both data unused by the
describes many natural scenarios: those in which the device is system and unrevealed data.
stolen, or it is confiscated and the user detained for questioning.
The snapshot adversarial model describes scenarios in which Garfinkel and Shelat [21] survey methods to destroy digital
access to the device is granted at distinct points in time, and file data, and identify two techniques that leave storage devices
system images are collected. For example, upon entering and usable after erasure: secure overwriting and cryptographic key
exiting a guarded facility or at a border-crossing. The snapshot disposal. In secure overwriting, old data are overwritten with
adversary may then use differences in the collected images to new data such that the old data are irrecoverable. Gutmann
identify changed data blocks on the device. [23] gives a technique for magnetic storage devices that takes
35 synchronous passes over the data in order to degauss the
Both models include the ability of adversaries to use media. (Fewer passes may be sufficient.) Techniques designed
various means (i.e., threats and physical violence) to compel to securely delete data from hard disk drives have been shown
the user to reveal some set of files. Both models allow the to be ineffective for flash-based storage [48].
adversary to perform advanced computer forensics on the disk
image, use password cracking programs, employ statistical For systems that employ encryption, Boneh and Lipton
tests, etc. These models subsume all previous deniable file propose that data may be securely deleted by “forgetting”
system adversarial models in the literature. the corresponding encryption key [15]; without the key, it
is computationally infeasible to ever decrypt the data again.
The actual disposal of the encryption key may involve secure
B. Security Definitions overwriting. Results from Reardon et al. [36] and Lee et
A deniable file system offers plausible deniability if the al. [26] indicate that key disposal techniques may be the most
adversary has no means of proving that the user has withheld appropriate technique for flash storage.
data, beyond what she has chosen to reveal. Alternatively, the
user must be able to convince the adversary that no data has Authenticated Encryption: Authenticated encryption pro-
been written to the file system beyond what she has chosen to vides confidentiality and data integrity [11]. Confidentiality,
reveal. In other words, it must be plausible that any unrevealed of course, is essential for hiding data at unrevealed levels.
block on the disk contains no valid data. Additionally, the file When users may be compelled to relinquish possession of their
system offers snapshot resistance if it has plausible deniability, mobile device, the benefits of data integrity under the loss of
even in the presence of a snapshot adversary. In particular, the physical security are also beneficial. Authenticated encryption,
user may have written data to the disk between snapshots, and though, requires message expansion—ciphertext are larger than
the adversary can determine which blocks have been modified the original plaintext—which is an obstacle to its integration
between accesses. It must be possible that any unrevealed into legacy file systems. Existing work in cryptographic file
block (modified or not) contains no data. systems (e.g. [6], [14], [52]) use only unauthenticated block
4TABLE I: Feature comparison of deniable file systems.
Skillen et al. Pang et al. McDonald et al. Anderson et al. Anderson et al.
DEFY Mobiflage [46] StegFS [33] StegFS [28] Scheme 1, [9] Scheme 2 [9]
Single-view Resistance ! ! ! ! ! !
Snapshot Resistance ! !
Arbitrary No. of Levels ! ! ! ! !
Authenticated Encryption !
Efficient Secure Deletion !
Data Loss Resistance Load-dependent ! ! Probabilistic Probabilistic !
Wear Leveling Aware !
ciphers, which preserves message size to meet the alignment file system should be easily distributable and compatible with
constraints of block-based storage devices. In practice, addi- popular operating systems (e.g. Android and Linux). Using a
tional storage must be used and managed for the extra bits loadable kernel module to extend the existing kernel allows
associated with ciphertext expansion. systems to be modified without rebuilding from source.
Minimizing Data Loss: Data loss occurs when hidden data VI. D ESIGN OVERVIEW
(unrevealed data at a high deniability level) is overwritten
because the file system is mounted at a lower level—an DEFY is designed as an extension to the YAFFS file
unfortunate, but unavoidable characteristic of any deniable file system, with security features inspired by WhisperYAFFS. We
system. One strategy to prevent overwriting is to maintain a chose YAFFS because it is designed to operate on raw NAND
global list of memory blocks that are free for writing (not in flash, handles wear leveling, is widely-deployed, and is open-
use by any higher or lower levels); a strategy similar to this is source. To YAFFS we add authenticated encryption, crypto-
employed by Pang et al. [33]. Alone, this strategy undermines graphic secure deletion, and support for multiple deniability
plausible deniability: a single-view adversary learns which levels that are resistant to strong adversaries. A comparison of
blocks are in-use across the system, revealing if hidden levels DEFY’s features with existing work appears in Table I. The
exist. The remedy in Pang is to create abandoned blocks, following provides a high-level description of DEFY’s main
or blocks that are falsely marked as in-use. This creates design features.
plausible deniability, at the expense of permanently sacrificing
capacity. Anderson et al. [9] prevent data loss in their system Deniability Levels: DEFY supports one or more deniability
through block replication, similarly suffering a significant levels, each associated with a level directory, and permits the
overhead to prevent data loss. While the capacity of NAND dynamic creation of levels. Each level directory exists under
drives is increasing and prices decreasing, the cost-per-byte the root directory of the file system. All files for a deniability
for flash memory is still almost double that of hard disk level are located below its level directory. Each deniability
devices, limiting the appeal of solutions with high storage level is associated with a unique name and cryptographic key,
overheads. What’s more, storage devices that employ wear derived from a user-provided password. The system maintains
leveling preclude file systems from modifying data in place no record of what levels exist in the system; it can only know
or at completely random locations. This entirely excludes data which levels are currently open. When a user reveals a level,
recovery strategies based on random placement of replicas, all lower levels are also revealed. This is a convenience, helps
or recovering overwritten blocks from n-out-of-m threshold- to minimize the chance of overwriting (since only unrevealed
based error correction codes. levels risk overwriting), and follows the conventions of previ-
ous work.
Wear Leveling: NAND flash has a limit to the number of Assigning deniability to directories at the root level is
times data can be written to a block before it fails. Many strategic and provides a number of advantages. Level direc-
devices, then, implement wear leveling, in which all writes tories allow for easy inheritance of deniability levels. Objects
are systematically written to new locations, preventing some created within a directory will, by default, inherit the level
blocks from failing far earlier than others. This has impli- of that directory, i.e. be correctly encrypted at the appro-
cations for both encrypting and deniable file systems: wear priate level. We believe this behavior to be quite natural,
leveling mechanisms may persist old versions of encrypted following the tradition of other security semantics (e.g. file
data, providing an adversary with a timeline of changes made system permissions), and frees users of the burden of assigning
to disk, and thus, an ability to differentiate between claimed deniability levels to individual files. Separating deniability
and actual disk activity. Wear leveling undermines any file level namespaces through level directories, also forces users
system whose security is predicated on the ability to overwrite to be more thoughtful, and perhaps, careful about how they
data. Any secure file system designed for flash-based storage categorize the sensitivity of their data.
should be secure and compatible with drives that either do or
do not manage their own wear leveling.
Authenticated Encryption: The two key challenges associ-
ated in implementing authenticated encryption in DEFY are:
Easily Deployable: To have the broadest impact, a deniable (1) designing a file system that can accommodate the data
5Input: Encrypted Page hx1 , . . . , xm i with page ID id,
Input: Data Page hd1 , . . . , dm i with page ID id, OOB
OOB data xoob , counter x, tag t, per-level keys K` , M`
data doob , counter x, and per-level keys K` , M`
1: ctr2 ← PAD-128(id||x||0)
1: ctr1 ← PAD-128(id||x||1)
2: σ ← t ⊕ x1 ⊕ . . . ⊕ xm ⊕ xoob
2: c1 , . . . , cm , coob ← AES-CTRctr 1
K` (d1 , . . . , dm , doob ) 3: c1 , . . . , cm , coob ← AES-CTRctr
σ
2
(x1 , . . . , xm , xoob )
3: σ ← HMAC-SHA256M` (c1 , ..., cm , coob ) 4: σ 0 ← HMAC-SHA256M` (c1 , . . . , cm , coob )
4: ctr2 ← PAD-128(id||x||0) 5: if σ 0 6= σ return ⊥
5: x1 , . . . , xm , xoob ← AES-CTRctrσ
2
(c1 , ..., cm , coob ) 6: ctr1 ← PAD-128(id||x||1)
6: t ← σ ⊕ x1 ... ⊕ xm ⊕ xoob 7: d1 , . . . , dm , doob ← AES-CTRctr 1
K` (c1 , . . . , cm , coob )
Output: Tag t, Page hx1 , . . . , xm i and OOB xoob
Output: Page hd1 , . . . , dm i, OOB doob
(a) AON Encryption.
(b) AON Decryption.
Fig. 1: Authenticated encryption/decryption for a page using the all-or-nothing transform in DEFY.
expansion that results from authentication and, (2) designing an tial output, reveals nothing about its input. No single message
encryption scheme that is supportive of efficient and granular of a ciphertext can be decrypted in isolation without decrypting
secure deletion. Here, we focus our discussion on the former, the entire ciphertext. The original intention of the transform
leaving a discussion of the latter for the next section. was to provide additional complexity to exhaustive search
attacks, by requiring an attacker to decrypt an entire message
DEFY’s encryption scheme is presented in Figure 1. The for each key guess. AON has been proposed to make secure
algorithm takes as input a data page, broken into m, 128- an RSA padding scheme [11], to make efficient smart-card
bit messages (d1 , . . . , dm ), the OOB data (doob ), a unique transactions [12], [13], [24], message authentication [19], and
page identifier (id), a unique global counter (x), a per-level threshold-type cryptosystems using symmetric primitives [8].
encryption key (K` ) and a per-level MAC key (M` ). The
algorithm implements an encrypt-then-MAC scheme: first en- Our design implements an encryption-based secure deletion
crypting the page and OOB data using AES in counter mode scheme based on Peterson et al.’s AON technique for secure
(AES-CTR), then MACing the resulting ciphertext using a deletion of versioned data [34]. The all-or-nothing transform
SHA-based message authentication code (HMAC-SHA256). allows any subset of a ciphertext block to be deleted (e.g.
An additional encryption using AES-CTR using the authen- through overwriting) in order to delete the entire ciphertext;
ticator as the key is performed to complete an all-or-nothing without all ciphertext blocks, the page can never be decrypted.
transform (described later). A tag (t) is created by XOR-ing When combined with authenticated encryption, the AON trans-
the ciphertext blocks (x1 , . . . , xm , xoob ) with the authenticator form creates a message expansion that is bound to the same
(σ). This small tag is not secret; rather, it is an expansion of all-or-nothing property. This small expansion becomes the
the encrypted data and is subject to the all-or-nothing property. tag and can be efficiently overwritten to securely delete the
The encrypted page (x1 , . . . , xm ) is written to disk as data, the corresponding page. Indeed, message expansion is fundamental
encrypted OOB data (xoob ) is written to the OOB area, and to our deletion model and the AON transform is a natural
the tag (t) is stored as metadata in the parent object. construct for providing efficient secure deletion for DEFY, as
it minimizes the amount of data needed to be overwritten,
The same counter and key pair should never be used for does not complicate key management, and conforms to our
encryption more than once. For the block cipher in counter hierarchical deletion model.
mode, we extract a unique counter value, padding this to
128-bits in length using some appropriate padding scheme
Metadata for DEFY: Metadata in YAFFS have been re-
(PAD-128). This value is derived from the page’s physical
purposed to support authenticated encryption and secure dele-
disk address (id) and a global sequence counter (x); both
tion. Every DEFY metadata object supports the storage of tags
are associated with a DEFY object and, by policy, are non-
for its child objects: data pages in the case of a file object,
repeatable in a file system. The encryption key and MAC key
or file objects in the case of a directory object. When a child
are also distinct between levels.
object is modified, the parent object is updated with a new tag,
We remark that other constructions for achieving all-or- overwriting the previous tag, securely deleting the old object.
nothing encryption, leveraging other cryptographic modes and As a result of storing a new tag, the parent object is modified.
algorithms, may provide better performance or a more elegant Thus, creating, deleting or modifying an object in DEFY will
design. For example, Steps 1–3 of Figure 1a may be combined trigger a tag cascade for all directory objects in that object’s
into a single call of OCB mode [39], which requires only path, up to the file system root. See Figure 2 for a simplified
one pass over the data to be made and is fully parallelizable. overview of DEFY’s hierarchical metadata design.
Our construction acts as proof-of-concept and an exemplar for Tags for the level directory are collocated in a tag storage
achieving our design goals. area (TSA), which is managed separately from the rest of
the file system. When the level tags are updated, they are
Encryption-Based Deletion: The same AON transform that written to a new block, and the previous version is erased and
provides authenticated encryption, also provides a means for re-written with pseudo-random data. The approach of using
efficient secure deletion. The original AON transform, due to a specially-managed area of flash storage to achieve secure
Rivest [38], is a cryptographic function that, given only a par- deletion is akin to the strategies proposed by Reardon et al.
6read and write operations, both unbuffered and buffered. We Relatedly, attacks against deniable file systems may be
believe these characterize the most common and I/O-bound possible when adversaries have access to data from external
operations for a file system. sources (“hints”) or are otherwise unconstrained by the single-
view and snapshot models. For example, Skillen and Mannan
With each test, IOZone performs an I/O operation on a propose a “colluding carrier” attack [46], where the adversary
number of uniformly-sized files, up to some maximum size. colludes with a wireless provider or ISP (e.g., through govern-
For example, when measuring the write performance of a mental writ), collecting network trace data to aid later forensic
64KB sized file, IOZone attempts to write sixteen 4KB files, analysis of the device. Discrepancies between the device logs
eight 8KB files, and so on, up to one 64KB file. For each and the carrier’s logs may enable an adversary to conclude
benchmark, we average the throughputs across four runs. the presence of hidden data, and compel hidden levels to be
Results, with standard deviations, are presented in Figure 6. revealed. Skillen and Mannan make suggestions to restrict
We find that DEFY performs comparably with Whis- these threats to deniable file systems for mobile devices,
perYAFFS, while both DEFY and WhisperYAFFS underper- including disabling wireless connectivity (or limiting network
form when compared with YAFFS, ext3, and ext4. This is not connectivity to WiFi only) during privileged use, and using
unexpected, due in large part to the additional computation multiple SIM cards and carriers to make log collection difficult.
requirements necessary to support their cryptographic opera- We, too, acknowledge DEFY’s limitations to resist this type
tions. It is notable that these results suggest our AON transform of attack, and suggest that users follow those same practices
comes at an expense similar to AES in XTS mode [20], in countries where carriers may assist forensic investigation.
used by WhisperYAFFS. Further, we believe the additional More generally, we find the ultimate guarantees of deniable
computational and I/O requirements for tag cascading have file systems have not been critically examined. In all existing
little to no impact on normal file system operations. definitions, the onus is on the adversary to prove that the
We also find that the number of deniability levels has little system contains hidden data. This reflects the presumption of
effect on file system performance. We configured a DEFY innocence common in many legal systems, i.e. the adversary
partition with three deniability levels and performed the same must prove the user’s guilt and until then she is presumed
IOZone benchmarks mounted under all three levels (i.e. one innocent. Given that adversaries have been known to torture
level, two level, and all levels revealed). Figure 7 presents the individuals for their passwords [47], it is unclear if a system
results. These findings demonstrate that performance in DEFY founded upon this tenant is viable for use in truly hostile
is an artifact of IO irrespective of the number of revealed (or environments. In practice, the very existence of a deniable file
unrevealed) levels. DEFY’s log-structured nature writes new system may draw unwanted attention. To a casual observer,
data to the head of the log, regardless from which level is per- DEFY looks and behaves like a full-disk encryption scheme,
forming the write. Writing data from many levels concurrently so that revealing a single level may be convincing.
may cause a single level’s blocks to be fragmented across the
device, which could lead to poor sequential read performance XI. C ONCLUSION
for rotating media. Indeed, poor sequential read performance
is a contributing factor to why log-structured files systems We have presented DEFY, a deniable file system for solid-
has not been more widely adopted. However, the uniform state memory, usable as a file system for mobile devices
random access performance of solid state drives render data and laptops. Current design patterns for deniable file systems
non-contiguity largely irrelevant, allowing system engineer’s cannot be easily adapted for many mobile devices; this is
to once again enjoy the manifold benefits of a log structure largely due to system design assumptions about the storage
(e.g. implicit versioning, inherent consistency, and simplified media that, while valid for many settings, are inappropriate
data structures). for solid-state drives. The physical properties of solid-state
memory require wear leveling and disallow in-place updates,
X. D ENIABLE F ILESYSTEMS IN P RACTICE motivating our use of a log-structured file system. Thus, DEFY
is the first log-structured deniable file system. At first glance,
We remark that the use of deniable file systems from social, log-structured systems appear to deeply conflict with the goal
legal, and usability perspectives has not been well-explored of empowering a user to deny actions from the recent past.
in the literature. In particular, all deniable file systems to We apply techniques from a secure, versioning file system
date employ user passwords for securing files at a certain in a completely new way, to support a log-structure with a
deniability level. This allows an adversary to undermine plau- deniable history. As the first deniable file system designed
sible deniability at the cost of a password-guessing attack. In for log-structured storage, we believe DEFY fills a gap in
our adversarial setting, some password protection mechanisms the space of privacy enhancing technologies for devices using
can be successfully utilized (e.g., using password-based key solid-state drives, such as mobile devices. DEFY also supports
derivation functions to increase the cost of brute force attacks) other features useful in a mobile setting, including authen-
while others cannot. For example, although not needed, pass- ticated encryption and fine-grained secure deletion of data.
word salts for each level’s password, would need to be stored Our DEFY prototype implementation is based on YAFFS and
somewhere persistent and, thus, could undermine plausible WhisperYAFFS, and is released as an open-source project on
deniability. Similarly, key management techniques used in BitBucket1 . Preliminary evaluation demonstrates performance
traditional disk encryption software, such as key wrapping [7], similar to that experienced with full-disk encryption on these
[31], [40], could likewise undermine deniability. Currently, all devices, i.e., WhisperYAFFS.
deniable file systems demand the user select good passwords,
and DEFY is no exception to this. 1 https://bitbucket.org/solstice/defy/
11ACKNOWLEDGMENTS [22] P. Gasti, G. Ateniese, and M. Blanton, “Deniable cloud storage: sharing
files via public-key deniability,” in WPES ’10: Proceedings of the 9th
The authors would like to thank the NDSS program annual ACM workshop on Privacy in the electronic society, Oct. 2010.
committee for their very constructive feedback, Hayawardh [23] P. Gutmann, “Secure deletion of data from magnetic and solid-state
Vijayakumar for feedback on a pre-publication version of this memory,” in Proceedings of the USENIX Security Symposium, July
paper, and LT M. Chase Smith for earlier work on a related 1996, pp. 77–90.
DEFY design. Our thanks to the YAFFS and WhisperYAFFS [24] M. Jakobsson, J. Stern, and M. Yung, “Scramble all. Encrypt small.” in
developers for their respective contributions to the free and Fast Software Encryption, vol. 1636, 1999, lecture Notes in Computer
Science.
open-source software movement.
[25] B. Kaliski, “PKCS #5: Password-based cryptography specification,”
IETF Network Working Group, Request for Comments RFC 2898, Sept.
R EFERENCES 2000.
[1] “UBIFS - A UBI File System,” October 2008, http://www.linux- [26] J. Lee, S. Yi, J. Heo, S. Y. Shin, and Y. Cho, “An Efficient Secure
mtd.infradead.org/doc/ubifs.html. Deletion Scheme for Flash File Systems,” Journal of Information
Science and Engineering, vol. 26, pp. 27–38, 2010.
[2] “Martus case studies: The global human rights abuse reporting system,”
2012, https://www.martus.org/resources/case studies.shtml. [Online]. [27] C. Manning, “How YAFFS works,” 23 May 2012, available at http:
Available: https://www.martus.org/resources/case studies.shtml //goo.gl/0Mdja.
[3] “GuardianProject/ChatSecure:Android,” 2014, [28] A. D. Mcdonald and M. G. Kuhn, “StegFS: A steganographic file system
https://guardianproject.info/apps/chatsecure. for Linux,” in Information Hiding, 1999.
[4] “GuardianProject/Orbot,” 2014, https://guardianproject.info/apps/orbot/. [29] J. Mull, “How a Syrian refugee risked his life to bear witness to atroc-
ities,” March 2012, toronto Star Online; posted 14-March-2012. [On-
[5] “Lookout/lookout mobile security,” 2014, https://www.lookout.com/.
line]. Available: http://www.thestar.com/news/world/2012/03/14/how
[6] “Truecrypt,” 2014, http://www.truecrypt.org/. a syrian refugee risked his life to bear witness to atrocities.html
[7] Accredited Standards Committee, X9, Inc., “ANS X9.102- Wrapping of [30] T. Müller and M. Spreitzenbarth, “Frost: Forensic recovery of scrambled
Keys and Associated Data,” http://eprint.iacr.org/2004/340.pdf, Novem- telephones,” in Applied Cryptography and Network Security (ACNS’13),
ber 2004. 2013, pp. 373–388.
[8] R. Anderson, “The dancing bear – a new way of composing ciphers,” [31] National Institute of Standards and Technology, “AES key wrap speci-
in Proceedings of the International Workshop on Security Protocols, fication,” November 2001.
April 2004.
[32] W. Norcott and D. Capps, “IOzone filesystem benchmark,”
[9] R. Anderson, R. Needham, and A. Shamir, “The steganographic file http://www.iozone.org/.
system,” in Information Hiding, Second International Workshop (IH
’98), Portland, Oregon, USA, April 1998, pp. 73–82. [33] H. Pang, K. lee Tan, and X. Zhou, “StegFS: A Steganographic File
System,” in Proceedings of the International Conference on Data
[10] M. Bellare, A. Desai, E. Jokipii, and P. Rogaway, “A Concrete Security Engineering, 2003.
Treatment of Symmetric Encryption,” in Proceedings of the Annual
Symposium on Foundations of Computer Science, 1997, pp. 394–403. [34] Z. N. J. Peterson, R. Burns, J. Herring, A. Stubblefield, and A. D.
Rubin, “Secure Deletion for a Versioning File System,” in Proceedings
[11] M. Bellare and C. Namprempre, “Authenticated Encryption: Relations
of the USENIX Conference on File and Storage Technologies, 2005.
among notions and analysis of the generic composition paradigm,”
in Advances in Cryptology - Asiacrypt’00 Proceedings, vol. 1976. [35] N. Provos and D. Mazieres, “A future-adaptable password scheme,” in
Springer-Verlag, 2000, lecture Notes in Computer Science. Proceedings of the USENIX Annual Technical Conference, 1999.
[12] M. Blaze, “High-bandwidth encryption with low-bandwidth smart- [36] J. Reardon, S. Capkun, and D. Basin, “Data node encrypted
cards,” in Fast Software Encryption, vol. 1039, 1996, pp. 33–40, lecture file system: Efficient secure deletion for flash memory,” in
Notes in Computer Science. Proceedings of the USENIX Security Symposium, 2012, pp.
[13] M. Blaze, J. Feigenbaum, and M. Naor, “A formal treatment of remotely 333–348. [Online]. Available: https://www.usenix.org/conference/
keyed encryption,” in Advances in Cryptology – EUROCRYPT ’98, vol. usenixsecurity12/technical-sessions/presentation/reardon
1403, 1998, pp. 251–265, Lecture Notes in Computer Science. [37] Reporters Without Borders, “Internet enemies,” 12 March 2012, avail-
[14] M. Blaze, “A cryptographic file system for UNIX,” in Proceedings of able at http://goo.gl/x6zZ1.
the ACM Conference on Computer and Communications Security, 1993, [38] R. L. Rivest, “All-or-nothing encryption and the package transform,” in
pp. 9–16. Fast Software Encryption Conference, vol. 1267, 1997, pp. 210–218,
[15] D. Boneh and R. Lipton, “A revocable backup system,” in Proceedings lecture Notes in Computer Science.
of the USENIX Security Symposium, July 1996, pp. 91–96. [39] P. Rogaway, M. Bellare, J. Black, and T. Krovet, “OCB: A block-
[16] R. Canetti, C. Dwork, M. Naor, and R. Ostrovsky, “Deniable encryp- cipher mode of operation for efficient authenticated encryption,” in
tion,” Advances in Cryptology — CRYPTO ’97, pp. 90–104, 1997. Proceedings of the ACM Conference on Computer and Communications
Security, November 2001, pp. 196–205.
[17] A. Czekis, D. J. St Hilaire, K. Koscher, S. D. Gribble, T. Kohno, and
B. Schneier, “Defeating encrypted and deniable file systems: Truecrypt [40] P. Rogaway and T. Shrimpton, “Deterministic authenticated-encryption
v5.1a and the case of the tattling os and applications,” 3rd USENIX a provable-security treatment of the key-wrap problem,” in Advances
Workshop on Hot Topics in Security (HotSec ’08), 2008. in Cryptology – EUROCRYPT 06, vol. 4004, 2007, Lecture Notes in
Computer Science.
[18] D. Defreez, “Android privacy through encryption,” Master’s thesis,
Southern Oregon University, May 2012, available at http://goo.gl/ [41] M. Rosenblum and J. K. Ousterhout, “The Design and Implementation
94HBb. of a Log-Structured File System,” Operating Systems Review, vol. 25,
pp. 1–15, 1991.
[19] Y. Dodis and J. An, “Concealment and its applications to authenticated
encryption,” in Advances in Cryptology – EUROCRYPT ’03, vol. 2656, [42] S. Schmitt, M. Spreitzenbarth, and C. Zimmermann, “Reverse engi-
2003, Lecture Notes in Computer Science. neering of the Android file system (YAFFS2),” Friedrich-Alexander-
[20] M. Dworkin, “Recommendation for block cipher modes of operation: Universität Eriangen-Nürnberg, Tech. Rep. CS-2011-06, 2011.
The XTS-AES mode for confidentiality on storage devices,” National [43] B. Schneier, ““Evil maid” attacks on encrypted hard drives,” 23 Oct.
Institute of Standards and Technology, NIST Special Publication SP- 2009, http://goo.gl/Z1Kny. [Online]. Available: https://www.schneier.
800-38E, January 2010. com/blog/archives/2009/10/evilmaidattac.html
[21] S. L. Garfinkel and A. Shelat, “Remembrance of data passed: A study [44] M. Seltzer, K. Bostic, M. K. McKusick, and C. Staelin, “An implemen-
of disk sanitization practices,” IEEE Security and Privacy, vol. 1, no. 1, tation of a log-structured file system for UNIX,” in Proceedings of the
pp. 17–27, 2003. Winter USENIX Technical Conference, January 1993, pp. 307–326.
12[45] A. Skillen, “Deniable storage encryption for mobile devices,” Master’s [49] “GitHub: WhisperSystems/RedPhone,” http://goo.gl/Mmz9s, Whisper-
thesis, Concordia University, 2013. Systems, 2012.
[46] A. Skillen and M. Mannan, “On implementing deniable storage [50] “GitHub: WhisperSystems/TextSecure,” http://goo.gl/3qoV8, Whisper-
encryption for mobile devices,” in Proceedings of the Network and Systems, 2012.
Distributed System Security Symposium, February 2013. [Online]. [51] “GitHub: WhisperSystems/WhisperYAFFS: Wiki,” http://goo.gl/Qsku4,
Available: http://spectrum.library.concordia.ca/975074/ WhisperSystems, 2012. [Online]. Available: https://github.com/
[47] M. Weaver, “Developer tortured by raiders with crowbars,” Daily WhisperSystems/WhisperYAFFS/wiki
Telegraph, 31 October 1997. [52] C. P. Wright, M. C. Martino, and E. Zadok, “Ncryptfs: A secure and
convenient cryptographic file system,” in Proceedings of the USENIX
[48] M. Wei, L. M. Grupp, F. E. Spada, and S. Swanson, “Reliably erasing Technical Conference, 2003, pp. 197–210.
data from flash-based solid state drives,” in Proceedings of the USENIX
Conference on File and Storage Technologies, 2011.
13You can also read
