Full-Datapath Secure Data Deletion Sarah Diesburg 5/4/2009 1

Overview Problem  Current secure deletion methods do not work State of the art  Optimistic system-wide assumptions Research  Holistic way to perform secure deletion 2

The Problem Decommissioned drives and storage devices leak sensitive information Problem State of the Art Research 3

The Problem Most users believe that files cannot be retrieved once  Files are no longer visible  The trashcan is emptied  The partition is formatted Problem State of the Art Research 4

Ideal Secure Deletion Irrevocably delete corresponding data and file/directory information Be easy to use Allow per-file granularity of deletion Achieve acceptable performance Behave correctly in the presence of failures Work with modern file systems Work with emerging storage media 5 Problem State of the Art Research

Secure Deletion Problem No ideal solution exists  Why? Conventional secure deletion methods are isolated  Make assumptions of other components  Secure deletion may fail 6 Problem State of the Art Research

General Secure Deletion Methods Methods include 1. Physical destruction 2. Data overwriting 3. Encryption with key erasure Physical destruction does not provide per- file deletion  Concentrate on methods (2) and (3) 7 Problem State of the Art Research

Layer-specific Methods Application- and file-system-layer solutions  Rely on in-place overwrites, which may not be honored by lower layers (e.g. RAID, journaling)  Write can preempt other writes to same location Storage-medium-specific solutions  Limited information from higher layers  No knowledge If block is sensitive, alive, dead  No per-file flash solutions 8 Problem State of the Art Research

Review of Research Goal We want easy to use, per-file, secure deletion to work with all datapath components  Type of storage should not matter  Type of file system should not matter Proposed solution: add secure semantics that span entire datapath 9 Problem State of the Art Research

Full Datapath Secure Deletion Components  User interaction Mark sensitive files using file system  Datapath extensions File system Storage management  Secure deletion semantics in storage management 10 Problem State of the Art Research

Data Path Expansion Lower layers do not know  Which files are sensitive  Which files are deleted Need to send information down somehow  Out-of-band  Hybrid  In-band 11 Problem State of the Art Research

Out-of-band Approach Add two FS requests to communicate out-of-band information  Secure allocate  Secure deallocate Extend storage management to handle new requests 12 Problem State of the Art Research

Out-of-band Challenges +Simple design – just add what we need - Crash scenarios  Metadata updated, delete request not make it  Delete request makes it, metadata not updated  Not easy to journal new requests - Files must be securely marked in both file system and flash  Problem occurs when media writes not in-place 13 Problem State of the Art Research

Hybrid Approach Pass secure information in-band Communicate secure delete out-of-band Tailor storage management accordingly 14 Problem State of the Art Research

Hybrid Challenges +Files only need to be securely marked in file system -Crash scenarios  Metadata updated, delete request not make it  Delete request makes it, metadata not updated  Not easy to journal new request or in-band info Does not discern secure info from file updates 15 Problem State of the Art Research

In-band Approach Write of 0’s implies secure deletion Information piggybacked on existing request structure Tailor storage management accordingly 16 Problem State of the Art Research

In-band Challenges + No new requests - Writing 0’s means a number of things 1. Writing data of all 0s 2. Marking file region as empty Partial FS block write 17 Problem State of the Art Research

Secure Deletion Semantics Concentrate on flash storage management Flash has different constraints than hard drives 18 Problem State of the Art Research

Flash Background Flash constraints  Data area must be explicitly erased before written  Erasures are slow  A data location can be erased up to 100,000 times Solution  Put in-place writes elsewhere on flash!  Avoid erasing data whenever possible 19 Problem State of the Art Research

20 Default Flash Write Behavior Flash management software rotates the usage of locations OS secrets Flash Logical AddressPhysical Address secrets 20 Problem State of the Art Research

21 Default Flash Write Behavior Flash management software rotates the usage of locations OS Logical AddressPhysical Address Write random bits to 1 secrets Flash secrets 21 Problem State of the Art Research

22 Default Flash Write Behavior Logical AddressPhysical Address Write random bits to 1 secrets Flash randomsecrets 22 Problem State of the Art Research OS Overwrites go to new block instead of original block Dead data left behind until that block is erased

Is this a problem? 23 Removal via hot airUniversal chip reader We must somehow erase sensitive data! 23 Problem State of the Art Research Raw flash chips can be removed and placed in a reader

Storage Management Secure Deletion Semantics Secure write Secure delete 24 Problem State of the Art Research

25 Secure Write We could modify the flash management software to delete dead, sensitive data on in-place update OS Logical AddressPhysical Address Secure write new to 1 secrets Flash secrets 25 Problem State of the Art Research

26 Secure Write OS Logical AddressPhysical Address Flash new secret secrets Erase! Secure write new to 1 26 Problem State of the Art Research Regular writes occur as normal

27 Secure Deletion We could modify the flash management software to delete sensitive data during file deletion OS Delete 1 secrets Flash secrets 27 Problem State of the Art Research Logical AddressPhysical Address 00 11

28 Secure Deletion Just erase corresponding location OS Flash secrets Erase! Delete 1 28 Problem State of the Art Research Logical AddressPhysical Address 00

Extra Challenges Atomicity of relevant file-system updates  Some operations must happen at once Dealing with asynchronous requests Incorporating journaling Optimizing future flash media management 29 Problem State of the Art Research

Summary This research will provide a full-datapath secure deletion model that is Easy to use With acceptable performance Crash resistant Compatible to modern file systems as well as with emerging solid-state storage 30

Questions? 31

BACKUP SLIDES 32

Thesis Statement Secure deletion can be accomplished through a full-datapath solution Research objectives 1. Demonstrate working full-datapath secure deletion framework 2. Optimize framework for an emerging storage media for which current methods do not work  Flash media 33 Problem State of the Art Research

Anticipated Challenges Correct full-datapath secure deletion model  Correct data categorization  System failures (e.g. journal, page cache, FTL) Creating efficient models for future flash management software  Acceptable performance  Reducing number of slow flash operations 34 Problem State of the Art Research

File System Methods Two types of secure deletion file systems exist:  Block-based file systems  Storage-specific file systems 35

File Systems Typical file systems expect disk  Block layer interface converts FS blocks into sectors Storage-specific file systems directly manage underlying storage units  No page cache  May implement own journal 36

Storage-specific FS Secure Deletion Limitations Optimized for specific type of storage  Cannot put hard drive under flash file system, etc. Deletes all files securely  User cannot specify specific files  Performance disadvantage 37

Crash Scenarios File system  Data erased, metadata not updated  Metadata updated, data not erased Block layer  Erase command in page cache during power- outage Flash  Copying good flash pages first during erase command 38

AON Transform Transform that is hard hard to invert unless all of the output is known 39 H  H  H  H  K = Encrypted data E( ) random key H( ) plaintext ciphertext tab