Full-Datapath
Secure Deletion
Sarah Diesburg
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
HHHHK
=
H( )
tab
39
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
40
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
41
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
•
Does not automatically imply deletion
42