Steganographic File Systems

1
Steganographic File Systems

• Claudia Diaz
• ESAT/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
3
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

4
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
• 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)

• 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 capacity
• Replication (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 -gt FAKfile name-gt 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
StegFSUpdate Algorithm
N
Y
Y
N
Y
N
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
Attacking multi-block filesUpdate one block

• Pattern (updating B1)
• As many dummy updates on data blocks as data B2s
  are chosen
• Overwrite file block B1 with random data
• Overwrite dummy block B2 with the updated data

Example Update block B13
20
Attacking multi-block filesUpdate a file
Update F1 in 34, 345, 127
Update F1 in 90, 333, 76
Update F1 in 1, 2, 3

• 123
• 175
• 213
• 1
• 34
• 479
• 2
• 345
• 290
• 43
• 3
• 127
• 231
• 146
• 216

234 23 345 333 12 257 34 90 241 57 12 127 76 321 4
68
479 200 93 76 125 90 12 245 222
333 60 189 230 349 432
34, 345, 127
90, 333, 76
21
Attacking multi-block filesAlgorithm
213 1 34 479 2 345 290 47 3 127 231 146 216 77 243
10 234 23 34 90 12 157 345 333 241 57 12 127 327
111 76 321 468 200 150 398 76
213 1 34 479 2 345 290 47 3 127 231 146 216 77 243
10 234 23 34 90 12 157 345 333 241 57 12 127 327
111 76 321 468 200 150 398 76
213 1 34 479 2 345 290 47 3 127 231 146 216 77 243
10 234 23 34 90 12 157 345 333 241 57 12 127 327
111 76 321 468 200 150 398 76
Moving GroupGM(A)
Moving GroupGM(A)
Moving GroupGM(A)
Moving GroupGM(A)
Moving GroupGM(A)
Fixed GroupGF(A)
Fixed GroupGF(A)
Moving GroupGM(A)
Fixed GroupGF(A)
22
Attacking multi-block filesFalse positives

• The attacker thinks he has found a file but the
  patterns have been randomly produced

B size of storage
b size of file searched
T total accesses
Number of file accesses
23
Attacking one-block files

• Assumption file blocks updated more frequently
  than dummy blocks

123 175 213 1 479 356 290 47 479 231 146 216 367 1
00 23 231 437 201
Near repetition
Near repetition
Need more than one update (hops)
24
Attacking one-block filesAlgorithm (h5)
90 431 67 98 239 347 278 95 467 109 21 263 278 222
417 322 347 274 87 9 123 321
123 175 213 1 479 356 290 47 479 231 146 216 367 1
00 23 479 431 231 347 67 12
479
431
231
67
347
278
274
end
222
end
25
Attacking one-block filesFalse positives

• Dummy block updates appear near ( such that
  ) in
  the h hops considered

26
Attacking one-block filesFalse negatives

• A file update happens far ( ) in one of the
  h hops

27
Simulation resultsMulti-block files
28
Simulation resultsOne-block files

• Rate of success func(f)
• -

29
Attack Conclusions

• Security claims unsubstantiated
• The algorithms do not produce same pattern for
  dummy and user updates
• The distribution of updated locations is
  different 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

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

33
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 resistancePool 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

38
Access cycle
39
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