Date post: | 13-Jan-2016 |
Category: |
Documents |
Upload: | herbert-sanders |
View: | 221 times |
Download: | 1 times |
Full-Datapath Secure Data Deletion
Sarah Diesburg5/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
5Problem • 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
6Problem • 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)
7Problem • 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
8Problem • 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
9Problem • 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
10Problem • 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
11Problem • 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
12Problem • 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
13Problem • State of the Art • Research
Hybrid Approach
Pass secure information in-band
Communicate secure delete out-of-band
Tailor storage management accordingly
14Problem • 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
15Problem • 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
16Problem • State of the Art • Research
In-band Challenges
+ No new requests
- Writing 0’s means a number of things1. Writing data of all 0s
2. Marking file region as empty• Partial FS block write
1717Problem • State of the Art • Research
Secure Deletion Semantics Concentrate on flash storage management Flash has different constraints than hard
drives
18Problem • 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
1919Problem • State of the Art • Research
20
Default Flash Write Behavior
Flash management software rotates the usage of locations
OS
secretsFlash
0 1 2 3 4 5 6
Logical Address Physical Address
0 0
1 1
secrets
20Problem • State of the Art • Research
21
Default Flash Write Behavior
Flash management software rotates the usage of locations
OS
Logical Address Physical Address
0 0
1 1
Write random
bitsto 1
secretsFlash
0 1 2 3 4 5 6
secrets
21Problem • State of the Art • Research
22
Default Flash Write Behavior
Logical Address Physical Address
0 0
1 2
Write random
bitsto 1
secretsFlash
0 1 2 3 4 5 6
randomsecrets
22Problem • 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 air
Universal chip reader
We must somehow erase sensitive data!
23Problem • 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
24Problem • 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 Address Physical Address
0 0
1 1
Secure write new
to 1
secretsFlash
0 1 2 3 4 5 6
secrets
25Problem • State of the Art • Research
26
Secure Write
OS
Logical Address Physical Address
0 0
1 2
Flash
0 1 2 3 4 5 6
newsecret
secrets
Erase!
Secure write new
to 1
26Problem • 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
Delete1
secretsFlash
0 1 2 3 4 5 6
secrets
27Problem • State of the Art • Research
Logical Address Physical Address
0 0
1 1
28
Secure Deletion
Just erase corresponding location
OS
Flash
0 1 2 3 4 5 6
secrets
Erase!
Delete1
28Problem • State of the Art • Research
Logical Address Physical Address
0 0
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
29Problem • 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?
3131
BACKUP SLIDES
32
Thesis Statement
Secure deletion can be accomplished through a full-datapath solution
Research objectives1. Demonstrate working full-datapath secure
deletion framework
2. Optimize framework for an emerging storage media for which current methods do not work
Flash media
33Problem • 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
34Problem • 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
HHHHK =
Encrypted data
E( ) random key
H( )
plaintext
ciphertext
tab