![]() |
FreeOTFE |
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:
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 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.
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.
To ensure the maximum security for your volumes, the following procedure is suggested after creating each new volume: