Full-Datapath Secure Deletion

1. Full-Datapath Secure Deletion Sarah Diesburg

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

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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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 Problem •State of the Art•Research

11. 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

12. 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

13. 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

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

15. 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

16. 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

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

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

19. 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. Logical Address Physical Address 0 0 1 1 Default Flash Write Behavior • Flash management software rotates the usage of locations OS secrets secrets Flash 0 1 2 3 4 5 6 20 Problem •State of the Art•Research

21. Logical Address Physical Address 0 0 1 1 Default Flash Write Behavior • Flash management software rotates the usage of locations Write random bits to 1 OS secrets secrets Flash 0 1 2 3 4 5 6 21 Problem •State of the Art• Research

22. Logical Address Physical Address 0 0 1 2 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 secrets secrets random Flash 0 1 2 3 4 5 6 22 Problem •State of the Art•Research

23. 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! 23 Problem •State of the Art•Research

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

25. Logical Address Physical Address 0 0 1 1 Secure Write • We could modify the flash management software to delete dead, sensitive data on in-place update Securewrite new to 1 OS secrets secrets Flash 0 1 2 3 4 5 6 25 Problem •State of the Art•Research

26. Logical Address Physical Address 0 0 1 2 Secure Write • Regular writes occur as normal Securewrite new to 1 OS Erase! secrets new secret Flash 0 1 2 3 4 5 6 26 Problem •State of the Art•Research

27. Logical Address Physical Address 0 0 1 1 Secure Deletion • We could modify the flash management software to delete sensitivedata during file deletion Delete 1 OS secrets secrets Flash 0 1 2 3 4 5 6 27 Problem •State of the Art•Research

28. Logical Address Physical Address 0 0 Secure Deletion • Just erase corresponding location Delete 1 OS Erase! secrets Flash 0 1 2 3 4 5 6 28 Problem •State of the Art• Research

29. 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

30. 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

31. Questions? 31

32. BACKUP SLIDES

33. Thesis Statement • Secure deletion can be accomplished through a full-datapath solution • Research objectives • 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

34. 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

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

36. 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

37. 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

38. 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

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

40. 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 • Does not discern secure info from file updates - Files must be securely marked in both file system and flash • Problem occurs when media writes not in-place

41. 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

42. In-band Challenges + No new requests - Writing 0’s means a number of things • Writing data of all 0s • Marking file region as empty • Partial FS block write • Does not automatically imply deletion 42