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:
- 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)
- 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...
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
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 http://www.legislation.hmso.gov.uk/acts/acts2000/20000023.htm).
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).
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
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
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
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!)
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:
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).
- Mount the new volume
- 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)
- Doublecheck that you have selected the right volume, and confirm your actions at the prompt displayed
- 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.
- Click "OK"
- 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
- Click "OK"
- Click "Yes" to confirm you wish to proceed