Top Banner

Click here to load reader

Steganographic File Systems

Dec 30, 2015

ReportDownload

Documents

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 Presentation

  • *Steganographic File SystemsClaudia DiazESAT/COSIC (K.U.Leuven)

  • *Talk OutlineMotivationRelated WorkTraffic Analysis Attacks on Continuously Observable Steganographic file systemsCountering Traffic AnalysisConclusionsSlides credit:The slides on traffic analysis attacks have been created by Carmela Troncoso

  • Steganographic File Systems MotivationProblem: 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 keysSoldiers, intelligence agentsCriminals forcing victims to hand bank access keysJournalists / human rights activists in countries where freedom of information is not guaranteed

  • Steganographic File Systems MotivationWe need to hide the existence of filesSolution plausible deniabilityAllow users to deny believably that any further encrypted data is located on the storage deviceIf password is not known, no information about existence of filesExampleSoldier revealing manualsBut keeping secret information on targets, plans, etc.

  • *Talk OutlineMotivationRelated WorkTraffic Analysis Attacks on Continuosly Observable Steganographic file systemsCountering Traffic AnalysisConclusions

  • *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 informationPassword: subset of files to combineDrawbacks:Needs a lot of cover files to be secureWriting/reading operations have high cost

  • *The Steganographic File System (II)Real files hidden in encrypted form in pseudo-random locations amongst random dataLocation derived from the name of the file and a password.Collisions (birthday paradox) overwrite dataUse only small part of the storage capacityReplication (need mechanism to detect overwriting)

  • *StegFS: A Steganographic File System for LinuxMcDonald 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 useUser can show lower levels but hide existence of high security onesBlock 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 BATPure replication to protect against loss of informationFree implementation (v1.1.4 in http://www.mcdonald.org.uk/StegFS/)

  • *StegFS: A Steganographic file system (I)

    Zhou, Pan and Tan (2003)Bitmap for blocks: free (0) or allocated (1)Allows multi-userTrusted (tamper resistant) user agentTypes of blocks:File blocks (1): contain encrypted user dataDummy blocks (0): free. Contain random dataAbandoned blocks (1): non used. Hide amount of file blocks

  • *StegFS: A Steganographic file system (II)

    FAK (File access key) : individually encrypt each fileEasy share files UAK (User access key): encrypts a hidden file that contains a directory of all of the (filename, FAK) pairs for that access levelEasy access for one userUAK -> FAK+file name-> File header with locations of blocksImplementation (http://xena1.ddns.comp.nus.edu.sg/SecureDBMS)

  • *Mnemosyne: Peer-to-Peer Steganographic Storage Hand and Roscoe (2002)Distributed steganographic file systemBlock orientedLocation based on file name + location keyTwo operations:putblock(blockID, data)getblock(blockID)Use IDA (Information Dispersal Algorithm) for replication (n out of m) Enhances resilienceDifficults traffic analysis

  • *Mojitos: A Distributed Steganographic File SystemGiefer and Letchner (2002)Combines StegFS (levels, BAT) and Mnemosyne (distributed, block level storage)Client Server architectureClient knows file name + access keyServers hold BAT, trusted with user keys (vulnerable to server hacks)Client asks inode (previous authentication) and then operates directly over file blocksUse cover traffic to hide patterns of access (no details)

  • *Continuously ObservableSteganographic File SystemsPrevious schemes resist one/two snapshotsWhat if attacker monitors raw storage?Remote or shared storeMultiple snapshots (arbitrarily close in time) prior to coercion

    Assumption: adversary can continuously record the contents of storage / monitor all accesses

  • *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 dataDummy blocks: free. Contain random dataUpdate operations:Data update: change content of blockDummy update: change IV of encryption (CBC block cipher)Relocation of blocksGoal: not possible to distinguish data and dummy updatesRead operations:Use oblivious storage to combine dummy and real reads

  • *Talk OutlineMotivationRelated WorkTraffic Analysis Attacks on Continuosly Observable Steganographic file systemsCountering Traffic AnalysisConclusions

  • *Traffic Analysis Attacks on Continuosly-observable Steganographic file systemsTroncoso, Diaz, Dunkelman and Preneel (2007)Attack on the update algorithm of StegFS [ZPT04]Exploit patterns in location accesses:Distinguish between user active and idle periodsFind files in the system (prior to coercion)

  • *StegFS:Update AlgorithmYNYYNN

    Request update B1?

    Pick RandomlyB2

    DummyUpdate

    B2=B1?

    DummyUpdate on B2

    B2 dummy?

    Rewrite B1 with random data

    Substitute B2 for updated B1

    Update on B1

  • *StegFS: proof of securityFor 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!!

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

    Attacking multi-block files:Update one blockExample: Update block B1=3

  • *Attacking multi-block files:Update a file1231752131344792345290433127231146216

    2342334533312257349024157121277632146847920093761259012245222 33360189230349432

    34, 345, 12790, 333, 76Update F1 in 1, 2, 3Update F1 in 34, 345, 127Update F1 in 90, 333, 76

  • *Attacking multi-block files:Algorithm213134479234529047312723114621677243102342334901215734533324157121273271117632146820015039876Fixed GroupGF(A)213134479234529047312723114621677243102342334901215734533324157121273271117632146820015039876213134479234529047312723114621677243102342334901215734533324157121273271117632146820015039876Moving GroupGM(A)Moving GroupGM(A)Moving GroupGM(A)Fixed GroupGF(A)Moving GroupGM(A)Moving GroupGM(A)Fixed GroupGF(A)Moving GroupGM(A)

  • *Attacking multi-block files:False positivesThe attacker thinks he has found a file but the patterns have been randomly producedB = size of storageb = size of file searchedT = total accessesNumber of file accesses

  • *Attacking one-block files:Assumption: file blocks updated more frequently than dummy blocks12317521314793562904747923114621636710023231437201

    Near repetitionNear repetitionNeed more than one update (hops)

  • *Attacking one-block files:Algorithm (h=5)1231752131479356290474792311462163671002347943123134767129043167982393472789546710921263278222417322347274879123321

    47943127867347231274222endend

  • *Attacking one-block files:False positivesDummy block updates appear near ( such that ) in the h hops considered

  • *Attacking one-block files:False negativesA file update happens far ( ) in one of the h hops

  • *Simulation resultsMulti-block files

  • *Simulation resultsOne-block files Rate of success func(f) -

  • *Security claims unsubstantiatedThe algorithms do not produce same pattern for dummy and user updatesThe distribution of updated locations is different depending on whether there is user activity or notBlocks are rarely relocated, and when they are, their new location is knownMulti-block file updates generate correlations between accessed locationsVery easy find multi-block files and easy one-block filesAttack ConclusionsA bit of randomness is not enough

  • *Talk OutlineMotivationRelated WorkTraffic Analysis Attacks on Continuosly Observable Steganographic file systemsCountering Traffic AnalysisConclusions

  • *RequirementsDifferent levels of securityForward and backward security after coercionData persistenceCounter traffic analysis

  • *Attack modelContinuously monitors the contents and accesses to the storageRecords all past states of the storage Performs real-time traffic analysis on the accessed block locations Ability to coerce the user at any pointUser produces some low-level keysAttacker inspects user computer statusAttacker should not learn about higher levels

  • System architecture

  • *TableA password per level decrypts all the level entriesBlock key for forward and backward securityH() to detect active attacks Metadata to manage the file system

  • *Data persistenceHigh security file blocks appear as empty (while in low security mode) thus data may be lostErasu