A Web Based Covert File System

A Web based Covert File System

By: Baliga, Kilian and IftodePresenter: Chris Sosa

At a Glance

Lays out the design of a Web-Based File System that provides:

1. plausible deniability

2. sharing

3. confidentiality

Novel meld of OS and Steganography

Motivation

There exists a need to keep data confidential The Web is a great medium for sharing but has issues

Service Providers are not inherently trustworthy Service Providers are susceptible to law enforcement

However …

Knowing of the existence of confidential data is bad enough A Hacker can attempt to break the encryption Big Brother can make you release your keys

What “we” really want

1. Plausible Deniability –Presence of data cannot be determined with certainty

2. Sharing – Ability to share data with authorized users

3. Confidentiality – Hidden data cannot be uncovered

Overview

Preliminaries Definitions Discussion of Steganography Introduction to FUSE

The Design The Design Avoiding Hot Spots Additional Features

Issues Related Work Conclusion

Definitions

Quantizer – A function that compresses a range of values to one value

Installable File System – A file system that is added to the kernel of an Operating System

Steganography

Our goal:

+ =

Quantization Index Modulation Basic Idea:

Every hidden message m indexes a Quantizer that is used to encode the input file

Quantizer functions designed s.t they do not overlap and s.t. their minimum distance is maximized (perturbation)

For more information refer to “Quantization Index Modulation: A Class of Provably Good Methods for Digital Watermarking and Information Embedding” by Chen et al.

The method that CovertFS will use is QIM with Statistical Restoration (repairing the Frequency Map from the DCT)

Filesystem in User Space

Possibility to implement a file system in User Space

Has Simple API to interact with FUSE Library

The Design

Mount requires authentication to Flickr

Can find root node and allocation map with account password

Metadata and data (blocks) are encoded into JPEG images in a 1-1 method

Writes execute as in a Log-structured File system

The Design (cnt’d)

More about the allocation Map Keep track of allocation map by chaining together

images Have names mapped to same hash value (hard?)

Sharing is done with each share having its own password

Why is it so complicated?

¡We Want to Avoid Hot Spots!

File System accesses and Online Image accesses “have” different patternsFS’s tend to use the same files oftenFS’s tend to modify files

Onlookers will be suspicious if they notice hot spots

Avoiding Hot Spots

Local caching of inodes and file metadata

Chained inodes

Log-structured File System

Psuedo Random Dummy Image Fetches

Is this enough?

Additional Features

CovertFS will provide Hidden Levels Protect confidential data if existence of the File System is

uncovered User can disclose only certain levels How can this be useful besides evading Big Brother? How does this affect Plausible Deniability?

Replication Why is this in the paper?

This leads to …

Issues

No Implementation

Assumptions about Online Image Accesses without any study

Cache Coherence and Data Consistency not addressed

Related Work

StegFS by McDonald et al (in unused disk blocks)

Statistical Restoration by Solanki, Sullivan and Chandrasekaran (used)

Future Work

Implement the system Peer 2 Peer Meets CovertFS How can we address some of the issues?

Cache ConsistencyCache CoherenceHotspots

“Generating” Real Images

Conclusion

Novel way of combining the concepts of a Log-structured File System, Steganograpy, and Distributed System concepts

However, has issues such as cache coherency and consistency that has yet to be addressed

No implementation to date

Questions