steganographic file systems
DESCRIPTION
Claudia Diaz ESAT/COSIC (K.U.Leuven). Steganographic File Systems. Talk Outline. Motivation Related Work Traffic Analysis Attacks on Continuously Observable Steganographic file systems Countering Traffic Analysis Conclusions. Slides credit : - PowerPoint PPT PresentationTRANSCRIPT
2
Talk Outline
Motivation Related Work Traffic Analysis Attacks on Continuously
Observable Steganographic file systems Countering Traffic Analysis Conclusions Slides credit:
The slides on traffic analysis attacks have been created by Carmela Troncoso
Steganographic File Systems Motivation
Problem: we want to keep stored information secure (confidential)
Encryption protects against the unwanted disclosure of information
– but… reveals the fact that hidden information exists!
User can be threatened / tortured / coerced to disclose the decryption keys
– Soldiers, intelligence agents
– Criminals forcing victims to hand bank access keys
– Journalists / human rights activists in countries where freedom of information is not guaranteed
Steganographic File Systems Motivation
We need to hide the existence of files Solution plausible deniability
– Allow users to deny believably that any further encrypted data is located on the storage device
– If password is not known, no information about existence of files
Example– Soldier revealing manuals– But keeping secret information on targets, plans, etc.
5
Talk Outline
Motivation Related Work Traffic Analysis Attacks on Continuosly
Observable Steganographic file systems Countering Traffic Analysis Conclusions
6
The Steganographic File System (I)
Anderson, Needham and Shamir (1998) First SFS, two approaches:
1. Use cover files such that a linear combination (XOR) of them reveals the information– Password: subset of files to combine– Drawbacks:
Needs a lot of cover files to be secure Writing/reading operations have high cost
7
The Steganographic File System (II)
2. Real files hidden in encrypted form in pseudo-random locations amongst random data– Location derived from the name of the file
and a password.– Collisions (birthday paradox) overwrite data
Use only small part of the storage capacityReplication (need mechanism to detect
overwriting)
8
StegFS: A Steganographic File System for Linux
McDonald and Kuhn (1999) 15 default security levels (initialized with random keys),
such that is not possible to know whether we have revealed the access keys to all levels in use
User can show lower levels but hide existence of high security ones
Block allocation table with file system content (instead of location derived from file name/password) where opening one level opens its (and all lower levels) entries in BAT
Pure replication to protect against loss of information Free implementation (v1.1.4 in http://www.mcdonald.org.uk/StegFS/)
9
StegFS: A Steganographic file system (I)
Zhou, Pan and Tan (2003)– Bitmap for blocks: free (0) or allocated (1)– Allows multi-user– Trusted (tamper resistant) user agent
Types of blocks:– File blocks (1): contain encrypted user data– Dummy blocks (0): free. Contain random data– Abandoned blocks (1): non used. Hide amount of
file blocks
10
StegFS: A Steganographic file system (II)
FAK (File access key) : individually encrypt each file– Easy share files
UAK (User access key): encrypts a hidden file that contains a directory of all of the (filename, FAK) pairs for that access level– Easy access for one user
UAK -> FAK+file name-> File header with locations of blocks
Implementation (http://xena1.ddns.comp.nus.edu.sg/SecureDBMS)
11
Mnemosyne: Peer-to-Peer Steganographic Storage
Hand and Roscoe (2002)– Distributed steganographic file system– Block oriented– Location based on file name + location key
Two operations:– putblock(blockID, data)– getblock(blockID)
Use IDA (Information Dispersal Algorithm) for replication (n out of m) – Enhances resilience– Difficults traffic analysis
12
Mojitos: A Distributed Steganographic File System
Giefer and Letchner (2002)– Combines StegFS (levels, BAT) and Mnemosyne
(distributed, block level storage)– Client – Server architecture
Client knows file name + access key Servers hold BAT, trusted with user keys
(vulnerable to server hacks) Client asks inode (previous authentication) and
then operates directly over file blocks Use cover traffic to hide patterns of access (no
details)
13
Continuously ObservableSteganographic File Systems
Previous schemes resist one/two snapshots What if attacker monitors raw storage?
– Remote or shared store– Multiple snapshots (arbitrarily close in time) prior to
coercion
Assumption: adversary can continuously record the contents of storage / monitor all accesses
14
Hiding Data Accesses in Steganographic File System
Only one proposal considering this attacker (Zhou, Pan &Tan, 2004)– Based on StegFS [PTZ03]
Types of blocks:– File blocks: contain encrypted user data– Dummy blocks: free. Contain random data
Update operations:– Data update: change content of block– Dummy update: change IV of encryption (CBC block cipher)– Relocation of blocks– Goal: not possible to distinguish data and dummy updates
Read operations:– Use oblivious storage to combine dummy and real reads
15
Talk Outline
Motivation Related Work Traffic Analysis Attacks on Continuosly
Observable Steganographic file systems Countering Traffic Analysis Conclusions
16
Traffic Analysis Attacks on Continuosly-observable Steganographic file systems
Troncoso, Diaz, Dunkelman and Preneel (2007)
Attack on the update algorithm of StegFS [ZPT04]
Exploit patterns in location accesses:– Distinguish between user active and idle periods– Find files in the system (prior to coercion)
17
StegFS:Update Algorithm
Request update B1?
Pick Randomly
B2
DummyUpdate
B2=B1?
DummyUpdate on
B2
B2 dummy?Rewrite B1
with random data
Substitute B2 for
updated B1Y
N
Y
Y
N
N
Update on B1
18
StegFS: proof of security
“For a data update, each block in the storage space has the same probability of being selected to hold the new data. Hence the data updates produce random
block I/Os, and follow exactly the same pattern as the dummy updates. Therefore, whether there is any data update or not, the updates on the raw
storage follow the same probability distribution as that of dummy updates.“
All locations have the same probability of being selected BUT:
– Location accesses produced by file updates follow different patterns than dummy updates.
Traffic analysis attacks on accessed locations!!
19
Pattern (updating B1):1. As many dummy updates on data blocks as data B2’s are
chosen
2. Overwrite file block B1 with random data
3. Overwrite dummy block B2 with the updated data
Attacking multi-block files:Update one block
Example: Update block B1=3
Dummy update on data block B2=290290
47
3
127
290 (F)
47 (F)
127 (D)
-
Operation performedAccess list
Block selected
Write B2=127 with updated content of B1
Overwrite file block B1=3 with random data
Dummy update on data block B2=47
20
Attacking multi-block files:Update a file
123175213
134
4792
345290433
127231146216
23423
34533312
2573490
2415712
12776
321468
4792009376
1259012
245222 33360
189230349432
34, 345, 127 90, 333, 76
Update F1 in 1, 2, 3
Update F1 in 34, 345, 127
Update F1 in 90, 333, 76
21
Attacking multi-block files:Algorithm
213134
4792
345290473
12723114621677
24310
23423349012
1573453332415712
12732711176
32146820015039876
Fixed GroupGF(A)
2131344792
345290473
12723114621677243102342334901215734533324157121273271117632146820015039876
2131344792
345290473
12723114621677243102342334901215734533324157121273271117632146820015039876
Moving GroupGM(A)
Moving GroupGM(A)
Moving GroupGM(A)
Fixed GroupGF(A)
Moving GroupGM(A)
Moving GroupGM(A)
Fixed GroupGF(A)
Moving GroupGM(A)
22
Attacking multi-block files:False positives
The attacker thinks he has found a file but the patterns have been randomly produced
B = size of storageb = size of file searched T = total accessesNumber of file accesses
23
Attacking one-block files:
Assumption: file blocks updated more frequently than dummy blocks
BBiP
i
D
111)(
1
123175213
147935629047
47923114621636710023
231437201
Near repetition
Near repetition
ffiP iF
11)(
Bf
1
Need more than one update (hops)
24
Attacking one-block files:Algorithm (h=5)
123175213
147935629047
47923114621636710023
4794312313476712
904316798
23934727895
46710921
263278222417322347274879
123321
479
431
278
67347
231
274
222
end
end
25
Attacking one-block files:False positives
• Dummy block updates appear near ( such that ) in the h hops considered hff
D
iDf PhPiPP
C
)1()()1(0
CCF DP
CD
)(
)(
fPDf
fPD
C
CC
26
Attacking one-block files:False negatives
A file update happens far ( ) in one of the h hops
)1()()1(1
f
h
if
DiFf P
i
hhPiPP
C
CD
27
Simulation resultsMulti-block files
10,0003%104-10
10,0003%102-3
Size of storage space
File update frequency
Number of files per size
Size of files (blocks)
0<1%>99%4-10
<2%<2%>99%2-3
False positives
Wrong sizeFiles foundSize of files
28
Simulation resultsOne-block files
10-8 100,000101210
Size of storage space
Hops
thresholdAccesses to
each fileNumber of
files C
• Rate of success func(f)
• - positivesfalsef
29
Security claims unsubstantiated
1. The algorithms do notnot produce same pattern for dummy and user updates
2. The distribution of updated locations is differentdifferent depending on whether there is user activity or not
Blocks are rarely relocated, and when they are, their new location is known
Multi-block file updates generate correlations between accessed locations
Very easy find multi-block files and easy one-block files
Attack Conclusions
A bit of randomness is not enough
30
Talk Outline
Motivation Related Work Traffic Analysis Attacks on Continuosly
Observable Steganographic file systems Countering Traffic Analysis Conclusions
31
Requirements
Different levels of security Forward and backward security after
coercion Data persistence Counter traffic analysis
32
Attack model
Continuously monitors the contents and accesses to the storage
Records all past states of the storage Performs real-time traffic analysis on the
accessed block locations Ability to coerce the user at any point
– User produces some low-level keys– Attacker inspects user computer status
Attacker should not learn about higher levels
34
Table
A password per level decrypts all the level entries Block key for forward and backward security H(·) to detect active attacks Metadata to manage the file system
35
Data persistence
High security file blocks appear as empty (while in low security mode) thus data may be lost
Erasure codes:– Converts n blocks in m such that n of them suffice
to recover the info
Regeneration of higher levels Difficult traffic analysis for file read operations
36
Traffic analysis resistance:Pool mix
Technique to anonymize email traffic used here to obscure relocation
Cycle: – Collect a block from the
raw storage, – Change its appearance, – Storing it in an pool (which
contains P blocks from previous cycles), and
– Randomly flush a block out More randomness in
relocations
37
Traffic analysis resistanceDummy traffic
Provide unobservability (idle/ non-idle periods) Automatically generated accesses to the storage. Pattern of dummy accesses must be statistically
indistinguishable from user requests The system chooses blocks at random to be read and
put in the pool– Works if files are small
More sophisticated dummy selection strategies are possible
Additional work (not presented)
Definition of metrics for unobservability and plausible deniability
Probabilistic function qψ(t)(t) to detect correlations generated by the repeated access to files
Pattern recognition algorithm for gathering evidence prior to coercion
Test for detection of file accesses after coercion
Results for unobservability and deniability
40
Conclusions
Different levels of security: Table Forward security after coercion: One-time block keys Data persistence: Erasure codes, redundancy Counter traffic analysis
Dummy traffic to conceal user activity High-entropy relocation of data to hide new
locations and access patterns Not trivial to achieve deniability for multi-block
files