Per-file Full-data-path Secure Deletion for Electronic Storage Principles of Operating Systems Sarah...
-
Upload
hillary-dixon -
Category
Documents
-
view
216 -
download
0
Transcript of Per-file Full-data-path Secure Deletion for Electronic Storage Principles of Operating Systems Sarah...
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
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
secure-deletion commands
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
secure-deletion commands
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
secure-deletion commands
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
TrueErase Secure_Write()
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
TrueErase Secure_Write()
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
TrueErase Secure_Write()
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
TrueErase Secure_Write()
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
TrueErase Secure_Write()
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
TrueErase Secure_Write()
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
Without Pointer-ordering Property
43
file A’smetadata
data
applications
file system
storage management
storage
TrueErase
memory
storage
Without Pointer-ordering Property
44
file A’smetadata
data
data
file A’smetadata
applications
file system
storage management
storage
TrueErase
memory
storage
Without Pointer-ordering Property
45
data
file A’smetadata
applications
file system
storage management
storage
TrueErase
memory
storage
Without Pointer-ordering Property
46
file B’smetadata
data
file A’smetadata
applications
file system
storage management
storage
TrueErase
memory
storage
Without Pointer-ordering Property
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
Pointer-ordering Property
49
file A’smetadata
data
data
applications
file system
storage management
storage
TrueErase
memory
storage
• Data blocks are propagated first
Pointer-ordering Property
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
Pointer-ordering Property
51
file A’smetadata
data
data
file A’smetadata
applications
file system
storage management
storage
TrueErase
memory
storage
Pointer-ordering Property
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