Steganographic File Systems

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

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 -> 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 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 dummyupdates. 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 files:Update one block Block selected Access list Operation performed 290 (F) 47 (F) 127 (D) - 290 47 3 127 Dummy update on data block B2=290 Dummy update on data block B2=47 Overwrite file block B1=3 with random data Write B2=127 with updated content of B1 • Pattern (updating B1): • As many dummy updates on data blocks as data B2’s are chosen • Overwrite file block B1 with random data • Overwrite dummy block B2 with the updated data Example: Update block B1=3

20. Attacking multi-block files:Update a file 123 175 213 1 34 479 2 345 290 43 3 127 231 146 216 Update F1 in 34, 345, 127 Update F1 in 90, 333, 76 Update F1 in 1, 2, 3 234 23 345 333 12 257 34 90 241 57 12 127 76 321 468 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 files:Algorithm 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 files:False 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 100 23 231 437 201 Near repetition Near repetition Need more than one update (hops)

24. Attacking one-block files:Algorithm (h=5) 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 100 23 479 431 231 347 67 12 479 231 431 347 67 278 274 end 222 end

25. Attacking one-block files:False positives • Dummy block updates appear near ( such that) in the h hops considered

26. Attacking one-block files:False negatives • A file update happens far ( )in one of the h hops

27. Simulation resultsMulti-block files Size of files (blocks) Number of files per size File update frequency Size of storage space 2-3 10 3% 10,000 4-10 10 3% 10,000 Size of files Files found Wrong size False positives 2-3 >99% <2% <2% 4-10 >99% <1% 0

28. Simulation resultsOne-block files Number of files Accesses to each file Hops threshold Size of storage space 10 12 10 10-8 100,000 • 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 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

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