36
Department of Computer Science, Johns Hopkins University Secure Deletion

Secure Deletion

Embed Size (px)

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 Presentation

Citation preview

Page 1: Secure Deletion

Department of Computer Science, Johns Hopkins University

Secure Deletion

Page 2: 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

Page 3: Secure Deletion

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

Page 4: Secure Deletion

Question?

How would you securely remove data from your system?

Page 5: Secure Deletion

Existing Techniques

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

Page 6: Secure Deletion

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

Page 7: Secure Deletion

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

Page 8: Secure Deletion

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

Page 9: Secure Deletion

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

Page 10: Secure Deletion

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

Page 11: Secure Deletion

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

Page 12: Secure Deletion

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 ||),( →

Page 13: Secure Deletion

C0

Secure Deletion Example

C1 C2

s0 s1 s211 …

Disk

File Metadata

Page 14: Secure Deletion

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’

Page 15: Secure Deletion

C0

Secure Deletion Example

C1 C2 C1’

s0 s1 s211 …

Disk

s0 s1’ s217 …

File Metadata

Delete file at time 11

Page 16: Secure Deletion

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

Page 17: Secure Deletion

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.

Page 18: Secure Deletion

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

Page 19: Secure 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

Page 20: Secure Deletion

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

Page 21: Secure Deletion

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]

Page 22: Secure Deletion

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.

Page 23: Secure Deletion
Page 24: Secure Deletion

Implementation

We’ve implemented secure deletion in the ext3cow versioning file system

Available at: www.ext3cow.com

Page 25: Secure Deletion
Page 26: Secure Deletion

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

Page 27: Secure Deletion

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

Page 28: Secure Deletion

……

C0

Secure Deletion Variation Example

C1 C2

s0 s1 s211 …

Disk

File Metadata

s0 s1 s217 ……

Page 29: Secure Deletion

……

C0

Secure Deletion Variation Example

C1 C2

s0 s1 s211 …

Disk

File Metadata

s0 s1 s217 ……

Page 30: Secure Deletion

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

Page 31: Secure Deletion

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

Page 32: Secure Deletion

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

Page 33: Secure Deletion

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

Page 34: Secure Deletion

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

Page 35: Secure Deletion

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

Page 36: Secure Deletion

Interface Example