Secure Deletion

1
Secure Deletion
2
What is Secure Deletion

• The permanent removal of data from disk
• When data is gone, its 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

3
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

4
Question?

• How would you securely remove data from your
  system?

5
Existing Techniques

• Destroy the device
• Secure Overwrite
• Key Disposal
• Secure Deletion for Versioning File System

6
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

7
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

8
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

9
User Tools

• Use Gutmann or other overwriting technique
• Wipe
• Boot and Nuke
• Etc
• Somewhat effective, however
• Cant destroy metadata (names, size, etc.)
• Get fooled by truncate
• Cant be interposed by operations
• mv fileA fileB
• Secure deletion needs to be done at lower level
• File system, device driver, device

10
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

11
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

12
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

13
Secure Deletion Example
File Metadata
s0
s1
s2
11

Disk
C0
C1
C2
14
Secure Deletion Example
Receive a write to block 2 at time 17
File Metadata
s0
s1
s2
11

Disk
C0
C1
C2
15
Secure Deletion Example
Delete file at time 11
File Metadata
s0
s1
s2
11
s0
s1
s2
17


Disk
C0
C1
C2
C1
16
Secure Deletion Example
Delete file at time 11
Block C1 is deleted permanently
File Metadata
s0
s1
s2
11
s0
s1
s2
17


Disk
C0
C1
C2
C1
17
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.

18
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

19
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

20
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

21
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 users 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

22
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.

23
(No Transcript)
24
Implementation

• Weve implemented secure deletion in the ext3cow
  versioning file system
• Available at www.ext3cow.com

25
(No Transcript)
26
AON Encryption
Input Data Block d1,dm, Block ID id, Counter x,
Encryption key K, MAC key M
Output Ciphertext Block x1,xm, Stub x0
27
Random Key Encryption
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
28
Secure Deletion Variation Example
File Metadata


s0
s1
s2
11
s0
s1
s2
17



Disk
C0
C1
C2
29
Secure Deletion Variation Example
File Metadata


s0
s1
s2
11
s0
s1
s2
17



Disk
C0
C1
C2
30
Future DirectionsA 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

31
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

32
Electronic Record Legislation

• 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

• 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

33
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

34
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

35
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 _at_ token
• cat filename_at_TIME
• cd directory_at_TIME

36
Interface Example