Per-File Full-Data-Path Secure Deletion for Electronic Storage Sarah M

Florida State University Libraries

Electronic Theses, Treatises and Dissertations The Graduate School

2012 Per-File Full-Data-Path Secure Deletion for Electronic Storage Sarah M. (Sarah Marie) Diesburg

Follow this and additional works at the FSU Digital Library. For more information, please contact [email protected] THE FLORIDA STATE UNIVERSITY

COLLEGE OF ARTS AND SCIENCES

PER-FILE FULL-DATA-PATH SECURE DELETION FOR ELECTRONIC STORAGE

SARAH M. DIESBURG

A Dissertation submitted to the Department of Computer Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy

Degree Awarded: Fall Semester, 2012 Sarah M. Diesburg defended this Dissertation on October 31, 2012. The members of the supervisory committee were:

An-I Andy Wang Professor Directing Dissertation

Steven Bellenot University Representative

Theodore Baker Committee Member

Mike Burmester Committee Member

Lois Hawkes Committee Member

The Graduate School has verified and approved the above-named committee members, and certifies that the dissertation has been approved in accordance with university requirements.

I dedicate this dissertation to my husband, Brad, and my parents for their love, support, and encouragement. I also dedicate this work to those everywhere who fight to protect personal privacy.

iii

ACKNOWLEDGEMENTS

I would like to thank my graduate advisor, Andy Wang, for his insightful discussions, support, and guidance throughout my graduate research and teaching career. You have shown by example how to not only produce top-notch research, but also how to be a good teacher, speaker, and writer. I would also like to thank my undergraduate advisor, Paul Gray, for lighting the fire that has inspired my research. I would never have reached this point if it had not been for your contagious passions for technology and education and the research opportunities you gave me. In addition, I would like to thank the members of my dissertation committee. Lois Hawkes has provided indispensable guidance in both navigating graduate school and my technical work. Ted Baker, Mike Burmester, and Steve Bellenot have also provided valuable feedback on my work and have helped me to push my research to a higher standard. Other students have made contributions to this work. In particular, I would like to thank both Chris Meyers and Mark Stanovich for their direct contributions to this research. Michael Mitchell, Justin Marshall, and Julia Gould have also made contributions. Research is a group effort, and I enjoyed the time I spent with all of you discussing ideas and implementations. I would like to acknowledge the grants and scholarships that have made this research possible. This work has been sponsored by NSF CNS-0845672/CNS-1065127, DoE P200A060279, Philanthropic Educational Organization, and Florida State University. The content of this dissertation is largely drawn from papers published in the proceedings of the 4th ACM International Workshop on Storage Security and Survivability [13] and the proceedings of the 28th Annual Computer Security Applications Conference [12], as well as a journal survey article published in ACM Computing Surveys [14]. I would like to thank Geoff Kuenning, Peter Reiher, and anonymous reviewers for their comments on improving the publications, and indirectly, the quality of this dissertation. On a personal note, I would like to thank Brad Diesburg for his love and support, especially during the more stressful times. My parents have always encouraged me to shoot for the stars, and I am thankful for all the sacrifices they made for me. I am thankful to Nichole Lee and Saiju Gangadharan for their friendship and morale support, and I am thankful to John and Karen Burns for providing the wonderful distraction and stress relief of dance. Finally, I would

iv like to thank Atomic Coffee and their mocha lattes for helping me get this dissertation completed on time.

TABLE OF CONTENTS

List of Tables ...... viii List of Figures ...... ix Abstract ...... xi 1. INTRODUCTION ...... 1 1.1 Legacy Storage-data-path Constraints ...... 3 1.2 Threat Models and Assumptions ...... 4 1.3 Contributions and Impact ...... 5 2. BACKGROUND ...... 7 2.1 Operating System Storage Data Path ...... 7 2.1.1 Background ...... 7 2.1.2 Data Path Challenges ...... 9 2.2 NAND Flash Secure Deletion ...... 10 2.3 Desirable Characteristics for Secure Deletion ...... 12 3. TRUEERASE DESIGN ...... 15 3.1 Design Guideline and Overview ...... 15 3.2 User Model...... 16 3.2.1 Sensitive Status ...... 17 3.2.2 Name Handling ...... 17 3.2.3 Links ...... 19 3.3 The Type/Attribute Propagation Module ...... 19 3.3.1 Data Structures and Globally Unique IDs ...... 19 3.3.2 Event Reporting Interface ...... 21 3.4 Storage-management Layer Enhancements ...... 23 3.4.1 NAND Flash ...... 23 3.4.2 Hard Drive ...... 25 3.5 Other Design Points ...... 25 3.6 File System Consistency Properties ...... 26 4. TRUEERASE IMPLEMENTATION ...... 29 4.1 User Model...... 29 4.2 File System Interactions with TAP ...... 30 4.2.1 File System Background ...... 30 4.2.2 Deployment Model ...... 31 4.3 Extended Storage-management Layer ...... 36 4.3.1 Extended Flash Device Interface ...... 36 4.3.2 INFTL Background ...... 37 4.3.3 INFTL Extensions ...... 40 4.3.4 Hard-drive Extensions ...... 42 4.4 Development Tools ...... 45 4.4.1 Lightweight Kernel Flash Monitor ...... 45 4.4.2 User-space Flash Development Environment ...... 46

5. VERIFICATION ...... 48 5.1 Basic Cases ...... 48 5.2 Two-version Programming ...... 49 6. PERFORMANCE EVALUATION ...... 53 6.1 Flash Chip Properties ...... 53 6.2 Flash Small File Workload ...... 56 7. RELATED WORK ...... 60 7.1 Layer-specific Solutions ...... 60 7.1.1 Storage-management-level Solutions ...... 60 7.1.2 File-system-level Solutions ...... 61 7.1.3 User-space Solutions ...... 63 7.2 Cross-layer Solutions ...... 64 7.2.1 Semantically-smart disk systems ...... 64 7.2.2 Type-safe Disks ...... 64 7.2.3 Modified Flash File Systems ...... 65 7.3 Remote and Distributed Solutions ...... 65 8. FUTURE DIRECTIONS ...... 67 8.1 Hard Drive Optimizations ...... 67 8.2 Flash Optimizations ...... 72 8.3 Other Expansions ...... 72 9. DISCUSSION ...... 74 9.1 Data Remanence ...... 74 9.1.1 Hard-drive Data Remanence Issues ...... 74 9.1.2 Flash Data Remanence Issues ...... 77 9.1.3 Other Issues ...... 78 9.2 ATA TRIM Command ...... 79 9.2.1 TRIM Background ...... 80 9.2.2 TRIM for Secure Deletion ...... 80 10. LESSONS LEARNED AND CONCLUDING REMARKS ...... 82 A. FILE SYSTEM SECURE OPERATION TRACES...... 84 A.1 Secure Creation and Deletion of Files ...... 84 A.2 Moving Files ...... 94 A.3 Replacing Files...... 98 A.4 Symlinks and Hard Links...... 102 B. PERMISSIONS ...... 115 REFERENCES ...... 116 BIOGRAPHICAL SKETCH ...... 122

vii

LIST OF TABLES

2.3.1 Existing Secure-deletion Methods and Characteristics...... 14

3.3.2.1 The TAP Interface...... 21

4.1.1 Legacy Secure-deletion Attribute Commands ...... 30

6.2.1 PostMark Flash Operations, Times, and Overhead Percentage Compared to Base ...... 57

6.2.2 Compilation Flash Operations, Times, and Overhead Percentage Compared to Base ...59

8.1.1 PostMark Hard Drive Elapsed Times Compared to Base ...... 68

9.1.1.1 Software-based Methods of Erasing Data on Non-volatile Storage (NISPOM) ...... 75

9.1.1.2 Peter Gutmann's 35-pass Overwrite Technique ...... 75

A.1.1 Empty File Trace...... 85

A.1.2 Small File Trace (1K) ...... 87

A.1.3 Small File Trace (13K with Single Indirect)...... 90

A.2.1 Move Non-secure File into Non-secure Directory Trace ...... 94

A.2.2 Move Secure File into Non-secure Directory Trace ...... 95

A.2.3 Move Non-secure File into Secure Directory Trace ...... 96

A.2.4 Move Secure File into Secure Directory Trace...... 97

A.3.1 Move Non-secure File onto Non-secure File Trace ...... 99

A.3.2 Move Secure File onto Non-secure File Trace ...... 100

A.3.3 Move Non-secure File onto Secure File Trace ...... 101

A.3.4 Move Secure File onto Secure File Trace ...... 102

A.4.1 Secure Symlink Trace ...... 104

A.4.2 Secure Hard Link Trace (a)...... 108

A.4.3 Secure Hard Link Trace (b) ...... 111

viii

LIST OF FIGURES

1.1 Percentage Change Use of Home Computers ...... 1

2.1.1.1 Comparison of Linux and Windows Storage Data Paths...... 8

2.1.1.2 Simplified Legacy Linux Data Path ...... 9

3.1.1 TrueErase Framework ...... 17

3.2.2.1 Traditional Permissions ...... 18

3.2.2.2 TrueErase Secure Deletion Sensitive Status Model...... 18

3.3.1.1 TAP Write Entry Fields ...... 20

3.3.1.2 TAP Deletion Reminder Fields ...... 20

4.2.2.1 Secure Data Updates ...... 32

4.2.2.2 Secure Metadata Updates ...... 34

4.2.2.3 Secure Data Deletion ...... 35

4.3.1.1 Flash-specific Interactions with TAP and Secure-deletion Commands ...... 37

4.3.2.1 Updates in INFTL ...... 39

4.3.2.2 Reads in INFTL ...... 40

4.3.3.1 INFTL Secure-write Operation ...... 41

4.3.4.1 Hard-drive-specific Interactions with TAP and Secure-deletion Commands ...... 42

4.3.4.2 Hard-drive Secure-deletion Processing ...... 44

4.3.4.3 Hard-drive Secure-write Processing ...... 45

4.4.2.1 User-space Flash Development Environment ...... 47

5.2.1 Verification Empty State Illustrating the State-space Matrix ...... 50

5.2.2 State-space Enumeration Program Algorithm ...... 51

5.2.3 Interactions of the State-space Enumeration Program with TAP ...... 52

6.1.1 Raw DiskOnChip Sequential Timings for Flash Operations ...... 54

6.1.2 Raw DiskOnChip Random Timings for Flash Operations ...... 55

6.2.1 PostMark Flash Elapsed Times for TrueErase Running Modes ...... 58

6.2.2 Compilation Flash Elapsed Times for TrueErase Running Modes ...... 58

8.1.1 PostMark Hard Drive Elapsed Times for TrueErase Running Modes ...... 68

8.1.2 PostMark Hard Drive Elapsed Times for TrueErase Debugging Modes ...... 70

9.1.3.1 Demonstration of Bad Sector Forwarding ...... 78

ABSTRACT

The amount of sensitive data stored on electronic media increases as the use of computers and mobile devices becomes more prevalent. For example, home computers and devices may store financial information (e.g., Quicken files or tax documents), usernames and passwords, private correspondence (e.g., emails or chat logs), and personal media files (e.g., pictures or videos). Business computers and devices may store sensitive client data and trade secrets. Government computers and devices may store personally identifiable data on citizens and classified materials. As the amount of digital sensitive information accrues, the need for the ability to securely remove this information increases. Short of physically destroying the entire storage medium, existing secure-deletion solutions tend to be piecemeal at best – they may only work for one type of storage or file system, may force the user to delete all files instead of selective files, may require the added complexities of encryption and key storage, may require extensive changes and additions to the computer’s operating system or storage firmware, and may not handle system crashes gracefully. This dissertation introduces TrueErase, a holistic secure-deletion framework that irrevocably deletes data and metadata. At heart, TrueErase is an information-propagation framework that works alongside of legacy operating system components for easier integration. Through its design, implementation, verification, and evaluation on both a hard drive and emerging solid-state storage, TrueErase shows that it is possible to construct a holistic, per-file, encryption-free, secure-deletion framework that accommodates different storage media and legacy file systems, requires limited changes to legacy systems, and handles common crash scenarios. The experience of building TrueErase further contributes insight into the mechanisms and complexities of the legacy operating system storage data path.

CHAPTER ONE

INTRODUCTION

As the cost of electronic storage declines rapidly, more data are stored on media such as hard disks, CDs, and thumb drives. In 2010, the U.S. Census Bureau reported that 77% of U.S. households own a computer (e.g., desktop computers, laptops, smart phones, and other handheld devices computers [49]). The trend of the paperless office also drives businesses and government agencies toward converting data, once stored in locked filing cabinets, into digital forms. As the years progress, more sensitive data are stored on electronic media. According to surveys conducted by the Center for Research on Information Technology and Organizations at the University of California, Irvine, home users in particular are increasingly using their computers to perform sensitive tasks [77]. Throughout the 11 years of this study, usage of email, online shopping, and online banking have increased 26%, 63%, and 150% respectively. These statistics suggest that many computers store data on personal finances and online transactions, not to mention other confidential data such as tax records, passwords for bank accounts, and email.

100 90 80 70 60 Percent 50 Use 40 Email 30 Online Shopping 20 10 Online Banking 0 1998 2000 2002 2004 2006 2008 2010 Year

Figure 1.1: Percentage Change Use of Home Computers

More sensitive data is being stored within industries and governments as well. One recent example includes the Health Information Technology for Economic and Clinical Health

(HITECH) act [25]. The HITECH act promotes the use of information technology for the electronic exchange of personal health information among providers and other health care entities, and it provides incentives intended to promote the widespread adoption of technology that supports the electronic sharing of data among hospitals, physicians, and other health care entities [75]. The sharing of this personal health data requires storage of this data on electronic media. In addition, the growing availability of mobile computing and storage devices encourages sensitive data to be stored on-the-go. Today, an insurance agent can carry a laptop that holds thousands of Social Security numbers, medical histories, and other confidential information. According to a 2008 Cisco survey [8], almost one in four employees said they carry corporate data on portable storage devices outside the office. Once sensitive data is no longer needed, users may wish to remove this data permanently from electronic storage. Although wary users may diligently empty their trash bins and reformat their storage, they may be unaware that typical deletion methods only make files invisible to users, while leaving behind recoverable sensitive data. Typical file deletion only updates the file’s metadata (e.g., pointers to the data) for bookkeeping purposes, while often leaving the file data intact. Even recreating the file system does not ensure secure deletion. For example, the MSDOS format command has been shown to only overwrite 0.1% of the data [18]. As a consequence, data thought to have been erased may still be retrieved from a wide array of decommissioned storage devices, including hard drives [18, 76] and USB storage devices like thumb drives [30]. One answer to this problem is secure deletion, which is concerned with rendering a file’s removed content and metadata (e.g., information such as a file’s name, size, and owner) irrecoverable, even to those with direct access to the hardware. We can divide most secure- deletion methodologies into two categories: coarse-grained and fine-grained secure deletion. Coarse-grained secure deletion is the simplest to understand and implement. It securely deletes large swaths of information over an entire storage partition or drive with no option to selectively delete smaller amounts of information (like specific files). The most extreme techniques include physically destroying the medium through smelting, shredding, sanding, pulverization, or acid bath [43]. Other techniques that allow storage to be reusable include specialty hardware commands to erase the entire storage or software that indiscriminately

2 destroys data across an entire device or partition (discussed in Chapter 2). However, certain coarse-grained methods do not always work on all media (one example is NAND flash [78]), and may be cumbersome to use when only a few files need to be securely deleted. Further, securely deleting an entire device or partition may be infeasible for embedded devices (e.g., cell phones). In contrast, fine-grained secure deletion implies the ability to securely delete information below the granularity of file system or storage units. A stronger example is per-file secure deletion, which is concerned with securely removing a specific file’s content and metadata. The extra control obtained through using a per-file secure-deletion solution can be beneficial in a variety of situations. It can assist with implementing privacy policies concerning the selective destruction of data after it has expired (e.g., client files), complying with government regulations to dispose of sensitive data (e.g., HIPPA [24]), deleting temporarily shared trade secrets, military applications demanding immediate destruction of selected data, and disposing of media in one- time-use applications. All of this may be done without turning off the computer or disrupting access to storage services. We introduce TrueErase, a holistic per-file secure-deletion framework that irrevocably deletes selective data and metadata upon user request. TrueErase is compatible with existing applications, works with emerging storage media and legacy file systems, and tracks sensitive data throughout the operating-system storage data path to ensure secure deletion is honored. TrueErase goes to the heart of the user's mental model: securely deleted data, like a shredded document, should be irrecoverable.

1.1. Legacy Storage-data-path Constraints

Implementing a full per-file secure-deletion solution is difficult due to the current design of the operating-system storage data path. The storage data path has many components, each is largely encapsulated from the other component (e.g. the file system is separate from the storage drivers), and components communicate through a narrow interface. In other words, each component interface of the storage data path is designed with the concept of information hiding so that the internal mechanisms of each component may evolve independently from other components.

However, the current information-hiding and encapsulation techniques in the storage data path inhibit secure deletion. Each component’s interface was not designed to communicate secure-deletion information, and many legacy components are not designed to handle secure deletion at all. As a result, existing per-file secure-deletion solutions tend to be very piecemeal. For example, a solution may be specific to one segment of the storage data path (e.g., the file system or the application layer) without taking into account other components (e.g., storage media type). This last point is important, as it can yield unexpected behavior using secure- deletion methods that may have worked previously in different environments. To illustrate, a secure deletion issued by a program may not be honored by optimization software used on typical flash devices that keep old versions of the data [78] or may not delete sensitive data from file systems that use a journal [60]. Perhaps the ideal solution is to remake all the components and interfaces in the storage data path. Unfortunately, this would require extensive changes to all storage drivers, file systems, and less visible components such as storage schedulers. Such a change would require industry acceptance and vast amounts of time and money. A more practical approach is to design a method to allow backward-compatible changes toward secure deletion in a way that does not break the current storage data path components or interfaces, or else, only modifies the interface where absolutely necessary. We embrace this pragmatism in the form of designing and adding a second, parallel storage data path that explicitly propagates secure-deletion information through all the layers of the storage data path. Components can be made to interact with our second data path to report and query secure- deletion information while preserving legacy behavior. We show that the cost of secure deletion using this extra secure storage data path is reasonable.

1.2. Threat Models and Assumptions

Achieving secure deletion is difficult due to diverse threat models. To narrow down the problem, we focus on dead forensics attacks on local storage, which occur after the computer has been shut down properly. In other words, we protect against attacks that occur after a user cleanly unmounts and shuts down the system after completing secure-deletion operations. If the system crashes before the secure-deletion operations finish, our framework must not allow the

4 information that was being securely deleted to leak or be in an inconsistent state after the system is brought back up. Attacks on backups, cold-boot attacks [23], covert channels, and policy violations are beyond our scope. In particular, our framework assumes that we have control of the entire storage data path in an uncompromised, single-user, single-file-system, non-RAID, non-distributed system. Thus, the research question is, under benign user control and system environments, what holistic solution can we design and build to ensure that the secure deletion of a file is honored throughout the legacy storage data path? Although tightly constrained, this criterion still presents significant design challenges. We also assume the presence of basic file-system-consistency properties [63], which have been shown to be a requirement of secure deletion. These basic properties can be found in modern file systems. We cannot verify secure deletion in file systems that cannot guarantee their own consistency (e.g., ext2, FAT). In addition to preserving consistency during crash scenarios, these properties allow us to enumerate file-system behavior during deletion operations for verification purposes. Further, all file-system update events are reported to our framework to verify that we are tracking all important events. These assumptions allow us to focus on building and verifying the properties of secure deletion.

1.3. Contributions and Impact

TrueErase is designed to overcome the many challenges of correctly propagating secure-deletion information in a full-data-path manner—all the way from the user to the storage. This framework is essential for building advanced secure-deletion capabilities such as the ones based on tainting or encryption-based key deletion. The major contributions of this work are summarized as follows:

Design and implementation of a per-file secure-deletion framework that works with the legacy storage data path and the emerging NAND flash.

Verification of the core component of the framework through black-box permutation of inputs and two-version programming.

Evaluation of our framework on two types of storage: legacy hard drives and emerging NAND flash commonly used on thumb drives and mobile devices.

An overarching framework that addresses the challenges of implementing and coordinating secure deletion throughout the legacy storage data path.

The remainder of this dissertation is organized as follows. Chapter 2 gives background on the operating system storage data path, discusses issues surrounding NAND flash secure deletion, and states and compares several desirable characteristics for a secure-deletion system. Chapter 3 introduces TrueErase and discusses its design. Chapter 4 discusses implementation of TrueErase and supporting tools. Chapter 5 addresses verification of TrueErase, and Chapter 6 evaluates TrueErase’s performance. Finally, Chapter 7 relates TrueErase to existing systems; Chapter 8 discusses future directions, Chapter 9 discusses additional issues, and Chapter 10 gives lessons learned and conclusion. File system traces to illustrate the implementation and verification of secure file system operations can be found in Appendix A.

CHAPTER TWO

BACKGROUND

This chapter first provides background on the legacy operating-system storage data path and its limitations imposed on existing secure-deletion solutions. This chapter then demonstrates how the emerging NAND flash storage medium prompts the need for a new secure-deletion framework. Finally, we further motivate the need for an all-around secure-deletion solution by discussing desirable characteristics of an ideal secure-deletion solution and comparing existing works to these characteristics.

2.1. Operating System Storage Data Path

Storage requests travel from user applications to the storage through the legacy operating-system storage data path. This legacy data path imposes many challenges in designing and building secure-deletion solutions.

2.1.1. Background

Figure 2.1.1.1 shows the storage data paths for the Linux and Windows operating systems (OSes). For both platforms, applications reside in user space. In Linux, an application makes a storage request through a POSIX-like API to a file system, and the request crosses the kernel boundary and is handled by the Virtual File System (VFS) Layer [35]. VFS eases individual file system implementations by providing common functions and allows different file systems to co- exist, including file systems operating locally such as ext3 and remote network file systems such as NFS. Local file systems then proceed to read and write to the block layer, which provides a unified interface to access block layer devices. When a Windows application makes a storage request to its file system, that request gets made through a specific subsystem interface such as the Win32 or POSIX subsystem [15]. Next, the storage request is passed to the I/O system services layer, which performs tasks such as looking up files and checking access rights [16]. After that, the request is passed to the I/O

7 manager. The I/O Manager translates storage requests into I/O request packets, which it then translates into device-specific calls. The File System Drivers are high-level drivers such as FAT and NTFS. These drivers rely on the Storage Device Drivers, which are lower-level drivers that directly access the storage media. Note that both Linux and Windows storage data paths share similar notions of file system and device drivers, and the Windows I/O subsystem includes the same functionality as the Linux VFS [42]. Thus, a secure-deletion framework designed for one can be generalized to both platforms. Linux is more conducive to prototype development due to its open-source nature and wide array of development tools for raw access to storage media. Thus, we chose to design and prototype our framework under Linux.

Application

Application Subsystem User Kernel I/O System Services I/O VFS Subsystem

I/O Manager

File System Driver

Device Drivers Device Drivers

Storage Storage Media Media

Linux Storage Windows Storage Data Data Path Path

Figure 2.1.1.1: Comparison of Linux and Windows Storage Data Paths

To simplify the illustration of TrueErase, it is sufficient to use Figure 2.1.1.2 to represent the Linux storage data path. In the figure, the file system box includes VFS, and the storage- management layer consists of the legacy block-layer interface, where all requests to files are transformed into block reads and writes, and low-level drivers to handle the vendor-specific representations of structures on the storage media. The storage-management layer can either exist in software as part of the block layer or in hardware. File systems communicate with the storage-management layer through the legacy block-layer interface.

Application

User Kernel

File System

Storage Management Layer

Storage Media

Figure 2.1.1.2: Simplified Legacy Linux Data Path

2.1.2. Data Path Challenges

The legacy storage data path imposes the following challenges in designing a secure-deletion solution. No inter-layer coordination: Due to the legacy block-layer interface, the storage- management layer has no information about a block’s file ownership or type [17, 64] and cannot support per-file deletion. File-system- and application-layer solutions are generally unaware of the storage medium and have limited control

over the storage location of data and metadata. In addition, storage such as NAND flash may leave versions of sensitive data behind. Thus, we need a solution that spans the entire data path to enforce secure deletion. No pre-existing deletion operation: Read and write operations are routinely sent to the storage device from file systems. However, to optimize performance, file systems generally do not issue requests to erase file content. Instead, the file system sends a series of write requests to remove references to data blocks and set the file size and allocation bits to zero. Complex storage-data-path optimizations: Secure deletion needs to retrofit legacy asynchronous optimizations. In particular, storage requests may be reordered, concatenated, split, consolidated (applying one update instead of many to the same location), cancelled, or buffered while in transit. Lack of data-path-wide identification: Tracking sensitive data throughout the OS is complicated by the possible reuse of data structures, ID numbers, and memory addresses. Verification: Although verification is often overlooked by various solutions, we need to ensure that (1) secure deletions are correctly propagated throughout the storage data path, and (2) assumptions are checked when possible.

As a result, it is difficult to add secure-deletion functionality to the legacy storage data path in a backwards-compatible way. All of these legacy storage data path challenges must be overcome to achieve a successful, verifiable secure-deletion solution.

2.2. NAND Flash Secure Deletion

While the legacy storage data path imposes constraints on secure deletion, the emerging NAND flash, a promising replacement for hard disks, poses new challenges as well. NAND flash is a form of solid-state storage often used in devices such as netbooks, thumb drives, smart phones, cameras, etc. Unfortunately, most current secure-deletion solutions were developed for hard drives, and they do not work as expected on NAND flash. To illustrate, we first compare it with traditional hard drives.

Hard drives are a type of magnetic storage that accept read and write storage requests from the OS. Data is stored on spinning platters in units of sectors (typically 512 bytes) accessed by heads mounted on a mechanical arm. Writes can be performed in-place, in that a write to a logical sector will directly overwrite the same physical sector. Much secure-deletion software relies on this in-place overwriting property and attempts to securely erase information from the hard drive by overwriting the sensitive information directly with random bits (further discussed in Chapter 9). These solutions are rarely complete, but at least it is possible through the current hard drive interface to directly overwrite sensitive data and verify that it is overwritten. NAND flash is a type of memory storage. In addition to reads and writes, it also accepts erase requests. NAND has the following characteristics: (1) In-place updates are generally not allowed—once a location is written, the location must be erased before it can be written again; (2) NAND reads and writes are in flash pages (e.g., 2-8 Kbytes), but erasures are performed in flash blocks (e.g., 64-512 Kbytes consisting of contiguous pages); thus, before a written page can be written again, the flash block containing this page must be erased, and other in-use pages in the same flash block need to be copied elsewhere; (3) writing is slower than reading, and erasure can be more than an order of magnitude slower [9]; (4) each storage location can be erased only 10K-1M times [9]; and (5) many NAND flash drives have extra hidden physical locations that may hold additional information. For example, one paper found between 6% and 25% more physical flash storage than their advertised logical capacity [78]. These physical challenges are commonly solved through the addition of a flash translation layer (FTL). The FTL sits atop the raw NAND flash interface (either in hardware or in software). For backward compatibility, the FTL exports a hard drive interface that accepts only read and write requests. As a common optimization to mask slow writes and erases, when flash receives a request to overwrite a flash page, the FTL remaps the write to a pre-erased flash page, stamps the page (with a version number), and marks the old page as invalid,1 to be cleaned later during the garbage collection cycle. These invalid pages are not accessible to components above the block layer, but can be recovered by forensic techniques [38]. To prolong the lifespan of the flash, wear-leveling techniques are often used to spread the number of erasures evenly across all storage locations.

1 Flash overwrites might be allowed for some special cases such as marking a page invalid.

Suppose a typical hard-drive-oriented secure-deletion program issues overwrites to a file with random bits. A typical flash-management layer would avoid the slow erases and spread the usage of flash locations by writing the random bits to another pre-erased area (if possible). The old pages are marked invalid or dead, but the dead data persist until garbage collection time, if they are even erased at all! Additionally, the FTL does not export any interface commands to erase data selectively or search for information on invalid pages. Thus, through the FTL interface, it is impossible to erase specific locations or discern if selective sensitive data persist on the medium. Another unfortunate trend of FTLs is that they are mostly implemented in hardware, directly on the flash device controller. An implication is that most FTLs (and their wear- leveling/block-management routines) cannot be seen or accessed by the OS. To leave the door of software FTL research open, we need to create an environment that enables and eases experimentation, to demonstrate the benefits of software-level developments and controls.

2.3. Desirable Characteristics for Secure Deletion

Designing a secure-deletion solution requires an understanding of desirable secure deletion characteristics to overcome challenges of the legacy storage data path and storage media. Per-file: Fine grained secure deletion brings greater control to the user while potentially reducing costly secure-deletion operations on the storage device. Encryption-free: Encryption systems securely delete by destroying the keys of encrypted files. These systems are complex due to the need to manage per-file keys, provide efficient random access, data and metadata padding and alignments, etc. Regardless, systems that keep keys on storage or third-party sites still need a way to securely delete keys on different types of storage media. Passphrase- derived keys can be surrendered (e.g., via coercion) to retrieve deleted files. Further, encrypted data left behind can be potentially recovered as encryption techniques expire due to advances in computing power (e.g., quantum computing) and implementation bugs uncovered afterwards [10, 13]. Data-path-wide: Many secure-deletion solutions are within one layer of the legacy storage data path, and do not take the interactions of other storage layers

into account when performing secure deletion. This oversight can leak sensitive data. An ideal solution should have a unifying framework that is able to track secure-deletion information throughout layers of the storage data path. Storage-medium-agnostic: Many secure-deletion solutions are specific to a certain type of storage and rely on specific storage guarantees. For example, secure-deletion solutions that employ multiple overwrites will not work on top of flash storage, and solutions that depend on a flash file system may not work on top of hard drives. A secure-deletion framework should be generalizable to different types of storage media. Limited changes to the legacy code: Per-file secure deletion requires some information from the file system. However, getting such information should not involve modifying thousands of lines of legacy code. Metadata secure deletion: Secure deletion should also remove metadata, such as the file name, size, etc. Crash handling: A secure-deletion solution should allow for system crashes and provide meaningful semantics afterwards.

Table 2.3.1 summarizes how existing solutions fare with respect to the characteristics listed above. The boxes that are marked with ü indicate the solution meets the corresponding desired characteristic. The boxes that are marked with ? indicate the publication does not clearly explain whether it meets the corresponding characteristic. TrueErase is the only solution that meets all the listed positive characteristics. Also note that TrueErase is the only solution to meet the storage-medium-agnostic characteristic. More details about other existing solutions will be discussed in Chapter 7.

Table 2.3.1: Existing Secure-deletion Methods and Characteristics. Columns: F. per-file; E. encryption-free; D. data-path-wide; S. storage-medium-agnostic; L. limited changes to legacy code; M. securely delete metadata; C. handle crashes F E D S L M C Secure delete encrypted device/partition key [27, 29, 37, 57, 74] ü ü ü Specialized hard drive commands [26] ü ü ü ü Specialized flash medium commands (page granularity) [78] ü ü ü Stackable file system deletion [31, 32] ü ü ü ü ü Modified file system – deletion through overwriting [3, 31, 32] ü ü ü ü ü Modified file system – deletion through encryption [48] ü ? ? Dedicated server(s) for encryption keys [19, 46] ü ü ? ü Encrypted backup system [5] ü ü ? User-space solution on top of flash file system [52] ü ü ü ? Overwriting tools [37, 55, 56, 60, 79] ü ü ü Modified flash file systems – device erasures and/or overwriting [52, 71] ü ü ü ü ? ? Modified flash file systems – encryption with key erasure [36] ü ü ? ü ? Semantically-Smart Disk Systems [64, 65] ü ü ü ü ü Type-Safe Disks [62] ü ü ü ü Data Node Encrypted File System [51] ü ü ü ü ü ü TrueErase ü ü ü ü ü ü ü

CHAPTER THREE

TRUEERASE DESIGN

This chapter introduces TrueErase, a holistic framework that propagates file-level information to the block-level storage-management layer via an auxiliary communication channel, so that per- file secure deletion can be honored throughout the data path.

3.1. Design Guideline and Overview

TrueErase is designed with the following observations and formulated design guidelines:

1. Modifying the request ordering of the legacy data path is undesirable because it is difficult to verify the legacy semantics. Thus, the legacy data flow is left intact.

2. Per-file secure deletion is a performance optimization over securely deleting all files. Thus, we can default to handling deletion operations securely by default whenever tricky corner cases of deletion are encountered.

3. Persistent states complicate system design with mechanisms to survive reboots and crashes. Thus, this solution minimizes the use of persistent states.

Figure 3.1.1 shows TrueErase components and an overview of the design: User model: A user can use legacy attribute-setting tools to specify files and directories whose data and metadata will be securely deleted when they are removed at an unspecified future time. Unmodified legacy applications can operate on those objects. Type/attribute propagation (TAP) module: For coordinating across storage layers and allowing file systems to express secure deletion, the file-system layer can report information and reminders of pending update events (e.g., zeroing bitmaps) to a centralized TAP module. We use a global unique-ID scheme to

help TAP identify in-transit storage requests. To handle legacy optimizations, we applied the first design principle, so TAP only passively gathers and forwards information and does not alter the flow and ordering of update requests. We applied our second design principle to handle tricky optimization cases securely by default. To ease recovery, we applied the third design principle, so TAP tracks only transient soft states. Thus, TrueErase needs no mechanisms to recover its states from crashes. Extended block-layer interface: The block-layer interface is extended so that it can ask TAP about file-level information. It then passes this information to the enhanced storage-management layer so that it may choose specific methods of secure deletion. Enhanced storage-management layer: We have implemented secure-deletion commands for different storage media to show that our solution is general. Note that certain optimizations are disabled when handling secure-deletion operations (e.g., caches built into the storage device are disabled). Verification tools: We provide kernel- and user-level tools to detect illegal block type changes, incorrect triggering of deletion events, and missing reports from the file system. We also provide tools to verify core system states and transitions.

The remaining subsection will discuss each area of TrueErase’s design in detail.

3.2. User Model

A novice user may turn on secure deletion for the entire storage device. A slightly more sophisticated user can turn on secure deletion for all user-modifiable folders. An expert user can follow traditional permission semantics and apply common attribute-setting tools to mark a file or directory as sensitive, which means the sensitive file or all files under the sensitive directory will be securely deleted when removed. A legacy application can then issue normal deletion operations that will be carried out securely to remove sensitive file and directory data content, metadata, and associated copies within the storage data path. However, there are deviations from the traditional permission models.

Application

User Kernel

TAP Report File System Block #

Block # Query Storage Management Layer

Secure Deletion Commands

Storage Media

Figure 3.1.1: TrueErase Framework. Non-shaded boxes and solid lines represent the legacy storage data path. The shaded box and dotted lines represent our augmented data path.

3.2.1. Sensitive Status

Certain secure-deletion semantics cannot easily follow traditional permission models. For example, toggling the sensitive status is different from toggling read/write access controls. To illustrate, prior to a file or directory being marked sensitive, older versions of data and metadata may have already been flushed to storage. Without tracking all file versions or removing old versions for all files at all times, TrueErase enforces secure deletion only for files or directories that have stayed sensitive since their creation. Should a non-sensitive file be marked sensitive, secure deletion will be carried out on a best-effort basis. That is, only versions of metadata and file content after the file is marked sensitive will be guaranteed to be securely deleted.

3.2.2. Name Handling

Another semantic deviation occurs when securely deleting a file name. A directory is typically represented as a special file, with its data content storing the file names it holds. Although the

17 permissions of a file are applied to its data content, permission to handle its name is controlled by its parent directory (Figure 3.2.2.1).

Figure 3.2.2.1: Traditional Permissions

Figure 3.2.2.2: TrueErase Secure Deletion Sensitive Status Model

However, under TrueErase, the sensitive status of a file is applied to its name as well (Figure 3.2.2.2). Thus, marking a file sensitive will also cause some of its parent directory’s data content to be securely handled, even if the parent directory is not marked sensitive. If we were to not allow this, marking a file sensitive would require marking its parent directory as sensitive. Since the parent directory’s name also needs to be handled as sensitive, the grandparent’s directory also has to be marked as sensitive. Thus, the sensitive status of a file will bubble from its parent to the root directory, making every file marked sensitive due to the inheritance semantic and negating our per-file solution goal.

3.2.3. Links

Similar to legacy semantics, a secure deletion of a hard link is performed when the link count decreases to zero. Symbolic link names and associated metadata are not supported, but file data written to a symbolic link will be treated as sensitive if the link's target file is sensitive. To illustrate, suppose symbolic link L points to sensitive file A. Writing data to symbolic link L will cause TAP to successfully query file A’s inode for a sensitive status. The same thing happens when deleting data from symbolic link L. However, the symbolic link itself will not be treated as sensitive due to lack of status bits stored in the symbolic link.

3.3. The Type/Attribute Propagation Module

The centralized type/attribute propagation (TAP) module expands the legacy data-path interface between the file-system and storage-management layers in a backward-compatible way. This passive forwarding module receives information on pending sensitive updates from file systems. Pending updates are further divided into deletions, writes to data blocks, metadata, etc. Unique identifiers consisting of page generation IDs and sector numbers are introduced to associate file system operations with corresponding TAP tracking records.

3.3.1. Data Structures and Globally Unique IDs

All TAP tracking records directly correspond to normal write requests from the file system and are further divided into categories based on the file system event (e.g., update or deletion). The tracking records that correspond to block updates are called write entries, and the tracking records that correspond to deletions are called deletion reminders. Since data structures (e.g., block I/O structures), namespaces (e.g., i-node numbers), and memory addresses can be reused, correct pairing of write entries and deletion reminders require a unique ID scheme. In particular, the IDs need to be (1) accessible throughout the data path and (2) altered when its content association changes. TrueErase embeds a globally unique page ID in each memory page structure, which is accessible throughout the data path. The ID is set at page allocation time, so that the same page reallocated to hold versions of the same logical block has different IDs. We choose to put unique IDs in the page structures, as opposed to other more 19 transient data path structures such as requests, because the page is directly associated with the data or metadata content from the moment the content is created and stays directly associated with the content until the content is freed. Many different tracking granularities exist in the data path, such as logical blocks for file systems, concatenated requests, physical sectors, and device-specific units. TAP tracks by physical sector, because the physical sector is unique to the storage device and can be computed from anywhere in the storage data path. The globally unique page ID and the physical sector number obtained by TAP from lower layers form a global unique ID (GUID), which we can use to uniquely associate information stored in TAP tracking records with the smallest applicable secure-deletion unit in the storage data path. In addition to the GUID, TAP write entries can contain much more information about the update. At minimum, write entries must contain the update's type (e.g., i-node and data) and the security status (sensitive or not sensitive). TAP write entries also contain an optional link to a TAP deletion reminder, which contains a list of physical sector numbers of blocks to be deleted and a field to specify that the deletion operation should happen either before or after the sector is written.

Globally unique page ID } GUID Sector number Sensitive status Update type Link to deletion reminder (optional)

Figure 3.3.1.1: TAP Write Entry Fields

List of sectors to be deleted Deletion time flag (before or after)

Figure 3.3.1.2: TAP Deletion Reminder Fields

3.3.2. Event Reporting Interface

Through the TAP interface (Table 3.3.2.1), the file system must report all important events: file deletions and truncations, file updates, and certain journaling activities.

Table 3.3.2.1: The TAP Interface TE_report_write(GUID, block type, secure status): Creates or updates a TAP write entry associated with the GUID. TE_report_delete(metadata GUID, metadata block type, metadata secure status, deletion sector number): Creates or updates a TAP deletion reminder that contains the sector number. The reminder is attached to the write entry (created as needed) associated with the metadata GUID. TE_report_copy(source GUID, destination GUID, flag): Copies information from a write entry corresponding to the source GUID to a new entry corresponding to the destination GUID. The flag determines whether deletion reminders should be transferred. TE_cleanup_write(GUID): Removes the write entry with a specified GUID. This call also handles the case in which a file has already been created, written, and deleted before being flushed to storage. TE_check_info(GUID): Used to query TAP to retrieve information about a block layer write with a specific GUID.

File deletions and truncations: Data deletion traditionally occurs in the file system when certain bookkeeping metadata is updated (e.g., file size in the inode and free block bitmaps). TAP allows file systems to associate deletion events with metadata update events that signal deletion via TE_report_delete(). Within TAP, write entries are associated with respective deletion reminders and their deletion lists. Eventually, the file system flushes the metadata update that signals deletion. Once the storage-management layer receives a sector to write, the interface uses the GUID to look up information in TAP through TE_check_info(). If the associated write entry references a deletion reminder, the storage-management layer must securely delete those sectors on the deletion list before writing the metadata update.

After secure deletion has been performed and the metadata has been written to storage, the storage-management layer can call TE_cleanup_write() to remove the associated TAP write entry and deletion reminders. For metadata blocks that behave like data blocks (e.g., directory content), deletion handling is the same as that of data blocks.

File updates: Performing deletion operations is not enough to ensure all sensitive information is securely deleted. By the time a secure-deletion operation is issued for a file, versions of its blocks may have been created and stored (e.g., due to flash optimizations), and the current metadata may not have references to old versions. One approach is to track all versions, so that they can be deleted at secure-deletion time. However, tracking these versions requires persistent states and recovery mechanisms to allow those states to survive failures. TrueErase avoids persistent states by tracking and deleting old versions along the way. That is, secure deletion is applied for each update that intends to overwrite a sensitive block in place (secure write for short). Therefore, in addition to deletion operations, TrueErase needs to track all in-transit updates of sensitive blocks. The file system can report pending writes to TAP through TE_report_write(). Eventually, the storage-management layer will receive a sector to write and can then look up information via TE_check_info(). If the corresponding write entry states that the sector is sensitive, the storage-management layer will write it securely. Otherwise, it will be written normally. After the sector is written, the storage-management layer calls TE_cleanup_write() to remove the associated TAP write entry.

Journaling and other events: Sometimes file blocks are copied to other memory locations due to file system consistency, performance, and accessibility reasons (e.g., file-system journal and bounce buffers). When that happens, any write entries associated with the original memory location must be copied and associated with the new memory location. If there are associated deletion reminders, whether they are transferred to the new copy is file-system-specific. For example, in ext3, the deletion reminders are transferred to the memory copy in the case of

22 bounce buffers because the original write entry never gets written. Memory copies are reported to TAP through TE_report_copy().

Crash handling: TAP contains no persistent states and requires no additional recovery mechanisms. Persistent states stored as file-system attributes are protected by the file system journal-recovery mechanisms. At recovery time, a journal is replayed with all operations handled securely. We then securely delete the entire journal. To hunt down leftover sensitive data blocks, we sequentially delete sensitive blocks that are not marked as allocated by the file system for flash and disk [3].

3.4. Storage-management Layer Enhancements

TrueErase does not choose a secure-deletion mechanism until a storage request has reached the storage-management layer. By doing so, TrueErase ensures that the chosen mechanism matches the characteristics of the underlying storage medium. In addition, TrueErase can further carry out different secure-deletion methods in accordance with different requirements and government regulations [43, 69]. TrueErase is applied to both NAND flash storage and hard drives to illustrate the flexibility of the framework.

3.4.1. NAND Flash

In addition to the exported read(page_number) and write(page_number) interface commands, we added two secure-deletion commands to the storage-management layer (i.e., FTL) for NAND flash.

Secure_delete(page numbers): This call copies other in-use pages from the current flash block to other areas, and marks them as unused in the flash block. The specified pages then can be marked invalid, and the current flash block is then cleared via a flash erase command.

Secure_write(page numbers, data): Generally, writing to the same logical page would result in a new physical page being allocated and written, with the physical page holding old data versions marked invalid. This call, on the other hand, will securely delete those invalid pages with Secure_delete() while allowing the current write to be written to a fresh flash page.

We choose this type of secure-deleting flash behavior instead of zero-overwriting or scrubbing [52, 71, 78] for ease of implementation and portability. These techniques rewrite an entire chunk of flash memory to zeros as a way to securely delete selective information without having to erase the entire erase block. The authors in [52] warn that zero-overwritting could leak information through advanced forensic techniques, specifically in determining the time in which particular gates were set to zero. Authors in [78] warn that scrubbing may violate some NAND flash behaviors specified by datasheets and may alter flash pages adjacent to the page that is being overwritten. Thus, zero-overwriting or scrubbing is not entirely portable, but it may provide better performance on compatible chips with workloads that favor single page secure deletions. When a NAND flash device driver runs low on space, it triggers wear leveling to compact in-use pages into fewer flash blocks. However, this internal storage reorganization does not consult with higher layers and has no knowledge of file boundaries, sensitive status, etc. Thus, in addition to storing a file’s sensitive status in the extended attribute, we found it necessary to store a sensitive-status bit in the control area stored on each flash page. (This area also contains a page’s in-use status.) With this bit, when a sensitive page is migrated to a different block, the old block is erased via Secure_delete(). Since flash drivers migrate in-use pages from to-be-erased blocks by copying those pages elsewhere before erasing the old versions, some sensitive pages may have duplicates during a crash. Given that the secure deletion of the page did not complete, the common journal crash- recovery mechanism will reissue the operation, so that other remaining in-use pages in the same flash block can continue the migration, and the block can then be erased.

3.4.2. Hard Drive

The hard drive interface allows reads and writes to its magnetic storage. Fortunately, hard drives allow in-place overwrites; therefore, we do not need to expand the hard drive interface. Instead, we can use the pre-existing hard drive interface to achieve secure deletion by adding secure-delete and -write functionality in a high-level software driver. This functionality is summarized in the function calls described below.

Secure_delete(sector numbers): This function call will overwrite the sectors specified by sector numbers in-place with random data. This functionality is implemented using regular hard drive write operations.

Secure_write(sector numbers, data): This function call will first overwrite the sectors specified by sector numbers with random bits before writing data. Again, this functionality is implemented using regular hard drive write operations.

The number of random-bit overwrites in each case is configurable. For further information on the number of recommended overwrites and data remanence issues, see Chapter 9. Hard drives still do not know about secure writes or deletions. We must create logic to query the TAP module and translate information gathered about secure writes and secure deletions into multiple random overwrite commands. To avoid modifying every low-level hard disk device driver, we can place these commands in a high-level software layer above the low- level hard drive drivers. Such a layer already exists to implement logical volume management and software RAID systems.

3.5. Other Design Points

Consolidation of requests: Consolidation (or buffering) of requests cannot be allowed in certain circumstances (e.g., consolidations of overwrites on storage). In this case, TrueErase needs to disable storage-built-in write caches or use barriers and device-specific flush calls to ensure that

25 persistent updates are achieved [44]. When consolidation is permitted (such as in the page cache or journal), TrueErase interprets an update’s sensitive status during consolidation conservatively. As long as one of the updates to a given location is sensitive, the resulting update will be sensitive.

Dynamic sensitive-mode changes for in-transit blocks: To simplify tracking of a block’s sensitive status, TrueErase allows a non-sensitive in-transit file or directory to be marked sensitive, but a sensitive object is not allowed to be marked non-sensitive.

Shared block security status: A metadata block often stores metadata for many files, likely with mixed sensitive status. Thus, updating non-sensitive metadata may also cause the sensitive metadata stored on the same block to appear in the storage data path. TrueErase simplifies the handling of this case by treating a shared metadata block as sensitive as long as one of its metadata entries is sensitive.

Partial secure deletion of a metadata sector: Securely deleting a file’s metadata only at the storage level is insufficient, as a metadata block shared by many files may still linger in the memory containing the sensitive metadata. If the block is written again, the metadata thought to be securely deleted will return to storage. In these cases, TrueErase zeros out the sensitive metadata within the block in memory, and then updates the metadata as a sensitive write.

3.6. File System Consistency Properties

The correctness of our framework cannot be guaranteed if it can interact with file systems that exhibit arbitrary behaviors. Therefore, we applied the consistency properties of file systems defined by [63] to enumerate corner cases. (These properties rule out ext2 and FAT, which are prone to inconsistencies due to crashes.) By working with file systems that adhere to these properties, we can simplify corner-case handling and verify our framework systematically.

In a grossly simplified sense, as long as pieces of file metadata reference the correct data and metadata versions throughout the storage data path, the system is considered consistent. In particular, we are interested in three properties in [63]. The first two are for non-journaling- based file systems. In a file system that does not maintain both properties, a non-sensitive file may end up with data blocks from a sensitive file after a crash recovery. The last one is needed for journaling-based file systems.

The reuse-ordering property ensures that once a file’s block is freed, the block will not be reused by another file before its free status becomes persistent. Otherwise, a crash may lead to a file’s metadata pointing to the wrong file’s content. Thus, before the free status of a block becomes persistent, the block will not be reused by another file or changed into a different block type. With this property, we do not need to worry about the possibility of dynamic file ownership and types (e.g. data or metadata) for in-transit blocks.

The pointer-ordering property ensures that a referenced data block in memory will become persistent before the metadata block in memory that references the data block. With this ordering reversed, a system crash could cause the persistent metadata block to point to a persistent data block location not yet written. This property does not specify the fate of updated data blocks in memory once references to the blocks are removed. However, the legacy memory page cache prohibits unreferenced data blocks from being written. The pointer-ordering property further indicates that right after a newly allocated sensitive data block becomes persistent, a crash at this point may result in the block being unreferenced by its file. To cover this case, we will perform secure deletion on unreferenced sensitive blocks at recovery time.

The non-rollback property ensures that older data or metadata versions will not overwrite newer versions persistently—important for journaling file systems with multiple versions of requests in transit. That is, we do not need to worry that an update to a block and its subsequent secure deletion will arrive at the persistent storage in the wrong order.

With these consistency properties, we can identify the structure of secure-deletion cases and handle them by: (1) ensuring that a secure deletion occurs before a block is persistently declared free, (2) the dual case of hunting down the persistent sensitive blocks left behind after a crash but before they are persistently referenced by file-system metadata, (3) making sure that secure deletion is not applied (in a sense, too late) to the wrong file, (4) the dual case of making sure that a secure block deletion is not performed too early and gets overwritten by a buffer update from a deleted file, and (5) handling in-transit versions of a storage request (mode changing, reordering, consolidation, merging, and splitting). Buffering, asynchrony, and cancelling of requests are handled by TAP.

CHAPTER FOUR

TRUEERASE IMPLEMENTATION

The TrueErase framework was prototyped under Linux 2.6.25.6. We applied our framework to the popular ext3 journaling file system version 1.41.3 (as reported by mkfs.ext3) due to its adherence to file-system-consistency properties [63]. Because raw flash devices and their development environments were not widely available when the research began, we used SanDisk’s DiskOnChip [54] flash and the associated Inverse NAND File Translation Layer (INFTL) kernel module as our FTL. Although DiskOnChip is somewhat dated, our design is applicable to modern flash and development environments. As future work, we will explore newer environments, such as OpenSSD [73]. We also implement TrueErase on a traditional hard drive. Overall, our user model required 198 lines of C code; TAP, 939; secure-deletion commands for flash, 592; secure-deletion commands for hard drive, 378; a user-level development environment for kernel code, 1,831; and a verification framework, 8,578. This chapter discusses the TrueErase implementation concerning the user model, file system interactions with the TAP module, and the extended storage-management layer for secure deletion commands.

4.1. User Model

A user can execute the legacy commands in Table 4.1.1 to modify the secure-deletion attribute on a file or directory. However, by the time a user can set attributes on a file, the file’s name may already be stored as non-sensitive. The problem is that the actions of creating a file and setting the file’s sensitive attribute are not performed together in an atomic way. One solution is to modify the creat() and mkdir() system calls to take a flag to specify the sensitive status. However, to make these changes accessible to end users, we need to further modify user programs to make use of our new flag.

Table 4.1.1: Legacy Secure-deletion Attribute Commands Command Synopsis chattr +s name Sets sensitive bit for file or directory specified by name. chattr –s name Removes sensitive bit for file or directory specified by name. lsattr name Lists the file attributes for file or directory specified by name.

Instead, without modifying the OS, we provide end users a set of wrapper scripts, each (1) creates an empty file or directory with a pseudo name, (2) marks it sensitive, and (3) renames it to the sensitive name. We name these scripts smkdir and screat, which create secure directories and files, respectively. The file or directory will be treated as sensitive after it is marked as sensitive, so these scripts may allow an untracked flush to storage of the pseudo name and the corresponding i-node linked to the pseudo name that contains information about the file or directory (i.e., size of zero bytes, ownership, and creation time). Unmodified legacy programs can make use the attribute inheritance semantic to enable secure deletion. Thus, a user can mark a directory to be used by a legacy program as sensitive. Once a directory is sensitive, any files or directories created under the sensitive directory will inherit the sensitive attribute automatically and be created as sensitive in an atomic fashion.

4.2. File System Interactions with TAP

TAP is implemented as a kernel module. This chapter gives a brief background on ext3 to clarify its interactions with TAP. Next, we discuss the TAP deployment model with ext3.

4.2.1. File System Background

We first give background on ext3 and its corresponding journaling block device (jbd). Ext3 is a popular journaling file system based on the non-journaling ext2. It was first merged into the mainline Linux kernel in November 2001 [1] and was used as the default file system on popular Linux distributions such as Debian and Fedora until 2011. Ext3 performs journaling by sending pending blocks to be written to the jbd module. The jbd module controls when and how blocks are written to the storage device. 30

File truncation/deletion under ext3: Ext3 deletes the data content of a file via its truncate function, which involves updating (t1) the i-node to set the file size to zero, (t2) metadata blocks to remove pointers to data blocks, and (t3) the bitmap allocation blocks to indicate the availability of blocks for reuse. Multiple rounds of truncates may be required to delete the content of a large file. Deleting a file involves: removing the name and i-node reference from the directory, adding the removed i-node to an orphan list; truncating the entire file via (t1) to (t3); removing the i-node from the orphan list; and updating the i-node map to free the i-node.

Journaling: Typical journaling employs the notion of a transaction, so the effect of an entire group of updates is either all or nothing. With group-commit semantics, the exact ordering of updates within a transaction (e.g., an update to an i-node allocation bitmap block) may be relaxed while preserving correctness, even in the face of crashes. To achieve this effect, all writes within a transaction are (j1) journaled or committed to storage persistently (commit stage); then (j2) propagated to their final storage destinations (checkpoint stage), after which (j3) they can be discarded from the journal. A committed transaction is considered permanent even before its propagation. Thus, once a block is committed to be free, it can be used by another file. At recovery time, committed transactions in the journal are replayed to re-propagate or continue propagating the changes to their final destinations. Uncommitted transactions are aborted.

Jbd: Jbd differentiates data and metadata. We chose the commonly used ordered mode, which journals only metadata but requires data blocks to be propagated to their final destination before the corresponding metadata blocks are committed to the journal.

4.2.2. Deployment Model

All truncation, file deletion, and journaling operations can be expressed and performed as secure writes and deletions to data and metadata blocks. The resulting deployment model and its applicability are similar to those of a journaling layer. We inserted around 60 TAP-reporting calls in ext3 and jbd, with most collocated with block-layer interface write submission functions and dirty functions (e.g., ext3_journal_dirty_data).

Applicable block types: Secure writes and deletions are performed for sensitive data blocks, i- node blocks, extended-attribute blocks, indirect blocks, directory blocks, and corresponding structures written to the journal. Remaining metadata blocks (e.g., superblocks) are frequently updated and shared among files (e.g., bitmaps) and do not contain significant information about files. By not treating these blocks as sensitive, we reduce the number of secure-deletion operations.

Secure data updates (Figure 4.2.2.1): Ext3/jbd calls TE_report_write() on sensitive data block updates, and TAP creates per-sector write entries. Updates to the TAP write entries with the same GUIDs are consolidated; this behavior reflects that of the page cache. The data update eventually reaches the storage-management layer (via commit), which retrieves the sensitive status via TE_check_info(). The layer can then perform the secure-write operation instead of the original write operation and invoke TE_cleanup_write() to remove the corresponding write entries.

block/storage- ext3/VFS jbd TAP mgmt layer journal final

write(D) TE_report_write(D) commit(D) (j1) TE_check_info(D) TE_secure_write(D) TE_cleanup_write(D)

Figure 4.2.2.1: Secure Data Updates. D is the data block in stages of being securely written. Dotted arrows show additional TrueErase calls being invoked to achieve secure data updates.

Secure metadata updates (Figure 4.2.2.2): A metadata block is journaled by jbd in ordered mode. Thus, in addition to writing it securely to its final storage destination, it must be securely written to and deleted from the journal.

Ext3/jbd also reports metadata updates to TAP via TE_report_write(). Repeated updates to the same metadata entries will lead to updates to TAP write entries with matching GUIDs. To commit a transaction, jbd calls TE_report_copy() to clone write entries and their sensitive status, with request destinations altered from final storage destinations to persistent journal locations. When the storage-management layer receives the journal update request via a journal commit, it performs checking, invokes the secure-write method, and cleans up the cloned journal write entries via TE_cleanup_write(), such as shown in the (j1) phase of Figure 4.2.2.2. The original write entries remain until they are propagated to their final storage destinations via a journal checkpoint. The storage-management layer performs checking, securely writes the metadata to the final destination, and cleans up the corresponding write entries, as shown in the (j2) phase of Figure 4.2.2.2. Jbd tracks in-use persistent journal locations through its own superblock. Periodically (or explicitly through an unmount), jbd checks the in-use status of journal locations in its log via cleanup_journal_tail(). If some of its log is no longer needed, it updates its superblock allocation pointers accordingly. We leverage this function to report journal locations no longer in use to TAP. If any of the locations match our previous sensitive metadata write entries, we securely delete the location after the updated journal superblock is written, as shown in phase (j3) of Figure 4.2.2.2. In the case of a crash, at file-system recovery time, we securely delete all journal locations through TE_report_delete() once all committed updates have been securely applied (not shown in the figure).

Secure data deletions (Figure 4.2.2.3): When deleting sensitive file content, ext3’s truncate function informs TAP of the deletion list and associated file i-node via TE_report_delete(). Given the transactional semantics of a journal, we can associate the content-deletion event with the file’s i-node update event instead of the free block bitmap update event. Thus, we securely delete data before step (t1). TAP will create and pair the i-node write entry with the corresponding secure-deletion reminder to hold the deletion list. When the write entry is copied via TE_report_copy(), reminders are transferred to the journal copy to ensure that secure deletions are applied to the matching instance of the i-node update. When the storage-management layer receives the request to commit the update of the sensitive i-node to the journal, the interface calls TE_check_info() and retrieves the sensitive 33 status of the i-node, along with the deletion list. The data areas are then securely deleted before the i-node update is securely written to the journal on storage.

block/storage- ext3/VFS jbd TAPmgmt layer journal final

write(M) TE_report_write(M)

TE_report_copy(MJ) (j1) commit(MJ) TE_check_info(MJ) TE_secure_write(MJ)

TE_cleanup_write(MJ) ~ ~ checkpoint(M) TE_check_info(M) (j2) TE_secure_write(M) TE_cleanup_write(M) ~ cleanup_journal_~tail(MJ, SJ) TE_report_delete(MJ, SJ) (j3) TE_check_info(SJ) write(SJ) TE_secure_delete(MJ)

Figure 4.2.2.2. Secure Metadata Updates. M is the reported metadata block; MJ is the reported metadata journal block; and SJ is the reported journal superblock. Dotted arrows show additional TrueErase calls being invoked to achieve secure metadata updates.

block/storage- ext3/VFS jbd TAP mgmt layer journal final

truncate(D, M) TE_report_delete(D, M)

TE_report_copy (MJ) commit(D, MJ) (j1) TE_check_info(MJ) TE_secure_delete(D) TE_secure_write(MJ)

TE_cleanup_write(D, MJ) ~

Figure 4.2.2.3: Secure Data Deletion. M is the updated metadata block; D is the data block in various stages of secure deletion; MJ is the metadata journal block that corresponds to the updated metadata block M. Dotted arrows show our augmented data path. Events (j2) and (j3) from Figure 4.2.2.2 occur at the end of this diagram concerning the secure update of metadata M.

Secure metadata deletions: During a file truncation or deletion, ext3 also deallocates extended attribute block(s) and indirect block(s). Those blocks are attached to the i-node’s list of secure- deletion reminders as well. To securely delete an i-node or a file name in a directory, the block containing the entry is securely updated and reported via TE_report_write(). Additionally, we zero out the i-node and variable-length file name in the in-memory copies, so that they will not negate the secure write performed at the storage-management layer. If a directory is deleted, its content blocks will be deleted in the same way as the content from a file.

Miscellaneous cases: Committed transactions might not be propagated instantly to their final locations. Across committed transactions, the same metadata entry (e.g., i-node) might have changed file ownership and sensitive status. Thus, jbd may consolidate, say, a non-sensitive

35 update 1, sensitive update 2, and non-sensitive update 3 to the same location into a non-sensitive update. As a remedy, once a write entry is marked sensitive, it remains sensitive until securely written.

4.3. Extended Storage-management Layer

This subsection discusses the implementation of secure-deletion commands in the storage- management layer for both DiskOnChip NAND flash and a traditional hard drive.

4.3.1. Extended Flash Device Interface

The flash-specific device drivers are contained and abstracted in the memory technology device (MTD) subsystem for Linux [40]. The MTD subsystem provides a unifying layer for management of flash devices, high-level drivers (such as FTLs), and low-level drivers (such as the generic NAND driver base and hardware-specific drivers). As part of the TrueErase framework, the software management layer must query the TAP module for secure-deletion information and carry out secure-deletion commands. Figure 4.3.1.1 shows a more detailed view of how this occurs for flash devices. The MTD subsystem contains a module that acts as a block-layer interface for MTD devices that use an FTL. In other words, this MTD block-layer interface exports a traditional hard-drive interface to the operating system and calls FTL-specific commands to handle the operating-system read and write requests. The FTL then handles these read and write requests through flash-specific commands (e.g., read pages, write pages) as well as flash-specific management commands (e.g., erase block). We extended the MTD block-layer interface module to (1) query TAP for secure-deletion information and (2) send secure-deletion commands to the FTL. The first modification was relatively easy, as we TE_check_info() followed by TE_cleanup_write() calls in the function that submits sector writes to the FTL. However, issuing flash secure-deletion commands to the FTL is more difficult, as the FTL interface only accepts traditional reads and writes. Instead, we need to tell the flash via the FTL to erase explicitly. Thus we expanded the FTL interface in the MTD block-layer interface module to accept secure_write() and secure_delete() commands. Figure

4.3.1.1 shows the storage data path flash-specific interactions with the TAP module and secure- deletion commands. We discuss how the FTL manages the secure-deletion commands in the next subsection.

TAP Report File System Block # Storage Block # Query Management Layer MTD Block Interface

Secure Deletion Commands

FTL and Flash Drivers

Storage Media

Figure 4.3.1.1: Flash-specific Interactions with TAP and Secure-deletion Commands

4.3.2. INFTL Background

To understand how we implement secure-deletion commands in an FTL, we first give background of Linux FTLs and demonstrate how a particular FTL works. Linux has four FTLs available inside the operating system through the MTD subsystem [40]. These FTLs are kernel modules that include: FTL, the NAND File Translation Layer (NFTL) [2, 59], INFTL, and mtdblock. The FTL module was designed primarily for NOR flash, and the mtdblock module is a very simple FTL that exports a block interface and contains no wear leveling. NFTL and INFTL were designed for San Disk’s (formerly M-System’s) DiskOnChip NAND flash. We used the INFTL module since it improves the earlier NFTL module and makes use of NAND-specific attributes. While our implementation focuses on one FTL and flash chip, the general semantics may be ported to others.

INFTL uses a stack-based algorithm to remap logical pages to physical ones. In addition, it uses block-level translation, where each flash block size is 16 KB, containing 32 512-byte pages, with 16 bytes of control area per page. During a read or write operation, a virtual flash block number can be computed by taking the incoming disk sector number and applying equation (4.3.2.1):

(ൌ H X (4.3.2.1 ݎݐݑ݈ܾ݈ܽ݋ܿ݇݊ݑܾ݉݁ݎݒ݅ ϐ ൊ ϐ

Similarly, given a sector number, the page number in the virtual flash block can be computed with equation (4.3.2.2):

( ൊ ϐሻ (4.3.2.2 Ψሺϐ ൌ ݎ݌ܽ݃݁݊ݑܾ݉݁

INFTL writes: Conceptually, INFTL uses a stack of flash blocks to provide the illusion of in- place updates. For example, during the first write to a virtual flash block, a physical flash block is allocated, and the virtual block number is stored in the control area of the physical block. This physical block is now at the top of the stack pertaining to that virtual block number. Now suppose an in-place write occurs to the same offset in the same virtual block. This write will occur in a newly allocated physical block, and this new physical block becomes the new top of the stack pertaining to the virtual block number. The virtual block number is written to the new physical block’s control area, as well as a pointer to the previous top of the stack. Figure 4.3.2.1 demonstrates in-place updates and writes in INFTL. Consider a flash device with three pages per block. Further, suppose we write “A” to disk sector 4. This means that we will write to the second page of virtual flash block 1 (Figure 4.3.2.1(a)). Next, suppose we write “B” to sector 4. Since the second page of virtual block 1 has already been written, we must write to the second page of a newly allocated, erased physical block, make the new block the top of the stack, and add a pointer to the old block underneath. The second page of the old block is also marked as invalid in the control area, and this is indicated with an “X” over the page (Figure 4.3.2.1(b)). Now suppose we write “C” to sector 3, or page 0 of virtual block 1.

Since the page is free in the block on the top of the stack, we are free to write “C” in-place. (Figure 4.3.2.1(c)).

(a) (b) (c)

Virtual Virtual Virtual Block #1 Block #1 Block #1 0 1 2 0 1 2 0 1 2 Top of A Top of B Top of C B Stack Stack Stack

0 1 2 0 1 2 A A

Figure 4.3.2.1: Updates in INFTL

Depending on the implementation, a virtual block stack may continue to grow without bounds until the flash device starts to become full. At that point, the stack of blocks will be consolidated into one block containing only the latest updates to free up space for garbage collection.

INFTL reads: INFTL sequentially searches stacks of blocks for data to read, starting from the top of the stack and moving to the bottom, and the first valid data page encountered is returned. If the first valid data page encountered is deleted or no data is found at all, all 0s will be returned. Figure 4.3.2.2 demonstrates reads in INFTL. Consider a flash device with three pages per block. Further consider that we want to read a sector from virtual flash block 1. We first read page 0 in the block on the top of the stack. If data is found, we return with the found data (Figure 4.3.2.2(a)). Suppose instead that we wish to read page 1 in the block, and the first instance of the second page that we encounter is marked as invalid (deleted) in its control area. This means that the page was recently marked as deleted, and we return with all 0s (Figure 4.3.2.2(b)). Alternatively, suppose the page we read is empty (e.g., page 2). We continue down the stack one block at a time, searching for either a page with data or a page marked as invalid. If we find nothing but empty pages when we have hit the bottom of the stack, then there was nothing to read. We then return with 0s (Figure 4.3.2.2(c)).

Virtual b) Deleted, Block #1 data, stop here

0 1 2 c) No data, a) Found B B data, stop here keep searching ... c) End of stack, NULL no data found

(a) data exists, (b) data deleted, (c) data not found

Figure 4.3.2.2: Reads in INFTL

4.3.3. INFTL Extensions

We extend INFTL to implement secure_write() and secure_delete() commands.

Secure write: As discussed in Chapter 3, secure-write semantics combine a write and secure deletion when an overwrite occurs. In INFTL, this means to set the maximum depth of any virtual block stack to 1, where 0 is the top of the stack. Once the maximum depth is met, the stack must be consolidated to depth 0. For an example of this behavior, see Figure 4.3.3.1. Suppose a virtual block originally consists of a stack of one page (see Figure 4.3.3.1(a)). Now suppose a page consisting of data “A” is overwritten with data “B”. We now have a stack depth of 1 (see Figure 4.3.3.1(b)). We now consolidate the virtual block stack to copy the valid pages further down in the stack onto the top block. All blocks that were lower than the top of the stack are then erased before the call returns (see Figure 4.3.3.1(c)).

Secure deletion: We can modify INFTL so that secure deletion is a special case of secure overwrite. When pages are to be securely erased, a new physical block is placed on top of the stack. All the valid data pages, minus the data page to be erased, are copied to the new physical block. Afterwards, the old physical block is erased, thereby consolidating the stack to a depth of 0.

(a) (b) (c)

Virtual Virtual Virtual Block #1 Block #1 Block #1 0 1 2 0 1 2 0 1 2 Top of K A J Top of B Top of K B J Stack Stack Stack

0 1 2 K A J

Figure 4.3.3.1: INFTL Secure-write Operation

Optimizations: For performance improvement, we implemented optimizations concerning the DiskOnChip flash and INFTL. Logical block alignment: We aligned the flash block boundaries of the data partition of the DiskOnChip with logical file system block boundaries. These boundaries were not aligned by default. When unaligned, the worst case scenario is that a single logical block write from the file system would straddle two flash erase blocks and cause both flash erase blocks to be updated. We implemented the alignment by changing the start of the DiskOnChip data partition to be on a logical block boundary. This optimization is not TrueErase-dependent, so we perform logical block alignment on all kernels in the evaluation chapter. Consolidated flash-block erasure: Deletion reminders tend to contain lists of locations to secure delete with a high spatial locality. Unfortunately, our initial implementation only performed single-page secure deletions on flash blocks, which meant that a single flash block could incur multiple erasures per processing of a single deletion reminder. We implemented an optimization that groups locations on a delete reminder list by flash block, and we use this information to securely delete multiple flash pages on a flash block with only one round of migration for other in-use pages. Delayed deletion: Since the existing INFTL stack algorithm already tracks old versions, we implemented the delayed-deletion optimization, which allows data

blocks to defer the secure-write consolidation to file deletion time. Basically, the maximum depth is no longer bounded. We explore the advantages of the delayed- deletion mode later during evaluation in Chapter 6. Delaying secure deletion for metadata is trickier and will be investigated in future work.

For correctness, because jbd does not allow reordering to violate file system constraints and our flash has no built-in cache, these optimizations have no effect on our experiments.

4.3.4. Hard-drive Extensions

The Linux device-mapper layer exists in the storage-management layer and serves the function of mapping (or stacking) a logical block device on top of one or more physical devices. File systems may be directly mounted on the exported logical device. Many block device abstractions are implemented in this layer, including the Linux Logical Volume Manager (LVM) that creates logical volumes across multiple disks, the Linux software implementation of Redundant Array of Independent Disks (RAID) that creates disk redundancy, and dm-crypt, which encrypts and decrypts read and write requests to disks, respectively. Figure 4.3.4.1 shows the location of the device mapper layer in relation to the rest of the legacy storage data path.

TAP Report File System Block # Storage Block # Management Layer Query Device Mapper Layer

Secure Deletion Commands

Block Device and Drivers

Storage Media

Figure 4.3.4.1: Hard-drive-specific Interactions with TAP and Secure-deletion Commands

Implementing a TrueErase hard-drive abstraction in this layer is advantageous because any device-mapper abstraction can be stacked on top of any other block device, regardless of low- level driver need (e.g., SATA, SCSI, etc.). In addition, a simple device mapper target called linear exists in this layer that maps a linear range of sectors onto a physical device. We base our TrueErase hard drive abstraction off the linear target and name it the TrueErase Device Mapper, or dm-te for short. The dm-te abstraction must (1) query TAP for secure-deletion information related to a sector it receives for writing and (2) perform possible secure-deletion operations (including secure write and secure delete). We placed TE_check_info() and TE_cleanup_write() calls inside the device-mapper “map” function, which inspects pending block I/O structures (block reads and writes) from the file system. The map function can also optionally “remap” pending block I/O structures to new locations, although we do not take advantage of the remapping feature. In addition, the map function also allows us to create additional block I/O structures and send them down to the data path towards the physical block device. Our research group utilized this functionality to create additional write block I/O structures filled with random data to overwrite sensitive areas in-place on the physical block device.

Secure delete: This functionality is called when TE_check_info() indicates a list of sectors must be securely deleted either before or after the current pending metadata block I/O is processed. Suppose TE_check_info() indicates that the secure deletion must be processed before the current pending block I/O. We first create a list of new, randomly-filled block I/O structures addressed to the sectors to be securely deleted and send it down to the physical block device. Following this list, we create and submit a barrier block I/O, which (1) ensures block I/Os will not be reordered across the barrier in the Linux disk scheduler and (2) flushes the on-disk cache for disks that support barrier requests. This procedure of sending a list of erase-block I/Os and barrier is repeated for the desired number of secure-deletion overwrites. Finally, we send the current pending metadata block I/O to the physical block device and call TE_cleanup_write(). Figure 4.3.4.2 gives examples of secure delete processing.

(a) Secure delete before processing pending (b) Secure delete after processing pending write write 1 Call TE_check_info() on pending write Call TE_check_info() on pending write 2 Create list of deletion block I/Os and send to Send pending metadata write block I/O to physical block device physical block device 3 Send barrier block I/O to physical block Create list of deletion block I/Os and send to device physical block device 4 Repeat steps 2-3 for additional overwrites Send barrier block I/O to physical block device 5 Send pending metadata write block I/O to Repeat steps 3-4 for additional overwrites physical block device 6 Call TE_cleanup_write() Call TE_cleanup_write() Figure 4.3.4.2: Hard-drive Secure-deletion Processing

Secure write: The goal of this functionality is to securely overwrite the sectors to be written with random data a specified number of times before performing the pending data or metadata write to help protect against certain types of data remanence attacks (see Chapter 9 for further information). Suppose TE_check_info() indicates the current pending block I/O must be securely written. We first create a block I/O structure filled with random bits directed to the pending block I/O sector address and send it down to the physical block device. We then must follow that submission by creating and submitting a barrier block I/O for reasons stated in the secure- deletion case. This procedure of processing the block I/O filled with random bits and barrier block I/O structure can be repeated for a desired number of overwrites. Finally, we send the current pending block I/O to the physical block device and call TE_cleanup_write(). Figure 4.3.4.3 demonstrates the secure write processing.

Secure write 1 Call TE_check_info() on pending write 2 Create secure write block I/O and send to physical block device 3 Send barrier block I/O to physical block device 4 Repeat steps 2-3 for additional overwrites 5 Send pending write block I/O to physical block device 6 Call TE_cleanup_write() Figure 4.3.4.3: Hard-drive Secure-write Processing

Secure-write optimizations: If the user determines that a single hard-drive overwrite is sufficient to securely erase the previously written information, repeated secure overwrites may be omitted. We chose to default to this case.

4.4. Development Tools

In addition to the implementation of the TrueErase framework, we also found the need to implement additional components to assist us with debugging and performance measurements. In this subsection, we discuss the implementation of a lightweight kernel flash monitor and a user-space flash development environment.

4.4.1. Lightweight Kernel Flash Monitor

Performance and wear in flash is directly related to the number of write and erase flash operations that occur. Tracking these operations can help us understand amplification effects of certain requests, optimize our secure-deletion commands, and extrapolate our evaluation results to other flash chips. To help us obtain these numbers, we implemented a lightweight kernel flash monitor inside INFTL to tabulate the number of flash operations that occur. Specifically, we tabulate the following NAND flash operations: page reads

page writes control page reads control page writes block erasures

In addition, we monitored the number of reads and writes issued to the INFTL from the MTD block-layer interface for amplification effects, the number of INFTL stack consolidations, and the number of out-of-room stack consolidations which indicate when the INFTL is out of pre- erased blocks and must start wear-leveling to regain room. We implemented this monitor through a lightweight library compiled into INFTL with functions that increment simple counters. We also implement functions to dump and reset the tabulations that are reachable from user-space through the Linux proc file interface.

4.4.2. User-space Flash Development Environment

Development and debugging inside the Linux kernel is more difficult than in user-space due to error handling (e.g, kernel OOPS) and lack of comprehensive debugging utilities. In addition, needlessly subjecting the NAND flash chip to debugging and regression testing can drastically shorten the life of the chip. This is especially important when working with hard-to-find chips. In answer to these problems, our research group designed and implemented a user-space flash development simulator. This simulator allows us to move the kernel MTD block-layer interface and FTL code into user space with little modification. We can then code and test secure-deletion modifications to those modules using direct kernel functions (e.g., kmalloc), yet also debug the modifications using common user-space debugging tools. Once the modifications pass regression testing, we can move the modifications back into the kernel. As shown in Figure 4.4.2.1, a block-device simulator module is necessary to take read and write requests issued from the file system and pass them back up to user space, where they are received by the user-space flash development simulator. Specifically, the read and write requests are processed by the user-space MTD block-layer interface, which was modified to receive these requests from the kernel proc interface. This modified MTD block-layer interface can make TAP query calls through the kernel proc interface to the TAP module and issue secure-

46 deletion commands to INFTL, also in user space. The INFTL makes flash operations on the connected backing store, which is actually a file. The implementation of a file backing store encourages the use of flash-state snapshots.

Flash File Backing Development Store Simulator

FTL

Secure Deletion Commands Modified MTD Block Application Interface

Query User Kernel Report TAP File System Block #

Block # Block Device Simulator

Figure 4.4.2.1: User-space Flash Development Environment

In addition to the advantages listed above, this user-space flash development simulator also saved traces of read and write requests received at the MTD block-layer interface and associated secure deletion operations. We found observing the ordering of operations useful in designing and debugging TrueErase. Appendix A demonstrates secure file-system operations through the use of traces gathered with this simulator.

CHAPTER FIVE

VERIFICATION

We (1) tested the basic cases, assumptions, and corner cases discussed in Chapter subsection 3.5 and (2) verified the state space of the TAP module.

5.1. Basic Cases

Sanity checks: We verified common cases of secure writes and deletes for empty, small, and large files and directories using random file names and sector-aligned content. After deletion, we scanned the raw storage and found no remnants of the sensitive information. We also traced common behaviors involving sensitive and non-sensitive objects; when the operation included a source and a destination, we tested all four possible combinations. The operations checked included moving objects to new directories, replacing objects, and making and updating symbolic and hard links. We also tested sparse files. In all cases, we verified that the operations behaved as expected. File system traces illustrating these cases may be found in Appendix A.

Emulated workload: We ran the PostMark benchmark [18] with default settings, modified with 20% of the files marked sensitive, with random content. Afterwards, we found no remnants of sensitive information.

Missing updates: To check that all update events and block types are reported, we looked for errors such as unanticipated block-type changes and unfound write entries in TAP, etc., which are signs of missing reports from the file system. Currently, all updates are reported.

Cases related to file-system-consistency properties: For cases derived from the reuse-ordering property, we created an ext3 file system with most of its i-nodes and blocks allocated to encourage reuse. Then we performed tight append/truncate and file creation/deletion loops with

48 alternating sensitive status. We used uniquely identifiable file content to detect sensitive information leaks and found none. For cases derived from the pointer-ordering property, we verified our ability to recover from basic failures and remove remnants of sensitive information. We also verified that the page cache prohibits unreferenced data blocks from being written to the storage. Since the page ID component of GUIDs increases monotonically, we can use this property to detect illegal reordering of sensitive updates for the cases derived from the non- rollback property. For consolidations within a transaction, we used tight update loops with alternating sensitive modes. For consolidations across transactions, we used tight file creation/deletion loops with alternating sensitive modes. We checked all consolidation orderings for up to three requests (e.g., non-sensitive/sensitive/non-sensitive, sensitive/non- sensitive/sensitive, etc.).

5.2. Two-version Programming

We enumerated the TAP state-transition table and verified its correctness via two-version programming.

State representation: Since we are modeling the internal state of the TAP module, we must model the behavior of its main data structures – write entries and delete reminders. Recall that write entries hold information about pending writes, and delete reminders are attached to write entries and hold information about sectors to be securely deleted. While write entries may hold quite a bit of information, we only need to track the information in write entries that affect the state of TAP. We exploited TAP’s properties to trim the state space. First, a write entry will not consolidate with other write entries. This property ensures that each sensitive update is carried out unless explicitly cancelled. Consolidation behaviors (e.g., page cache) are achieved by performing updates directly to the write entry. Second, the next state transition is based on current write entries of different types within a current state (plus inputs). With those two properties, we can reduce the representation of a state to at most one write entry of each type, and explore all state-generating rules.

To illustrate, each state holds one write entry for nine types of blocks: data, i-node, other metadata, journal copy of data, journal copy of i-node, journal copy of other metadata, copy of data, copy of i-node, and copy of other metadata. Additionally, each write entry has four status bits: allocated, sensitive, having reminder attached, and ready-to-be-deleted from the journal. Thus, a state is a 9x4 matrix and can be represented as 36 bits, with 236 states. Figure 5.2.1 demonstrates the start state (empty state), with no blocks allocated.

Block Allocated Sensitive Attached delete Ready to be reminder deleted Data 0 0 0 0 I-node 0 0 0 0 Other metadata 0 0 0 0 Journal copy of data 0 0 0 0 Journal copy of i-node 0 0 0 0 Journal copy of other metadata 0 0 0 0 Copy of data 0 0 0 0 Copy of i-node 0 0 0 0 Copy of other metadata 0 0 0 0

Figure 5.2.1: Verification Empty State Illustrating the State-space Matrix

As an optimization, we applied our knowledge of ext3 to allow either a journal copy or regular copy row to be allocated. This optimization reflects the normal behavior of the file system and TAP and further reduces the state space.

State transitions: Each interface call triggers a state transition based on the function input parameters. For example, the first TE_report_write() on a non-sensitive i-node will transition from the empty state (a zero matrix), say S0, to a state S1, where the allocated bit for the i-node is set to 1. If TE_report_write() is called again to mark the i-node as sensitive, S1 is transitioned to a new state S2, with allocated and sensitive bits set to 1s.

State-space enumeration: To enumerate states and transitions, we permuted all TAP interface functions with all possible input parameters to the same set of write entries. A small range of GUIDs was used so that each write entry could have a unique GUID, but GUID collisions were allowed to test error conditions. The result is a full state transition table populated by edges consisting of a start state, a transition, and an ending state. An ending state in an edge can consist of a valid state, an error state, or a stop state. A valid state is determined by a valid function return code from TAP. Likewise, an error state is determined by an error function return code from TAP. All errors should cause TAP to transition back to the previous state. A stop state occurs when successful execution of a function would cause the state to expand beyond our constraints (e.g., multiple blocks of the same type). We created an enumeration program to systematically create a state-transition table of all reachable states. This user-space program interacted directly with the TAP module to determine successful execution of a transition (TAP function) and resulting state of a write entry. In addition to the enumeration program, we had to create a Linux proc module to communicate with the TAP module from user space, and we expanded TAP by creating functions to allow us to query the internal states of its data structures. Figure 5.2.2 breaks down the state-space enumeration program algorithm, and Figure 5.2.3 shows the interactions of the state enumeration program with the TAP module.

1. Begin with empty start state S e 2. Place S on FIFO e 3. If FIFO not empty, retrieve current state S from FIFO c 4. Iterate all transitions on S with all parameters. If each c resulting state S is valid and has never been visited, r place S on FIFO. Output all resulting edges to state r table output file.

5. Goto step 3 until FIFO empty

Figure 5.2.2: State-space Enumeration Program Algorithm

Given that the enumeration step can be viewed as traversing a state-space tree in breadth-first order, the tree fanout at each level is the total number of interface call-parameter combinations (261). As an optimization, we visited only states reachable from the empty starting state, and avoided repeated state-space and sub-tree branches. As a result, we explored a tree depth of 16 and located ~10K unique reachable states, or ~2.7M state transitions.

State-space Output Enumeration Program

User /proc Kernel Report/query Function return/ internal state status

TAP Block #

Block #

Figure 5.2.3: Interactions of the State-space Enumeration Program with TAP

Two-version-programming verification: Given that the state-transition table is filled with mostly illegal transitions that end in stop or error states, we applied n-version programming to verify the table, where the probability of hitting the same bug with the same handling can be reduced as we add more versions. In this work, n=2. We wrote a user-level state-transition program based on hundreds of conceptual rules (e.g., marking a write entry of any type as sensitive will set the sensitive bit to 1). The enumerated state-transition table was reconciled with the one generated by the first state-space enumeration program. Of these, 61% are error transitions; 25% leading to creating two write entries of the same type, which is the boundary of our state representation; 5% are self-transitions; and 9% are legal transitions to other states.

CHAPTER SIX

PERFORMANCE EVALUATION

We evaluated TrueErase’s overhead by comparing it to an unmodified Linux 2.6.25.6 running ext3 on top of DiskOnChip NAND flash. We ran PostMark [33] to measure the overhead for metadata-intensive small-file I/Os. We also compiled the OpenSSH version 5.1p1 [45] to measure the usage for larger files. We ran our experiments on an Intel® Pentium® D CPU 2.80GHz dual-core Dell OptiPlex GX520 with 4-GB DDR533 and 1-GB DoC MD2203-D1024- V3-X 32-pin DIP mounted on a PCI-G DoC evaluation board. Each experiment was repeated 5 times. The 90% confidence intervals are within 22%. The hard drive solution, while working and verified, demonstrates a high, fixed performance overhead. We give current hard-drive performance numbers as well as an in-depth discussion of what is needed to fix the overhead in Chapter 8.

6.1. Flash Chip Properties

Before starting PostMark and compilation tests, we first take measurements of each of the five raw flash operations: erase an erase block, read a page, write a page, read a page’s control area, and write a page’s control area. We accessed the DiskOnChip through the raw MTD interface so we could determine our best speeds without the overhead of the INFTL module. Each erase block is 16KB, each page is 512 bytes, and each page’s control area is 16 bytes. Figure 6.1.1 shows histograms of operations applied to sequential flash locations, and Figure 6.1.2 shows histograms of operations applied to random flash locations. Each histogram is based on 50 operations. As expected, the flash chip shows no significant difference between sequential and random operations. Figure 6.1.1 shows that page reads and writes take similar amount of time because writes are always directed to a pre-erased area. A block erase takes roughly double the amount of time as a page write. As expected, control area reads and writes are comparatively fast, with control area reads taking not quite half as long as control area writes. INFTL was

53 designed for fast control area reads, as the stack algorithm requires many control area reads for stack pointer traversal.

60 50 40

count 30 20 10 0 0 500 1000 1500 time (microseconds) (a) Erase timings (16 KB erase block size)

60 60 50 50 40 40 count 30 count 30 20 20 10 10 0 0 0 500 1000 1500 0 500 1000 1500 time (microseconds) time (microseconds)

(b) Write timings (512 B) (c) Read timings (512 B)

60 60 50 50 40 40 count 30 count 30 20 20 10 10 0 0 0 500 1000 1500 0 500 1000 1500 time (microseconds) time (microseconds)

(d) Control area write timings (16 B) (e) Control area read timings (16 B)

Figure 6.1.1: Raw DiskOnChip Sequential Timings for Flash Operations

60 50 40 count 30 20 10 0 0 500 1000 1500 time (microseconds) (a) Erase timings (16 KB erase block size)

60 60 50 50 40 40 count 30 count 30 20 20 10 10 0 0 0 500 1000 1500 0 500 1000 1500 time (microseconds) time (microseconds)

(b) Write timings (512 B) (c) Read timings (512 B)

60 60

40 40 count count 20 20

0 0 0 500 1000 1500 0 500 1000 1500 time (microseconds) time (microseconds)

(d) Control area write timings (16 B) (e) Control area read timings (16 B)

Figure 6.1.2: Raw DiskOnChip Random Timings for Flash Operations

6.2. Flash Small File Workload

As the first part of our performance evaluation, we ran PostMark [33] to measure the overhead for metadata-intensive small-file I/Os. The PostMark tests were conducted on the DiskOnChip NAND flash through the ext3 file system with the INFTL modules loaded. We used the default PostMark configuration with the following changes: 10K files, 10K transactions, 1-KB block size for reads and writes, and a read bias of 80%. We also modified PostMark to create and mark different percentages of files as sensitive. These files can be chosen randomly or with spatial locality, which is approximated by choosing the first x% of file numbers to be marked as sensitive. Before running tests for each experimental setting, we dirtied our flash by running PostMark with 0% sensitive files enough times to trigger wear leveling. Thus, our experiments reflect a flash device operating at steady state. A sync command was issued after each run to force all pending storage requests to finish and is reflected in the elapsed time. Table 6.2.1 shows PostMark flash operations, times, and overhead percentages compared to the base case (no secure deletion on a vanilla kernel). Figure 6.2.1 compares PostMark run times for the various modes. We can see that when TrueErase operates with no sensitive files (0%), metadata tracking and queries account for 3% overhead compared to the base case. With 10% of files marked sensitive, the slowdown factor can be as high as 11, which confirmed the numbers in a prior study [78]. However, with 5% of files marked sensitive and with locality and delayed secure deletion of file data blocks, the slowdown factor can be reduced to 3.4, which is comparable to disk-based secure deletion numbers [31]. We noticed some feedback amplification effects. Longer runs mean additional memory page flushes, which translate into more writes, which involve more reads and erases as well and lead to even longer times. Thus, minor optimizations can improve performance significantly.

OpenSSH compilations: We issued make+sync and make clean+sync to measure the elapsed times for compiling and cleaning OpenSSH [45]. For the TrueErase case, we marked the openbsd-compat directory sensitive before issuing make, which would cause all newly created files (e.g., .o files) in that directory to be treated as sensitive. Those files account for roughly 27% of the newly generated files (8.2% of the total number of files and 4.1% of the total number of bytes after compilation). Before running each set of tests, we dirtied the flash in the same way as with PostMark and threw away the first run that warms up the page cache. Table 6.2.2 shows

compilation flash operations, times, and overhead percentages compared to the base case (no secure deletion on a vanilla kernel). Figure 6.2.2 compares compilation run times for the various modes. The data shows that under these conditions, a user would experience a compilation slowdown within a factor of 1.4 under the delay-deletion mode. A user would experience a slowdown within a factor of 6.9 with the delayed-deletion mode under a deletion-intensive workload. For the entire compilation cycle of make+sync with make clean+sync, a user would experience an overall slowdown within 60% under the delayed-deletion mode. Overall, we find the overhead is within our expectations. Further improvements in performance are future work.

Table 6.2.1: PostMark Flash Operations, Times, and Overhead Percentage Compared to Base page control-area page control- erases time reads reads writes area writes (secs) Base 300K 1.97M 218K 237K 4.28K 671 0% 0.99x 1.08x 1.01x 1.01x 1.00x 1.03x 1% random 3.69x 2.09x 2.82x 2.79x 2.58x 2.93x 1% locality 2.95x 1.89x 2.33x 2.31x 2.16x 2.44x 1% random, delayed deletion 3.41x 2.00x 2.61x 2.59x 2.47x 2.73x 1% locality, delayed deletion 2.77x 1.77x 2.20x 2.19x 2.08x 2.29x 5% random 10.3x 4.22x 6.91x 6.83x 6.67x 7.39x 5% locality 6.69x 3.19x 4.86x 4.81x 4.32x 5.05x 5% random, delayed deletion 7.56x 3.48x 4.99x 4.99x 5.18x 5.54x 5% locality, delayed deletion 4.40x 2.33x 3.29x 3.29x 3.02x 3.42x 10% random 15.3x 5.82x 9.96x 9.84x 9.75x 10.7x 10% locality 9.96x 4.24x 7.00x 6.92x 6.23x 7.27x 10% random, delayed deletion 9.44x 4.23x 5.91x 5.96x 6.54x 6.80x 10% locality, delayed deletion 5.82x 2.96x 4.19x 4.22x 3.90x 4.45x

10% locality, delayed 5% locality, delayed 1% locality, delayed 10% random, delayed

Running Mode 5% random, delayed 1% random, delayed 10% locality 5% locality 1% locality 10% random 5% random 1% random 0% base

0 2000 4000 6000 8000 10000 Seconds

Figure 6.2.1: PostMark Flash Elapsed Times for TrueErase Running Modes

300

250

200

Seconds 150 make 100 clean

0 Base Random Random, delayed Running Mode

Figure 6.2.2: Compilation Flash Elapsed Times for TrueErase Running Modes

Table 6.2.2: Compilation Flash Operations, Times, and Overhead Percentage Compared to Base page reads control-area reads page control-area erases time writes writes (secs) make + sync Base 25.3K 108K 22.5K 23.9K 352 89 Random 4.79x 3.10x 3.15x 3.15x 3.13x 2.51x Random, delayed deletion 1.70x 1.37x 1.41x 1.43x 1.40x 1.41x make clean + sync Base 1.60K 3.73K 445 514 22 3 Random 10.0x 10.1x 13.6x 15.0x 7.14x 8.13x Random, delayed deletion 8.47x 8.36x 11.0x 12.6x 6.22x 6.87x Total Base 26.9K 112K 23.0K 24.4K 374 92 Random 5.10x 3.33x 3.35x 3.40x 3.37x 2.70x Random, delayed deletion 2.10x 1.60x 1.59x 1.66x 1.69x 1.59x

CHAPTER SEVEN

RELATED WORK

This chapter discusses existing work related to secure deletion on both flash and hard drive storage. We first discuss solutions that are isolated on separate layers of the storage data path. Next, we give examples of cross-layer solutions. Finally, we discuss solutions that involve remote and distributed solutions.

7.1. Layer-specific Solutions

Various solutions have been proposed; however, most of them operate at one layer of the legacy data path (Figure 2.1.1.2). While layering encourages the portability of individual layers, the types of information available at each layer restrict the effectiveness of secure-deletion solutions.

7.1.1. Storage-management-level Solutions

At the lowest level, the storage-management layer handles vendor-specific representations on the storage media. Since this layer accepts requests from layers above through the block-layer interface in terms of logical blocks, it has no information on a block’s type (e.g., data, metadata), file ownership, in-use status, etc. [17, 64]. Subsequently, solutions at this layer tend to operate on all blocks indiscriminately, with no support for per-file secure deletion. One method of performing storage-management-level secure deletion is to encrypt all data on the storage device or partition and revoking the device’s or partition’s encryption key. Many USB thumb drives provide encrypted storage with secure deletion as a secondary goal implemented through cryptographic mechanisms provided on the flash drive itself. This means that encryption and decryption are transparent to the host operating system, yet a mechanism must be provided (usually via operating system driver or application) to allow the user to input an encryption key (or a password that unlocks the encryption key or keys). Examples include Ironkey [29] and Kingston [57] USB drives.

Similarly, hard drives may also perform secure deletion of the entire partition or drive by employing full device encryption and revoking the key. Thibadeau [74] proposes this method as an overall component of trusted computing for disk drives at the end of their device life cycle. An examples of this type of hard drive includes the Seagate Secure Self-Encrypting Drive [50], which claims to render the hard drive unreadable in less than a second through erasure of the cryptographic key. Other proposed methods may allow smaller granularity secure deletion at the storage- management level, but do not provide a mechanism to correctly implement it. In [27], the author suggests implementation of erasure through deletion of file encryption keys at the hard drive firmware level, but does not provide detail on how this functionality is implemented or triggered. Wei et al. [78] propose a method of secure deletion to selective flash blocks in an FTL, but they do not provide the ability to map blocks to files and metadata to support secure deletion at the file granularity. Finally, specialized disk commands may be used to overwrite data locations on a hard drive or erase all locations on a flash drive. The disk drive Secure Erase command [26], defined in the ANSI ATA and SCSI interface specifications, internally overwrites and reports successful erasure of all user-accessible disk blocks. Unfortunately, bad blocks on a reassigned list (Chapter 9) may optionally not be overwritten if the OS does not have access to them. Some solid-state flash drives also support this command, but Wei et al. [78] have discovered that these commands do not always work on solid-state drives.

7.1.2. File-system-level Solutions

The file-system layer generally is unaware of the storage medium and has no control over the physical storage location of data and metadata. Thus, a file system may issue writes of random bits to the same location, intending to perform military-grade secure deletion [69] via in-place disk overwrites. Instead, the underlying storage medium can actually be a flash drive. Such devices typically write every version of an update (even to the same logical location) to a different physical location, to avoid the slow erases required by flash before updating the same location, negating the intent of secure deletion. Note that per-file, encryption-based solutions will not solve the problem, since the lower layer may not honor the secure-deletion semantics to

61 remove file keys. File-system-layer solutions may also overlook the sensitive information left behind by common journaling mechanisms, which log information to ease recovery. File systems may securely delete data by encrypting the data and then securely erasing the key. One solution [48] is built on top of the versioning file system ext3cow [47], and is based on the all-or-nothing (AON) transform [6, 53]. AON is defined as a cryptographic transform that, given only partial output, reveals nothing about its input. AON is leveraged in the secure versioning file system to make decryption impossible if one or more of the ciphertext blocks belonging to a file (or a file version) is deleted. Two examples of data overwriting file systems are FoSgen [31] and Purgefs [32]. Both file systems are stackable file systems built in the File System Translator language (FiST) [81]. FiST allows developers to describe stackable file systems at a high level and generates kernel file system modules for various platforms (e.g., Solaris, Linux, and FreeBSD). Purgefs can overwrite file data and metadata when deleting or truncating a file. Alternatively, to increase efficiency, the purge-delete option can be chosen using a special file attribute, for which only files with such an attribute will be purge deleted. Purgefs will delete data one or more times and supports the NIST standards and all NISPOM overwrite patterns (Table 9.1.1.1). FoSgen consists of two components: a file system extension and the user mode shred tool (Section 7.1.3). FoSgen intercepts files that require overwriting and moves them to a special directory. The shred tool, invoked either manually or periodically, eventually writes over the data in the special directory. The authors of FoSgen have also created patches to add secure-deletion functionality to the ext3 file system. The first patch adds one-pass secure-deletion functionality, and the second patch supports multiple overwrites and securely deletes a file’s metadata. Both implementations work in all three of ext3’s journaling modes and erase either a specially marked file’s data or all files on top of a hard drive. In addition, Bauer and Priyantha [3] have modified the ext2 file system for asynchronous secure deletion by passing secure-deletion information to a deletion daemon. The deletion-daemon performs retrieves and stores the blocks that need to be overwritten, issues new overwrite requests directly to the underlying hard drive, and returns blocks that have been deleted to ext3 for reallocation.

7.1.3. User-space Solutions

At the application layer, solutions are carried out by user-level programs. Given that these programs operate through file systems, they inherit the same constraints as the file-system-level solutions. Additionally, user programs that do not overwrite entire partitions have limited control of a file’s metadata, and thus cannot enforce secure deletion, leading to the leakage of information such as file names, file sizes, etc. Three main software methods exist for overwriting sensitive data: 1. Overwrite the contents of a file. 2. Delete the file normally, and then overwrite all free space in the partition. 3. Erase the entire partition or disk.

The first method is quickest if only a few small files are to be securely overwritten. Many utilities, both free and commercial, are available to perform this operation. Three common UNIX utilities are shred [60], wipe [79], and secure rm [56]. These utilities will overwrite a file’s content with random data for a configurable number of passes. In addition, OS X contains a built-in file secure-erase feature [37] that overwrites files. Overwriting all the free space in the partition is more of an afterthought method and might be employed after files have been deleted the normal way. One example is scrub, a Unix open-source utility [55], which erases free space in a partition by creating a file that extends to all the free space. A user needs to remember to remove the file after the application is done. The scrub utility implements user-selectable pattern algorithms compliant with the U.S. Department of Defense [43]. Reardon et al. [52] introduce two user-space secure deletion methods for use on top of flash media shown to work on the YAFFS file system: purging and ballooning. Purging overwrites all free space immediately, and ballooning causes periodic secure deletion by keeping the file system full of junk data, thereby causing more frequent YAFFS garbage collection. Erasing the entire partition or disk will securely delete all confidential information on the partition or disk such as data, metadata, and directory structures. One such software utility is Darik’s Boot and Nuke, or DBAN [11], which is a self-contained bootable media that wipes a hard drive by filling it with random data. Depending on the size of the drive, the erasure process can take a long time.

7.2. Cross-layer Solutions

This section discusses existing cross-layer secure-deletion solutions. However, the solutions listed here do not fulfill all the desirable secure deletion characteristics listed in Chapter 2.

7.2.1. Semantically-smart disk systems

A semantically-smart disk system (SDS) [65] tries to understand how the file system uses the hard drive beyond the information made available by the interface between the two components. In other words, an SDS can have access to certain knowledge of the file system’s on-disk data structures and policies and can make intelligent decisions based on this knowledge, such as pre- fetching blocks on a per-file basis. The authors describe a “secure-deleting” SDS that guarantees that deleted file data will be rendered unrecoverable by recognizing deleted blocks through “operation inferencing” and overwriting those blocks with different data patterns a specified number of times. Since it is possible that the file system might immediately reallocate those deleted blocks to another file, the SDS must track those deleted blocks and queue up pending write requests to those blocks until the secure overwrites have finished. The authors also make a note that the ext2 file system must be mounted synchronously to operate correctly. Using implicit detection techniques, which enable the storage system to infer block liveness information without modification of the file system, Sivathanu et al. [64] make a next- generation SDS prototype called FADED (A File-Aware Data-Erasing Disk) that operates under asynchronous file systems.

7.2.2. Type-safe Disks

A type-safe disk [62] directly expands the block-layer interface and the storage-management layer to perform free-space management on a hard drive. Using a type-safe disk, a modified file system can specify the allocation of blocks and their pointer relationships. As an example, this work implements secure deletion on ext2. Basically, this solution tracks when a block is garbage-collected and overwrites it one or more times. It ensures that the block is not reallocated before it is overwritten by postponing associated updates to the free block bitmap until the overwriting is complete. 64

7.2.3. Modified Flash File Systems

Lee et al. [36] have modified YAFFS, a log-structured file system for NAND, to handle secure file deletion. The modified YAFFS encrypts files and stores each file’s key along with the file’s metadata. Whenever a file is deleted, its key is erased, and the encrypted data blocks remain. Sun et al. [71] modified YAFFS and exploited certain types of NAND flash that allow overwriting of pages to achieve secure deletion. Raerdon et al. [52] also modifies YAFFS to use a flash-chip-specific zero-overwriting technique. In addition, Raerdon et al. [51] developed the Data Node Encrypted File System (DNEFS). DNEFS modifies the flash file system UBIFS to perform secure deletion at the data node level, which is the smallest unit of reading/writing. DNEFS performs encryption and decryption of individual data nodes and relies on a key generation and deletion scheme to prevent access to overwritten or deleted data. Since UBIFS is designed for flash with scaling constraints, the approach is not as applicable for disks and larger- scale storage settings.

7.3. Remote and Distributed Solutions

Vanish [19] is a distributed secure-deletion system that aims to destroy past, archived copies of data on the Web after a user-specified amount of time without any specific action on the part of the user. It accomplishes this by encrypting information and using Shamir secret sharing [70] to split the key into pieces. Using Shamir secret sharing, only a configurable threshold t pieces are needed to reconstruct the decryption key. These pieces are then distributed randomly to different distributed nodes. After a period of time, enough key pieces will vanish from the distributed nodes so that < t pieces remain. However, the Vanish authors admit that, in addition to the general system, they must verify that the operating environment does not preserve information and suggest incorporating methods of sanitizing data on storage. A solution such as TrueErase could be used in conjunction with this framework. Perlman’s ephemerizer [46] again addresses the problem of securely erasing data after a configurable period of time. Data is encrypted, and keys are created, advertised, and destroyed through an “ephemerizer” service. The authors suggest an implementation of an ephemerizer as a remote machine in which the message keys are stored in a tamper-resistant smart card that

65 performs cryptographic operations. It is also necessary for the ephemerizer to be authenticated with any client and communications with it protected against eavesdropping attacks. A revocable backup system [5] has a goal of secure deleting backup files without having to modify the backup media. This system encrypts backups on a per-file basis and stores the encryption key file on original server. The backup file’s encryption key is revoked when the backup file is to be securely deleted. Unfortunately, this solution does not discuss how to securely erase the encryption keys themselves.

CHAPTER EIGHT

FUTURE DIRECTIONS

This chapter discusses future work concerning the TrueErase framework. First, we discuss the TrueErase implementation on top of the hard drive and potential performance optimizations. Secondly, we talk about future work in the NAND flash realm. Finally, we conclude with a list of other possible expansions.

8.1. Hard Drive Optimizations

We implemented the hard drive solution for TrueErase as discussed in Section 4.3.4 as an illustration of the storage-portability of this framework. Our hard-drive-based performance numbers are not quite satisfactory due to current simple data structures. However, we present our current numbers and bottlenecks, and we show that acceptable performance numbers are well within reach. Specifically, we implemented the solution in the Linux 2.6.25.6 kernel running ext3 and a custom-made driver in the Linux device-mapper layer to issue hard-drive secure operations called dm-te (te stands for TrueErase). We ran our experiments on an Intel® Pentium® D CPU 2.80GHz dual-core Dell OptiPlex GX520 with 4-GB DDR533 and Seagate® Barracuda® 7200.12 ST3500413AS 500GB 7200 RPM 16MB cache SATA 6.0Gb/s 3.5" internal hard drive. We also verified that the hard drive code works as expected according to the different verification points in Chapter 5. Recall that the dm-te driver queries the TAP module for secure information. If the dm-te driver determines that a secure deletion operation must take place, it creates new, randomly- filled block I/O structures to overwrite the areas to be securely deleted. A secure write operation works similarly by overwriting the area to be written before the sensitive data is written. The number of overwrites with randomly-filled data is configurable. In the following tests, the number of secure-deletion overwrites is equal to one. In addition, since common experience shows that one in-place overwrite operation is sufficient [7, 31], we omit the secure-write operation as discussed as an optimization in Chapter 4.

As the first part of our performance evaluation, we ran PostMark [33] to measure the overhead for metadata-intensive small-file I/Os. We used the same configuration we used for the NAND flash experiments, with the only modification being more transactions (50K instead of 10K). We also marked different percentages of files as sensitive with random or spatial locality. A sync command was issued after each run to force all pending storage requests to finish and is reflected in the elapsed time. In addition, each experiment was repeated 10 times.

10% locality

5% locality

1% locality

10% random Running Mode 5% random

1% random

base

0 500 1000 1500 Seconds Figure 8.1.1: PostMark Hard Drive Elapsed Times for TrueErase Running Modes

Table 8.1.1: PostMark Hard Drive Elapsed Times Compared to Base time (secs) base 90.6 0% 1.54x 1% random 3.53x 5% random 7.67x 10% random 10.54x 1% locality 3.17x 5% locality 5.54x 10% locality 7.9x

Figure 8.1.1 shows elapsed times for different TrueErase running modes with 1%, 5%, and 10% of files marked as sensitive in both random and high-locality modes with 90% confidence intervals within 4%. Table 8.1.1 charts the same data with overhead percentages compared to the base kernel. Of particular note is that this implementation exhibits a 1.54x overhead compared to the base kernel when there are no files marked sensitive. To understand the potential causes of this high overhead, we examine the factors described below.

Device-mapper layer: First, since our disk-based and flash-based implementations differ in the storage-manager layer component to insert secure-write and –deletion commands, we are interested in finding out if the device-mapper layer used for the disk implementation causes overhead. We can do so by inserting a “dummy” device mapper layer with all of the TrueErase functionality removed. In Chapter 4, we introduced such a layer named linear, which simply maps a linear range of sectors onto a physical device.

Records reporting from the file system: For verification, the file system layer has to report all sensitive and non-sensitive update and deletion events. We would like to know how much overhead can be reduced if we report only sensitive ones. We test how much time is taken up by TAP record processing by introducing two new debugging modes: full reporting and selective reporting. Full reporting mode is the default mode, where the file system reports all writes to TAP. Selective reporting mode is a new mode where the file system only reports sensitive writes and secure deletes to TAP.

Checking for sensitive bits for i-node and directory writes: Files and directories in the file system are marked as sensitive via a bit stored in the file or directory’s i-node. Whenever the file system reports a block to be written to TAP, it must first check to see if the block is sensitive. Five types of blocks in the ext3 file system may be sensitive: data blocks, i-node blocks, directory blocks, extended attributes, and indirect blocks. Data blocks, extended attributes, and indirect blocks are owned by a single file; therefore, only one sensitive bit must be checked. However, i-node blocks and directory blocks are handled differently. If any i-node on an i-node

69 block is sensitive, the whole i-node block must be treated as sensitive. Similarly, if any name on a directory block is sensitive, the whole directory block must be treated as sensitive. A potential performance problem lies in how i-node and directory blocks are checked for sensitive information. Consider an i-node block to be written, consisting of 8 128-byte i-nodes on a 1K block. In the worst case where all i-nodes are actually not sensitive, all 8 i-nodes on the block are currently individually checked, and this check is done whenever one i-node is updated (e.g., access time stamp). Similarly, in the worst case where no directory entry on a directory block is sensitive, all i-nodes corresponding to the directory entries on the directory block are still currently individually checked. Checking an i-node involves lookup and locking operations, which may further slow down the operations. We introduced two new debugging modes called bit checking and no bit checking. The bit-checking mode checks the sensitive status of i-node blocks and directory blocks as normal. The no-bit-checking mode replaces the secure-bit-checking functions for i-node and directory blocks with no-ops. While this would normally break secure deletion, we run these modes with 0% secure files to see how much (if any) overhead is reduced. Finally, we run further PostMark benchmarks with the same configuration as explained earlier in all debugging modes with 0% sensitive files to determine the amounts the above listed factors contribute to overhead. Figure 8.1.2 shows the results.

0% selective reporting, no bit checking

0% full reporting, no bit checking

0% selective reporting, bit checking Debugging Mode 0% full reporting, bit checking

0% linear

base

0 20 40 60 80 100 120 140 160 Seconds

Figure 8.1.2: PostMark Hard Drive Elapsed Times for TrueErase Debugging Modes

From Figure 8.1.2, we can see that the elapsed time using the linear device-mapper driver instead of the dm-te driver is the same as the base case at the 90% confidence interval. The 0% full reporting, bit-checking mode is the normal mode, and it is the same as the 0% mode in Table 8.1.1. When we run TrueErase in selective reporting mode, the overhead over the base case is reduced from 54% to 32%. When we combine the selective reporting and no bit checking modes, overhead is reduced to 10% over the base case. In other words, these two factors contribute to 80% of the current overhead found in the 0% mode. Future work will concern optimizing the method in which write entries are stored and retrieved in the TAP module (currently via linked lists) and how i-node and directory blocks are checked for sensitive status (currently sequential). Another potential optimization comes from the discontinuation of block barrier I/O requests in newer kernels [72]. Barriers have been traditionally used to preserve ordering of I/O requests by not allowing the kernel I/O scheduler to reorder I/O requests across the barrier and flush any on-disk cache. This type of behavior is necessary to preserve the ordering of I/O requests necessary to ensure file-system consistency in a journaling file system, but it often comes at the price of performance because the I/O request queue must be drained before any other requests can proceed. Recall that we also use barrier requests extensively in our dm-te driver to ensure proper ordering and flushing of I/O requests. In newer kernels (as of 2.6.37), barrier block I/O requests have been phased out. File systems must now, instead of issuing barrier block I/O requests, wait for completion for a batch of I/O requests before sending the next batch to ensure proper ordering. In addition, a “force unit access” (FUA) flush request has been introduced so that the file system may ensure that any on- disk cache is flushed before proceeding. Since I/O queues no longer need to be drained, overall I/O performance increases with no cost to file system consistency. Since TrueErase was implemented in 2.6.25.6, we could not take advantage of the new, barrier-less operations. Future work includes porting TrueErase to a newer kernel that supports FUA to take advantage of these optimizations in our dm-te driver.

8.2. Flash Optimizations

NAND flash erase operations take the longest times to complete. Therefore, it would make the most sense to optimize secure-deletion methods in the flash storage-management layer to make the fewest erase operations as possible. Since flash must be erased one block at a time, one optimization might be to try to predict and collocate dead (invalid) sensitive flash pages on the same flash block as the corresponding live page. Thus, when secure-deletion occurs, only one block need be erased. Extrapolated further, live and dead flash pages belonging to an entire secure file could be grouped on as few flash blocks as possible, further reducing the amount of block erases when file deletion time comes. This might be accomplished by treating each sensitive file in flash as a mini-log, writing updates sequentially on the flash. Another way to reduce the amount of erasure involves using the all-or-nothing (AON) transform [6, 53]. AON is defined as a cryptographic transform that, given only partial output, reveals nothing about its input. This transform could be leveraged in secure deletion to delete just one small portion of the sensitive file to render the file unreadable. Recently, a new flash development environment called OpenSSD [73] has become available, which can allow us to program new secure-deleting FTLs on top of modern flash hardware. As future work, we will explore new flash environments such as this.

8.3. Other Expansions

Other future work will include tracking sensitive data between files and applications via tainting mechanisms, and generalizations to handle swapping, hibernation, RAID, and volume managers.

Tainting mechanisms: Mechanisms that track the propagation of sensitive data throughout the entire system are called tainting mechanisms. For example, a user could copy information from a sensitive file into memory and paste that information into a non-sensitive file. A tainting system would track the sensitive data between the files and potentially either allow or disallow the copy. TrueErase could use tainting information to propagate sensitive status across files to carry out secure deletion.

Swapping and hibernation: Sensitive information from memory may land on persistent storage via swapping and hibernation mechanisms. Swapping is used to present a larger amount of RAM than is physically available to applications, and memory pages that no longer fit into RAM are “swapped” onto a special swap file or partition. Memory page faults occur when the memory management system cannot find the desired page in the physical RAM and must bring the memory back into RAM via the swap area. Similarly, hibernation mechanisms save the current contents of memory to persistent storage for future fast restoration of the system. Since contents of memory may be sensitive, this information must be securely written to and deleted from persistent storage. TrueErase currently does not allow swapping or hibernation, and a fine-grained tainting mechanism below the file granularity is needed to allow TrueErase to securely delete sensitive regions within the files used for swapping or hibernation.

RAID and volume managers: RAID systems and volume managers provide an abstraction of multiple physical storage devices under one logical storage device with optional parity and/or error-correcting information. Software RAID and volume management is implemented in the Linux device-mapper layer, and our hard-drive implementation is implemented in the same layer. Certain types of volume management and RAID that do not store parity or other error-correcting information may already work under the current implementation of TrueErase and need to be tested. Extra stored information (such as parity) must be treated as sensitive if sensitive information can be re-constructed.

CHAPTER NINE

DISCUSSION

This chapter discusses the important issue of data remanence, which is defined as the residual physical representation of data that has been erased or overwritten [66]. It is very important that each secure deletion-solution proposed investigate the possibility of data remanence. In addition, we also discusses the recently-added ATA TRIM command [61], which is a new way to propagate some deletion information to NAND flash storage as a performance optimization.

9.1. Data Remanence

Data remanence issues vary greatly, depending on the type of underlying storage. Hard drives consist of magnetically-charged platters with read/write heads. NAND flash storage is a type of memory that stores information through a charge on the floating gate of a transistor. Since we use traditional hard drives and NAND flash storage in our secure-deletion examples, we will respectively discuss their data remanence issues here.

9.1.1. Hard-drive Data Remanence Issues

Many forensic techniques are available to the determined (and well-funded) attacker to recover data from traditional hard drives. CMRR scanning microscopes [26] can recover data on a piece of a destroyed disk if any remaining pieces are larger than a single 512-byte record block in size, which is about 1/125” on today’s drives. Another approach is to use a spin-stand to collect several concentric and radial magnetic surface images, which can be processed to form a single surface image [39]. A less well-funded attacker can resort to many drive-independent data recovery techniques [67], which may be used on most hard drives independently of their make. Thus, it is important to consider the method of erasure when securely deleting data from hard drives. NIST recommends that magnetic media be overwritten at least three times [68]. The Department of Defense [43] suggests an overwrite with a character, its compliment, then a

74 random character, as well as other software-based, overwrite methods that refer to non-volatile electronic storage as listed below in Table 9.1.1.1. Peter Gutmann [22] developed a 35-pass data overwriting scheme to work on older disks that use error-correcting-encoding patterns referred to as run-length-limited encodings. The basic idea is to flip each magnetic domain on the disk back and forth as much as possible without writing the same pattern twice in a row and to saturate the disk surface to the greatest depth possible. Peter Gutmann’s 35-pass overwrite technique is demonstrated in Table 9.1.1.2.

Table 9.1.1.1: Software-based Methods of Erasing Data on Non-volatile Storage (NISPOM) ID Erasure method

C Overwrite all addressable locations with a character.

D Overwrite all addressable locations with a character, its complement, then a random character and verify.

E Overwrite all addressable locations with a character, its complement, then a random character.

H Overwrite all locations with a random pattern, with binary zeros, and then with binary ones.

Table 9.1.1.2: Peter Gutmann's 35-pass Overwrite Technique Pass number Data written Hex code 1 Random Random 2 Random Random 3 Random Random 4 Random Random 5 01010101 01010101 01010101 0x55 0x55 0x55 6 10101010 10101010 10101010 0xAA 0xAA 0xAA 7 10010010 01001001 00100100 0x92 0x49 0x24 8 01001001 00100100 10010010 0x49 0x24 0x92 9 00100100 10010010 01001001 0x24 0x92 0x49 10 00000000 00000000 00000000 0x00 0x00 0x00 11 00010001 00010001 00010001 0x11 0x11 0x11 12 00100010 00100010 00100010 0x22 0x22 0x22 13 00110011 00110011 00110011 0x33 0x33 0x33

Table 9.1.1.2 continued

Pass number Data written Hex code 14 01000100 01000100 01000100 0x44 0x44 0x44 15 01010101 01010101 01010101 0x55 0x55 0x55 16 01100110 01100110 01100110 0x66 0x66 0x66 17 01110111 01110111 01110111 0x77 0x77 0x77 18 10001000 10001000 10001000 0x88 0x88 0x88 19 10011001 10011001 10011001 0x99 0x99 0x99 20 10101010 10101010 10101010 0xAA 0xAA 0xAA 21 10111011 10111011 10111011 0xBB 0xBB 0xBB 22 11001100 11001100 11001100 0xCC 0xCC 0xCC 23 11011101 11011101 11011101 0xDD 0xDD 0xDD 24 11101110 11101110 11101110 0xEE 0xEE 0xEE 25 11111111 11111111 11111111 0xFF 0xFF 0xFF 26 10010010 01001001 00100100 0x92 0x49 0x24 27 01001001 00100100 10010010 0x49 0x24 0x92 28 00100100 10010010 01001001 0x24 0x92 0x49 29 01101101 10110110 11011011 0x6D 0xB6 0xDB 30 10110110 11011011 01101101 0xB6 0xDB 0x6D 31 11011011 01101101 10110110 0xDB 0x6D 0xB6 32 Random Random 33 Random Random 34 Random Random 35 Random Random

Many fear that magnetic force microscopy can recover data that has been overwritten. Magnetic force microscopy and magnetic force scanning tunneling microscopy [20] analyze the polarity of the magnetic domains of the electronic storage medium. For example, when a zero overwrites a one, the actual value will become .95 and when a one overwrites a one it will be 1.05. The number of overwrite passes thought necessary to delete data securely is controversial. Some believe governmental agencies (perhaps with magnetic force microscopy)

76 can recover data that has been overwritten any number of times, but most data recovery companies say they cannot recover data that has been overwritten even once [7, 31]. Also, Wright et al. [80] show that one wipe is enough to securely delete data such that it cannot be recovered, and they also demonstrate the infeasibility of using magnetic force microscopy in actual practice to recover usable amounts of data from hard drives. Specifically, the authors find that the calculated probability of recovering data from a used, high-density hard drive that uses the new Extended Partial-Response Maximum-Likelihood (EPRML) encoding scheme was indistinguishable from a random guess.

9.1.2. Flash Data Remanence Issues

Many forensic techniques are also available to the determined attacker to recover data from NAND flash memory, as well as interesting wear-leveling artifacts if data is not securely deleted [38]. A flasher tool is a vendor-specific device that uses a simple hardware interface and software to copy all flash memory data to another location for analysis. Flasher tools are often used to make full memory copies of a wide range of cell phones. Sometimes, a Joint Test Action Group (JTAG) test access port is available on an embedded device, which can be used to make an image of the flash memory. Finally, an attacker could physically remove the flash memory chip from the printed circuit board and read it with a flash chip reader. Specifically, flash memory chips can be removed via a variety of tactics using de-soldering tools or hot air. The primary way of deleting data on NAND flash memory is to issue erase commands to the low-level flash blocks. However, the changes in cell threshold voltage between erased-and- programmed and never-programmed cells are very discernible in virgin flash memory, but become less noticeable after ten write/erase cycles [66]. The following general design rules are suggested for the developer to make data recovery from flash memory more difficult [21]:

Cycle flash cells 10-100 times with random data before writing anything sensitive to them. Program (write with all 0s) flash cells before erasing them to eliminate detectable residual charge effects.

9.1.3. Other Issues

Two additional data remanence issues that pertain to both hard disk drives and flash drives in relation to secure deletion are bad block/sector forwarding and storage-persistent caches. Bad sectors are hard disk locations that cannot be accessed consistently, developed during the normal use of a hard disk. Bad sector forwarding is performed transparently at the hardware level, in which the firmware identifies and remaps a bad sector to a reserved area hidden from the user through the hard-disk defects table (G-List) [58]. In other words, the defective sector is replaced with a sector on a different part of the hard disk. The defective sector cannot be accessed again by the hard disk itself. Figure 9.1.3.1 demonstrates bad sector forwarding. Data sector 2 has gone bad and has been detected by the hard disk firmware. The hard disk firmware remaps sector 2 to the reserved area sector 0. Now whenever a read or write operation is performed on sector 2, the operation will be mapped to reserved area sector 0.

Figure 9.1.3.1: Demonstration of Bad Sector Forwarding

The problem with bad sector forwarding is that the sector might still be partially readable with only a small number of error bytes. This presents a problem if a bad sector contains sensitive data or important cryptographic information (such as a key or initialization vector) that could still be read using other forensic methods. Unfortunately the ATA specification does not have a command to turn off bad sector forwarding, so vendor-specific ATA commands must be used [58]. Similarly, NAND flash storage devices maintain a list of bad blocks, which are erase blocks that contain one or more invalid bits of questionable reliability [41]. Blocks may ether become bad during regular use or they may ship this way, and they are differentiated from normal blocks through a vendor-specific mark in a control area located inside the block.

A flash bad-block list or table is created by reading all the control areas in the flash memory for the vendor-specific mark, and then may be stored persistently for faster load time. The bad-block list is managed through the flash FTL, which may be in either the storage hardware or the OS software. Once a block is determined to be bad, its data contents are copied to a replacement block and all future attempts to address the block are readdressed to the replacement block. At this time, the TrueErase framework does not address bad block/sector forwarding. This issue can be partially mitigated in the future using a few possible methods: (1) use encryption so that only cryptographically-scrambled information remains on the bad block list (although care must be taken if a cryptographic key or initialization vector winds up on the list), (2) use device-specific commands to periodically clear the bad-block list (if the commands are available), or (3) disable bad block/sector forwarding and handle the bad areas in software (if that functionality is available). Unfortunately, if the underlying media is truly damaged, the only remaining way available to erase the information is through device physical destruction. In addition to bad block/sector forwarding, persistent caches have been placed in storage systems to improve performance [31]. These caches may not only defer writing to the actual physical media, but may also aggregate multiple writes to the same location on the disk as a single write. In this case, we can solve the problem with two possible methods: (1) disable the write cache of the storage media with a disk-specific command, or (2) use firmware commands to allow us to perform explicit secure deletion on the persistent cache (if they exist).

9.2. ATA TRIM Command

The ATA8 TRIM command is implemented on some flash drives to improve performance [61]. It allows the file system to specify blocks that are no longer in-use, and the flash drive can discard them through internal garbage collection. TRIM was not meant to be a secure-deletion substitute, and it does not guarantee data deletion. This subsection gives background on the TRIM command and explains why it is not suitable to implement secure deletion.

9.2.1. TRIM Background

TRIM was created to speed up NAND solid-state drive performance by giving the underlying flash wear-leveling algorithms knowledge of storage areas that are no longer in use by the file system. With this knowledge, the wear-leveling algorithms can erase these areas on flash in the background in order to store up unused, pre-erased areas in anticipation of future writes. Thus, overall flash write performance can be increased. In Linux, the TRIM command is supported beginning with kernel 2.6.33 and is implemented through special discard block I/O requests sent from the file system that specify a range of sectors to be freed [4]. TRIM is used with file systems in two modes: online and offline. Online modes issue TRIM in conjunction with file truncates and deletes, and the offline mode exports a file system ioctl call to allow a user program to issue TRIM on ranges of the file system free space.

9.2.2. TRIM for Secure Deletion

Since the TRIM command already passes file-system deletion information to the underlying storage media, it might seem logical to attempt to use TRIM to implement secure deletion on flash storage. However, there are a number of problems with the current implementation: Delayed deletion: FTLs on current solid-state drives can issue the TRIM-suggested block erases at any time in the future, so it is difficult to make guarantees about if and when the specified data locations get erased. A current study showed that up to 27% of blocks were recoverable on a TRIM-enabled device [34]. Metadata deletion: The smallest unit of deletion that the TRIM command can pass down is of the size of a sector. However, sometimes secure information must be erased at a smaller granularity (e.g., i-node, file name). Logically addressable areas: TRIM cannot be used as a substitute for the TrueErase secure_write() operation. Thus, old copies of data from previous sensitive writes may reside in non-addressable areas on the flash due to normal flash copy-on-write behavior. When TRIM is finally issued to the addressable areas that hold the current copy of the

sensitive data, the old copies are missed. Even TRIM in offline mode only issues TRIM requests to addressable areas. File system consistency: TRIM operations in software and firmware need to be verified to work with current file system consistency models [28].

Overall, the TRIM command is a step in the right direction by adding a way to propagate deletion information into the storage data path. However, TrueErase addresses issues necessary to carry out data-path-wide secure deletion.

CHAPTER TEN

LESSONS LEARNED AND CONCLUDING REMARKS

This dissertation presents our third version of TrueErase. Overall, we found retrofitting security features to the legacy storage data path is more complex than we first expected. Initially, we wanted to create a solution that would work with all popular file systems. However, we found it difficult to verify the correctness of secure deletion when working with file systems that can violate consistency properties. The verification problem became much more tractable when working with file systems with the file system consistency properties discussed in Chapter 3. Our earlier designs experimented with different methods to propagate information across different storage layers, such as adding new special synchronous I/O requests and sending direct flash commands from the file system. After struggling to work against the inherent asynchrony in the data path, we instead chose to work with it. This meant that we could not easily insert new synchronous commands or direct storage commands without interfering with other asynchronous behavior throughout the data path. Instead, we associate secure-deletion information with the legacy data path flow. We also decoupled the storage-specific secure-deletion action from the secure information propagation for ease of portability to different storage types. We also found it tricky to formulate the GUID scheme, due to multiple in-transit versions and the placement of GUIDs. To illustrate, using only the sector number was insufficient when handling multiple in-transit updates to the same sector with conflicting sensitive status. Placing a GUID in transient data structures, such as a block I/O structures, had complications when these structures can be split, concatenated, copied, and even destroyed before reaching storage. We solved the problem by associating a GUID with the specific memory pages that contain the data. Tracking-granularity issues exist throughout the legacy storage data path. Data is stored in memory pages. File systems interact with blocks, multiples of which may exist on one memory page. The block layer may concatenate blocks together to form requests, which may span more than one memory page. Finally, requests are broken up into storage-specific granularities (e.g., disk sectors or flash pages). Various granularities make it difficult to map our solution into existing theoretical verification frameworks [63].

Finally, our work would not have been possible without direct access to a flash FTL. An unfortunate trend of FTLs is that they are mostly implemented in hardware, directly on the flash device controller. An implication is that most FTLs (and their wear-leveling/block-management routines) cannot be seen or accessed by the OS. To leave the door of software FTL research open, we need to create an environment that enables and eases experimentation, to demonstrate the benefits of software-level developments and controls. To summarize, we have presented the design, implementation, evaluation, and verification of TrueErase, a legacy-compatible, per-file, secure-deletion framework that irrevocably deletes data and metadata on hard drives and emerging NAND flash solid-state drives. We have identified and overcome the challenges of specifying and propagating information across storage layers. We show that we can handle common system failures. We have verified TrueErase and its core logic via cases derived from file-system-consistency properties and state-space enumeration. We have shown that TrueErase has acceptable performance on NAND flash storage, and acceptable performance for hard drives is in reach. Finally, through this work, we have gathered valuable insights and lessons about the mechanisms of the legacy storage data path. Although a secure-deletion solution that can withstand diverse threats remains elusive, TrueErase is a promising step toward this goal.

APPENDIX A

FILE SYSTEM SECURE OPERATION TRACES

The following traces have been created by the user-space flash development simulator and illustrate operations occurring in the MTD block interface. These traces are illustrative in showing the ordering of writes received from the higher layers of the operating system storage data path as well as the inserted secure deletion operations to be performed on the flash device. Normally, the only types of information that can be gathered at this location include the type of pending operation (read or write) and the destination sector number. Due to the extra information in the TAP module and the TrueErase framework, we can include the following extra information in our traces: secure status, page ID, i-node number, and sector type. Note that not all types of sectors have an i-node number. For example, data from a file can be identified by that file’s i-node number. However, the file system superblock is not associated with an i- node. In the cases of an operation with no associated i-node, the i-node field in the trace is left blank. In addition, these traces illustrate secure-write and secure-delete behavior. If a pending write is secure, the lower flash drivers will be instructed to issue the write securely. In addition, the interaction with the TAP module at this layer allows us to retrieve secure deletion information and issue secure delete commands to the lower flash drivers.

A.1. Secure Creation and Deletion of Files

This subsection demonstrates traces derived from creating a secure file of various sizes and then securely deleting that file. Secure operations are highlighted. For all traces in this subsection, the secure file is associated with i-node 12, the root directory is associated with i-node 2, and the journal is associated with i-node 8. Table A.1.1 creates and deletes an empty, sensitive file and is broken down into phases. During the “mount the file system” phase, the file system superblock is updated and written. During the “create secure file and sync” phase, a sensitive i-node for the file is created as well as a sensitive file name in the root directory. The sensitive metadata is written securely first to the file system journal and then to the final destination. During the “delete secure file and sync”

84 phase, the file’s sensitive i-node and name are zeroed and written securely to the file system journal and then final destination. Finally, during the “un-mount the file system” phase, the file system journal is purged. Two previous copies of the file’s secure i-node and name are securely deleted.

Table A.1.1: Empty File Trace Mount the file system Action Sector Secure Status Page ID I-nodes Sector Type WRITE 2 NON-SECURE 1293522 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1293522 EXT3 SUPERBLOCK

Create secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK WRITE 1054 NON-SECURE 1293557 8 JOURNAL DESCRIPTOR WRITE 1055 NON-SECURE 1293557 8 JOURNAL DESCRIPTOR WRITE 1056 NON-SECURE 1293555 INODE FREEMAP IN JOURNAL WRITE 1057 NON-SECURE 1293555 INODE FREEMAP IN JOURNAL WRITE 1058 NON-SECURE 1293522 GROUP DESCRIPTOR IN JOURNAL WRITE 1059 NON-SECURE 1293522 GROUP DESCRIPTOR IN JOURNAL WRITE 1060 SECURE 1293555 12 INODE IN JOURNAL WRITE 1061 SECURE 1293555 12 INODE IN JOURNAL WRITE 1062 NON-SECURE 1293555 2 INODE IN JOURNAL WRITE 1063 NON-SECURE 1293555 2 INODE IN JOURNAL WRITE 1064 SECURE 1293621 2 DIR IN JOURNAL WRITE 1065 SECURE 1293621 2 DIR IN JOURNAL WRITE 1066 NON-SECURE 1293871 8 JOURNAL COMMIT RECORD WRITE 1067 NON-SECURE 1293871 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 1293522 GROUP DESCRIPTOR WRITE 5 NON-SECURE 1293522 GROUP DESCRIPTOR WRITE 520 NON-SECURE 1293555 INODE FREEMAP WRITE 521 NON-SECURE 1293555 INODE FREEMAP WRITE 522 NON-SECURE 1293555 2 INODE WRITE 523 NON-SECURE 1293555 2 INODE WRITE 524 SECURE 1293555 12 INODE WRITE 525 SECURE 1293555 12 INODE WRITE 1024 SECURE 1293621 2 DIR WRITE 1025 SECURE 1293621 2 DIR

Table A.1.1 continued

Delete secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 1293871 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 1293871 8 JOURNAL DESCRIPTOR WRITE 1070 SECURE 1293621 2 DIR IN JOURNAL WRITE 1071 SECURE 1293621 2 DIR IN JOURNAL WRITE 1072 NON-SECURE 1293555 2 INODE IN JOURNAL WRITE 1073 NON-SECURE 1293555 2 INODE IN JOURNAL WRITE 1074 NON-SECURE 1293522 EXT3 SUPERBLOCK IN JOURNAL WRITE 1075 NON-SECURE 1293522 EXT3 SUPERBLOCK IN JOURNAL WRITE 1078 SECURE 1293555 12 INODE IN JOURNAL WRITE 1079 SECURE 1293555 12 INODE IN JOURNAL WRITE 1080 NON-SECURE 1293522 GROUP DESCRIPTOR IN JOURNAL WRITE 1081 NON-SECURE 1293522 GROUP DESCRIPTOR IN JOURNAL WRITE 1082 NON-SECURE 1293555 INODE FREEMAP IN JOURNAL WRITE 1083 NON-SECURE 1293555 INODE FREEMAP IN JOURNAL WRITE 1084 NON-SECURE 1293877 8 JOURNAL COMMIT RECORD WRITE 1085 NON-SECURE 1293877 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 1293522 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1293522 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 1293522 GROUP DESCRIPTOR WRITE 5 NON-SECURE 1293522 GROUP DESCRIPTOR WRITE 520 NON-SECURE 1293555 INODE FREEMAP WRITE 521 NON-SECURE 1293555 INODE FREEMAP WRITE 522 NON-SECURE 1293555 2 INODE WRITE 523 NON-SECURE 1293555 2 INODE WRITE 524 SECURE 1293555 12 INODE WRITE 525 SECURE 1293555 12 INODE WRITE 1024 SECURE 1293621 2 DIR WRITE 1025 SECURE 1293621 2 DIR

Un-mount the file system Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK DELETE 1060 SECURE 1293555 8 INODE IN JOURNAL DELETE 1061 SECURE 1293555 8 INODE IN JOURNAL DELETE 1064 SECURE 1293621 8 DIR IN JOURNAL DELETE 1065 SECURE 1293621 8 DIR IN JOURNAL WRITE 1052 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK

Table A.1.1 continued

Action Sector Secure Status Page ID I-nodes Sector Type DELETE 1070 SECURE 1293621 8 DIR IN JOURNAL DELETE 1071 SECURE 1293621 8 DIR IN JOURNAL DELETE 1078 SECURE 1293555 8 INODE IN JOURNAL DELETE 1079 SECURE 1293555 8 INODE IN JOURNAL WRITE 1052 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1293557 8 JOURNAL SUPERBLOCK WRITE 2 NON-SECURE 1293522 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1293522 EXT3 SUPERBLOCK

Table A.1.2 creates and deletes a small, sensitive file with 1K of data and is broken down into phases. During the “mount the file system” phase, the file system superblock is updated and written. During the “create secure file and sync” phase, a sensitive i-node for the file is created as well as a sensitive file name in the root directory. In addition, 1K of sensitive file data is written. The sensitive metadata is written securely first to the file system journal and then to the final destination. During the “delete secure file and sync” phase, the file’s sensitive i-node and name are zeroed and written securely to the file system journal and then final destination. Before the file’s i-node is securely written to the journal, the file’s data is securely deleted. Finally, during the “un-mount the file system” phase, the file system journal is purged. Two previous copies of the file’s secure i-node and name are securely deleted.

Table A.1.2: Small File Trace (1K) Mount the file system Action Sector Secure Status Page ID I-nodes Sector Type WRITE 2 NON-SECURE 1398389 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1398389 EXT3 SUPERBLOCK

Create secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 12290 SECURE 1398723 12 DATA WRITE 12291 SECURE 1398723 12 DATA WRITE 1052 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK WRITE 1054 NON-SECURE 1398393 8 JOURNAL DESCRIPTOR

Table A.1.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1055 NON-SECURE 1398393 8 JOURNAL DESCRIPTOR WRITE 1056 NON-SECURE 1398391 INODE FREEMAP IN JOURNAL WRITE 1057 NON-SECURE 1398391 INODE FREEMAP IN JOURNAL WRITE 1058 NON-SECURE 1398389 GROUP DESCRIPTOR IN JOURNAL WRITE 1059 NON-SECURE 1398389 GROUP DESCRIPTOR IN JOURNAL WRITE 1060 SECURE 1398391 12 INODE IN JOURNAL WRITE 1061 SECURE 1398391 12 INODE IN JOURNAL WRITE 1062 NON-SECURE 1398391 2 INODE IN JOURNAL WRITE 1063 NON-SECURE 1398391 2 INODE IN JOURNAL WRITE 1064 SECURE 1398633 2 DIR IN JOURNAL WRITE 1065 SECURE 1398633 2 DIR IN JOURNAL WRITE 1066 NON-SECURE 1398720 BLOCK FREEMAP IN JOURNAL WRITE 1067 NON-SECURE 1398720 BLOCK FREEMAP IN JOURNAL WRITE 1068 NON-SECURE 1398726 8 JOURNAL COMMIT RECORD WRITE 1069 NON-SECURE 1398726 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 1398389 GROUP DESCRIPTOR WRITE 5 NON-SECURE 1398389 GROUP DESCRIPTOR WRITE 518 NON-SECURE 1398720 BLOCK FREEMAP WRITE 519 NON-SECURE 1398720 BLOCK FREEMAP WRITE 520 NON-SECURE 1398391 INODE FREEMAP WRITE 521 NON-SECURE 1398391 INODE FREEMAP WRITE 522 NON-SECURE 1398391 2 INODE WRITE 523 NON-SECURE 1398391 2 INODE WRITE 524 SECURE 1398391 12 INODE WRITE 525 SECURE 1398391 12 INODE WRITE 1024 SECURE 1398633 2 DIR WRITE 1025 SECURE 1398633 2 DIR

Delete secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1070 NON-SECURE 1398726 8 JOURNAL DESCRIPTOR WRITE 1071 NON-SECURE 1398726 8 JOURNAL DESCRIPTOR WRITE 1072 SECURE 1398633 2 DIR IN JOURNAL WRITE 1073 SECURE 1398633 2 DIR IN JOURNAL WRITE 1074 NON-SECURE 1398391 2 INODE IN JOURNAL WRITE 1075 NON-SECURE 1398391 2 INODE IN JOURNAL WRITE 1078 NON-SECURE 1398389 EXT3 SUPERBLOCK IN JOURNAL WRITE 1079 NON-SECURE 1398389 EXT3 SUPERBLOCK IN JOURNAL DELETE 12290 SECURE 1398728 12 DATA DELETE 12291 SECURE 1398728 12 DATA

Table A.1.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1080 SECURE 1398391 12 INODE IN JOURNAL WRITE 1081 SECURE 1398391 12 INODE IN JOURNAL WRITE 1082 NON-SECURE 1398720 BLOCK FREEMAP IN JOURNAL WRITE 1083 NON-SECURE 1398720 BLOCK FREEMAP IN JOURNAL WRITE 1084 NON-SECURE 1398389 GROUP DESCRIPTOR IN JOURNAL WRITE 1085 NON-SECURE 1398389 GROUP DESCRIPTOR IN JOURNAL WRITE 1086 NON-SECURE 1398391 INODE FREEMAP IN JOURNAL WRITE 1087 NON-SECURE 1398391 INODE FREEMAP IN JOURNAL WRITE 1088 NON-SECURE 1398732 8 JOURNAL COMMIT RECORD WRITE 1089 NON-SECURE 1398732 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 1398389 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1398389 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 1398389 GROUP DESCRIPTOR WRITE 5 NON-SECURE 1398389 GROUP DESCRIPTOR WRITE 518 NON-SECURE 1398720 BLOCK FREEMAP WRITE 519 NON-SECURE 1398720 BLOCK FREEMAP WRITE 520 NON-SECURE 1398391 INODE FREEMAP WRITE 521 NON-SECURE 1398391 INODE FREEMAP WRITE 522 NON-SECURE 1398391 2 INODE WRITE 523 NON-SECURE 1398391 2 INODE WRITE 524 SECURE 1398391 12 INODE WRITE 525 SECURE 1398391 12 INODE WRITE 1024 SECURE 1398633 2 DIR WRITE 1025 SECURE 1398633 2 DIR

Un-mount the file system Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK DELETE 1060 SECURE 1398391 8 INODE IN JOURNAL DELETE 1061 SECURE 1398391 8 INODE IN JOURNAL DELETE 1064 SECURE 1398633 8 DIR IN JOURNAL DELETE 1065 SECURE 1398633 8 DIR IN JOURNAL WRITE 1052 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK DELETE 1072 SECURE 1398633 8 DIR IN JOURNAL DELETE 1073 SECURE 1398633 8 DIR IN JOURNAL DELETE 1080 SECURE 1398391 8 INODE IN JOURNAL DELETE 1081 SECURE 1398391 8 INODE IN JOURNAL WRITE 1052 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK

Table A.1.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1053 NON-SECURE 1398393 8 JOURNAL SUPERBLOCK WRITE 2 NON-SECURE 1398389 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1398389 EXT3 SUPERBLOCK

Table A.1.3 creates and deletes a small, sensitive file with 13K of data to demonstrate what happens with sensitive file indirect blocks. During the “mount the file system” phase, the file system superblock is updated and written. During the “create secure file and sync” phase, the following sensitive blocks are written: i-node, directory (which contains the file name), indirect, and 13 1K data blocks. The sensitive metadata is written securely first to the file system journal and then to the final destination. During the “delete secure file and sync” phase, the file’s sensitive i-node and name are zeroed and written securely to the file system journal and then final destination. Before the file’s i-node is securely written to the journal, the file’s data and indirect blocks are securely deleted. Finally, during the “un-mount the file system” phase, the file system journal is purged. Two previous copies of the file’s secure i-node and name are securely deleted, as well as one copy of the indirect block.

Table A.1.3: Small File Trace (13K with Single Indirect) Mount the file system Action Sector Secure Status Page ID I-nodes Sector Type WRITE 2 NON-SECURE 1490951 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1490951 EXT3 SUPERBLOCK

Create secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 14338 SECURE 1491298 12 DATA WRITE 14339 SECURE 1491298 12 DATA WRITE 14340 SECURE 1491299 12 DATA WRITE 14341 SECURE 1491299 12 DATA WRITE 14342 SECURE 1491300 12 DATA WRITE 14343 SECURE 1491300 12 DATA WRITE 14344 SECURE 1491301 12 DATA WRITE 14345 SECURE 1491301 12 DATA WRITE 14346 SECURE 1491302 12 DATA WRITE 14347 SECURE 1491302 12 DATA

Table A.1.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 14348 SECURE 1491303 12 DATA WRITE 14349 SECURE 1491303 12 DATA WRITE 14350 SECURE 1491305 12 DATA WRITE 14351 SECURE 1491305 12 DATA WRITE 14352 SECURE 1491306 12 DATA WRITE 14353 SECURE 1491306 12 DATA WRITE 14354 SECURE 1491308 12 DATA WRITE 14355 SECURE 1491308 12 DATA WRITE 14356 SECURE 1491310 12 DATA WRITE 14357 SECURE 1491310 12 DATA WRITE 14358 SECURE 1491311 12 DATA WRITE 14359 SECURE 1491311 12 DATA WRITE 14360 SECURE 1491312 12 DATA WRITE 14361 SECURE 1491312 12 DATA WRITE 14364 SECURE 1491313 12 DATA WRITE 14365 SECURE 1491313 12 DATA WRITE 1052 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK WRITE 1054 NON-SECURE 1490956 8 JOURNAL DESCRIPTOR WRITE 1055 NON-SECURE 1490956 8 JOURNAL DESCRIPTOR WRITE 1056 NON-SECURE 1490953 INODE FREEMAP IN JOURNAL WRITE 1057 NON-SECURE 1490953 INODE FREEMAP IN JOURNAL WRITE 1058 NON-SECURE 1490951 GROUP DESCRIPTOR IN JOURNAL WRITE 1059 NON-SECURE 1490951 GROUP DESCRIPTOR IN JOURNAL WRITE 1060 SECURE 1490953 12 INODE IN JOURNAL WRITE 1061 SECURE 1490953 12 INODE IN JOURNAL WRITE 1062 NON-SECURE 1490953 2 INODE IN JOURNAL WRITE 1063 NON-SECURE 1490953 2 INODE IN JOURNAL WRITE 1064 SECURE 1491206 2 DIR IN JOURNAL WRITE 1065 SECURE 1491206 2 DIR IN JOURNAL WRITE 1066 NON-SECURE 1491291 BLOCK FREEMAP IN JOURNAL WRITE 1067 NON-SECURE 1491291 BLOCK FREEMAP IN JOURNAL WRITE 1068 SECURE 1491297 12 INDIRECT IN JOURNAL WRITE 1069 SECURE 1491297 12 INDIRECT IN JOURNAL WRITE 1070 NON-SECURE 1491316 8 JOURNAL COMMIT RECORD WRITE 1071 NON-SECURE 1491316 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 1490951 GROUP DESCRIPTOR WRITE 5 NON-SECURE 1490951 GROUP DESCRIPTOR WRITE 518 NON-SECURE 1491291 BLOCK FREEMAP WRITE 519 NON-SECURE 1491291 BLOCK FREEMAP

Table A.1.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 520 NON-SECURE 1490953 INODE FREEMAP WRITE 521 NON-SECURE 1490953 INODE FREEMAP WRITE 522 NON-SECURE 1490953 2 INODE WRITE 523 NON-SECURE 1490953 2 INODE WRITE 524 SECURE 1490953 12 INODE WRITE 525 SECURE 1490953 12 INODE WRITE 1024 SECURE 1491206 2 DIR WRITE 1025 SECURE 1491206 2 DIR WRITE 14362 SECURE 1491297 12 INDIRECT WRITE 14363 SECURE 1491297 12 INDIRECT

Delete secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1072 NON-SECURE 1491323 8 JOURNAL REVOKE DESCRIPTOR WRITE 1073 NON-SECURE 1491323 8 JOURNAL REVOKE DESCRIPTOR WRITE 1074 NON-SECURE 1491323 8 JOURNAL DESCRIPTOR WRITE 1075 NON-SECURE 1491323 8 JOURNAL DESCRIPTOR WRITE 1078 SECURE 1491206 2 DIR IN JOURNAL WRITE 1079 SECURE 1491206 2 DIR IN JOURNAL WRITE 1080 NON-SECURE 1490953 2 INODE IN JOURNAL WRITE 1081 NON-SECURE 1490953 2 INODE IN JOURNAL WRITE 1082 NON-SECURE 1490951 EXT3 SUPERBLOCK IN JOURNAL WRITE 1083 NON-SECURE 1490951 EXT3 SUPERBLOCK IN JOURNAL DELETE 14338 SECURE 1491318 12 DATA DELETE 14339 SECURE 1491318 12 DATA DELETE 14340 SECURE 1491318 12 DATA DELETE 14341 SECURE 1491318 12 DATA DELETE 14342 SECURE 1491318 12 DATA DELETE 14343 SECURE 1491318 12 DATA DELETE 14344 SECURE 1491319 12 DATA DELETE 14345 SECURE 1491319 12 DATA DELETE 14346 SECURE 1491319 12 DATA DELETE 14347 SECURE 1491319 12 DATA DELETE 14348 SECURE 1491319 12 DATA DELETE 14349 SECURE 1491319 12 DATA DELETE 14350 SECURE 1491319 12 DATA DELETE 14351 SECURE 1491319 12 DATA DELETE 14352 SECURE 1491320 12 DATA DELETE 14353 SECURE 1491320 12 DATA DELETE 14354 SECURE 1491320 12 DATA

Table A.1.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type DELETE 14355 SECURE 1491320 12 DATA DELETE 14356 SECURE 1491320 12 DATA DELETE 14357 SECURE 1491320 12 DATA DELETE 14358 SECURE 1491320 12 DATA DELETE 14359 SECURE 1491320 12 DATA DELETE 14360 SECURE 1491297 12 DATA DELETE 14361 SECURE 1491297 12 DATA DELETE 14364 SECURE 1491297 12 DATA DELETE 14365 SECURE 1491297 12 DATA DELETE 14362 SECURE 1491297 12 INDIRECT DELETE 14363 SECURE 1491297 12 INDIRECT WRITE 1084 SECURE 1490953 12 INODE IN JOURNAL WRITE 1085 SECURE 1490953 12 INODE IN JOURNAL WRITE 1086 NON-SECURE 1491291 BLOCK FREEMAP IN JOURNAL WRITE 1087 NON-SECURE 1491291 BLOCK FREEMAP IN JOURNAL WRITE 1088 NON-SECURE 1490951 GROUP DESCRIPTOR IN JOURNAL WRITE 1089 NON-SECURE 1490951 GROUP DESCRIPTOR IN JOURNAL WRITE 1090 NON-SECURE 1490953 INODE FREEMAP IN JOURNAL WRITE 1091 NON-SECURE 1490953 INODE FREEMAP IN JOURNAL WRITE 1092 NON-SECURE 1491325 8 JOURNAL COMMIT RECORD WRITE 1093 NON-SECURE 1491325 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 1490951 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1490951 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 1490951 GROUP DESCRIPTOR WRITE 5 NON-SECURE 1490951 GROUP DESCRIPTOR WRITE 518 NON-SECURE 1491291 BLOCK FREEMAP WRITE 519 NON-SECURE 1491291 BLOCK FREEMAP WRITE 520 NON-SECURE 1490953 INODE FREEMAP WRITE 521 NON-SECURE 1490953 INODE FREEMAP WRITE 522 NON-SECURE 1490953 2 INODE WRITE 523 NON-SECURE 1490953 2 INODE WRITE 524 SECURE 1490953 12 INODE WRITE 525 SECURE 1490953 12 INODE WRITE 1024 SECURE 1491206 2 DIR WRITE 1025 SECURE 1491206 2 DIR

Un-mount the file system Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK

Table A.1.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type DELETE 1060 SECURE 1490953 8 INODE IN JOURNAL DELETE 1061 SECURE 1490953 8 INODE IN JOURNAL DELETE 1064 SECURE 1491206 8 DIR IN JOURNAL DELETE 1065 SECURE 1491206 8 DIR IN JOURNAL DELETE 1068 SECURE 1491297 8 INDIRECT IN JOURNAL DELETE 1069 SECURE 1491297 8 INDIRECT IN JOURNAL WRITE 1052 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK DELETE 1078 SECURE 1491206 8 DIR IN JOURNAL DELETE 1079 SECURE 1491206 8 DIR IN JOURNAL DELETE 1084 SECURE 1490953 8 INODE IN JOURNAL DELETE 1085 SECURE 1490953 8 INODE IN JOURNAL WRITE 1052 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 1490956 8 JOURNAL SUPERBLOCK WRITE 2 NON-SECURE 1490951 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 1490951 EXT3 SUPERBLOCK

A.2. Moving Files

This subsection demonstrates traces derived from moving empty files into various directories. For all traces in this subsection, both the file and the directory are created in the root directory. Creation and deletion of the file and directory are omitted. Secure operations are highlighted. For all traces in this subsection, the file is associated with i-node 12, the root directory is associated with i-node 2, and the journal is associated with i-node 8. The move destination directory i-node number is variable. Table A.2.1 moves a non-secure file into a non-secure directory. The i-nodes of the root source directory, destination directory, and file are updated and written. In addition, both the source root directory block and destination directory block are updated and written. All metadata is first written to the file system journal before the metadata is written to the final destination.

Table A.2.1: Move Non-secure File into Non-secure Directory Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1078 NON-SECURE 1897715 8 JOURNAL DESCRIPTOR WRITE 1079 NON-SECURE 1897715 8 JOURNAL DESCRIPTOR 94

Table A.2.1 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1080 NON-SECURE 1897705 56225 INODE IN JOURNAL WRITE 1081 NON-SECURE 1897705 56225 INODE IN JOURNAL WRITE 1082 NON-SECURE 1897708 56225 DIR IN JOURNAL WRITE 1083 NON-SECURE 1897708 56225 DIR IN JOURNAL WRITE 1084 NON-SECURE 1897580 12 INODE IN JOURNAL WRITE 1085 NON-SECURE 1897580 12 INODE IN JOURNAL WRITE 1086 NON-SECURE 1897703 2 DIR IN JOURNAL WRITE 1087 NON-SECURE 1897703 2 DIR IN JOURNAL WRITE 1088 NON-SECURE 1897580 2 INODE IN JOURNAL WRITE 1089 NON-SECURE 1897580 2 INODE IN JOURNAL WRITE 1090 NON-SECURE 1897835 8 JOURNAL COMMIT RECORD WRITE 1091 NON-SECURE 1897835 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 1897580 2 INODE WRITE 523 NON-SECURE 1897580 2 INODE WRITE 524 NON-SECURE 1897580 12 INODE WRITE 525 NON-SECURE 1897580 12 INODE WRITE 1024 NON-SECURE 1897703 2 DIR WRITE 1025 NON-SECURE 1897703 2 DIR WRITE 458758 NON-SECURE 1897705 56225 INODE WRITE 458759 NON-SECURE 1897705 56225 INODE WRITE 460802 NON-SECURE 1897708 56225 DIR WRITE 460803 NON-SECURE 1897708 56225 DIR

Table A.2.2 moves a secure file into a non-secure directory. The i-node of the secure file is securely updated and written. Since a sensitive name is being securely zeroed out and moved from the root directory block to the destination directory block, both those directory blocks are securely updated and written. All metadata is first written to the file system journal before the metadata is written to the final destination.

Table A.2.2: Move Secure File into Non-secure Directory Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1078 NON-SECURE 1811737 8 JOURNAL DESCRIPTOR WRITE 1079 NON-SECURE 1811737 8 JOURNAL DESCRIPTOR WRITE 1080 NON-SECURE 1811646 18073 INODE IN JOURNAL WRITE 1081 NON-SECURE 1811646 18073 INODE IN JOURNAL WRITE 1082 SECURE 1811651 18073 DIR IN JOURNAL

Table A.2.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1083 SECURE 1811651 18073 DIR IN JOURNAL WRITE 1084 SECURE 1811522 12 INODE IN JOURNAL WRITE 1085 SECURE 1811522 12 INODE IN JOURNAL WRITE 1086 SECURE 1811644 2 DIR IN JOURNAL WRITE 1087 SECURE 1811644 2 DIR IN JOURNAL WRITE 1088 NON-SECURE 1811522 2 INODE IN JOURNAL WRITE 1089 NON-SECURE 1811522 2 INODE IN JOURNAL WRITE 1090 NON-SECURE 1811924 8 JOURNAL COMMIT RECORD WRITE 1091 NON-SECURE 1811924 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 1811522 2 INODE WRITE 523 NON-SECURE 1811522 2 INODE WRITE 524 SECURE 1811522 12 INODE WRITE 525 SECURE 1811522 12 INODE WRITE 1024 SECURE 1811644 2 DIR WRITE 1025 SECURE 1811644 2 DIR WRITE 147978 NON-SECURE 1811646 18073 INODE WRITE 147979 NON-SECURE 1811646 18073 INODE WRITE 148482 SECURE 1811651 18073 DIR WRITE 148483 SECURE 1811651 18073 DIR

Table A.2.3 moves a non-secure file into a secure directory. Since the file is not sensitive and remains non-sensitive after the move, the file’s i-node is not written securely. However, since the destination directory is sensitive, the destination directory’s i-node and directory block are securely written. Finally, the root directory is not sensitive, but it contains the name of the sensitive directory, so the root directory block is securely written as it is updated. All metadata is first written to the file system journal before the metadata is written to the final destination.

Table A.2.3: Move Non-secure File into Secure Directory Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1078 NON-SECURE 1984102 8 JOURNAL DESCRIPTOR WRITE 1079 NON-SECURE 1984102 8 JOURNAL DESCRIPTOR WRITE 1080 SECURE 1984014 38153 INODE IN JOURNAL WRITE 1081 SECURE 1984014 38153 INODE IN JOURNAL WRITE 1082 SECURE 1984017 38153 DIR IN JOURNAL

Table A.2.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1083 SECURE 1984017 38153 DIR IN JOURNAL WRITE 1084 NON-SECURE 1983889 12 INODE IN JOURNAL WRITE 1085 NON-SECURE 1983889 12 INODE IN JOURNAL WRITE 1086 SECURE 1984011 2 DIR IN JOURNAL WRITE 1087 SECURE 1984011 2 DIR IN JOURNAL WRITE 1088 NON-SECURE 1983889 2 INODE IN JOURNAL WRITE 1089 NON-SECURE 1983889 2 INODE IN JOURNAL WRITE 1090 NON-SECURE 1984282 8 JOURNAL COMMIT RECORD WRITE 1091 NON-SECURE 1984282 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 1983889 2 INODE WRITE 523 NON-SECURE 1983889 2 INODE WRITE 524 NON-SECURE 1983889 12 INODE WRITE 525 NON-SECURE 1983889 12 INODE WRITE 1024 SECURE 1984011 2 DIR WRITE 1025 SECURE 1984011 2 DIR WRITE 311302 SECURE 1984014 38153 INODE WRITE 311303 SECURE 1984014 38153 INODE WRITE 319490 SECURE 1984017 38153 DIR WRITE 319491 SECURE 1984017 38153 DIR

Table A.2.4 moves a secure file into a secure directory. The i-nodes of the root source directory, destination directory, and file are securely updated and written. In addition, both the source root directory block and destination directory block are securely updated and written. All metadata is first written to the file system journal before the metadata is written to the final destination.

Table A.2.4: Move Secure File into Secure Directory Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1078 NON-SECURE 2070154 8 JOURNAL DESCRIPTOR WRITE 1079 NON-SECURE 2070154 8 JOURNAL DESCRIPTOR WRITE 1080 SECURE 2069978 6025 INODE IN JOURNAL WRITE 1081 SECURE 2069978 6025 INODE IN JOURNAL WRITE 1082 SECURE 2069982 6025 DIR IN JOURNAL WRITE 1083 SECURE 2069982 6025 DIR IN JOURNAL WRITE 1084 SECURE 2069847 12 INODE IN JOURNAL

Table A.2.4 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1085 SECURE 2069847 12 INODE IN JOURNAL WRITE 1086 SECURE 2069975 2 DIR IN JOURNAL WRITE 1087 SECURE 2069975 2 DIR IN JOURNAL WRITE 1088 NON-SECURE 2069847 2 INODE IN JOURNAL WRITE 1089 NON-SECURE 2069847 2 INODE IN JOURNAL WRITE 1090 NON-SECURE 2070273 8 JOURNAL COMMIT RECORD WRITE 1091 NON-SECURE 2070273 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 2069847 2 INODE WRITE 523 NON-SECURE 2069847 2 INODE WRITE 524 SECURE 2069847 12 INODE WRITE 525 SECURE 2069847 12 INODE WRITE 1024 SECURE 2069975 2 DIR WRITE 1025 SECURE 2069975 2 DIR WRITE 49674 SECURE 2069978 6025 INODE WRITE 49675 SECURE 2069978 6025 INODE WRITE 58370 SECURE 2069982 6025 DIR WRITE 58371 SECURE 2069982 6025 DIR

A.3. Replacing Files

This subsection demonstrates traces derived from moving a source file onto a destination file. In other words, the source file replaces the destination file. For all traces in this subsection, both source and destination files are created in the root directory. Creation of the source and destination file is omitted, and deletion of the destination file is omitted. Secure operations are highlighted. For all traces in this subsection, the source file is associated with i-node 12, the destination file is associated with i-node 13, the root directory is associated with i-node 2, and the journal is associated with i-node 8. Table A.3.1 moves a non-secure file onto a non-secure file. The i-nodes of both the source and destination file are updated and written. Only one write is required, since both these i-nodes physically reside on one block. In addition, the i-node of the root directory is updated and written, as well as the root directory block. All metadata is first written to the file system journal before the metadata is written to the final destination.

Table A.3.1: Move Non-secure File onto Non-secure File Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 2565474 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 2565474 8 JOURNAL DESCRIPTOR WRITE 1070 NON-SECURE 2565469 2 DIR IN JOURNAL WRITE 1071 NON-SECURE 2565469 2 DIR IN JOURNAL WRITE 1072 NON-SECURE 2565145 12,13 INODE IN JOURNAL WRITE 1073 NON-SECURE 2565145 12,13 INODE IN JOURNAL WRITE 1074 NON-SECURE 2565145 2 INODE IN JOURNAL WRITE 1075 NON-SECURE 2565145 2 INODE IN JOURNAL WRITE 1078 NON-SECURE 2565143 EXT3 SUPERBLOCK IN JOURNAL WRITE 1079 NON-SECURE 2565143 EXT3 SUPERBLOCK IN JOURNAL WRITE 1080 NON-SECURE 2565143 GROUP DESCRIPTOR IN JOURNAL WRITE 1081 NON-SECURE 2565143 GROUP DESCRIPTOR IN JOURNAL WRITE 1082 NON-SECURE 2565145 INODE FREEMAP IN JOURNAL WRITE 1083 NON-SECURE 2565145 INODE FREEMAP IN JOURNAL WRITE 1084 NON-SECURE 2565719 8 JOURNAL COMMIT RECORD WRITE 1085 NON-SECURE 2565719 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 2565143 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 2565143 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 2565143 GROUP DESCRIPTOR WRITE 5 NON-SECURE 2565143 GROUP DESCRIPTOR WRITE 520 NON-SECURE 2565145 INODE FREEMAP WRITE 521 NON-SECURE 2565145 INODE FREEMAP WRITE 522 NON-SECURE 2565145 2 INODE WRITE 523 NON-SECURE 2565145 2 INODE WRITE 524 NON-SECURE 2565145 12,13 INODE WRITE 525 NON-SECURE 2565145 12,13 INODE WRITE 1024 NON-SECURE 2565469 2 DIR WRITE 1025 NON-SECURE 2565469 2 DIR

Table A.3.2 moves a secure file onto a non-secure file. The i-node of the secure source file is zeroed and securely written. Since the i-node of the destination file resides on the same block as the i-node of the secure source file, both end up being written securely. In addition, the name of the secure source file is securely zeroed, and the sensitive name replaces the name of the destination file. These actions cause the root directory block to be securely updated and written. All metadata is first written to the file system journal before the metadata is written to the final destination.

Table A.3.2: Move Secure File onto Non-secure File Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 2651464 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 2651464 8 JOURNAL DESCRIPTOR WRITE 1070 SECURE 2651376 2 DIR IN JOURNAL WRITE 1071 SECURE 2651376 2 DIR IN JOURNAL WRITE 1072 SECURE 2651249 12,13 INODE IN JOURNAL WRITE 1073 SECURE 2651249 12,13 INODE IN JOURNAL WRITE 1074 NON-SECURE 2651249 2 INODE IN JOURNAL WRITE 1075 NON-SECURE 2651249 2 INODE IN JOURNAL WRITE 1078 NON-SECURE 2651247 EXT3 SUPERBLOCK IN JOURNAL WRITE 1079 NON-SECURE 2651247 EXT3 SUPERBLOCK IN JOURNAL WRITE 1080 NON-SECURE 2651247 GROUP DESCRIPTOR IN JOURNAL WRITE 1081 NON-SECURE 2651247 GROUP DESCRIPTOR IN JOURNAL WRITE 1082 NON-SECURE 2651249 INODE FREEMAP IN JOURNAL WRITE 1083 NON-SECURE 2651249 INODE FREEMAP IN JOURNAL WRITE 1084 NON-SECURE 2651583 8 JOURNAL COMMIT RECORD WRITE 1085 NON-SECURE 2651583 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 2651247 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 2651247 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 2651247 GROUP DESCRIPTOR WRITE 5 NON-SECURE 2651247 GROUP DESCRIPTOR WRITE 520 NON-SECURE 2651249 INODE FREEMAP WRITE 521 NON-SECURE 2651249 INODE FREEMAP WRITE 522 NON-SECURE 2651249 2 INODE WRITE 523 NON-SECURE 2651249 2 INODE WRITE 524 SECURE 2651249 12,13 INODE WRITE 525 SECURE 2651249 12,13 INODE WRITE 1024 SECURE 2651376 2 DIR WRITE 1025 SECURE 2651376 2 DIR

Table A.3.3 moves a non-secure file onto a secure file. Since moving one file on top of another file causes the destination file to be deleted, the i-node of the secure destination file is zeroed and securely written. Since the i-node of the source file resides on the same block as the i-node of the destination file, both end up being written securely. The root directory block is not written securely, because the name of the destination file is no longer secure. All metadata is first written to the file system journal before the metadata is written to the final destination.

100

Table A.3.3: Move Non-secure File onto Secure File Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 2737144 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 2737144 8 JOURNAL DESCRIPTOR WRITE 1070 NON-SECURE 2737056 2 DIR IN JOURNAL WRITE 1071 NON-SECURE 2737056 2 DIR IN JOURNAL WRITE 1072 SECURE 2736934 12,13 INODE IN JOURNAL WRITE 1073 SECURE 2736934 12,13 INODE IN JOURNAL WRITE 1074 NON-SECURE 2736934 2 INODE IN JOURNAL WRITE 1075 NON-SECURE 2736934 2 INODE IN JOURNAL WRITE 1078 NON-SECURE 2736932 EXT3 SUPERBLOCK IN JOURNAL WRITE 1079 NON-SECURE 2736932 EXT3 SUPERBLOCK IN JOURNAL WRITE 1080 NON-SECURE 2736932 GROUP DESCRIPTOR IN JOURNAL WRITE 1081 NON-SECURE 2736932 GROUP DESCRIPTOR IN JOURNAL WRITE 1082 NON-SECURE 2736934 INODE FREEMAP IN JOURNAL WRITE 1083 NON-SECURE 2736934 INODE FREEMAP IN JOURNAL WRITE 1084 NON-SECURE 2737263 8 JOURNAL COMMIT RECORD WRITE 1085 NON-SECURE 2737263 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 2736932 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 2736932 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 2736932 GROUP DESCRIPTOR WRITE 5 NON-SECURE 2736932 GROUP DESCRIPTOR WRITE 520 NON-SECURE 2736934 INODE FREEMAP WRITE 521 NON-SECURE 2736934 INODE FREEMAP WRITE 522 NON-SECURE 2736934 2 INODE WRITE 523 NON-SECURE 2736934 2 INODE WRITE 524 SECURE 2736934 12,13 INODE WRITE 525 SECURE 2736934 12,13 INODE WRITE 1024 NON-SECURE 2737056 2 DIR WRITE 1025 NON-SECURE 2737056 2 DIR

Table A.3.4 moves a secure file onto a secure file. The i-nodes of both the source and destination file are securely updated and written. Only one write is required, since both these i- nodes physically reside on one block. In addition, the root directory block is securely updated, since it must securely zero out the name of the source file and the destination file is secure. All metadata is first written to the file system journal before the metadata is written to the final destination.

101

Table A.3.4: Move Secure File onto Secure File Trace Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 2822944 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 2822944 8 JOURNAL DESCRIPTOR WRITE 1070 SECURE 2822781 2 DIR IN JOURNAL WRITE 1071 SECURE 2822781 2 DIR IN JOURNAL WRITE 1072 SECURE 2822653 12,13 INODE IN JOURNAL WRITE 1073 SECURE 2822653 12,13 INODE IN JOURNAL WRITE 1074 NON-SECURE 2822653 2 INODE IN JOURNAL WRITE 1075 NON-SECURE 2822653 2 INODE IN JOURNAL WRITE 1078 NON-SECURE 2822651 EXT3 SUPERBLOCK IN JOURNAL WRITE 1079 NON-SECURE 2822651 EXT3 SUPERBLOCK IN JOURNAL WRITE 1080 NON-SECURE 2822651 GROUP DESCRIPTOR IN JOURNAL WRITE 1081 NON-SECURE 2822651 GROUP DESCRIPTOR IN JOURNAL WRITE 1082 NON-SECURE 2822653 INODE FREEMAP IN JOURNAL WRITE 1083 NON-SECURE 2822653 INODE FREEMAP IN JOURNAL WRITE 1084 NON-SECURE 2823071 8 JOURNAL COMMIT RECORD WRITE 1085 NON-SECURE 2823071 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 2822651 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 2822651 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 2822651 GROUP DESCRIPTOR WRITE 5 NON-SECURE 2822651 GROUP DESCRIPTOR WRITE 520 NON-SECURE 2822653 INODE FREEMAP WRITE 521 NON-SECURE 2822653 INODE FREEMAP WRITE 522 NON-SECURE 2822653 2 INODE WRITE 523 NON-SECURE 2822653 2 INODE WRITE 524 SECURE 2822653 12,13 INODE WRITE 525 SECURE 2822653 12,13 INODE WRITE 1024 SECURE 2822781 2 DIR WRITE 1025 SECURE 2822781 2 DIR

A.4. Symlinks and Hard Links

This subsection demonstrates traces derived from creating and updating symlinks and hard links that point to sensitively-marked files. First, an original secure file is created in the root directory, and the link is created which points to the secure file. For all traces in this subsection, both the file and the link are created in the root directory. Next, the file is updated by writing 1K of data to the link. Finally, the link and file are deleted. Secure operations are highlighted. For all

102 traces in this subsection, the file is associated with i-node 12, the symlink is associated with i- node 13, the root directory is associated with i-node 2, and the journal is associated with i-node 8. Table A.4.1 creates, updates, and deletes a symlink that points to a secure file and is broken down into phases. For all phases, all metadata is first written to the file system journal before the metadata is written to the final destination. During the “create the secure file and sync” phase, the sensitive i-node for the file is updated and securely written. The file’s name is also securely written in the root directory’s block. The next phase is the “create the symlink and sync” phase. The i-node for the symlink and name of the symlink are updated and written. Recall from subsection 3.2.3 that symlink names and metadata will not be treated sensitively due to the lack of a symlink sensitive bit in the user model. However, because the symlink i-node (13) is co-located on the same file system block as the file’s sensitive i-node (12), the entire i-node block must be updated and written sensitively. Similarly, the root directory block must be updated and written sensitively because the block contains the sensitive file’s name. During the “update the symlink” phase, 1K of data is written to the symlink. Recall from subsection 3.2.3 that data pointed to by a symlink will be treated sensitively or non-sensitively based on the sensitive status of the file’s i-node. Since the file’s i-node is sensitive, the data is securely written. In addition, the i-nodes for the secure file and symlink are updated and securely written. Next, the symlink is deleted during the “delete the symlink and sync” phase. The i-node block that contained the symlink’s i-node (13) is securely updated because it contains the sensitive file’s i-node (12). Similarly, the root directory block must be updated and written sensitively because the block contains the sensitive file’s name. Finally, during the “delete the secure file and sync” phase, the file’s sensitive i-node and name are zeroed and written securely to the file system journal and then final destination. Before the file’s i-node is securely written to the journal, the file’s data blocks are securely deleted.

103

Table A.4.1: Secure Symlink Trace Create the secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 247179 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 247179 8 JOURNAL SUPERBLOCK WRITE 1054 NON-SECURE 247179 8 JOURNAL DESCRIPTOR WRITE 1055 NON-SECURE 247179 8 JOURNAL DESCRIPTOR WRITE 1056 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1057 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1058 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1059 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1060 SECURE 247177 12 INODE IN JOURNAL WRITE 1061 SECURE 247177 12 INODE IN JOURNAL WRITE 1062 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1063 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1064 SECURE 247414 2 DIR IN JOURNAL WRITE 1065 SECURE 247414 2 DIR IN JOURNAL WRITE 1066 NON-SECURE 247501 8 JOURNAL COMMIT RECORD WRITE 1067 NON-SECURE 247501 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 5 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 520 NON-SECURE 247177 INODE FREEMAP WRITE 521 NON-SECURE 247177 INODE FREEMAP WRITE 522 NON-SECURE 247177 2 INODE WRITE 523 NON-SECURE 247177 2 INODE WRITE 524 SECURE 247177 12 INODE WRITE 525 SECURE 247177 12 INODE WRITE 1024 SECURE 247414 2 DIR WRITE 1025 SECURE 247414 2 DIR

Create the symlink and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 247501 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 247501 8 JOURNAL DESCRIPTOR WRITE 1070 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1071 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1072 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1073 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1074 SECURE 247177 13 INODE IN JOURNAL WRITE 1075 SECURE 247177 13 INODE IN JOURNAL WRITE 1078 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1079 NON-SECURE 247177 2 INODE IN JOURNAL

104

Table A.4.1 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1080 SECURE 247414 2 DIR IN JOURNAL WRITE 1081 SECURE 247414 2 DIR IN JOURNAL WRITE 1082 NON-SECURE 247557 8 JOURNAL COMMIT RECORD WRITE 1083 NON-SECURE 247557 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 5 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 520 NON-SECURE 247177 INODE FREEMAP WRITE 521 NON-SECURE 247177 INODE FREEMAP WRITE 522 NON-SECURE 247177 2 INODE WRITE 523 NON-SECURE 247177 2 INODE WRITE 524 SECURE 247177 13 INODE WRITE 525 SECURE 247177 13 INODE WRITE 1024 SECURE 247414 2 DIR WRITE 1025 SECURE 247414 2 DIR

Update the symlink and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 13314 SECURE 247624 12 DATA WRITE 13315 SECURE 247624 12 DATA WRITE 1084 NON-SECURE 247557 8 JOURNAL DESCRIPTOR WRITE 1085 NON-SECURE 247557 8 JOURNAL DESCRIPTOR WRITE 1086 SECURE 247177 13,12 INODE IN JOURNAL WRITE 1087 SECURE 247177 13,12 INODE IN JOURNAL WRITE 1088 NON-SECURE 247622 BLOCK FREEMAP IN JOURNAL WRITE 1089 NON-SECURE 247622 BLOCK FREEMAP IN JOURNAL WRITE 1090 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1091 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1092 NON-SECURE 247625 8 JOURNAL COMMIT RECORD WRITE 1093 NON-SECURE 247625 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 5 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 518 NON-SECURE 247622 BLOCK FREEMAP WRITE 519 NON-SECURE 247622 BLOCK FREEMAP WRITE 524 SECURE 247177 13,12 INODE IN JOURNAL WRITE 525 SECURE 247177 13,12 INODE IN JOURNAL

Delete the symlink and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1094 NON-SECURE 247625 8 JOURNAL DESCRIPTOR WRITE 1095 NON-SECURE 247625 8 JOURNAL DESCRIPTOR

105

Table A.4.1 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1096 SECURE 247414 2 DIR IN JOURNAL WRITE 1097 SECURE 247414 2 DIR IN JOURNAL WRITE 1098 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1099 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1100 NON-SECURE 247146 EXT3 SUPERBLOCK IN JOURNAL WRITE 1101 NON-SECURE 247146 EXT3 SUPERBLOCK IN JOURNAL WRITE 1102 SECURE 247177 13 INODE IN JOURNAL WRITE 1103 SECURE 247177 13 INODE IN JOURNAL WRITE 1104 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1105 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1106 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1107 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1108 NON-SECURE 247686 8 JOURNAL COMMIT RECORD WRITE 1109 NON-SECURE 247686 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 247146 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 247146 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 5 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 520 NON-SECURE 247177 INODE FREEMAP WRITE 521 NON-SECURE 247177 INODE FREEMAP WRITE 522 NON-SECURE 247177 2 INODE WRITE 523 NON-SECURE 247177 2 INODE WRITE 524 SECURE 247177 13 INODE WRITE 525 SECURE 247177 13 INODE WRITE 1024 SECURE 247414 2 DIR WRITE 1025 SECURE 247414 2 DIR

Delete the secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1110 NON-SECURE 247686 8 JOURNAL DESCRIPTOR WRITE 1111 NON-SECURE 247686 8 JOURNAL DESCRIPTOR WRITE 1112 SECURE 247414 2 DIR IN JOURNAL WRITE 1113 SECURE 247414 2 DIR IN JOURNAL WRITE 1114 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1115 NON-SECURE 247177 2 INODE IN JOURNAL WRITE 1116 NON-SECURE 247146 EXT3 SUPERBLOCK IN JOURNAL WRITE 1117 NON-SECURE 247146 EXT3 SUPERBLOCK IN JOURNAL DELETE 13314 SECURE 247743 12 DATA DELETE 13315 SECURE 247743 12 DATA WRITE 1118 SECURE 247177 12 INODE IN JOURNAL

106

Table A.4.1 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1119 SECURE 247177 12 INODE IN JOURNAL WRITE 1120 NON-SECURE 247622 BLOCK FREEMAP IN JOURNAL WRITE 1121 NON-SECURE 247622 BLOCK FREEMAP IN JOURNAL WRITE 1122 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1123 NON-SECURE 247146 GROUP DESCRIPTOR IN JOURNAL WRITE 1124 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1125 NON-SECURE 247177 INODE FREEMAP IN JOURNAL WRITE 1126 NON-SECURE 247746 8 JOURNAL COMMIT RECORD WRITE 1127 NON-SECURE 247746 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 247146 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 247146 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 5 NON-SECURE 247146 GROUP DESCRIPTOR WRITE 518 NON-SECURE 247622 BLOCK FREEMAP WRITE 519 NON-SECURE 247622 BLOCK FREEMAP WRITE 520 NON-SECURE 247177 INODE FREEMAP WRITE 521 NON-SECURE 247177 INODE FREEMAP WRITE 522 NON-SECURE 247177 2 INODE WRITE 523 NON-SECURE 247177 2 INODE WRITE 524 SECURE 247177 12 INODE WRITE 525 SECURE 247177 12 INODE WRITE 1024 SECURE 247414 2 DIR WRITE 1025 SECURE 247414 2 DIR

Table A.4.2 creates and updates a secure hard link and is broken down into phases. For all phases, all metadata is first written to the file system journal before the metadata is written to the final destination. During the “create the secure file and sync” phase, the sensitive i-node for the file is updated and securely written. The file’s name is also securely written in the root directory’s block. Next, during the “create the secure hard link” phase, the sensitive i-node for the file is updated and securely written. In addition, the root directory block is securely written because it contains the names of the secure file and hard link. During the “update the secure hard link and sync” phase, 1K of data is written to the hard link, which causes the data to be securely written. In addition, the i-node for the secure file is updated and securely written. Next, in the “delete the secure hard link and sync” phase, the hard link is securely deleted by zeroing out the hard link’s

107 name in the root directory block and securely writing that block. In addition, the file’s i-node is securely updated. Finally, in the “delete the secure file and sync” phase, the file’s sensitive i- node and name are zeroed and written securely to the file system journal and then final destination. Before the file’s i-node is securely written to the journal, the file’s data blocks are securely deleted.

Table A.4.2: Secure Hard Link Trace (a) Create the secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 335735 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 335735 8 JOURNAL SUPERBLOCK WRITE 1054 NON-SECURE 335735 8 JOURNAL DESCRIPTOR WRITE 1055 NON-SECURE 335735 8 JOURNAL DESCRIPTOR WRITE 1056 NON-SECURE 335731 INODE FREEMAP IN JOURNAL WRITE 1057 NON-SECURE 335731 INODE FREEMAP IN JOURNAL WRITE 1058 NON-SECURE 335699 GROUP DESCRIPTOR IN JOURNAL WRITE 1059 NON-SECURE 335699 GROUP DESCRIPTOR IN JOURNAL WRITE 1060 SECURE 335731 12 INODE IN JOURNAL WRITE 1061 SECURE 335731 12 INODE IN JOURNAL WRITE 1062 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1063 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1064 SECURE 335942 2 DIR IN JOURNAL WRITE 1065 SECURE 335942 2 DIR IN JOURNAL WRITE 1066 NON-SECURE 336028 8 JOURNAL COMMIT RECORD WRITE 1067 NON-SECURE 336028 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 335699 GROUP DESCRIPTOR WRITE 5 NON-SECURE 335699 GROUP DESCRIPTOR WRITE 520 NON-SECURE 335731 INODE FREEMAP WRITE 521 NON-SECURE 335731 INODE FREEMAP WRITE 522 NON-SECURE 335731 2 INODE WRITE 523 NON-SECURE 335731 2 INODE WRITE 524 SECURE 335731 12 INODE WRITE 525 SECURE 335731 12 INODE WRITE 1024 SECURE 335942 2 DIR WRITE 1025 SECURE 335942 2 DIR

Create the secure hard link and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 336028 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 336028 8 JOURNAL DESCRIPTOR WRITE 1070 NON-SECURE 335731 2 INODE IN JOURNAL

108

Table A.4.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1071 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1072 SECURE 335942 2 DIR IN JOURNAL WRITE 1073 SECURE 335942 2 DIR IN JOURNAL WRITE 1074 SECURE 335731 12 INODE IN JOURNAL WRITE 1075 SECURE 335731 12 INODE IN JOURNAL WRITE 1078 NON-SECURE 336086 8 JOURNAL COMMIT RECORD WRITE 1079 NON-SECURE 336086 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 335731 2 INODE WRITE 523 NON-SECURE 335731 2 INODE WRITE 524 SECURE 335731 12 INODE WRITE 525 SECURE 335731 12 INODE WRITE 1024 SECURE 335942 2 DIR WRITE 1025 SECURE 335942 2 DIR

Update the secure hard link and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 9280 SECURE 336149 12 DATA WRITE 9281 SECURE 336149 12 DATA WRITE 1080 NON-SECURE 336150 8 JOURNAL DESCRIPTOR WRITE 1081 NON-SECURE 336150 8 JOURNAL DESCRIPTOR WRITE 1082 SECURE 335731 12 INODE IN JOURNAL WRITE 1083 SECURE 335731 12 INODE IN JOURNAL WRITE 1084 NON-SECURE 336147 BLOCK FREEMAP IN JOURNAL WRITE 1085 NON-SECURE 336147 BLOCK FREEMAP IN JOURNAL WRITE 1086 NON-SECURE 335699 GROUP DESCRIPTOR IN JOURNAL WRITE 1087 NON-SECURE 335699 GROUP DESCRIPTOR IN JOURNAL WRITE 1088 NON-SECURE 336152 8 JOURNAL COMMIT RECORD WRITE 1089 NON-SECURE 336152 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 335699 GROUP DESCRIPTOR WRITE 5 NON-SECURE 335699 GROUP DESCRIPTOR WRITE 518 NON-SECURE 336147 BLOCK FREEMAP WRITE 519 NON-SECURE 336147 BLOCK FREEMAP WRITE 524 SECURE 335731 12 INODE WRITE 525 SECURE 335731 12 INODE

Delete the secure hard link and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1090 NON-SECURE 336152 8 JOURNAL DESCRIPTOR WRITE 1091 NON-SECURE 336152 8 JOURNAL DESCRIPTOR WRITE 1092 SECURE 335942 2 DIR IN JOURNAL

109

Table A.4.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1093 SECURE 335942 2 DIR IN JOURNAL WRITE 1094 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1095 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1096 SECURE 335731 12 INODE IN JOURNAL WRITE 1097 SECURE 335731 12 INODE IN JOURNAL WRITE 1098 NON-SECURE 336211 8 JOURNAL COMMIT RECORD WRITE 1099 NON-SECURE 336211 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 335731 2 INODE WRITE 523 NON-SECURE 335731 2 INODE WRITE 524 SECURE 335731 12 INODE WRITE 525 SECURE 335731 12 INODE WRITE 1024 SECURE 335942 2 DIR WRITE 1025 SECURE 335942 2 DIR

Delete the secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1100 NON-SECURE 336211 8 JOURNAL DESCRIPTOR WRITE 1101 NON-SECURE 336211 8 JOURNAL DESCRIPTOR WRITE 1102 SECURE 335942 2 DIR IN JOURNAL WRITE 1103 SECURE 335942 2 DIR IN JOURNAL WRITE 1104 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1105 NON-SECURE 335731 2 INODE IN JOURNAL WRITE 1106 NON-SECURE 335699 EXT3 SUPERBLOCK IN JOURNAL WRITE 1107 NON-SECURE 335699 EXT3 SUPERBLOCK IN JOURNAL DELETE 9280 SECURE 336266 12 DATA DELETE 9281 SECURE 336266 12 DATA WRITE 1108 SECURE 335731 12 INODE IN JOURNAL WRITE 1109 SECURE 335731 12 INODE IN JOURNAL WRITE 1110 NON-SECURE 336147 BLOCK FREEMAP IN JOURNAL WRITE 1111 NON-SECURE 336147 BLOCK FREEMAP IN JOURNAL WRITE 1112 NON-SECURE 335699 GROUP DESCRIPTOR IN JOURNAL WRITE 1113 NON-SECURE 335699 GROUP DESCRIPTOR IN JOURNAL WRITE 1114 NON-SECURE 335731 INODE FREEMAP IN JOURNAL WRITE 1115 NON-SECURE 335731 INODE FREEMAP IN JOURNAL WRITE 1116 NON-SECURE 336269 8 JOURNAL COMMIT RECORD WRITE 1117 NON-SECURE 336269 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 335699 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 335699 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 335699 GROUP DESCRIPTOR WRITE 5 NON-SECURE 335699 GROUP DESCRIPTOR

110

Table A.4.2 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 518 NON-SECURE 336147 BLOCK FREEMAP WRITE 519 NON-SECURE 336147 BLOCK FREEMAP WRITE 520 NON-SECURE 335731 INODE FREEMAP WRITE 521 NON-SECURE 335731 INODE FREEMAP WRITE 522 NON-SECURE 335731 2 INODE WRITE 523 NON-SECURE 335731 2 INODE WRITE 524 SECURE 335731 12 INODE WRITE 525 SECURE 335731 12 INODE WRITE 1024 SECURE 335942 2 DIR WRITE 1025 SECURE 335942 2 DIR

Table A.4.3 illustrates the same trace as Table A.4.2, except that the file is deleted before the hard link. We see that the file’s data is not securely deleted until the file’s link count becomes zero (e.g. secure deletion of the hard link).

Table A.4.3: Secure Hard Link Trace (b) Create the secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1052 NON-SECURE 423803 8 JOURNAL SUPERBLOCK WRITE 1053 NON-SECURE 423803 8 JOURNAL SUPERBLOCK WRITE 1054 NON-SECURE 423803 8 JOURNAL DESCRIPTOR WRITE 1055 NON-SECURE 423803 8 JOURNAL DESCRIPTOR WRITE 1056 NON-SECURE 423801 INODE FREEMAP IN JOURNAL WRITE 1057 NON-SECURE 423801 INODE FREEMAP IN JOURNAL WRITE 1058 NON-SECURE 423769 GROUP DESCRIPTOR IN JOURNAL WRITE 1059 NON-SECURE 423769 GROUP DESCRIPTOR IN JOURNAL WRITE 1060 SECURE 423801 12 INODE IN JOURNAL WRITE 1061 SECURE 423801 12 INODE IN JOURNAL WRITE 1062 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1063 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1064 SECURE 424012 2 DIR IN JOURNAL WRITE 1065 SECURE 424012 2 DIR IN JOURNAL WRITE 1066 NON-SECURE 424107 8 JOURNAL COMMIT RECORD WRITE 1067 NON-SECURE 424107 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 423769 GROUP DESCRIPTOR WRITE 5 NON-SECURE 423769 GROUP DESCRIPTOR WRITE 520 NON-SECURE 423801 INODE FREEMAP

111

Table A.4.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 521 NON-SECURE 423801 INODE FREEMAP WRITE 522 NON-SECURE 423801 2 INODE WRITE 523 NON-SECURE 423801 2 INODE WRITE 524 SECURE 423801 12 INODE WRITE 525 SECURE 423801 12 INODE WRITE 1024 SECURE 424012 2 DIR WRITE 1025 SECURE 424012 2 DIR

Create the secure hard link and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1068 NON-SECURE 424107 8 JOURNAL DESCRIPTOR WRITE 1069 NON-SECURE 424107 8 JOURNAL DESCRIPTOR WRITE 1070 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1071 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1072 SECURE 424012 2 DIR IN JOURNAL WRITE 1073 SECURE 424012 2 DIR IN JOURNAL WRITE 1074 SECURE 423801 12 INODE IN JOURNAL WRITE 1075 SECURE 423801 12 INODE IN JOURNAL WRITE 1078 NON-SECURE 424160 8 JOURNAL COMMIT RECORD WRITE 1079 NON-SECURE 424160 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 423801 2 INODE WRITE 523 NON-SECURE 423801 2 INODE WRITE 524 SECURE 423801 12 INODE WRITE 525 SECURE 423801 12 INODE WRITE 1024 SECURE 424012 2 DIR WRITE 1025 SECURE 424012 2 DIR

Update the secure hard link and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 9280 SECURE 424221 12 DATA WRITE 9281 SECURE 424221 12 DATA WRITE 1080 NON-SECURE 424222 8 JOURNAL DESCRIPTOR WRITE 1081 NON-SECURE 424222 8 JOURNAL DESCRIPTOR WRITE 1082 SECURE 423801 12 INODE IN JOURNAL WRITE 1083 SECURE 423801 12 INODE IN JOURNAL WRITE 1084 NON-SECURE 424219 BLOCK FREEMAP IN JOURNAL WRITE 1085 NON-SECURE 424219 BLOCK FREEMAP IN JOURNAL WRITE 1086 NON-SECURE 423769 GROUP DESCRIPTOR IN JOURNAL WRITE 1087 NON-SECURE 423769 GROUP DESCRIPTOR IN JOURNAL WRITE 1088 NON-SECURE 424223 8 JOURNAL COMMIT RECORD

112

Table A.4.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1089 NON-SECURE 424223 8 JOURNAL COMMIT RECORD WRITE 4 NON-SECURE 423769 GROUP DESCRIPTOR WRITE 5 NON-SECURE 423769 GROUP DESCRIPTOR WRITE 518 NON-SECURE 424219 BLOCK FREEMAP WRITE 519 NON-SECURE 424219 BLOCK FREEMAP WRITE 524 SECURE 423801 12 INODE WRITE 525 SECURE 423801 12 INODE

Delete the secure file and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1090 NON-SECURE 424223 8 JOURNAL DESCRIPTOR WRITE 1091 NON-SECURE 424223 8 JOURNAL DESCRIPTOR WRITE 1092 SECURE 424012 2 DIR IN JOURNAL WRITE 1093 SECURE 424012 2 DIR IN JOURNAL WRITE 1094 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1095 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1096 SECURE 423801 12 INODE IN JOURNAL WRITE 1097 SECURE 423801 12 INODE IN JOURNAL WRITE 1098 NON-SECURE 424274 8 JOURNAL COMMIT RECORD WRITE 1099 NON-SECURE 424274 8 JOURNAL COMMIT RECORD WRITE 522 NON-SECURE 423801 2 INODE WRITE 523 NON-SECURE 423801 2 INODE WRITE 524 SECURE 423801 12 INODE WRITE 525 SECURE 423801 12 INODE WRITE 1024 SECURE 424012 2 DIR WRITE 1025 SECURE 424012 2 DIR

Delete the secure hard link and sync Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1100 NON-SECURE 424274 8 JOURNAL DESCRIPTOR WRITE 1101 NON-SECURE 424274 8 JOURNAL DESCRIPTOR WRITE 1102 SECURE 424012 2 DIR IN JOURNAL WRITE 1103 SECURE 424012 2 DIR IN JOURNAL WRITE 1104 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1105 NON-SECURE 423801 2 INODE IN JOURNAL WRITE 1106 NON-SECURE 423769 EXT3 SUPERBLOCK IN JOURNAL WRITE 1107 NON-SECURE 423769 EXT3 SUPERBLOCK IN JOURNAL DELETE 9280 SECURE 424325 12 DATA DELETE 9281 SECURE 424325 12 DATA WRITE 1108 SECURE 423801 12 INODE IN JOURNAL

113

Table A.4.3 continued

Action Sector Secure Status Page ID I-nodes Sector Type WRITE 1109 SECURE 423801 12 INODE IN JOURNAL WRITE 1110 NON-SECURE 424219 BLOCK FREEMAP IN JOURNAL WRITE 1111 NON-SECURE 424219 BLOCK FREEMAP IN JOURNAL WRITE 1112 NON-SECURE 423769 GROUP DESCRIPTOR IN JOURNAL WRITE 1113 NON-SECURE 423769 GROUP DESCRIPTOR IN JOURNAL WRITE 1114 NON-SECURE 423801 INODE FREEMAP IN JOURNAL WRITE 1115 NON-SECURE 423801 INODE FREEMAP IN JOURNAL WRITE 1116 NON-SECURE 424328 8 JOURNAL COMMIT RECORD WRITE 1117 NON-SECURE 424328 8 JOURNAL COMMIT RECORD WRITE 2 NON-SECURE 423769 EXT3 SUPERBLOCK WRITE 3 NON-SECURE 423769 EXT3 SUPERBLOCK WRITE 4 NON-SECURE 423769 GROUP DESCRIPTOR WRITE 5 NON-SECURE 423769 GROUP DESCRIPTOR WRITE 518 NON-SECURE 424219 BLOCK FREEMAP WRITE 519 NON-SECURE 424219 BLOCK FREEMAP WRITE 520 NON-SECURE 423801 INODE FREEMAP WRITE 521 NON-SECURE 423801 INODE FREEMAP WRITE 522 NON-SECURE 423801 2 INODE WRITE 523 NON-SECURE 423801 2 INODE WRITE 524 SECURE 423801 12 INODE WRITE 525 SECURE 423801 12 INODE WRITE 1024 SECURE 424012 2 DIR WRITE 1025 SECURE 424012 2 DIR

114

APPENDIX B

PERMISSIONS

Parts of this dissertation have been published in other forms; copyrights of those works are held by the Association of Computing Machinery. In all cases, permission has been granted to include these materials in this dissertation.

ACM COPYRIGHT NOTICE. Copyright © 2010, 2012 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept., ACM, Inc., fax +1 (212) 869-0481, or [email protected].

This dissertation contains excerpts, figures, and tables from the following publications:

Diesburg, S., Meyers, C., Stanovich, M., Mitchell, M., Marshall, J., Gould, J., Wang, A.I.A. and Kuenning, G. 2012. TrueErase: Per-file Secure Deletion for the Storage Data Path. Proceedings of the 28th Annual Computer Security Applications Conference (Dec. 2012). Diesburg, S.M. and Wang, A.-I.A. 2010. A survey of confidential data storage and deletion methods. ACM Computing Surveys. 43, 1 (Dec. 2010), 2:1–2:37.

115

REFERENCES

[1] “2.4.15-final:” 2001. http://marc.info/?l=linux-kernel&m=100650331813822&w=2. Accessed: 2012-09-13.

[2] Ban, A. 1995. Flash file system. Google Patents.

[3] Bauer, S. and Priyantha, N.B. 2001. Secure data deletion for Linux file systems. Proceedings of the 10th Usenix Security Symposium (2001), 153–164.

[4] Block layer discard requests [LWN.net]: 2008. https://lwn.net/Articles/293658/. Accessed: 2012-09-30.

[5] Boneh, D. and Lipton, R. 1996. A revocable backup system. USENIX Security Symposium (1996), 91–96.

[6] Boyko, V. 1999. On the security properties of OAEP as an all-or-nothing transform. Advances in Cryptology—Crypto’99 (1999), 783–783.

[7] Can Intelligence Agencies Read Overwritten Data?: 2011. http://www.nber.org/sys- admin/overwritten-data-guttman.html. Accessed: 2012-09-29.

[8] Cisco Survey Designates 10 Riskiest Data Loss Behaviors: 2008. http://www.crn.com/news/security/210604893/cisco-survey-designates-10-riskiest-data-loss- behaviors.htm. Accessed: 2012-08-07.

[9] Cooke, J. 2007. Flash memory technology direction. Micron Applications Engineering Document. (2007).

[10] CWE - CWE-327: Use of a Broken or Risky Cryptographic Algorithm (2.2): http://cwe.mitre.org/data/definitions/327.html. Accessed: 2012-09-05.

[11] Darik’s Boot And Nuke | Hard Drive Disk Wipe and Data Clearing: http://www.dban.org/. Accessed: 2012-09-25.

[12] Diesburg, S., Meyers, C., Stanovich, M., Mitchell, M., Marshall, J., Gould, J., Wang, A.I.A. and Kuenning, G. 2012. TrueErase: Per-file Secure Deletion for the Storage Data Path. Proceedings of the 28th Annual Computer Security Applications Conference (Dec. 2012).

[13] Diesburg, S.M., Meyers, C.R., Lary, D.M. and Wang, A.I.A. 2008. When cryptography meets storage. Proceedings of the 4th ACM International Workshop on Storage Security and Survivability (2008), 11–20.

[14] Diesburg, S.M. and Wang, A.-I.A. 2010. A survey of confidential data storage and deletion methods. ACM Computing Surveys. 43, 1 (Dec. 2010), 2:1–2:37.

116

[15] End-User I/O Requests and File Objects: http://msdn.microsoft.com/en- us/library/windows/hardware/ff544248(v=vs.85).aspx. Accessed: 2012-08-30.

[16] Example I/O Request - An Overview: http://msdn.microsoft.com/en- us/library/windows/hardware/ff544531(v=vs.85).aspx. Accessed: 2012-08-30.

[17] Ganger, G.R. 2001. Blurring the line between OSes and storage devices. Technical Report CMU-CS-01-166, Carnegie Mellon University.

[18] Garfinkel, S.L. and Shelat, A. 2003. Remembrance of data passed: a study of disk sanitization practices. Security Privacy, IEEE. 1, 1 (Feb. 2003), 17 – 27.

[19] Geambasu, R., Kohno, T., Levy, A.A. and Levy, H.M. 2009. Vanish: increasing data privacy with self-destructing data. Proceedings of the 18th USENIX Security Symposium (Berkeley, CA, USA, 2009), 299–316.

[20] Gomez, R.D., Burke, E.R., Adly, A.A. and Mayergoyz, I.D. 1992. Magnetic force scanning tunneling microscope imaging of overwritten data. Magnetics Conference, 1992. Digests of Intermag ’92., International (Apr. 1992), 420.

[21] Gutmann, P. 2001. Data remanence in semiconductor devices. 10th USENIX Security Symposium (2001).

[22] Gutmann, P. 1996. Secure deletion of data from magnetic and solid-state memory. Proceedings of the Sixth USENIX Security Symposium, San Jose, CA (1996).

[23] Halderman, J.A., Schoen, S.D., Heninger, N., Clarkson, W., Paul, W., Calandrino, J.A., Feldman, A.J., Appelbaum, J. and Felten, E.W. 2009. Lest we remember: cold-boot attacks on encryption keys. Commun. ACM. 52, 5 (May. 2009), 91–98.

[24] Health Insurance Portability and Accountability Act of 1996: http://www.hhs.gov/ocr/privacy/hipaa/administrative/statute/hipaastatutepdf.pdf. Accessed: 2012-07-24.

[25] HITECH Act Enforcement Interim Final Rule: 2009. http://www.hhs.gov/ocr/privacy/hipaa/administrative/enforcementrule/hitechenforcementifr. html. Accessed: 2012-08-07.

[26] Hughes, G. 2004. CMRR Protocols for disk drive secure erase. Technical report, Center for Magnetic Recording Research, University of California, San Diego.

[27] Hughes, G.F. 2002. Wise drives [hard disk drive]. Spectrum, IEEE. 39, 8 (Aug. 2002), 37 – 41.

[28] Intel pulls SSD Toolbox for killing drives under Windows 7 -- Engadget: 2009. http://www.engadget.com/2009/10/27/intel-pulls-ssd-toolbox-for-killing-drives-under- windows-7/. Accessed: 2012-09-30.

117

[29] Ironkey: http://www.ironkey.com. Accessed: 2012-07-26.

[30] Jones, A., Valli, C. and Dabibi, G. 2009. The 2009 Analysis of Information Remaining on USB Storage Devices Offered for Sale on the Second Hand Market. Australian Digital Forensics Conference (2009), 61.

[31] Joukov, N., Papaxenopoulos, H. and Zadok, E. 2006. Secure deletion myths, issues, and solutions. Proceedings of the Second ACM Workshop on Storage Security and Survivability (New York, NY, USA, 2006), 61–66.

[32] Joukov, N. and Zadok, E. 2005. Adding secure deletion to your favorite file system. Security in Storage Workshop, 2005. SISW ’05. Third IEEE International (Dec. 2005), 8 pp.–70.

[33] Katcher, J. 1997. PostMark: A new file system benchmark. Technical Report TR3022, Network Appliance, 1997. www. netapp. com/tech_library/3022. html.

[34] King, C. and Vidas, T. 2011. Empirical analysis of solid state disk data retention when used with contemporary operating systems. Digital Investigation. 8, (2011), S111–S117.

[35] Kleiman, S.R. 1986. Vnodes: An architecture for multiple file system types in Sun UNIX. USENIX Summer (1986), 238–247.

[36] Lee, J., Heo, J., Cho, Y., Hong, J. and Shin, S.Y. 2008. Secure deletion for NAND flash file system. Proceedings of the 2008 ACM Symposium on Applied Computing (New York, NY, USA, 2008), 1710–1714.

[37] Mac OS X Security Configuration for Mac OS X Version 10.6 Snow Leopard: http://images.apple.com/support/security/guides/docs/SnowLeopard_Security_Config_v10.6. pdf. Accessed: 2012-07-25.

[38] Marcel Breeuwsma, Martien De Jongh, Coert Klaver, Ronald Van Der Knijff and Roeloffs, M. 2009. Forensic Data Recovery from Flash Memory. CiteSeerX.

[39] Mayergoyz, I.D., Serpico, C., Krafft, C. and Tse, C. 2000. Magnetic imaging on a spin- stand. Journal of Applied Physics. 87, 9 (May. 2000), 6824 –6826.

[40] Memory Technology Device (MTD) Subsystem for Linux.: http://www.linux- mtd.infradead.org/. Accessed: 2012-07-29.

[41] Micron 2011. Bad Block Management in NAND Flash Memory Introduction. Technical Report #TN-29-59.

[42] Migrate device control applications from Windows to Linux: http://www.ibm.com/developerworks/linux/library/l-devctrl-migration/. Accessed: 2012-08- 30.

118

[43] National Industrial Security Program Operating Manual 5220.22-M: 1995. http://www.usaid.gov/policy/ads/500/d522022m.pdf. Accessed: 2012-07-26.

[44] Nightingale, E.B., Veeraraghavan, K., Chen, P.M. and Flinn, J. 2008. Rethink the sync. ACM Trans. Comput. Syst. 26, 3 (Sep. 2008), 6:1–6:26.

[45] OpenSSH: http://openssh.com/. Accessed: 2012-06-07.

[46] Perlman, R. 2005. The ephemerizer: making data disappear. Sun Microsystems, Inc.

[47] Peterson, Z. and Burns, R. 2005. Ext3cow: a time-shifting file system for regulatory compliance. Trans. Storage. 1, 2 (May. 2005), 190–212.

[48] Peterson, Z.N.J., Burns, R., Herring, J., Stubblefield, A. and Rubin, A. 2005. Secure deletion for a versioning file system. Proceedings of the USENIX Conference on File And Storage Technologies (FAST) (2005), 143–154.

[49] Presence and Type of Computer for Households, by Selected Householder Characteristics: 2010. http://www.census.gov/hhes/computer/files/2010/table1C.xls. Accessed: 2012-08-05.

[50] Protect your Data with Seagate Secure Self-Encrypting Drives | Seagate: 2012. http://www.seagate.com/tech-insights/protect-data-with-seagate-secure-self-encrypting- drives-master-ti/. Accessed: 2012-09-27.

[51] Reardon, J., Capkun, S. and Basin, D. 2012. Data Node Encrypted File System: Efficient Secure Deletion for Flash Memory. 21st USENIX Security Symposium (Aug. 2012).

[52] Reardon, J., Marforio, C., Capkun, S. and Basin, D. 2011. Secure Deletion on Log- structured File Systems. Technical Report arXiv:1106.0917.

[53] Rivest, R. 1997. All-or-nothing encryption and the package transform. Fast Software Encryption (1997), 210–218.

[54] SanDisk 2006. DiskOnChip 2000 DIP.

[55] Scrub utility: http://code.google.com/p/diskscrub/. Accessed: 2012-07-26.

[56] Secure rm: http://sourceforge.net/projects/srm/. Accessed: 2012-07-26.

[57] Secure USB Flash Drives | Kingston: http://www.kingston.com/us/usb/encrypted_security. Accessed: 2012-07-26.

[58] Shirobokov, A. 2006. The Drive Imaging as Part of Data Recovery.pdf. ACE Data Recovery Engineering Inc.

[59] Shmidt, D. 2002. TrueFFS wear-leveling mechanism. Technical Note (TN-DOC-017), M- Systems Flash Disk Pioneers, May. 20, (2002), 1–4.

119

[60] Shred Linux/Unix man page: http://linux.about.com/library/cmd/blcmdl1_shred.htm. Accessed: 2012-07-26.

[61] Shu, F. and Obr, N. 2007. Data set management commands proposal for ATA8-ACS2.

[62] Sivathanu, G., Sundararaman, S. and Zadok, E. 2006. Type-safe disks. Proceedings of the 7th Symposium on Operating Systems Design and Implementation (Berkeley, CA, USA, 2006), 15–28.

[63] Sivathanu, M., Arpaci-Dusseau, A.C., Arpaci-Dusseau, R.H. and Jha, S. 2005. A logic of file systems. Proceedings of the 4th USENIX Conference on File and Storage Technologies - Volume 4 (Berkeley, CA, USA, 2005), 1–1.

[64] Sivathanu, M., Bairavasundaram, L.N., Arpaci-Dusseau, A.C. and Arpaci-Dusseau, R.H. 2004. Life or death at block-level. Proceedings of the 6th Conference on Symposium on Opearting Systems Design & Implementation - Volume 6 (Berkeley, CA, USA, 2004), 26– 26.

[65] Sivathanu, M., Prabhakaran, V., Popovici, F.I., Denehy, T.E., Arpaci-Dusseau, A.C. and Arpaci-Dusseau, R.H. 2003. Semantically-smart disk systems. Proceedings of the 2nd USENIX Conference on File and Storage Technologies (2003), 73–88.

[66] Skorobogatov, S. 2005. Data Remanence in Flash Memory Devices. Cryptographic Hardware and Embedded Systems – CHES 2005. J. Rao and B. Sunar, eds. Springer Berlin / Heidelberg. 339–353.

[67] Sobey, C.H., Orto, L. and Sakaguchi, G. 2006. Drive-independent data recovery: the current state-of-the-art. IEEE Transactions on Magnetics. 42, 2 (Feb. 2006), 188 – 193.

[68] Special Publication 800-36: Guide to Selecting Information Technology Security Products: 2003. http://csrc.nist.gov/publications/nistpubs/800-36/NIST-SP800-36.pdf. Accessed: 2012-09-25.

[69] Special Publication 800-88: Guidelines for Media Sanitization: 2006. http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_with-errata.pdf. Accessed: 2012-07-26.

[70] ssss: Shamir’s Secret Sharing Scheme: http://point-at-infinity.org/ssss/. Accessed: 2012- 09-28.

[71] Sun, K., Choi, J., Lee, D. and Noh, S.H. 2008. Models and Design of an Adaptive Hybrid Scheme for Secure Deletion of Data in Consumer Electronics. Consumer Electronics, IEEE Transactions on. 54, 1 (Feb. 2008), 100 –104.

[72] The end of block barriers [LWN.net]: http://lwn.net/Articles/400541/. Accessed: 2012- 09-29.

120

[73] The OpenSSD Project: http://www.openssd-project.org/wiki/The_OpenSSD_Project. Accessed: 2012-07-27.

[74] Thibadeau, R. 2006. Trusted Computing for Disk Drives and Other Peripherals. Security Privacy, IEEE. 4, 5 (Oct. 2006), 26 –33.

[75] United States Government Accountability Office 2010. Electronic Personal Health Information Exchange - Health Care Entities’ Reported Disclosure Practices and Effects on Quality of Care.

[76] Valli, C. and Woodward, A. 2007. Oops they did it again: The 2007 Australian study of remnant data contained on 2nd hand hard disks. Australian Digital Forensics Conference (2007), 12.

[77] Venkatesh, A., Dunkle, D. and Wortman, A. 2011. Evolving Patterns of Household Computer Use: 1999-2010. University of California, Irvine.

[78] Wei, M., Grupp, L.M., Spada, F.E. and Swanson, S. 2011. Reliably erasing data from flash-based solid state drives. Proceedings of the 9th USENIX Conference on File and Stroage Technologies (Berkeley, CA, USA, 2011), 8–8.

[79] Wipe: Secure File Deletion: http://wipe.sourceforge.net/. Accessed: 2012-07-26.

[80] Wright, C., Kleiman, D. and Sundhar R.S., S. 2008. Overwriting Hard Drive Data: The Great Wiping Controversy. Proceedings of the 4th International Conference on Information Systems Security (Berlin, Heidelberg, 2008), 243–257.

[81] Zadok, E. and Nieh, J. 2000. FiST: a language for stackable file systems. Proceedings of the annual conference on USENIX Annual Technical Conference (Berkeley, CA, USA, 2000), 5–5.

121

BIOGRAPHICAL SKETCH

Sarah M. Diesburg was born and raised in Waterloo, Iowa and completed her Bachelors of Science degree magna cum laude in Computer Science from the University of Northern Iowa located in Cedar Falls, Iowa in the Fall of 2004. In the Summer of 2005 she joined Florida State University in Tallahassee, Florida as a graduate student and received a Masters of Science degree in Information Security in the Summer of 2008. Since entering graduate school, Sarah has conducted research in the areas of systems, storage, and security, held multiple research and teaching assistantship positions, held elected leadership positions in student organizations, and worked as an information security auditor. Sarah is currently a member of the Association of Computing Machinery, Upsilon Pi Epsilon, Golden Key International Honour Society, and the Philanthropic Educational Organization.

122