secure deletion
DESCRIPTION
Secure Deletion. What is Secure Deletion. The permanent removal of data from disk When data is gone, it’s gone for good “Emptying the trash” is not good enough Simply frees blocks for later allocation Data exist intact and readable - PowerPoint PPT PresentationTRANSCRIPT
Department of Computer Science, Johns Hopkins University
Secure Deletion
What is Secure Deletion
The permanent removal of data from disk– When data is gone, it’s gone for good
“Emptying the trash” is not good enough– Simply frees blocks for later allocation– Data exist intact and readable
Even after reallocation, data may be recovered using more expensive forensic techniques– Magnetic Force Microscopy
Need For Secure Deletion Important feature for security conscious users Informational records are becoming entirely
electronic Legislation - over 4000 new laws
– Records that go out of audit scope should do so forever (Sarbanes-Oxley)
– Patients may wish to redact portions of their medical record (HIPAA Privacy Rule)
– When a disk is subpoenaed, old, irrelevant or sensitive data should be inaccessible
Question?
How would you securely remove data from your system?
Existing Techniques
Destroy the device Secure Overwrite Key Disposal Secure Deletion for Versioning File System
Secure Overwrite
Idea introduced by Peter Gutmann 36 synchronous passes over contiguous data Each pass is a particular pattern of 1s and 0s
designed to degauss the magnetic media– Takes into account standard ECCs and other bit
reordering techniques
Problem: very slow, large files may each take minutes to delete
Other Variants
Zeroing the data with one pass (not enough) 3 passes of random data (may be enough) DOD specifies only 7 passes NIST released its secure deletion recommendation,
identifying four grades:– Disposal (throw non-confidential disks away)– Clearing (Protection against simple keyboard attacks)– Purging (Protection against laboratory attacks)– Destroying
Key Disposal
Idea introduced by Dan Boneh Encrypt data with a key When you want to delete data, simply “throw
away” the key– Destroy device keys reside on– Secure overwrite keys
Problems: A key per file may be too course grained. A key per block is a huge amount of keys to manage
User Tools Use Gutmann or other overwriting technique
– Wipe– Boot and Nuke– Etc…
Somewhat effective, however– Can’t destroy metadata (names, size, etc.)– Get fooled by truncate– Can’t be interposed by operations
mv fileA fileB
Secure deletion needs to be done at lower level– File system, device driver, device
Secure Deletion in Versioning Systems
Legislation also requires versioning in file system
Current secure deletion techniques cannot by directly applied
Remember– Data are often shared between version– Data cannot be kept contiguous
Problems with Secure Deletion Key Disposal: Block sharing hinders key
management– Could never discard a version-key – Fine-grained deletion requires a key per block, and results in
an explosion of keys Secure Overwriting: Naively overwriting a shared
block will erase it from subsequent versions Secure overwriting has performance concerns
– Identifying shared block dependencies before committing to a deletion
– Overwriting is very slow– Data to be removed should be contiguous
Our Big Idea
A keyed transform takes a key, a data block, and a nonce
Creates an encrypted block and a small stub When the key is private, data is secure and
authenticated Securely overwriting a stub, securely deletes the
corresponding data block, even if the adversary is later given the key
iiik sCNBf ||),( →
C0
Secure Deletion Example
C1 C2
s0 s1 s211 …
Disk
File Metadata
17 …
C0
Secure Deletion Example
C1 C2
s0 s1 s211 …
Disk
File Metadata
s0 s1 s2
Receive a write to block #2 at time 17
C1’
s1’
C0
Secure Deletion Example
C1 C2 C1’
s0 s1 s211 …
Disk
s0 s1’ s217 …
File Metadata
Delete file at time 11
C0
Secure Deletion Example
C1 C2 C1’
s0 s1 s211 …
Disk
s0 s1’ s217 …
File Metadata
Delete file at time 11
Block C1 is deleted permanently
Features of Our Design The stubs are not secret and reveal nothing
about the data or the key Stubs for a version are stored together. Overwriting 4K of stubs erases 1MB of (non-
contiguous) data.
Our Contributions
Two algorithms for the secure deletion of data in a versioning file system– One based on the all-or-nothing transform– One based on randomized keys
Big Result: Our deletion technique is 200X faster than traditional deletion
The AON Secure Deletion
Based on the all-or-nothing (AON) transform designed by Rivest
A partial output of the ciphertext reveals nothing about the plaintext
No single ciphertext message can be decrypted in isolation
Requires no additional keys
AON Secure Deletion
Overwriting any small subset of the ciphertext block deletes the entire block
The encryption creates a message expansion that is bound to the same AON properties
The expansion becomes the stub and can be securely overwritten to erase the entire data block
Random Key Secure Deletion Encryption must employ randomization to avoid such
a text guessing attack Each data block is encrypted with a randomly
generated key Each random key is encrypted with the user’s key,
and serves as the stub Like AON, uses authenticated encryption and does
not need extra keys Random key secure deletion draws upon the Boneh
key disposal and lock-boxes in Plutus [Kallahalla03]
Random Key Secure Deletion
Suffers from a larger message expansion– A 384 bit stub vs. 128 bit stub– Only the encrypted key needs to be securely
overwritten
Cannot delete any subset of the bits. Must delete stub.
Implementation
We’ve implemented secure deletion in the ext3cow versioning file system
Available at: www.ext3cow.com
AON Encryption
txxx
ccCTRAESxx
xidctr
ccSHAHMACt
ddCTRAEScc
xidctr
m
mctrtm
idx
mM
mctrKm
idx
⊕⊕⊕←−←
←
−−←−←
←
−−
−−−
...:6),...,(,...,:5
0||||:4
),...,(1:3),...,(,...,:2
0||1||||:1
10
11
||||1282
1
11
1||||1281
2
1
Input: Data Block d1,…dm, Block ID id, Counter x, Encryption key K, MAC key M
Output: Ciphertext Block x1,…xm, Stub x0
Random Key Encryption
),(1:6
)(:5
0||||:4
),...,(,...,:3
||:2
:1
0
||||128
11
oM
ctrK
idx
nnoncekm
AER
cctrSHAHMACt
kCTRAESc
xidctr
ddAEcc
xidnonce
k
−−←−←
←
←
←Κ⏐ ⏐←
−−
Input: Data Block d1,…dn, Block ID id, Counter x, Encryption key K, MAC key M
Output: Ciphertext Block c1,…cn, Stub x0, Authentication t, c1,…cm
……
C0
Secure Deletion Variation Example
C1 C2
s0 s1 s211 …
Disk
File Metadata
s0 s1 s217 ……
……
C0
Secure Deletion Variation Example
C1 C2
s0 s1 s211 …
Disk
File Metadata
s0 s1 s217 ……
Future Directions:A Verifiable Audit Trail
Data on disk is easily malleable– Data may be forged, deleted, or otherwise altered
Legislation requires companies to make a strong statement about data validity
Methods of authenticating data exist, but are unsuitable in the versioning environment– Unable to efficiently create a verifiable chain of
changes How do we combine proving something exists
to a 3rd party with deleting something forever
The Ext3cow File System Open-source file system, based on ext3, that
implements file system snapshot and versioning– Captures immutable, point-in-time views of the
entire file system
Intuitive time-shifting interface for accessing the past
Encapsulated entirely in the file system Low storage overhead and negligible
performance degradation
Electronic Record Legislation HIPAA (1996)
– Technical security mechanisms
– Physical safeguards E-SIGN (2000)
– Digital contracts are as legitimate as paper contracts
FISMA (2002)– Framework for ensuring
security controls for storage– Security of system must be
commensurate with security of data
Sarbanes-Oxley (2002)– CEO, CFO responsible for
accurate financial reports– Management assessment of
internal controls– Real time disclosure– Criminal penalties for altering
documents Gramm-Leach-Bliley (2002)
– Consumer records kept confidential
– Protect against threats and unauthorized access
Federal Records Act DoD Directive 5015.2
Ext3cow Related Work Enumerated Versions
– Cedar, VMS, TOPS No meaningful way to access old versions
File System Snapshot– FFS, LFS, Spiralog
Snapshot used for recovery No access to past versions
– WAFL Discrete access to versions
Time-oriented interface– Elephant
No stable inodes VFS implementation
Ext3cow Design
Encapsulated totally within the on-disk file system layer– No kernel interfaces are changed– Easy to install (modularity)– Finer grained control over kernel data structures
Metadata organization Data placement Memory management
– Provides stable inode numbers
Time-shifting Interface
Versions are accessed through a time-shifting interface
Time-shifting provides a continuous view of time
Past looks like a logically complete backup Past is accessed via the ‘@’ token
– cat filename@TIME– cd directory@TIME
Interface Example