TrueCrypt's Deniable File System

Fri, 18 Jul 2008 02:56:02 +0000

Together with Tadayoshi Kohno, Steve Gribble, and three of their students at the University of Washington, I have a new paper that breaks the deniable encryption feature of TrueCrypt version 5.1a. Basically, modern operating systems leak information like mad, making deniability a very difficult requirement to satisfy.

ABSTRACT: We examine the security requirements for creating a Deniable File System (DFS), and the efficacy with which the TrueCrypt disk-encryption software meets those requirements. We find that the Windows Vista operating system itself, Microsoft Word, and Google Desktop all compromise the deniability of a TrueCrypt DFS. While staged in the context of TrueCrypt, our research highlights several fundamental challenges to the creation and use of any DFS: even when the file system may be deniable in the pure, mathematical sense, we find that the environment surrounding that file system can undermine its deniability, as well as its contents. Finally, we suggest approaches for overcoming these challenges on modern operating systems like Windows.

The students did most of the actual work. I helped with the basic ideas, and contributed the threat model. Deniability is a very hard feature to achieve.

There are several threat models against which a DFS could potentially be secure:
One-Time Access. The attacker has a single snapshot of the disk image. An example would be when the secret police seize Alice’s computer.
Intermittent Access. The attacker has several snapshots of the disk image, taken at different times. An example would be border guards who make a copy of Alice’s hard drive every time she enters or leaves the country.
Regular Access. The attacker has many snapshots of the disk image, taken in short intervals. An example would be if the secret police break into Alice’s apartment every day when she is away, and make a copy of the disk each time.

Since we wrote our paper, TrueCrypt released version 6.0 of its software, which claims to have addressed many of the issues we've uncovered. In the paper, we said:

We analyzed the most current version of TrueCrypt available at the writing of the paper, version 5.1a. We shared a draft of our paper with the TrueCrypt development team in May 2008. TrueCrypt version 6.0 was released in July 2008. We have not analyzed version 6.0, but observe that TrueCrypt v6.0 does take new steps to improve TrueCrypt’s deniability properties (e.g., via the creation of deniable operating systems, which we also recommend in Section 5). We suggest that the breadth of our results for TrueCrypt v5.1a highlight the challenges to creating deniable file systems. Given these potential challenges, we encourage the users not to blindly trust the deniability of such systems. Rather, we encourage further research evaluating the deniability of such systems, as well as research on new yet light-weight methods for improving deniability.

So we cannot break the deniability feature in TrueCrypt 6.0. But, honestly, I wouldn't trust it. There have been two news articles (and a SlashDot thread) about the paper. One talks about a generalization to encrypted partitions. If you don't encrypt the entire drive, there is the possibility -- and it seems very probable -- that information about the encrypted partition will leak onto the unencrypted rest of the drive. Whole disk encryption is the smartest option. Our paper will be presented at the 3rd USENIX Workshop on Hot Topics in Security (HotSec '08). I've written about deniability before.

Underhanded Implementation of RC4

Fri, 20 Jun 2008 02:56:23 +0000

A runner-up in last year's Underhanded C Contest was a flawed implementation of RC4 that eventually just passed plaintext through unencrypted. Plausibly deniable, and very clever.

The other winners are also clever.

[SecurityRatty] tag: deniable

TrueCrypt's Deniable File System

Underhanded Implementation of RC4