Per-file Full-data-path Secure Deletion for Electronic Storage Principles of Operating Systems Sarah Diesburg 11/15/2012 Florida State University

Per-file Full-data-path Secure Deletion for Electronic Storage

Principles of Operating Systems

Sarah Diesburg

11/15/2012

Florida State University

Overview

People want to delete sensitive info on storage in such a way that it cannot be recovered

Problem Existing methods may not

always work or be easy to use

Solution TrueErase brings

backwards-compatible deletion to the average user

2

Motivation

Amount of stored, sensitive data is growing Financial & customer info Trade secrets Usernames Passwords Correspondence Personal media files

[Ven11] 3

1998 2000 2002 2004 2006 2008 20100

10

20

30

40

50

60

70

80

90

100

Email

Online Shopping

Online Banking

Year

Percent Use

Problem

Normal file deletion leaves data behind Even formatting the device may not erase data E.g., MSDOS format removes < 0.1% of data

Secure deletion solutions are designed to irrecoverably delete information Must delete both data and metadata, which is

information about the data such as file name

4

Existing Solutions

Device- or partition-wide secure deletion Inflexible and may not work on some media

Per-file solutions Many solutions are incomplete Encryption-based solutions

Need to delete per-file keys Encryption schemes may expire

Generally do not work with average users or different combinations of file systems and storage media (e.g., disks, thumb drives)

[Die08, Wei11, CWE12] 5

Why Per-file?

Assists with Selective destruction of expired data (client data,

government policies) Deleting temporarily shared trade secrets Immediate destruction of sensitive data (military) Disposing of media in one-time-use applications

May be performed without turning off computer or disrupting storage access

Follow user expectations of delete

6

Why is it hard?

Storage components do not share info Low-level components

have no notion of files Intrusive to expand

interfaces Must retrofit secure

deletion into the entire storage data path With legacy

optimizations

7

applications

file system

storage management

storage

Why is it hard?

Legacy storage components have no existing mechanisms to delete file data May require extensive changes to legacy

components How do we know if our solution works?

What is the structure of various corner cases? What if a crash occurs during deletion?

8

Our Focus

Dead forensic attacks on local storage Occur after the computer has been shut down

properly Future work: backups, compromised systems,

covert channels, memory attacks Strong assumptions to simplify solution

Uncompromised, single-user, single-file-system, non-RAID, non-distributed system

9

Research Question

Under the most benign environments What can we design and build to ensure that

the secure deletion of a file is honored? Throughout the legacy storage data path

Missing/complimentary piece to support more advanced secure-deletion solutions Encryption-based solutions Tainting-based solutions

10

Approach

Use a parallel data path to pass file deletion information to lower storage components Leaves original data flow unmodified Backward compatible with legacy optimizations

When in doubt, handle deletion securely Simplifies hard corner cases

Avoid storing persistent states No need to recover them after crashes

11

TrueErase Framework Overview User model sets files

for secure deletion Components report

secure-deletion info to TAP module

Storage management query TAP for info and issue secure-deletion commands

12

applications

file system

storage management

storage

user model

TAP

secure-deletion commands

User Model

Use secure-deletion bit or extended attributes Specify files/dirs for

secure deletion Too expensive to

delete all files securely Compatible with

legacy applications With some deviations

13

applications

file system

storage management

storage

user model


TAP

User Model

Backwards-compatible semantics ‘chattr +s’ New files within a folder inherit permissions of

folder Some deviations

Once marked sensitive, always sensitive Name handling

14

Name Handling Deviation

Legacy file-permission semantics

If we were to use these semantics… Sensitive status may bubble up to the root

15

dir i-node

file

filei-node

datapermission

Name Handling Deviation

Legacy file-permission semantics

TrueErase’s sensitive status

16

dir i-node

file

filei-node

datapermission

dir i-node

file

filei-node

datasensitivestatus

TAP Module

Type/attribute propagation module (TAP) File system reports

pending updates Uses global unique IDs

to track versions

Tracks only in-transit soft states Can be reconstructed

17

applications

file system

storage management

storage

user model


TAP

What information to track? Deletions, but this info is not enough…

At the secure-deletion time Same location of a file may be updated couple times Metadata may not reference old versions anymore Unless all updates are tracked

TrueErase deletes old versions as updates occur Secure deletion + update = secure write

Tracks all in-transit updates for verification

18

Tracking: how hard can it be? Cannot rely on storage data structures, IDs,

and memory addresses due to reuse Complicated by various access granularities Also versions of storage requests in transit

Used memory page IDs and physical storage sector number to form globally unique IDs Reset at page allocation time Reused page holding different versions of a sector

has different IDs

19

How to interact with TAP?

Report_write() creates a tracking entry Report_delete() associates deletion info to a

tracking entry Report_copy() clones a tracking entry and

transfers deletion info Check_info() retrieves deletion info Cleanup_write() deletes a tracking entry

20

Crash Recovery

Rely on journaling file system to protect secure-deletion attributes

During recovery, apply secure ops for all Even for data and metadata of non-sensitive files

involved in the recovery phase Securely wipe the journal

And sensitive information not yet referenced by the file system

21

Enhanced Storage-management Layer Enhanced storage-

management layer Can inquire about file-

system-level info Added secure-deletion

commands for various storage media Issue erase command

for flash; write random 0s and 1s for disk

Encryption-free

22

applications

file system

storage management

storage

user model


TAP

Properties of NAND Flash

Erasure is slow Reads/writes in flash pages (e.g., 2-8 KB) Deletes in flash blocks (e.g., 64-512 KB)

Consisting of contiguous pages Unlike disks, no in-place updates

Flash block containing the page needs to be explicitly erased before being written again In-use pages are moved elsewhere

23

To Overcome Flash Property Challenges To optimize performance

A storage-management component remaps an overwrite request to an erased empty page Old page may stick around

24

NAND Update Example

25

Flash block

Suppose we have a flash block

NAND Update Example

26

Flash page

Each flash block can be divided into multiple flash pages Pages can be read and written

NAND Update Example

27

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

Suppose pages already have some data

NAND Update Example

28

Suppose file system wants to overwrite location 2 with new data But no in-place overwrites allowed!

z

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

NAND Update Example

29

Flash first allocates a new flash block with pre-erased pages

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

NAND Update Example

30

Flash then writes the new data to the new flash page while marking the old flash page as invalid Future reads to location 2 will be serviced by new page

z

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

z

TrueErase NAND Secure-deletion Commands Flash interface only accepts reads and writes

Not erases! We expand the flash interface for two new

commands Secure_delete() Secure_write()

31

TrueErase NAND Secure-deletion Commands Secure_delete(pages)

Copies other in-use pages from the current flash block to elsewhere

Issue erase command on the current block Secure_write(page)

Write the new page Call Secure_delete() on the old (if applicable)

32

TrueErase Secure_Write()

33

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

Suppose pages already have some data


34

Suppose file system wants to perform a secure write to location 2 with new data

z

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r


35

First allocate a new flash block with pre-erased pages

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r


36

Flash then writes the new data to the new flash page while marking the old flash page as invalid Future reads to location 2 will be serviced by new page

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

z

z


37

Now we have to perform a secure delete to erase previous version of location 2 But we can only delete on a flash-block granularity…

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

z


38

First, copy all other in-use pages to the new block

a

g

m

b

h

n

c

i

o

d

j

p

e f

k

q

l

r

a

g

m

z

h

n

c

i

o

d

j

p

e f

k

q

l

r


39

Finally, erase entire old flash block No invalid copies of data left over All future reads will be serviced by new flash block

a

g

m

z

h

n

c

i

o

d

j

p

e f

k

q

l

r

Internal Reorganization (Garbage Collection) Problem

No respect for file boundaries, sensitive status Solution: store sensitive-status bit in per-

page control areas Used to enforce secure-deletion semantics during

internal flash reorganization

40

File-system-consistency Properties and Secure Deletion Pointer-ordering property ensures that data

block in memory is written to storage Before referencing metadata block is written to

storage

41

Without Pointer-ordering Property

42

applications

file system

storage management

storage

TrueErase


43

file A’smetadata

data

applications

file system

storage management

storage

TrueErase

memory

storage


44

file A’smetadata

data

data

file A’smetadata

applications

file system

storage management

storage

TrueErase

memory

storage


45

data

file A’smetadata

applications

file system

storage management

storage

TrueErase

memory

storage


46

file B’smetadata

data

file A’smetadata

applications

file system

storage management

storage

TrueErase

memory

storage


47

file B’smetadata

data

data

file A’smetadata

applications

file system

storage management

storage

TrueErase

memory

storage

• Secure deletion of A can end up deleting B’s block

Pointer-ordering Property

48

file A’smetadata

data

applications

file system

storage management

storage

TrueErase

memory

storage


49

file A’smetadata

data

data

applications

file system

storage management

storage

TrueErase

memory

storage

• Data blocks are propagated first


50

file A’smetadata

data

data

applications

file system

storage management

storage

TrueErase

memory

storage

• Need to turn off storage built-in cache to prevent reordering

• Or issue device-specific flush commands

• Need to handle crash at this point

• Remove orphaned sensitive blocks at recovery time


51

file A’smetadata

data

data

file A’smetadata

applications

file system

storage management

storage

TrueErase

memory

storage


Does not mention what happens to freed in-memory sensitive data blocks Those blocks can be written to storage

persistently without file system knowing what is going on

They must not undo our secure deletion

52

File-system-consistency Properties and Secure Deletion Reuse-ordering property ensures that a

freed block will not be reused Before its free status is written to storage

Implications for a secure deletion operation Until the free status is written, we can

Perform secure operations on the block Be guaranteed that the block will not change it’s status

(file ownership or type)

53

File-system-consistency Properties and Secure Deletion Non-rollback property ensures that older

versions will not overwrite newer versions on storage

Implications a secure-deletion operation Secure-deletion operation and normal updates will

be applied in the correct order

54

Structure of Corner Cases

Ensuring that a secure deletion occurs before a block is persistently declared free

Hunting down the persistent sensitive blocks left behind after a crash

Making sure that secure deletion is not applied to the wrong file

Making sure that a securely deleted block is not overwritten by an old, secure unreferenced block

Handling versions of requests in transit

55

Implementation &Verification Prototyped under Linux, for disk and flash

Used ext3, which holds file-system-consistency properties

Inserted ~60 TAP calls Core framework component verified via

model-checking-like methods and two-version programming Systemically verified 10K unique states and 2.7M

state transitions Include the cases for common crashes

[Siv05] 56

More Details in the Dissertation Interchangeable user-level/kernel-level

development framework Flash performance optimizations Verification framework

57

Flash Storage Evaluation

Evaluated using OpenSSH compilation and modified PostMark benchmarks OpenSSH: 1.6x slowdown for 27% files marked

sensitive under openbsd-compat directory PostMark: 3.4x slowdown for first 5% files

marked sensitive Performance comparable to other works that

involve tailored and extensive system changes

58[Jou06, Kat97, Wei11]

Related Work

Levels Solutions F E D S L M C

Storage manage-ment

Secure delete encrypted device/partition key Specialized hard drive commands Specialized flash medium commands (page granularity)

File system

Stackable file system deletion Modified file system – deletion through overwriting Modified file system – deletion through encryption ? ?

User space

User-space solution on top of flash file system ?

Overwriting tools Remote Dedicated server(s) for encryption keys ?

Encrypted backup system ?

Data-path-wide

Modified flash file systems – device erasures and/or overwriting ? ?

Modified flash file systems – encryption with key erasure ? ?

Semantically-Smart Disk Systems [Siv03] Type-Safe Disks [Siv06] Data Node Encrypted File System [Rea12] TrueErase

59Columns: F. per-file; E. encryption-free; D. data-path-wide; S. storage-medium-agnostic; L. limited changes to legacy code; M. securely delete metadata; C. handle crashes

Future Work

Use TrueErase as a building block for more advanced secure-deletion methods Incorporate encryption and tainting Handle additional threat models

Distributed environments

TAP framework can be used to explore other data-path-wide capabilities Performance optimizations Improve reliability

60

Lessons Learned

Retrofitting security features is quite complex Need to know the entire the data path

File-systems-consistency properties crucial to make verification tractable

Propagating information is tricky Especially in the face of asynchrony Important to keep legacy flow intact Allow secure-deletion operations be defined at the

storage-management layer

61

Lessons Learned

Tracking information can be challenging Unlike network, in-transit requests can be

cancelled and consolidated Tracking granularities vary throughout

Metadata blocks can be shared Access to non-sensitive file can bring sensitive info into

memory

Hard to gain raw flash access for research and development Vendors should find ways to make HW more open

62

Conclusion

We have designed, implemented, evaluated, and verified a secure-deletion solution that Irrecoverably deletes file data and metadata General and backward-compatible to different

storage types and popular file systems Acceptable performance Systematically verified (rare in existing solutions) Handles common crashes

63

Acknowledgements

National Science Foundation Department of Education Philanthropic Educational Organization Florida State University Research Foundation

64

Publications

[Die13] Sarah Diesburg, Christopher Meyers, Mark Stanovich, Michael Mitchell, Justin Marshall, Julia Gould, An-I Andy Wang, and Geoff Kuenning. TrueErase: Full-storage-data-path Per-file Secure Deletion. To be submitted to ACM Transactions on Storage (TOS).

[Die12] Sarah Diesburg, Christopher Meyers, Mark Stanovich, Michael Mitchell, Justin Marshall, Julia Gould, An-I Andy Wang, and Geoff Kuenning. TrueErase: Per-File Secure Deletion for the Storage Data Path. Proceedings of the 2012 ACM Annual Computer Security Applications Conference (ACSAC), 2012, to appear. [19% acceptance rate]

[Die10] Sarah Diesburg and An-I Andy Wang. A Survey of Confidential Data Storage and Deletion Methods. ACM Computing Surveys (CSUR), 43(1), 2010.

[Die08] Sarah Diesburg, Christopher Meyers, David Lary, and An-I Andy Wang. When Cryptography Meets Storage. Proceedings of the 4th ACM International Workshop on Storage Security and Survivability (StorageSS), October 2008.

65

Questions?

66

References

[CWE12] CWE - CWE-327: Use of a Broken or Risky Cryptographic Algorithm (2.2): http://cwe.mitre.org/data/definitions/327.html. Accessed: 2012-09-05.

[Die08] Diesburg, S.M., Meyers, C.R., Lary, D.M. and Wang, A.I.A. 2008. When cryptography meets storage. Proceedings of the 4th ACM International Workshop on Storage Security and Survivability (2008), 11–20.

[Jou06] Joukov, N., Papaxenopoulos, H. and Zadok, E. 2006. Secure deletion myths, issues, and solutions. Proceedings of the Second ACM Workshop on Storage Security and Survivability (New York, NY, USA, 2006), 61–66.

[Kat97] Katcher, J. 1997. Postmark: A new file system benchmark. Technical Report TR3022, Network Appliance, 1997. www. netapp. com/tech_library/3022. html.

[Rea12] Reardon, J., Capkun, S. and Basin, D. 2012. Data Node Encrypted File System: Efficient Secure Deletion for Flash Memory. 21st USENIX Security Symposium (Aug. 2012).

67

References

[Siv03] Sivathanu, M., Prabhakaran, V., Popovici, F.I., Denehy, T.E., Arpaci-Dusseau, A.C. and Arpaci-Dusseau, R.H. 2003. Semantically-smart disk systems. Proceedings of the 2nd USENIX Conference on File and Storage Technologies (2003), 73–88.

[Siv05] Sivathanu, M., Arpaci-Dusseau, A.C., Arpaci-Dusseau, R.H. and Jha, S. 2005. A logic of file systems. Proceedings of the 4th USENIX Conference on File and Storage Technologies - Volume 4 (Berkeley, CA, USA, 2005), 1–1.

[Siv06] Sivathanu, G., Sundararaman, S. and Zadok, E. 2006. Type-safe disks. Proceedings of the 7th Symposium on Operating Systems Design and Implementation (Berkeley, CA, USA, 2006), 15–28.

[Ven11] Venkatesh, A., Dunkle, D. and Wortman, A. 2011. Evolving Patterns of Household Computer Use: 1999-2010. University of California, Irvine.

[Wei11] Wei, M., Grupp, L.M., Spada, F.E. and Swanson, S. 2011. Reliably erasing data from flash-based solid state drives. Proceedings of the 9th USENIX Conference on File and Stroage Technologies (Berkeley, CA, USA, 2011), 8–8.

68

Documents

Per-file Full-data-path Secure Deletion for Electronic Storage Principles of Operating Systems Sarah Diesburg 11/15/2012 Florida State University