1 Steganographic File Systems Claudia Diaz ESAT/COSIC (K.U.Leuven)

1

Steganographic File Systems

Claudia DiazESAT/COSIC (K.U.Leuven)

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

System architecture

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

Access cycle

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

41

Thank you