FreeOTFE logo FreeOTFE
Free disk encryption software for PCs and PDAs
(PDA version of WWW site)

Plausible Deniability


The subject of "plausible deniability" and OTFE systems is a lot more involved than "do my volume files have any kind of identifying signature?"

"Plausible deniability" in OTFE systems is largely based on the theory that you can claim that your volume files are not encrypted data; you don't know what they are - you can't be expected to know every operation that your OS carries out! Perhaps it's some corrupt data that the system recovered at some stage?

This claim is only possible with OTFE systems which do not embed any kind of "signature" into their encrypted data (typically an unencrypted critical data area). FreeOTFE volume files have no such signature.

However, this simplistic approach to plausible deniability has many drawbacks, and is highly unlikely to offer any significant form of protection; for example:

  1. Encrypted data has relatively high entropy - something "corrupt files, recovered automatically by the OS" are not likely to have. (Recovered data is likely to have some form of recognisable structure, or signature, somewhere within it)
  2. Having several GB of high-entropy data stored on your HDD, together with an OTFE package, is likely to be viewed as "suspicious" at the very least...

Legal Issues

Legally, the presence of large volume files (even without any form of signature) may very well be viewed as grounds for reasonable suspicion to be raised; in which case further action may be taken by an attacker (e.g. arrest, interrogation, beating, torture, and other rubber hose cryptanalysis techniques). Obviously, if reasonable suspicion can be raised, this simplistic approach provides very little in the way of plausible deniability!

Legally (in the US at least, and in theory) what it really boils down to is: does the fact that a prosecution cannot prove that the data held is encrypted data, together with a user's denial, produce reasonable doubt as to whether the data is not an OTFE volume or not? Raising reasonable doubt as to what your volumes files really are is the aim of "plausible deniability"; leaving it up to the prosecution to prove, beyond reasonable doubt, they store encrypted data.

In the UK (AIUI), things are slightly different with the "Regulation of Investigatory Powers Act (RIPA)" (see Depending largely on how the courts may interpret it, a user (as defendant) may eventually find yourself in the position of effectively having to prove that the data found is not an OTFE volume (or any other form of encrypted data).

Hidden Volumes

More advanced OTFE systems go one step further: support for hidden volumes (as FreeOTFE does).

Here, you have a "normal" OTFE volume filled with data that you have no objection to disclosing to an attacker. Mounting the volume with a different password causes the OTFE system to read a different part of the "host" volume file; giving access to a separate "hidden" volume.

Here the concept of "plausible deniability" is much stronger; theoretically an attacker is not able to determine (let alone prove) whether or not such a hidden volume is present.

However, the implementation of such "hidden volumes" is not as trivial as it may seem at first.

In order for this approach to be successful, the host volume file must be initialized by writing random data to it. This is required since the host volume file may well have been created by simply writing 0x00's to your HDD in order to generate a large enough file. Any hidden volume stored within such a host volume file may well cause an attacker suspicion as to whether a hidden volume exists. (The hidden volume will appear as a large amount of high-entropy data, stuck in the middle of the volume file; interrupting the neat pattern of 0x00's!)

The "random data" used for this process cannot simply be pseudorandom data; given the size of a typical volume file (even ones as small as a MB), pseudorandom data can potentially be identified as such, and become predictable. In this case, your hidden volume will not appear as high-entropy data stuck in the middle of a series of 0x00 bytes, but as high-entropy data interrupting any pattern formed by the pseudorandom data!

Because truly random data can be difficult to rapidly generate in large quantities using a computer. Pseudorandom data can still be used though: by encrypting it before it is written to the host volume file. In principle, although not as good as a cryptographically secure RNG, this should give the data written to the volume file a suitable degree of entropy.

The easiest way of accomplishing this is, which will work with any OTFE system, is to mount the host volume as per normal and overwrite all of its free space with a single pass of pseudorandom data. The data written to the mounted volume will be encrypted as it is written to the host volume file.

More Advanced Hidden Volumes

The technique described above for mounting and overwriting a volume before creating a hidden volume on it still isn't enough though.

If you were to be forced to hand over the key to the outer, "host", volume; an attacker could then apply the same analysis - but this time to the mounted (plaintext) version of your host volume. Again, any hidden volume may well stick out in any pattern within the pseudorandom data.

The solution suggested is to encrypt the pseudorandom data before it is used to overwrite the mounted volume's free space; any attacker attempting to identify a hidden volume, even with the key to the outer "host" volume, would not be able to differentiate between your encrypted pseudorandom data, and an encrypted hidden volume.

This all assumes the cypher used is strong enough, of course...

For obvious reasons, all such overwriting must be carried out before the hidden volume is created (doing so afterwards would probably corrupt your hidden volume!)

In Practice

Needless to say, FreeOTFE offers full functionalty with overwriting and the encryption of random data used, and support for arbitary numbers of hidden volumes within a single host volume.

To ensure the maximum security for your volumes, the following procedure is suggested after creating each new volume:

  1. Mount the new volume
  2. Select the new volume just mounted, and then select the "Tools | Overwrite entire drive..." menuitem. (Note: The "Overwrite free space..." option should not be selected for this purpose, as this will miss overwriting parts of the volume which the filesystem reserves)
  3. Doublecheck that you have selected the right volume, and confirm your actions at the prompt displayed
  4. Select "Encrypted data", and a suitable cypher from the dropdown list. Note that the cypher selected does not have to be the same as the one used to secure your volume.
  5. Click "OK"
  6. Generate some random data to be used as the key for the cypher by "waggling" the mouse pointer over the space shown on the dialog displayed
  7. Click "OK"
  8. Click "Yes" to confirm you wish to proceed
At this point, the volume will be overwritten. Depending on your hardware, this process may take some time! After the overwrite completes, format the drive. The new volume will then be ready for use. To create a hidden volume within the volume just created, dismount the drive and carry out the normal procedure for creating a hidden volume (see the Advanced Topics section for instructions on how to do this).