Full-Datapath Secure Data Deletion Sarah Diesburg 5/4/2009 1 Overview Problem State of the art Current secure deletion methods do not work 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 Problem • State of the Art • Research 5 Secure Deletion Problem No ideal solution exists Why? Conventional secure deletion methods are isolated Make assumptions of other components Secure deletion may fail Problem • State of the Art • Research 6 General Secure Deletion Methods Methods include 1. 2. 3. Physical destruction Data overwriting Encryption with key erasure Physical destruction does not provide perfile deletion Concentrate on methods (2) and (3) Problem • State of the Art • Research 7 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 Problem • State of the Art • Research 8 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 Problem • State of the Art • Research 9 Full Datapath Secure Deletion Components User interaction Datapath extensions Mark sensitive files using file system File system Storage management Secure deletion semantics in storage management Problem • State of the Art • Research 10 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 Problem • State of the Art • Research 11 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 Problem • State of the Art • Research 12 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 Problem • State of the Art • Research 13 Hybrid Approach Pass secure information in-band Communicate secure delete out-of-band Tailor storage management accordingly Problem • State of the Art • Research 14 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 Problem • State of the Art • Research 15 In-band Approach Write of 0’s implies secure deletion Information piggybacked on existing request structure Tailor storage management accordingly Problem • State of the Art • Research 16 In-band Challenges + No new requests - Writing 0’s means a number of things Writing data of all 0s Marking file region as empty 1. 2. • Partial FS block write Problem • State of the Art • Research 17 Secure Deletion Semantics Concentrate on flash storage management Flash has different constraints than hard drives Problem • State of the Art • Research 18 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 Problem • State of the Art • Research 19 Default Flash Write Behavior Flash management software rotates the usage of locations OS Flash secrets secrets 0 1 2 Logical Address Physical Address 0 0 1 1 3 Problem • State of the Art • Research 4 5 6 20 Default Flash Write Behavior Flash management software rotates the usage of locations Write random bits to 1 OS Flash secrets secrets 0 1 2 Logical Address Physical Address 0 0 1 1 3 Problem • State of the Art • Research 4 5 6 21 Default Flash Write Behavior Overwrites go to new block instead of original block Dead data left behind until that block is erased Write random bits to 1 OS Flash secrets secrets random 0 1 2 Logical Address Physical Address 0 0 1 2 3 Problem • State of the Art • Research 4 5 6 22 Is this a problem? Raw flash chips can be removed and placed in a reader Removal via hot air Universal chip reader We must somehow erase sensitive data! Problem • State of the Art • Research 23 Storage Management Secure Deletion Semantics Secure write Secure delete Problem • State of the Art • Research 24 Secure Write We could modify the flash management software to delete dead, sensitive data on in-place update Secure write new to 1 OS Flash secrets secrets 0 1 2 Logical Address Physical Address 0 0 1 1 3 Problem • State of the Art • Research 4 5 6 25 Secure Write Regular writes occur as normal Secure write new to 1 OS Logical Address Physical Address 0 0 1 2 Erase! Flash new secret secrets 0 1 2 3 Problem • State of the Art • Research 4 5 6 26 Secure Deletion We could modify the flash management software to delete sensitive data during file deletion Delete 1 OS Flash secrets secrets 0 1 2 Logical Address Physical Address 0 0 1 1 3 Problem • State of the Art • Research 4 5 6 27 Secure Deletion Just erase corresponding location Delete 1 OS Logical Address Physical Address 0 0 Erase! Flash secrets 0 1 2 3 Problem • State of the Art • Research 4 5 6 28 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 Problem • State of the Art • Research 29 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. 2. Demonstrate working full-datapath secure deletion framework Optimize framework for an emerging storage media for which current methods do not work Flash media Problem • State of the Art • Research 33 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 Problem • State of the Art • Research 34 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 Block layer Data erased, metadata not updated Metadata updated, data not erased Erase command in page cache during poweroutage 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 Encrypted data plaintext E( ) ciphertext random key HHHHK = H( ) tab 39