Undeniable Deniable Filesystems
In a new paper published on Bruce Schneier's website (http://www.schneier.com/paper-truecrypt-dfs.pdf), researchers examine deniable file systems (DFS). The paper specifically focuses on DFS as implemented by TrueCrypt 5.1 and finds several severe limitations imposed upon DFS by regular data usage.
DFS is a hidden file system that cannot be discovered by an attacker. In TrueCrypt you can create a "hidden" volume inside an encrypted volume. The encrypted volume can consist of a file on the actual filesystem, or an entire partition or device can be encrypted. Because an encrypted file system is written with "random" encrypted bits, it is impossible to tell what portion of the hidden volume is occupied by files. Because of this organization, a hidden file system can be created inside an encrypted file system. In order to access the hidden file system a user has to supply two passwords, one to unlock and mount the encrypted file system and a separate password to unlock and mount the hidden file system. Because of the structure of the encrypted file system there is no way to tell that a hidden file system exists on the encrypted file system. This means that if forced to mount an encrypted file system (say at a border crossing) there is no way for someone examining the encrypted file system to locate a hidden file system, at least that's the idea.
In their paper, researchers examined several scenarios in which a hidden file system might be exposed by features of the operating system (specifically Windows Vista, but the findings seem to apply to Windows XP and may apply to other operating systems as well), and other applications on the computer. The paper detailed how the operating system can leave clues as to the existence of files as well as the fact that hidden filesystems exist. For instance, when Windows creates a list of "Recent" files it stores information about those files as well, including the volume serial number the file was accessed on. An attacker (or customs agent) can examine the volume serial numbers for all available volumes and because in TrueCrypt a hidden volume has a volume number separate and unique form the encrypted volume, the investigator could tell the file was mounted from a volume they weren't given access to. The paper points out several media reports of people being asked to decrypt their laptops for inspection at border crossings and points out that this volume serial number discrepancy could lead border agents to suspect a hidden volume.
Even more damaging to the deniability of a DFS was the operation of many third party programs. The paper specifically examines Google Desktop and Microsoft Office. Both capture data, including snapshots of files, through their normal usage. This means that data can be leaked outside of the hidden and even encrypted volumes and stored in clear on a users computer. Microsoft Office, for instance, stores snapshots of documents so that if the program crashes the document can be recovered. These snapshots are deleted when the document is saved and closed, but they aren't securely deleted from the hard drive and can be recovered. The paper is far from exhaustive in its examination of third party programs, but they point out several cases where simply using a computer under normal circumstances can circumvent and defeat a DFS.
The topic of DFS is not particularly new. The paper cites several efforts at DFS over the years. The problem is that computers and the programs people use aren't designed for this type of privacy. Even with properly implemented encrypted and deniable file systems, the operating system and user programs don't cooperate with the privacy standards set by DFS and reveal information in a way so as to defeat DFS. Unfortunately I think computing privacy has a long way to go before a secure, private, computing platform is available seamlessly to an end user. In the interim be very careful about how you utilize DFS and be sure to understand the risks that your normal data usage may pose to the deniability of your DFS.