Full-Datapath Secure Data Deletion

1
Full-Datapath Secure Data Deletion

• Sarah Diesburg
• 5/4/2009

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 0s 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 0s 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
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
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
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
random
secrets
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
Secure Write

• We could modify the flash management software to
  delete dead, sensitive data on in-place update

Secure write new to 1
OS
secrets
secrets
Flash
0
1
2
3
4
5
6
25
Problem State of the Art Research
26
Secure Write

• Regular writes occur as normal

Secure write new to 1
OS
Erase!
new secret
secrets
Flash
0
1
2
3
4
5
6
26
Problem State of the Art Research
27
Secure Deletion

• We could modify the flash management software to
  delete sensitive data during file deletion

Delete 1
OS
secrets
secrets
Flash
0
1
2
3
4
5
6
27
Problem State of the Art Research
28
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