oramfs - ORAM filesystem written in Rust
https://github.com/kudelskisecurity/oramfs oramfs - ORAM filesystem written in Rust [Rust 1.49+](https://blog.rust-lang.org/2020/12/31/Rust-1.49.0.html) [crates.io](https://crates.io/crates/oramfs) [License: GPL v3](http://www.gnu.org/licenses/gpl-3.0) Oramfs provides a fully encrypted and optionally authenticated Oblivious RAM filesystem. Not only does it preserve data confidentiality, but it also prevents remote attackers from observing data access patterns. oramfs features: - ORAM - encrypt files and hide read/write access patterns from remote storage. Enhanced privacy! - Resizable ORAM - extend your ORAM when more space is required! - Cloud storage agnostic - synchronize your files to any remote server that can be mounted as a local directory - Filesystem agnostic - ext4 is used by default. Manual mode lets you use the filesystem you like. - Supports multiple encryption ciphers - ChaCha8, AES-CTR, AES-GCM - Supports multiple ORAM schemes - [Path ORAM](https://eprint.iacr.org/2013/280.pdf), etc. - Written in Rust - Avoids memory safety issues, great performance [DISCLAIMER] oramfs is a prototype and may not be ready for production. It may erase some of your data. Make sure to backup important data before using this software. Why use oramfs? On an encrypted filesystem, an ORAM prevents an attacker from knowing whether read or write operations are performed and which parts of the filesystem are accessed. This enhanced privacy comes with a loss of performance. To setup the ORAM, two inputs are required. A public directory and a private directory. The public directory can be seen as the server and the private directory as the client. The public directory can be any local directory, including remote data mounted as a local directory. Hence, hiding access patterns to a remote SSH directory or to a remote cloud storage is possible. Indeed, these remote storages simply need to be mounted as a local directory first, and then, that directory can be used as the public directory for oramfs . For example, [Rclone](https://github.com/rclone/rclone) supports mounting a variety of cloud storage providers as local directories. The private directory is the one that should be used to access files stored in the ORAM. Any operation performed on the private directory has an impact on the public directory. And if that public directory is a mounted remote storage, then it is safely and transparently synchronized to the remote server whenever an operation is performed on the private directory. Requirements - Rust - FUSE (libfuse-dev package on Debian-based systems, fuse package on Arch) Getting started Install Rust using [rustup](https://rustup.rs/) if it is not installed yet. In /etc/fuse.conf, make sure to enable the user_allow_other option. If not already installed, install the libfuse-dev (Debian-based systems) package using your package manager. For other systems, the package may be named differently. Then, build oramfs using cargo: cargo build --release To get maximum performance and take advantage of native CPU instructions (AES-NI), build in release mode and target the native CPU: RUSTFLAGS="-Ctarget-cpu=native" cargo build --release The oramfs binary will be created in the target/release directory. For convenience, add it to your PATH. Note that installing the binary can also be performed with cargo install --path .. It will be installed in ~/.cargo/bin by default. export PATH=$PATH:target/release Then, create or mount a public directory to be protected by the ORAM, and a private directory: mkdir public mkdir private Finally, run the executable and create an ORAM configuration called myoram: oramfs add myoram public/ private/ Follow the interactive instructions and complete the ORAM setup. Once the ORAM configuration is setup, the details are saved to ~/.config/oramfs/oramfs.yml. Now the ORAM can be mounted and unmounted at any time using this configuration. oramfs mount myoram To unmount the ORAM: oramfs umount myoram To enlarge the ORAM, make sure it is unmounted first, then double its size: oramfs enlarge myoram Then it can be mounted as usual and its size will be larger than before. How does it work? Instead of implementing a full filesystem, oramfs only provides a mounted file. Therefore, the user is expected to create a filesystem on top of that file using a loop device, the filesystem of their choice and finally mounting that filesystem. Note that such operations usually require root privileges and therefore oramfs requires those privileges for mounting. Sudo is called to achieve this, and therefore, oramfs can simply be run as a regular user. It will prompt for your password when sudo is called for mount-related operations. oramfs takes a public directory as input and exposes a single private file, which is a proxy for read and write operations so that they are privacy-preserving thanks to an ORAM scheme. The mounted private file can be used to setup a loop device using losetup. Then, any filesystem, such as ext4 can be created on top of that loop device. oramfs automates this process, but also lets users do it manually if they want to. +---------------------------------------------------+ | | | ext4 filesystem | <---+ or any other FS or your choice | | +---------------------------------------------------+ | | | Loop device (/dev/loop0) | <---+ created with losetup | | +---------------------------------------------------+ | | | ORAMFS (FUSE) | <---+ Input : *public* local directory | | Output : *private* single file, +-------------------+-----------------+-------------+ for use with loop device | | | | | Local directory | Cloud storage | SSHFS | <---+ Input directory can be anything | | | | that appears as a local directory, +-------------------+-----------------+-------------+ including mounted remote directories. Examples: SSH, FTP, anything supported by rclone or similar tools, any mounted FUSE filesystem, etc. Before using ORAMFS: $ tree . ├── private <---+ empty directory └── public <---+ this is the directory that the attacker can see ("public" directory) When ORAMFS is in use, every operation done in the "private" directory - or directly on the "oram" private file in the mountpoint directory - appears ORAMified in the "public" directory. In the standard use case, the user does not directly modify the "oram" private file, but instead uses a higher level abstraction (the filesystem in the "private" directory). The user typically mounts their public cloud storage to the "public" directory before running ORAMFS, so that the public files are transparently synchronized to the cloud in a privacy-preserving way. When ORAMFS is in use: $ tree . ├── private │ └── lost+found │ └── very_private_document.txt └── public └── node_0.oram └── node_1.oram └── node_2.oram └── ... $ tree /tmp/oramfs_myoram/ /tmp/oramfs_myoram/ └── oram Example with remote storage In this example, we go through the setup of an ORAM that transparently synchronizes data to a remote FTP server. Of course, one could use any other remote storage (SSH server, Google Drive, etc.). Anything that can be mounted as a local directory. We assume that an rclone remote has already been configured for an FTP server you have access to, using rclone config. The rclone config file should have an entry for that remote, similar to: [myftp] type = ftp host = 1.2.3.4 user = myusername pass = mypassword Let's mount the remote FTP server directory as local directory. We will use this directory as public directory of our ORAM: rclone mount --daemon --allow-other --dir-cache-time 1s --poll-interval 1s --vfs-cache-mode writes --vfs-write-back 200ms myftp:somedirectory/ public Create an ORAM called myoram: $ oramfs add myoram public/ private/ Please enter desired ORAM total size in bytes, or press enter to use default [default: 16000000 (16 MB)]: Adjusting ORAM size to closest valid value: 16711680 bytes Please enter path to client data directory to use, or press enter to use default [default: /home/foobar/.config/oramfs/myoram]: Please enter path to mointpoint directory to use, or press enter to use default [default: /tmp/oramfs_myoram]: Successfully added ORAM myoram. Mount the ORAM, write a file to it: $ oramfs mount myoram $ echo hello world > private/somefile When finished, unmount it: $ oramfs unmount myoram That's it! Files written/read to/from the private directory are encrypted and access patterns are hidden to the FTP server. For more details, make sure to read the Privacy section below. Configuration The main configuration file is located at ~/.config/oramfs/oramfs.yml. Existing ORAM profiles can be modified by simply editing that file. For example, the ORAM scheme could be changed from pathoram to fakeoram. For a description of all the options, see oramfs add --help. Note that changing these options probably require re-initializing the ORAM, and therefore, it's not possible to change those options without losing the data in an existing ORAM. Advanced Usage Show help with cargo run -- -h Foreground mode By default, oramfs runs in the background. Use --foreground to avoid that. Note that when oramfs runs in the foreground, it implies that manual mode is used. oramfs mount myoram --foreground Manual mode For maximum control, manual mode can be used (--manual). Mount ORAMFS using Path ORAM (with explicit parameters). The mounted ORAMFS appears as a file under the specified mountpoint directory. By default, it is in /tmp/oramfs_{ORAM_NAME}/oram. mkdir private mkdir public oramfs add myoram public/ private/ oramfs mount myoram --manual Since manual mode does not automatically mount a file system for you, you must do it yourself. To do so, create an ext4 filesystem on top of the ORAM. Note that mount automatically creates a loop device for us: mkfs.ext4 /tmp/oramfs_myoram/oram mount -o sync /tmp/oramfs_myoram/oram private/ echo "hello oram" > private/hello.txt Using another filesystem than ext4 oramfs supports any filesystem. To use something different from the default ext4, do the following. During initialization, pass the --manual flag, then manually create the filesystem of your choice on the oram file in the mountpoint directory. Here is an example with ext3: oramfs add myoram public/ private/ oramfs mount myoram --manual mkfs.ext3 /tmp/oramfs_myoram/oram oramfs umount myoram oramfs mount myoram When enlarging an ORAM using a different filesystem, pass the --manual flag. Then, manually resize and unmount the oram file: oramfs umount myoram oramfs enlarge myoram --manual resize2fs -f /tmp/oramfs_myoram/oram # or equivalent for your filesystem oramfs umount myoram oramfs mount myoram Mounting multiple ORAMs at the same time When mounting multiple ORAMs at the same time, make sure that the ORAMs use different, public directories, private directories, mountpoints and client data directories. ORAM initialization Important: the first time that an ORAM is mounted, the --init option is passed automatically. --init is a destructive operation and it will permanently destroy any data in an existing ORAM. In practice, there should be little need to manually pass --init. oramfs looks at the init property in the global oramfs config file to determine whether the ORAM was already initialized. Using other ORAM schemes than Path ORAM This prototype currently only implements [Path ORAM](https://eprint.iacr.org/2013/280.pdf), but it is built so that more schemes can be added in the future. To prove this, there is a second scheme named fakeoram built-in, but it should not be used in production because it is not a true ORAM. FakeORAM is a "Hello World" example ORAM scheme that could be useful for developers who want to add new ORAM schemes to oramfs. To use another scheme, such as fakeoram, update the configuration file and change the algorithm entry to fakeoram. Then simply mount and initialize the oram. Privacy The public directory can be safely mirrored to the cloud, without the cloud provider knowing which file is being accessed and whether read or write operations were performed. One scenario would be to mount a remote Google Drive directory as the public directory, and use that public directory as the public directory for the ORAMFS. Performance When native CPU instructions can be used, AES may be faster than ChaCha8. Changing the cipher can be achieved by passing the --cipher aes-ctr or --cipher aes-gcm flag on adding an ORAM, for example. One can also directly edit the configuration file and reinitialize the ORAM with the updated cipher. Note that this will destroy any data in the ORAM, so proceed with caution when initializing an ORAM. To achieve the best performance, make sure to build or run using cargo's --release flag and to pass the RUSTFLAGS="-Ctarget-cpu=native" environment variable. Benchmarks oramfs was compared to [UtahFS](https://github.com/cloudflare/utahfs). Oramfs was used with default values (AES-GCM, 16MB oram size). UtahFS was used with a local disk and the oram option was set to true. Note that performance is highly sensitive to the choice of n, z and b parameters in oramfs. In this benchmark, the defaults were used for 10MB. Then the ORAM was enlarged (n was doubled) for 25 MB. Read performance File size oramfs UtahFS Speedup 10 MB 1 sec 9 sec 9x 25 MB 3 sec 26.5 sec 8.8x Write performance File size oramfs UtahFS Speedup 10 MB 15 sec 30 sec 2x 25 MB 50 sec 95 sec 1.9x Usage on SSD or flash storage For each read or write operation, the ORAM scheme actually performs multiple operations under the scenes. Even for read operations, underlying write operations are performed. This can significantly reduce the lifespan of SSDs. Limitations and future work Note that oramfs is still a prototype and has the following known limitations. Memory zeroization Memory is currently not zeroized on exit/crash. An attacker may be able to extract private keys or passphrases from non-zeroized memory. Read caching If reads are cached, then the ORAM won't perform any work on cached reads. This is a privacy issue because it would mean that if all reads are cached, then we can be sure that any modification to the public directory must be a write operation. To avoid read caching, on Linux, always clear the kernel cache before reading a file from the ORAM: # sync; echo 1 > /proc/sys/vm/drop_caches Testing Run tests with cargo test --release Contributing Feel free to open an issue or pull request. Code should be formatted with rustfmt. To automatically format the whole project: cargo fmt No warnings should appear when running cargo build and cargo clippy. Additionally, all tests should pass (See Testing section).
On 30/06/2021 22:55, coderman wrote:
I read that bit, and I still don't know how it works. You don't explain properly, just give a lot of irrelevant implementation stuff. In all cases, but especially for explanations, keep it simple. And answer the question, don't futz around - I don't want to know how you implemented it (at least not here), I want to know how it works.
That's it! Files written/read to/from the private directory are encrypted and access patterns are hidden to the FTP server.
Not as far as I can see. It seems simple to attack, 'oh look the file(system) has been changed, the user wrote or deleted a file' therefore he has accessed the filesystem. Have you considered how to do secure deletion? It is very tricky. If an attacker can see the raw fs in a state which includes a particular file, and the key is not deleted, then if he gets the undeleted key at any future time he can read the file. Peter Fairbrother
I have not reviewed the source. https://en.m.wikipedia.org/wiki/Oblivious_RAM An *oblivious RAM (ORAM) simulator* is a compiler <https://en.m.wikipedia.org/wiki/Compiler> that transforms algorithms <https://en.m.wikipedia.org/wiki/Algorithms> in such a way that the resulting algorithms preserve the input <https://en.m.wikipedia.org/wiki/Input/output>-output <https://en.m.wikipedia.org/wiki/Output_%28computing%29> behavior of the original algorithm but the distribution <https://en.m.wikipedia.org/wiki/Probability_distribution> of memory <https://en.m.wikipedia.org/wiki/Memory> access pattern of the transformed algorithm is independent of the memory access pattern of the original algorithm. The definition of ORAMs is motivated by the fact that an adversary can obtain nontrivial information about the execution of a program and the nature of the data <https://en.m.wikipedia.org/wiki/Data> that it is dealing with, just by observing the pattern in which various locations of memory are accessed during its execution. An adversary can get this information even if the data values are all encrypted <https://en.m.wikipedia.org/wiki/Encryption>. The definition suits equally well to the settings of protected programs running on unprotected shared memory <https://en.m.wikipedia.org/wiki/Shared_memory> as well as a client running a program on its system by accessing previously stored data on a remote server <https://en.m.wikipedia.org/wiki/Remote_server>. The concept was formulated by Oded Goldreich <https://en.m.wikipedia.org/wiki/Oded_Goldreich> in 1987.[1] <https://en.m.wikipedia.org/wiki/Oblivious_RAM#cite_note-G87-1>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, July 1st, 2021 at 5:01 PM, Peter Fairbrother peter@tsto.co.uk wrote:
i did not write this, but i did want to point out: even reads drive obfuscating writes to the underlying volume. note that for SSDs in particular, this is a change in behavior: usually once error limit reached, and write leveling maxed out, you can still read what has been written. in this case, only reading can still drive duty cycle to failure on SSD type storage. i don't have a specific number on write overload for any activity (including reads) but this would be useful to know in advance... best regards,
On Sat, Jul 3, 2021 at 5:08 PM coderman <coderman@protonmail.com> wrote:
Here's the scheme they mention as an option, it has what you're looking for... https://eprint.iacr.org/2013/280.pdf Seems like something a service provider uses, might result in thier hosting provider doing slightly more ssd swaps. What are some motivations for a general oram fs? Travis -- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com>
What are some motivations for a general oram fs?
Travis
Travis, I felt quite scared and confused and a little angry reading this question. What led you to ask it? What kind of plans are you hoping to inform from the answer? Do you use encryption, or do anything to protect your privacy? Regarding access timing, like tor you could use cover traffic accessing your data, writing and reading to it constantly. I wonder if there is something newer than ORAM that obscures access timing patterns.
On Mon, Jul 5, 2021 at 6:32 AM Karl Semich <0xloem@gmail.com> wrote:
Karl, The last system I used that employed chaff packets was https://en.wikipedia.org/wiki/WASTE. WASTE had a setting that would generate traffic constantly - there was a little discussion with the Tor people around whether or not to employ a similar system, but they decided against it. The question is earnest, I literally don't know why you would want an ORAM-FS for general personal use. The linked paper covers the ability to recover information in a multi-user environment, and suggests an ORAM storage to account for that - I get that. An ORAM-FS is different. What threats does the added benefit of using ORAM account for in a file system? As in; I really enjoy encryption and privacy, and I'm looking to get read up on when and where I should apply ORAM to a filesystem. -Travis -- Twitter | LinkedIn | GitHub | TravisBiehn.com
Travis, WASTE sounds super cool. The question is earnest, I literally don't know why you would want an
It is frightening that it is in earnest for you to find more value, without expressing a reason to. I am reminded of times projects have been disrupted, or behaviors and situations been profiled preceding great harm What do threats matter, when there is an opportunity to encrypt? When something like this is posted, it is a blessing. Ideally, everyone would be using oramfs as much as they possibly could, for everything. To protect their privacy for the times when it ends up being relevant. The threat is that we might stop doing that. It is a very, very large threat.
I'm afraid I can't give a good answer because of my "locks" situation, but obviously we are enswathed with multi-user disk situations, for real.
On Mon, Jul 5, 2021 at 2:04 PM Karl Semich <0xloem@gmail.com> wrote:
I'm afraid I can't give a good answer because of my "locks" situation, but obviously we are enswathed with multi-user disk situations, for real.
Karl, If I asked 'what do you have to hide?' then I think your spidey sense should tingle :) That's not the case. ORAM is a technique that you can apply to a system, an encrypted filesystem ideally incorporates the requisite design and mix of primitives in order to achieve effective operational security, with that meets operational impact objectives. I'm wondering why I would take on the operational costs (to my mission, say, 'taking over the moon', and cost, for example, of decreased bandwidth and increased latency) of a filesystem that uses ORAM, rather than conventional encrypted filesystems. As another example, a 'hidden volume' is a feature that an encrypted filesystem can have, I can explain that a hidden volume exists to counter a rubber hose attack. If someone asked why a hidden volume is useful there's no problem in asking or answering the question. The attack isn't obvious to everyone and consequently the benefit of suffering the operational burden of solving the problem (e.g. using hidden volumes with plausible contents) can't be understood until explained. So maybe with this framing in mind; what attacks does the use of ORAM-FS counter? -Travis -- Twitter | LinkedIn | GitHub | TravisBiehn.com
On Mon, Jul 5, 2021, 3:17 PM Travis Biehn <tbiehn@gmail.com> wrote:
asked why a hidden volume is
useful there's no problem in asking or answering the question. The
attack isn't obvious to everyone and consequently the benefit of
So maybe with this framing in mind; what attacks does the use of
ORAM-FS counter?
What's your threat model? I bet I can think of a lot. https://lists.cpunks.org/pipermail/cypherpunks/2021-July/088855.html Would you consider a rubber hose attack to be the only thing a hidden volume can help against?
On Mon, Jul 5, 2021 at 3:31 PM Karl Semich <0xloem@gmail.com> wrote:
Hidden volumes solve for any type of coerced decryption. I can use Tahoe-LAFS for personal backup and it'll be encrypted, but it wont have ORAM. Most academic work on ORAM is in the context of a centralized cloud service provider. ORAM was not invented in absence of a threat, but it may be applied to a system with no benefit. Here's an example statement from https://arxiv.org/pdf/1605.09779.pdf "ObliviSync: Practical Oblivious File Backup and Synchronization" "ORAM is a powerful tool that solves a critical problem in cloud security. Consider a hospital which uses cloud storage to backup their patient records. Even if the records are properly encrypted, an untrusted server that observes which patient files are modified will learn sensitive medical information about those patients. They will certainly learn that the patient has visited the hospital recently, but also may learn things like whether the patient had imaging tests done based on how large the file is that is updated. Moreover, they might learn for instance that a patient has cancer after seeing an oncologist update their records. This type of inference, and more, can be done despite the fact that the records themselves are encrypted because the access pattern to the storage is not hidden". Karl, pleasure writing to you, I hope you understand a bit better why I'm asking about ORAM-FS's benefits. -Travis -- Twitter | LinkedIn | GitHub | TravisBiehn.com
Hidden volumes solve for any type of coerced decryption.
That's what a rubber hose attack is.
I hear you asking with an eye towards when a large business or government might find it efficient to use. I don't understand why you are asking this. I observed you didn't share a threat model. Oramfs is actually completely pluggable under the hood. What do you think about expanding it so it can do non-obfuscated encryption if desired? This would be incredibly easy to add.
On Mon, Jul 5, 2021 at 4:40 PM Karl Semich <0xloem@gmail.com> wrote:
Karl, How do we know that your commentary isn't in bad faith? Textbook disruption techniques. Please share your rationale for questioning my rationale. Just kidding, -Travis -- Twitter | LinkedIn | GitHub | TravisBiehn.com
Thanks for the joke, Travis. Yeah, don't trust me, I'm messed up in the head from my fears and experiences. It's nice to read your quote that answered part of your question. I composed a couple emails that answered more as I saw them, but honestly I was scared to send them, I'm so sorry. We need to build, share, and use stuff like oramfs more. I don't know what to say to cause that.
On Mon, Jul 5, 2021 at 5:07 PM Karl Semich <0xloem@gmail.com> wrote:
Yes, The development, open distribution, and use of tools like ORAM-FS is important. Here's where I'm at; A frame; just one example of the differences between windows' early NTFS file encryption and 'TrueCrypt''s approach. In NTFS the structure of the filesystem was not encrypted, so an adversary could see all the filenames and metadata but no content. In a TrueCrypt volume an adversary has an opaque blob. An adversary can look at r/w access to a TC-like blob (a non-ORAM encrypted FS) and determine what filesystem is in use, then the attacker might guess at the boundaries of individual files, determine the specific implementation of the filesystem (a specific version), the Operating System writing to it, and when some typical files are being written to or read from. If you don't hook any commodity software up to the ORAM-FS then the attacker can probably at most glean the filesystem type and the boundaries of individual files. Depending on the filesystem they may also recover more structural information. I don't see a clear benefit when the files being r/w'd are a variety that your attacker can't predict (a mix of non-standardized mission specific artifacts). But I see an advantage if they can. It looks like access patterns are really useful when the domain of the data is constrained (in structure and type, or perhaps the access domain (e.g. search)); e.g. medical records and emails. The ORAM topic is fresh to me, maybe it's time to do a deep dive on the academic work. Happy for other examples or pointers to content that might help. -Travis -- Twitter | LinkedIn | GitHub | TravisBiehn.com
This is fun =) I can get into funny states of mind in topics like this, so if it gets weird I'm sorry. As you quoted, you can get way more information than that. I have not been through college, myself. They can train a machine learning algorithm around common types of files and identify the file types. For many files, also the content. They can also observe your behavior via other channels to learn how it relates to your disk activity and infer things about what you are doing. To do that, they have to think of it, realise that it's possible, and research it. I don't see a clear benefit when the files being r/w'd are a variety
that your attacker can't predict (a mix of non-standardized mission specific artifacts). But I see an advantage if they can.
They can theoretically classify your different file types and uses based on the different access patterns those types and uses have. Once classified, if they have another channel or the usage between classes has meaning, they can begin analysing or predicting content and use to some degree. To do that, they have to think of it, realise that it's possible, and research it. It looks like access patterns are really useful when the domain of the
data is constrained (in structure and type, or perhaps the access domain (e.g. search)); e.g. medical records and emails.
That will certainly make it easier. The ORAM topic is fresh to me, maybe it's time to do a deep dive on
the academic work. Happy for other examples or pointers to content that might help.
I have no academic experience myself, maybe others do. I was dissociated while posting this and may have stated something false as true. I am surprised to have written it so succinctly, maybe that happened because I didn't review it for accuracy. Please support community software.
On 05/07/2021 22:23, Travis Biehn wrote: [...]
Quick - well maybe not that quick - recap. I will start with what will seem like some digressions, but which aren't entirely so, and try and pull the threads together. It's a bit untidy as it contains bits written for other purposes, sorry. The first encrypted filing systems encrypted individual files, but not the associated metadata like file names, directory structure etc. This concealed file contents to some extent but not eg file size, file access patterns etc, which could be used to guess the file's contents. They did nothing to hide file existence. Deniable file systems, where an observer cannot see the files in the system and the existence of files or even filing systems can only be demonstrated by use of a key, began with Rubberhose in about 1995 (an Assange project, though aiui it was Suelette Dreyfus who did the work). They were formalised as steganographic file systems by Ross Anderson in about 2000 and there were a few papers shortly after which didn't contribute much more. These file systems were on private storage, and the idea was that an attacker would get a single snapshot of the raw encrypted and steganised file system in the private storage, through eg maid attack or seizure, to base his attack on. If a key was given or coerced then it would be cryptographically difficult for an attacker to say that there were more keys which concealed other files. This works, sort-of, in the "gimme the keys to access the files or go to jail" law-enforcement case, but in the Rubberhose use case, "gimme the keys and I'll stop torturing you" torture case not so well - a rational torturer may just keep on torturing forever. In 2005 Truecrypt filled an entire storage space with random data, then overwrote this partially with the encrypted files and metadata, sometimes as a blob, which could also be a file inside another blob. When properly set up this could both provide obscured file existence and steganographic file hiding. With the growth of cloud storage it became desirable to create a file system which provided file existence hiding when the main storage is public (as opposed to private but subject to snapshot copying) and an attacker could see all the block reads and writes. In order to get file existence hiding when the storage is public an important extra requirement is file access hiding, as otherwise the existence of files can be deduced from access patterns. As block accesses are public, we have to somehow separate block accesses from file accesses. There are other considerations like an attacker can replay the file system to any previous state, so the situation where a key which accesses a deleted file is still in use, and may be given up/demanded/coerced should be avoided. Ongoing attempts have been made, by myself and others, to extend the techniques used in steganographic file systems to create observable deniable/steganographic filing systems using public storage, but so far they have failed. The idea of oblivious transfer, where one piece of information is sent but the sender does not know which piece, had been around for a while, and in 1981 Michael Rabin showed it was possible to do it. This developed into the wider field of PIR, private information retrieval. This seems an obvious candidate for our deniable-file-system-with-public-storage, but unfortunately in single database PIR the database has to do more than serve up existing file blocks, which makes it unsuitable for use in many cases. [PIR could perhaps be used to create an untraceable messaging service on the twitter-message-length scale. The problem here is scaling, because in order to be oblivious the system has to look at each bit of data in the system for each oblivious read. However it might be possible to do some one-look-for-multiple-reads trickery.] Around 1990 Oded Goldreich and later Rafael Ostrovsky came up with the idea of oblivious RAM. This from Wikipedia: "A Turing machine (TM) is said to be oblivious if for any two inputs of the same length, the motions of the tape heads (=the pattern of reads and writes) remain the same." gives some idea. This was initially meant to be used for software protection, preventing an attacker with access to RAM from learning about the operation of the software by analysing RAM reads and writes with different inputs. Note however that other methods, eg an examination of the single pattern of reads and writes, are not defended against in the Wikipedia quote, so in practice the motions of the tape heads are not identical but only probabilistically indistinguishable. An ORAM is actually better suited to input protection by obfuscation than software protection. Then came the great idea, why not use an ORAM (an ORAM is a program in a TM or computer, not an algorithm) to connect between the private workings of the user's computer, and public storage (eg the cloud) as the RAM in the ORAM model, and thus create an observable deniable/steganographic filing system. Unfortunately I don't know of any ORAM OSFS which actually work in practice. I haven't looked at the one which began this thread in detail though. Problems of bolting ORAMs onto computers include the fact that file accesses are not all the same length or with the same temporal size distribution, and they vary by user - (we would also like to obscure which user is in play) - and thus it is very hard to set default overheads. Also the assumptions for a theoretical ORAM may be very different to the requirements of a practical file-existence-hiding program. And probabilistic indistinguishability, a requirement for a secure ORAM, is a slippery concept especially when eg the total quantity of data available to an attacker is open-ended. Peter Fairbrother
participants (5)
-
coderman -
Karl -
Karl Semich -
Peter Fairbrother -
Travis Biehn