Full-Datapath Secure Data Deletion Sarah Diesburg 5/4/2009 1.

Post on 13-Jan-2016

227 views 1 download

Tags:

Transcript of Full-Datapath Secure Data Deletion Sarah Diesburg 5/4/2009 1.

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