![]() |
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:
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: