secure data deletion...secure deletion protects the security and privacy of sensitive data corporate...
Post on 10-Aug-2020
6 Views
Preview:
TRANSCRIPT
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)
adversary compromise timelinedata obtained
examples of adversarial compromises
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
examples of adversarial compromises
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
adversary compromise timelinedata obtained
examples of adversarial compromises
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
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
{}
{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
X-axis: time; Y-axis: space of storage medium
black square: writing to a block at a time
distance between two black squares: bound on deletion latency
24
Ballooning
X-axis: time; Y-axis: space of storage medium
black square: writing to a block at a time
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
usedusedusedunusedunused
used
*... ...
data nodes
main storage area
seq # file # offset keypos data1112212
40960
00
81920
[...][...]
[...][...]
[...][...][...]8192
123456
0
valid noyesnoyesnoyesyes
unused
unused
unused
33
Key State Map
����������
1234567
next
assigned
key
erase block 2
erase block 1
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
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
usedusedusedunusedunused
used
... ...
data nodes
main storage area
seq # file # offset keypos data1112212
40960
00
81920
[...][...]
[...][...]
[...][...][...]8192
123456
0
valid noyesnoyesnoyesyes
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
kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2
KSA main storage
(3) associate key
39
DNEFS Read
kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2
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
kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2
main storageKSA
1DISCARD DN
44
DNEFS Discard
kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2
main storageKSA
(1) read key position
45
DNEFS Discard
kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2
main storageKSA
(2) discard key value
46
DNEFS Discard
kE (DN ) 33kE (DN ) 221k 1E (DN ) ......k3 k4k1 k2
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)
source encrypts destination
securely−deleting
storage medium
56
Static Tree Solution
storage medium
persistent
Legend
key (stored)
key (deleted)
data block (stored)
data block (deleted)
source encrypts destination
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
Static Tree Solution
storage medium
persistent
Legend
key (stored)
key (deleted)
data block (stored)
data block (deleted)
source encrypts destination
securely−deleting
storage medium
58
Update Mechanism
storage medium
persistent
Legend
key (stored)
key (deleted)
data block (stored)
data block (deleted)
source encrypts destination
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
Key Disclosure Graph
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
Key Disclosure Graph
����������
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
Key Disclosure Graph
k2
5k (D )5 3
SDSM
Storage Media Content
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
Key Disclosure Graph
����������
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
Key Disclosure Graph
6k (D4)
k2
5k (D )5 3
SDSM
Storage Media Content
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
Key Disclosure Graph
����������
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
Key Disclosure Graph
4)
k2
75
SDSM
Storage Media Content
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
Key Disclosure Graph
����������
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
Key Disclosure Graph
6k (D4)
k2
7
SDSM
Storage Media Content
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
top related