secure data deletion...secure deletion protects the security and privacy of sensitive data corporate...

Secure Data Deletion

Joel ReardonETH Zurich

2014

1

Secure deletion: the task of deleting data from aphysical medium so that the data is irrecoverable.

2

Why is this needed?

Secure deletion protects the security and privacy of sensitive datacorporate data, customer data, banking dataprivileged communicationsGPS locations, wireless network namese-mail autosync

3

A data item is securely deleted froma physical medium if an adversary that is given

an interface to access the medium is unableto recover the deleted data item.

4

Why is this a problem?

“delete” is often intuitively misuseddiscard: no longer need somethingsecurely delete: render it irrecoverable

file deletionimplemented by discarding the file

old solutions often faildegaussing only works for magnetic mediaoverwrite the file with zeros often doesn’t work

destroy a physical mediumexpensive, extraordinary

encrypt the datakeys can be compromised or coerced

5

Adversarial Model

We assume a computationally-bounded unpredictablemultiple-access coercive adversary

computationally-bounded: cannot decrypt withoutcorresponding key

unpredictable: compromise time is unknown; no extraordinarymeasures

multiple-access: adversary may compromise multiple times

coercive: adversary obtains any secret keys and passphrasesrequired for access

6

Security Goal

Protect the confidentiality of data for which no compromiseoccurs during its lifetime

each data item has a lifetimethe time between its initial creation and its subsequent discard.

if compromise occurs, the adversary trivially obtains all valid datagoal is that every adversarial compromise only obtains valid data

non−existing valid

...... dataread

datadatacreate discard

deletedData item

User

Some solutions do not immediately delete data after its lifetime:deletion latency: time after lifetime during which adversary stillobtains dataexistential latency: time before lifetime during which adversary stillobtains dataclocked solutions provide fixed bounds on these latencies

7

Example: secdel implementation

adversary compromise timelinedata obtained

examples of adversarial compromises

implementation

09 1002 03 04 05 06 07 08 11 12 13 14 15 1601

data items

stored

03

03

02

02

07

07

09

09

03 04 05 06 11 12 13 14 15 1601 1003

1405{1,2,4,5}

{1,4}

{1,4}

{1,2,3,4,5,6}

time

1

2

3

4

5

6

7

3 7

4 6

10

2 12

13

10

15 16

data life

14

SECDEL

8 8

{}

{4}

{4}

{3,4

,5}

{1,2

,4}

{3,4

,5}

{1,4

}

{1,2

,4}

{1,2

,4}

{1,4

}

{3,4

,5}

{3,5

}

{5}

{6}

{4,7

}

{6}

discardcreatenum

8

Example: secdel-clock implementation

implementation (clock = 4 units)



09 1002 03 04 05 06 07 08 11 12 13 14 15 1601

data items

stored

{3,4

,5}

{3,4

,5}

{1,2

,4,7

}

{3,5

,6}

{3,5

,6}

{}

{4}

{1,4

}

{1,2

,4}

{1,2

,4}

{1,2

,4}

{1,2

,4}

{4}

{3,4

,5}

{3,5

}

{3,5

}

03

03

02

02

07

07

09

09

time

1

2

3

4

5

6

7

3 7

4 6

10

2 12

13

10

15 16

data life = clock edge

14

SECDEL−CLOCK

8 8

createnum discard

03 04 05 06 11 12 13 14 15 1601 1003

1405

{1,2,3,4,5,6}

{1,4}

{1,2,3,4,5}

{1,2,4}

9

Example: secdel-clock-exist implementation

implementation (clock = 4 units)

adversary compromise timeline


data obtained

09 1002 03 04 05 06 07 08 11 12 13 14 15 1601

data items

stored

{3,4

,5}

{3,4

,5}

{1,2

,4}

{3,4

,5}

{3,5

}

{1,2

,4}

{1,2

,4}

{1,2

,4}

{1,2

,4,7

}

{1,2

,4,7

}

{1,2

,4,7

}

{1,2

,4,7

}

{3,4

,5}

{3,5

,6}

{3,5

,6}

{3,5

,6}

03

03

02

02

07

07

09

09

time

1

2

3

4

5

6

7

3 7

4 6

10

2 12

13

10

15 16

data life = clock edge

14

SECDEL−CLOCK−EXIST

8 8

03 04 05 06 11 12 13 14 15 1601 1003

1405

{1,2,4}

{1,2,3,4,5,6,7}

{1,2,3,4,5,6,7}

{1,2,3,4,5,7}

createnum discard

10

Example: inplace and semipersistent implementation



and implementations

09 1002 03 04 05 06 07 08 11 12 13 14 15 1601

data items

stored

{}

{4}

{1,2

,4}

{1,2

,4}

{1,2

,4}

{1,4

}

{1,2

,4}

{1,4

,7}

{1,4

,7}

{3,4

,5}

{3,4

,5}

{3,4

,5}

{3,4

,5}

{3,4

,5}

{3,4

,6}

{3,4

,6}

03

03

02

02

07

07

09

09

03 04 05 06 11 12 13 14 15 1601 1003

1405

{1,4}

{1,2,3,4,5}

{1,2,3,4,5,6,7}

{1,2,4,7}

time

1

2

3

4

5

6

7

3 7

4 6

10

2 12

13

10 15

15 16

data life

SEMIPERSISTENTINPLACE

8 8

createnum discard

11

Example: persistent implementation



implementation

09 1002 03 04 05 06 07 08 11 12 13 14 15 1601

data items

stored

{}

{4}

{1,2

,4}

{1,2

,4}

{1,2

,4}

{1,4

}

{1,2

,4}

{1,2

,4,7

}

{1,2

,4,7

}

{1−

5,7

}

{1−

5,7

}

{1−

5,7

}

{1−

5,7

}

{1−

5,7

}

{1−

7}

{1−

7}

03

03

02

02

07

07

09

09

03 04 05 06 11 12 13 14 15 1601 1003

1405

{1,4}

{1,2,3,4,5,6,7}

{1,2,4,7}

{1,2,3,4,5,7}

time

1

2

3

4

5

6

7

3 7

4 6

10

2 12

13

10

15 16

data life

14

PERSISTENT

8 8

createnum discard

12

Part One: Secure Deletion for Flash Memory

13

Flash memory uses

��

��

��

��

SSD

14

Flash memory organization

erase block size: e.g., 64 pages, 128 KiBerase block: unit of erasure, bad block

page size: e.g., 2 KiBpage: unit of read/write

address

0x00000

0x20000

0x40000

.......

15

Flash memory with log-structured storage

ε

file 4

blk 1

file 4 file 4 file 3 file 3

headblk 2headblk 2

file 1file 3

head head

file 1

blk 4blk 3

file 1 file 2

delete

file 3 file 1

blk 2blk 2

file 1

head

file 3

blk 1

ε ε εε ε ε ε εε

file 4

blk 1

file 4 file 4 file 3 file 3

headblk 2headblk 2

file 1file 3

head head

file 1

blk 4blk 3

file 1 file 2

delete

file 3 file 1

blk 2blk 2

file 1

head

file 1

blk 1

file 3

blk 1

file 3

blk 1

file 1

blk 1

...

... obsolete data

... ε log’s end

ε empty pageε ε ε ε ε

... ... ... ......

all empty

all obsolete

valid datafile X

block Y

erase block ~128 KB

page ~ 2 KB

Legend

ε εfile 3file 3

blk 3 head

file 1

blk 1

file 1

blk 1

file 2

blk 2

file 1

blk 3

head

file 2file 2

blk 2

ε

file 3file 3

blk 3 head

file 1

blk 1

file 2

blk 2

file 1

blk 3

head

file 2file 2

blk 2

ε

(b) after compaction(a) before compaction

16

Write and erase granularity asymmetry

media collection I/O unit erase unit erase op. relevant cost

optical disc library track disc destroy blank mediamagnetic tape vault backup cassette tape-over tape wear, drive timeflash memory memory page erase block erasure erase block wear, powerpunched cards stack column card shred blank media, repunching

1

Asymmetry between erase and write unit size is not limited toflash memory

other examples may differ greatly in scale but have a similar problemwear or efficiency requires more than just copy and erase

17

Flash secure deletion related work

Secure erase / factory resetdeletes all data on the storage medium: extraordinary

Compactioncopy valid data and erase the erase block: wear

Batched compactiontrade-off with deletion latency

Scrubbingdrain charge from flash cells; does not use erase

18

User-Level Secure Deletion on Log-Structured File Systems

19

We Investigate the Status Quo for Deletion in YAFFS

YAFFS is a log-structured flash file systemwas used for internal memory of Android smart phones

we run a modified YAFFS on a Nexus One smart phonereport erase block allocations

gives us upper bound on deletion latency

record all write behaviour

build a model of writes for simulation

20

Block Allocations on Android/Nexus

0 20 40 60 80 100 120 140Time (hours)

0

200

400

600

800

1000

1200

1400

1600

Allo

cate

d er

ase

bloc

k nu

mbe

r

X-axis: time; Y-axis: space of storage medium

black square: writing to a block at a time

distance between two black squares: upper bound on deletionlatency

21

Deletion Latency

Storage medium size Deletion latency*

200 MB 46.2 hours1 GB 169.7 hours2 GB 370.3 hours

*95th percentile measure

1

some data was not deleted

100th percentile measurement undefined

if phone is not used, then data remains indefinitely

deletion only occurs when block storing data is re-allocated

22

Three user-level solutions:purging, ballooning, and a hybrid.

23

Purging



distance between two black squares: bound on deletion latency

24

Ballooning



distance between two black squares: bound on deletion latency

25

Ballooning

0 50 100 150 200 250 300 350 400 450Erase block allocations per hour

0

10

20

30

40

50Med

ian de

letio

n latenc

y (hou

rs)

advantages:trade-off between block allocation rate and deletion latency

disadvantages:deletion is not guaranteed

26

Hybrid Solution

combine ballooning at all times with occasional purgingpurging can be clock-based or event-based

periodic purging guarantees deletionpurging is faster since ballooning occupies large empty space

well-suited to reduce the cost of purging for large media

Size Fill ratio* Ballocs/hr Deletion latency ** Daily-purge add cost

20 % 32.7 41.5 hours 64.8 Balloc/hr200 MB 63 % 53.4 10.8 hours 29.4 Balloc/hr

80 % 95.0 4.2 hours 14.8 Balloc/hr

4 % 25.3 349 hours 652.6 Balloc/hr2 GB 43 % 36.6 34.7 hours 68.0 Balloc/hr

76 % 87.5 8.5 hours 35.2 Balloc/hr80 % 205 4.7 hours 20.2 Balloc/hr

* average percent of live data per erase block

** 95th percentile measurement (100th undefined)

1

27

Data Node Encrypted File System

28

System Model

user

PERSISTENT

PERSISTENT

user

(a) existing system

(b) DNEFS system

user

file system

KSA

SECDEL

main storage

main

storage

file system

+ DNEFS

29

Keystore Properties

KSA is used to implement a keystorea special kind of storage medium whose purpose is to assign, read, anddiscard random binary stringsthese strings are used as encryption keys for blocks of datasecurely deleting the string thereby securely deletes the dataefficiency comes from the small size of the KSA, e.g., 1%

Three properties ensure that it provides fine-grained secure datadeletion:

assigned key values are unpredictableassigned key values must be fresh (bounded existential latency)discarded key value must be soon after securely deleted (boundeddeletion latency)

30

Clocked Keystore Implementation

data item

lifetime

U

A

D

assigned

unused

key positionst

ate

assign

time

replacereplace

}

deletionexistentiallatency latency

compromisable }

epoch 1 epoch 2 epoch 3 epoch 4 epoch 5 epoch 6

replace

discarded

valuestored

clock

value 1 value 2 value 3 value 4

discard

31

Key State Map

��

next

assigned

key

1234567

k k k k k43210

k k k k5 6 7

k8 9

erase block 2

erase block 1

0−4

5−9

10−14

k k k kk

k k k k k10 11 12 13 14

15 16 17 18 19

KSAkey state map

pos state

123456789

0used

usedusedusedunusedunused

used

*... ...

data nodes

main storage area

seq # file # offset keypos data1112212

40960

00

81920

[...][...]

[...][...]

[...][...][...]8192

123456

0

valid noyesnoyesnoyesyes

discarded

discarded

discarded

15−19

32

Key State Map

��

1234567

next

assigned

key

erase block 2

erase block 1

0−4

5−9

10−14

15−19 k k k kk

k k k k k10 11 12 13 14

15 16 17 18 19

k k k5 6 7

k k310

k k2

k8

k4

9k

KSAkey state map

pos state

123456789

0used


used

*... ...

data nodes

main storage area


40960

00

81920

[...][...]

[...][...]

[...][...][...]8192

123456

0


unused

unused

unused

33

Key State Map

��

1234567

next

assigned

key

erase block 2

erase block 1

KSAkey state map

pos state

123456789

0used


used

*... ...

data nodes

main storage area


40960

00

81920

[...][...]

[...][...]

[...][...][...]8192

123456

0


unused

unused

unused

0−4

5−9

10−14

15−19

k k k5 6 7

k k310

k k2

k8

k9

4k

14k

k1918

k

13kk

12

17k

16k

11k

10k

k15

34

Key State Map

��

1234567

erase block 2

erase block 1next

assigned

key

KSAkey state map

pos state

123456789

0used


used

... ...

data nodes

main storage area


40960

00

81920

[...][...]

[...][...]

[...][...][...]8192

123456

0


unused

unused

unused

0−4

5−9

10−14

15−19

k k k5 6 7

k k310

k k2

k8

k9

4k

k10

k11

k12

k13

k14

19kk

18k

17k

16k

15

*

35

DNEFS Write

kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2

KSA main storage

3DNWRITE

36

DNEFS Write

kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2

kE (DN ) 33

KSA main storage

(1) encrypt3DN

37

DNEFS Write

kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2

kE (DN ) 33

KSA main storage

(2) write data

38

DNEFS Write


KSA main storage

(3) associate key

39

DNEFS Read


1READ DN

main storageKSA

40

DNEFS Read

kE (DN ) 33kE (DN ) 22

......k3 k4k1 k2 1k 1E (DN )

1k 1E (DN )

(1) read encrypted data and key position

main storageKSA

41

DNEFS Read

kE (DN ) 33kE (DN ) 22

......

1k 1E (DN )

1k 1E (DN )

k3 k4k1

k1

main storageKSA

k2

(2) read encryption key

42

DNEFS Read

kE (DN ) 33kE (DN ) 22

......

1k 1E (DN )

1k 1E (DN )

k3 k4k1

k1

DN1

main storageKSA

k2

(3) decrypt and return data

43

DNEFS Discard


main storageKSA

1DISCARD DN

44

DNEFS Discard


main storageKSA

(1) read key position

45

DNEFS Discard


main storageKSA

(2) discard key value

46

DNEFS Discard


main storageKSA

(2) discard data node

47

Extensions and Optimizations

KSA Update Policiesdifferent data items can have different policiese.g., clock period one minute versus one hour

KSA Organizationbest batching efficiency is when discarded keys are colocated on KSAerase blocksgenerational garbage collection can be used to heuristically infer datalifetime

Improving Reliabilitythe loss of a single KSA block implies the loss of substantially more datareplication may be needed to protect data

Encrypted File SystemDNEFS can be trivially extended to an encrypted file systemencrypt the KSA’s contents with a password-derived key

48

UBIFSec

DNEFS is implemented as UBIFSecUBIFS is a flash file systemsupports logical erase blocks, wear levelling, and atomic update

Experimental validation shows it is feasible to useRequires access to raw flash

DNEFS integrated into hardware FTL would be more versatile

49

Part Two: Secure Deletion for Remote Storage

50

Why remote storage

‘Cloud’ computing has become widespreadSecure deletion may not be correctly doneAdversary may control the storage medium

Model as a persistent storage mediumFurther assume that the adversary has live access to the storage medium

51

System Model

PERSISTENT

"small"

storage medium

vulnerable tocoercive attacks

useruser

SECDEL

storage medium

"large"

continuallycompromised

52

Persistent Settings

setting tape vault remote storage

motivation cheap massive backups convience of ubiquitous access

persistent magnetic tapes networked file systems

secdel guarded machine at site smart card, laptop, mobile phone

adversary insider at vault or in transit operator of remote storage server

setting monitored communications analog remnants

motivation global passive adversary intrinsic for some media

persistent network communication media with remnants

secdel session keys, signing key media without remnants

adversary eavesdropper and key compromise advanced forensic capabilities

1

53

Two Extreme Solutions

securely−deleting

storage medium

persistent

storage medium

securely−deleting

storage medium

persistent

storage medium

key (stored) data block (stored)

source encrypts destination

Legend

54

Two Extreme Solutions

securely−deleting

storage medium

persistent

storage medium

securely−deleting

storage medium

persistent

storage medium

key (stored)

key (deleted)

data block (stored)

data block (deleted)source encrypts destination

Legend

55

Static Tree Solution

storage medium

persistent

Legend

key (stored)

key (deleted)

data block (stored)

data block (deleted)


securely−deleting

storage medium

56


storage medium

persistent

Legend

key (stored)

key (deleted)

data block (stored)



EA(B) E

ED(I)ED(H)

(BK )2EIEH

securely−deleting

storage medium A

EB(D) E (E)BEC(F) E C(G)

A(C)

(BK )1

57


storage medium

persistent

Legend

key (stored)

key (deleted)

data block (stored)



securely−deleting

storage medium

58

Update Mechanism

storage medium

persistent

Legend

key (stored)

key (deleted)

data block (stored)



securely−deleting

storage medium

59

Related Work

How to forget a secret

(c) Perlman’s Ephemerizer

(f) DNEFS

:

(e) Geambasu et al.’s Vanish

(d) Popper et al’s Porter Devices

A revocable backup system

(a) Boneh and Lipton’s (b) Di Crescenzo et al.’s

60

Related Work

Fadea service provides attribute-based securely-deletable values

e.g., expiration times, user existing, etc.

these values can be combined to form boolean expression of OR andAND

keys to encrypt data are derivable if the boolean expression is TRUEa TRUE predicate is one whose corresponding key is still available

Policy-Based Secure Deletionbuilds a directed policy graph mapping attributes to derivable keyseach node in the graph is a k-out-of-n secret share

if k incoming edges are TRUE, then the key for that node is derivableand it is TRUElogical OR and AND are special cases

provides proofs for all constructions

61

Key Disclosure Graphs and Shadowing Graph Mutations

62

Key Disclosure Graph

��

k1

4k (D2) t1

k1

kE (D )5 3k2

E (k )4kE (k )

2 3

Derivable


k2

5k (D )5 3

SDSM

Storage Media Content

t0time

value

PSM

k k4 1E (k )k3 1 2 2

E (D ) E (D )

k2E (k )

5

3k (D1)

1

1 2 3 4 5 1 2 3

datakeys

attack

time

63


��

k1

4k (D2) t1

k1

kE (D )5 3k2

E (k )4kE (k )

2 3

k1

t2

k6 4E (D )k1

E (k )6

Derivable


k2

5k (D )5 3

SDSM


t0time

value

PSM

k k4 1E (k )k3 1 2 2

E (D ) E (D )

k (D6 4)

k2E (k )

5

3k (D1)

2

1

1 2 3 4 5 6 1 2 3 4

datakeys

attack

time

64


��

k1

4k (D2) t1 t2

k1 k1

k6 4E (D )k1

E (k )6k2

E (k )5

kE (D )5 3k2

E (k )4kE (k )

2 3

k7

k 6E (k )

7

k

k 27E (k )k6 5

E (k )Derivable


6k (D4)

k2

5k (D )5 3

SDSM


t0time

value

PSM

k k4 1E (k )k3 1 2 2

E (D ) E (D )

3t

7

3k (D1)

3

2

1

1 2 3 4 5 6 7 1 2 3 4

datakeys

attack

time

65


��

k

4k (D2) t1 t2 t4

k1 k1 k7

k 6E (k )

7k 27E (k )k6 5

E (k )

k6 4E (D )k1

E (k )6k2

E (k )5

kE (D )5 3k2

E (k )4kE (k )

2 3

k1

Derivable


4)

k2

75

SDSM


t0 t3time

value

PSM

k k4 1E (k )k3 1 2 2

E (D ) E (D )

3k (D )5k (D6

3k (D1)

k7

3

2

1

1 2 3 4 5 6 7 1 2 3 4

datakeys

attack

time

66


��

k1

kk (D )5 3

4k (D2) t1 t2 t4

k1 k1 k7k7

t5

k 27E (k )k6 5

E (k )

k6 4E (D )k1

E (k )6k2

E (k )5

kE (D )5 3k2

E (k )4kE (k )

2 3


6k (D4)

k2

7

SDSM


t0 t3time

value

PSM

k k4 1E (k )k3 1 2 2

E (D ) E (D )

Derivable

3k (D1)

k

k

9

8 k10 11k (D 4 )

datakeys1 2 3 4 5 6 7 98 01 11

1

2

3

4

1 2 3 4

attack

time

k8

kkE (k )10 11 11 4

E (D )k 4E (k )

k 6E (k )

7

3E (k )kk8 10

E (k )kE (k 8 9

)9

9

67

Secure deletion

Secure deletion of a data item requires:determining all of the derivable ancestors in the KDGmaking these ancestors all underivableancestor relation based on the ever-growing KDG

How do we avoid storing the entire KDG?require that in the KDG there is at most one unique path that connectsany pair of verticesin graph theory, such a graph is called a mangrove

68

Mangroves

69

How do we ensure that the KDG is always a mangrove?We use shadowed updates.

70

Shadowing

Shadowed updates in a technique in file systemsNew versions of data are written to new (empty) locationsOld version remains but is no longer validAnything that references the old version is also shadow-updated whenreferring to the new location

We use keys instead of versionsAny change results in a new key being generated to encrypt the newversionKey wrappers must then change to store the new key, etc.

71

Shadowing Mutation

72

Shadowing Mutation

73

Shadowing Mutation

74

Shadowing Mutation

75

Shadowing Mutation

76

Shadowing Mutation

77

Related Work as Mangroves

(f) DNEFS

:

(e) Geambasu et al.’s Vanish

(d) Popper et al’s Porter Devices

How to forget a secret

(c) Perlman’s Ephemerizer

A revocable backup system

(a) Boneh and Lipton’s (b) Di Crescenzo et al.’s

78

We implement a caching B-Tree version of this solution.

79

Summary

80

Summary

We studied the problem of secure deletionData lifetime, existential and deletion latenciesComputationally-bounded unpredictable multiple-access coerciveadversary

Considered the problem for flash memoryAsymmetry in erase unit sizeProposed DNEFS for fine-grained efficient deletionUsed a clocked keystore to provide encryption keys

Considered the problem for remote storageCombination of persistent and secdelPersistent medium is continually compromisedIntroduced the key disclosure graph to reason about worst caseadversarial knowledge

81

Acknowledgments

Work presented based on articles co-authored with:My advisers Srdjan Capkun and David BasinFellow Ph.D students Claudio Marforio and Hubert Ritzdorf

Also thanks to my funders:ZISC partners (including IBM)SNF grant Sinergia Project No. CRSII2 136318/1

82

Selected Bibliography

Boneh and Lipton, “A Revocable Backup System,” 1996Gutmann, “Secure Deletion of Data from Magnetic and Solid-State Memory,” 1996Di Crescenzo et al., “How to Forget a Secret,” 1999Garfinkel and Shelat, “Remembrance of Data Passed: A Study of Disk Sanitization Practices,” 2003Perlman, “The Ephemerizer: Making Data Disappear,” 2005Kissel et al., “Guidelines for Media Sanitization,” 2006Geambasu et al., “Vanish: increasing data privacy with self-destructing data,” 2009Tang et al., “FADE: Secure Overlay Cloud Storage with File Assured Deletion,” 2010Popper et al., “Keeping Data Secret under Full Compromise using Porter Devices,” 2010Wei et al., “Reliably Erasing Data from Flash-Based Solid State Drives,” 2011Reardon et al., “Secure Deletion on Log-structured File Systems,” 2012.Reardon et al., “Data Node Encrypted File System: Efficient Secure Deletion for Flash Memory,” 2012.Diesburg et al., “TrueErase: Per-File Secure Deletion for the Storage Data Path,” 2012Reardon et al., “SoK: Secure Data Deletion,” 2013.Cachin et al., “Policy-Based Secure Deletion,” 2013Reardon et al., “Secure Data Deletion from Persistent Media,” 2013.Reardon et al., “On Secure Data Deletion,” 2014.

1

83

secure data deletion...secure deletion protects the security and privacy of sensitive data corporate...

Documents