Secure Deletion for Electronic Storage Principles of Operating Systems Sarah Diesburg 11152012 Florida State University Overview People want to delete sensitive info on storage in such a way that it cannot be recovered ID: 322927
Download Presentation The PPT/PDF document "Per-file Full-data-path" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Per-file Full-data-path Secure Deletion for Electronic Storage
Principles of Operating Systems
Sarah Diesburg
11/15/2012
Florida
State UniversitySlide2
OverviewPeople 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
2Slide3
Motivation
Amount of stored, sensitive data is growing
Financial & customer info
Trade secretsUsernamesPasswords CorrespondencePersonal media files
[Ven11]
3Slide4
ProblemNormal 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 informationMust delete both data and
metadata, which is information about the data such as file name
4Slide5
Existing SolutionsDevice- or partition-wide secure deletion
Inflexible and may not work on some media
Per-file solutions
Many solutions are incompleteEncryption-based solutionsNeed to delete per-file keysEncryption 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]
5Slide6
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 applicationsMay be performed without turning off computer or disrupting storage accessFollow user expectations of delete
6Slide7
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 pathWith legacy optimizations
7
applications
file system
storage
management
storage Slide8
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?
8Slide9
Our FocusDead forensic attacks on local storage
Occur after the computer has been shut down properly
Future work: backups
, compromised systems, covert channels, memory attacksStrong assumptions to simplify solutionUncompromised, single-user, single-file-system, non-RAID, non-distributed system
9Slide10
Research QuestionUnder the most benign environmentsWhat 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 solutionsTainting-based solutions
10Slide11
ApproachUse 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 securelySimplifies hard corner casesAvoid storing persistent statesNo need to recover them after crashes
11Slide12
TrueErase Framework Overview
User model
sets files for secure deletionComponents report secure-deletion info to TAP moduleStorage management query TAP for info and issue
secure-deletion commands
12
applications
file system
storage
management
storage
user model
TAP
secure-deletion
commandsSlide13
User ModelUse secure-deletion bit or extended attributes
Specify files/
dirs
for secure deletionToo expensive to delete all files securelyCompatible with legacy applicationsWith some deviations
13
applications
file system
storage
management
storage
user model
secure-deletion
commands
TAPSlide14
User ModelBackwards-compatible semantics
‘
chattr
+s’New files within a folder inherit permissions of folderSome deviationsOnce marked sensitive, always sensitiveName handling
14Slide15
Name Handling DeviationLegacy file-permission semantics
If we were to use these semantics…
Sensitive status may bubble up to the root
15
dir
i-node
file
file
i-node
data
permissionSlide16
Name Handling DeviationLegacy file-permission semantics
TrueErase’s sensitive status
16
dir
i-node
file
file
i-node
data
permission
dir
i-node
file
file
i-node
data
sensitive
statusSlide17
TAP ModuleType/attribute propagation module (
TAP
)
File system reports pending updatesUses global unique IDs to track versionsTracks only in-transit soft statesCan be reconstructed
17
applications
file system
storage
management
storage
user model
secure-deletion
commands
TAPSlide18
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 anymoreUnless all updates are tracked
TrueErase deletes old versions
as updates occurSecure deletion + update =
secure write
Tracks all in-transit updates for verification
18Slide19
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 transitUsed memory page IDs and physical storage sector number to form globally unique IDsReset at page allocation timeReused page holding different versions of a sector has different IDs
19Slide20
How to interact with TAP?Report_write()
creates a tracking entry
Report_delete
() associates deletion info to a tracking entryReport_copy() clones a tracking entry and transfers deletion infoCheck_info()
retrieves deletion infoCleanup_write()
deletes a tracking entry
20Slide21
Crash RecoveryRely 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
21Slide22
Enhanced Storage-management LayerEnhanced 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 diskEncryption-free
22
applications
file system
storage
management
storage
user model
secure-deletion
commands
TAPSlide23
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 pagesUnlike 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
23Slide24
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
24Slide25
NAND Update Example
25
Flash block
Suppose we have a flash blockSlide26
NAND Update Example
26
Flash page
Each flash block can be divided into multiple flash pages
Pages can be read and writtenSlide27
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 dataSlide28
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
rSlide29
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
rSlide30
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
zSlide31
TrueErase NAND Secure-deletion CommandsFlash interface only accepts reads and writes
Not erases!
We expand the flash interface for two new commands
Secure_delete()Secure_write()
31Slide32
TrueErase NAND Secure-deletion CommandsSecure_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)
32Slide33
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 dataSlide34
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
rSlide35
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
rSlide36
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
zSlide37
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
zSlide38
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
rSlide39
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
rSlide40
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
40Slide41
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
41Slide42
Without Pointer-ordering Property
42
applications
file system
storage
management
storage
TrueEraseSlide43
Without Pointer-ordering Property
43
file A’s
metadata
data
applications
file system
storage
management
storage
TrueErase
memory
storageSlide44
Without Pointer-ordering Property
44
file A’s
metadata
data
data
file A’s
metadata
applications
file system
storage
management
storage
TrueErase
memory
storageSlide45
Without Pointer-ordering Property
45
data
file A’s
metadata
applications
file system
storage
management
storage
TrueErase
memory
storageSlide46
Without Pointer-ordering Property
46
file B’s
metadata
data
data
file A’s
metadata
applications
file system
storage
management
storage
TrueErase
memory
storageSlide47
Without Pointer-ordering Property
47
file B’s
metadata
data
data
file A’s
metadata
applications
file system
storage
management
storage
TrueErase
memory
storage
Secure deletion of A can end up deleting B’s blockSlide48
Pointer-ordering Property
48
file A’s
metadata
data
applications
file system
storage
management
storage
TrueErase
memory
storageSlide49
Pointer-ordering Property
49
file A’s
metadata
data
data
applications
file system
storage
management
storage
TrueErase
memory
storage
Data blocks are propagated firstSlide50
Pointer-ordering Property
50
file A’s
metadata
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 timeSlide51
Pointer-ordering Property
51
file A’s
metadata
data
data
file A’s
metadata
applications
file system
storage
management
storage
TrueErase
memory
storageSlide52
Pointer-ordering PropertyDoes 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
52Slide53
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 storageImplications for a secure deletion operationUntil the free status is written, we canPerform secure operations on the blockBe guaranteed that the block will not change it’s status (file ownership or type)
53Slide54
File-system-consistency Properties and Secure Deletion
Non-rollback property
ensures that older versions will not overwrite newer versions on storageImplications a secure-deletion operationSecure-deletion operation and normal updates will be applied in the correct order
54Slide55
Structure of Corner CasesEnsuring 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 blockHandling versions of requests in transit
55Slide56
Implementation &Verification
Prototyped under Linux, for disk and flash
Used ext3, which
holds file-system-consistency propertiesInserted ~60 TAP callsCore framework component verified via model-checking-like methods and two-version programmingSystemically verified 10K unique states and 2.7M state transitions
Include the cases for common crashes
[Siv05]
56Slide57
More Details in the DissertationInterchangeable user-level/kernel-level development framework
Flash performance optimizations
Verification framework
57Slide58
Flash Storage EvaluationEvaluated using
OpenSSH
compilation
and modified PostMark benchmarksOpenSSH: 1.6x slowdown for 27% files marked sensitive under
openbsd-compat directoryPostMark
: 3.4x slowdown for first 5% files marked sensitivePerformance comparable to other works that involve tailored and extensive system changes
58
[Jou06, Kat97, Wei11]Slide59
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
59
Columns: 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 crashesSlide60
Future WorkUse TrueErase
as a building block for more advanced secure-deletion methods
Incorporate encryption and tainting
Handle additional threat modelsDistributed environmentsTAP framework can be used to explore other data-path-wide capabilitiesPerformance optimizationsImprove reliability
60Slide61
Lessons LearnedRetrofitting 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 trickyEspecially in the face of asynchronyImportant to keep legacy flow intactAllow secure-deletion operations be defined at the storage-management layer
61Slide62
Lessons LearnedTracking information can be challenging
Unlike network, in-transit requests can be cancelled and consolidated
Tracking granularities vary throughout
Metadata blocks can be sharedAccess to non-sensitive file can bring sensitive info into memoryHard to gain raw flash access for research and developmentVendors should find ways to make HW more open
62Slide63
ConclusionWe 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 performanceSystematically verified (rare in existing solutions)Handles common crashes
63Slide64
AcknowledgementsNational Science FoundationDepartment of Education
Philanthropic Educational Organization
Florida State University Research Foundation
64Slide65
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.
65Slide66
Questions?
66Slide67
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).
67Slide68
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