Skip to content

Latest commit

 

History

History
147 lines (92 loc) · 10.8 KB

plausible_deniability.md

File metadata and controls

147 lines (92 loc) · 10.8 KB
Raw
<TITLE>Plausible Deniability</TITLE> [![LibreCrypt logo](https://github.com/t-d-k/librecrypt/raw/master/src/Common/Common/images/DoxBox128.png)](http://LibreCrypt.tdksoft.co.uk/) _[LibreCrypt](http://LibreCrypt.tdksoft.co.uk/): Open-Source disk encryption for Windows_ ***

Plausible Deniability

### Overview

The subject of "plausible deniability" and transparant encryption systems is a lot more involved than "do my containers have any kind of identifying signature?"

Some people believe they can get "Plausible deniability" by simply claiming that their volume files are not encrypted data: "I don't know what they are - I can't be expected to know every operation that my OS carries out! Perhaps it's some corrupt data that the system recovered at some stage?"

However, while LibreCrypt container files have no 'signature' that identifies them as such, this approach does not offer any significant form of protection because:

  • Encrypted data has high 'entropy' - i.e. it looks like 'random' data - something corrupt files, partial downloads, etc do not 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 disk, together with an encryption app, is likely to be viewed as "suspicious".
### 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 encrypted 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 themselves in the position of effectively having to prove that the data found is not encrypted, or of proving they have forgotten the password.

### Hidden Volumes

More advanced transparent systems go one step further: support for 'hidden' volumes (as LibreCrypt does).

Here, you have a "normal" container filled with data that you are prepared to disclose to an attacker. Opening the Container with a different password causes LibreCrypt to read a different part of the file containing the container; giving access to a separate "hidden" container.

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 container is present.

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

The host file may well have been created by writing zeros to your HDD in order to generate a large enough file. Any hidden volume stored within such a host file will stand out from the 'background'. The hidden Container will appear as a large amount of high-entropy data, stuck in the middle of the file; interrupting the neat pattern of zeros, and an attacker will know a hidden Container exists.

So in order for this approach to be successful, the LibreCrypt container file must be initialised by writing it with data indistinguishable from encrypted data. This background data is sometimes referred to as 'chaff'.

The 'chaff' cannot be just pseudo-random data; pseudo-random data can potentially be distinguished from encrypted data, and even be predictable. In this case, the hidden volume will appear as high-entropy data against a pattern formed by the pseudo-random data.

Truly random data is difficult to generate in large quantities using a computer. However data produced by a 'cryptographically secure pseudorandom number generator' (CSPRNG) is thought to be indistinguishable from random data and, importantly, from encrypted data without cracking the cypher.<1--TODO:ref-->

So to attain plausible deniability, LibreCrypt automatically overwrites any host file or partition, when its created, with the output from a CSPRNG.

The CSPRNG data is produced by encrypting pseudorandom data using a truly random key.

If no other source of randomness is enabled (on the 'RNG' tab of the advanced dialog) you will have to "waggle" the mouse pointer over the space shown on the dialog displayed.

This ensures that if a hidden volume is created, the encrypted data is invisible against the 'background'.

A related issue is that without this 'chaff' an attacker can easily tell the amount of data stored in the volume. This is because the encrypted data will only be in the file where data has been written.

This overwriting can take a long time for large volumes, particularly on flash drives. It can be disabled on the 'chaff' tab of the advanced creation dialog.

If this is disabled, note the following:

  1. An attacker can easily tell the amount of data stored in the volume.
  2. If at a later date you add a hidden volume to the file, this can easily be found by an attacker (but see below)
  3. If at a later date you create a volume with 'chaff' intending to create a hidden volume in it, an attacker may wonder why this volume is different and conclude it contains a hidden volume.

The only way to avoid this last - an attacker guessing a volume contains a hidden one, because chaff was used - is to add chaff by default to all volumes and require the user to explicitly disable it. This provides a plausible reason why chaff was used on a particular volume.

If you create a volume without using 'chaff' and at a later date you want to add a hidden volume, a way of avoiding making it visible (point 2 above) is to overwrite the free space in the 'outer' volume with CSPRNG data; to do this:

  1. Mount the outer volume
  2. Select the new volume just mounted, and then select the "Tools | Overwrite free space..." option
  3. Double-check 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 drop-down 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 (if no cryptlib is selected)
  7. Click "OK"
  8. Click "Yes" to confirm you wish to proceed

At this point, the free space will be overwritten. Depending on your hardware, this process may take some time . To create a hidden volume, 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).

Note this will miss overwriting parts of the volume which the filesystem reserves, it is also slower than using 'chaff' to start with (as the data is encrypted twice).

Legacy Versions

DoxBox v6.0 and FreeOTFE did not use 'chaff' as described above. A manual process was given (similar to that above), however this would have to be done on every volume created - even those without hidden volumes - to achieve plausible deniability.

If you ever intend to use hidden volumes, and you did not follow this process, it's recommended to create new volumes in DoxBox v6.1 or LibreCrypt 6.2 or later and move any data over. You should do likewise if you did not follow this process, and you wish to prevent an attacker knowing the amount of data stored in the container.

### Multiple Hidden Volumes

In order to increase security further, a transparant encryption system should not be limited to just a single hidden volume in any given volume, but should allow an arbitrary number of hidden volumes to be created.

This gives better security over systems which only permit a maximum number of hidden volumes within any given host volume. Even if an attacker manages to force the user to reveal that a hidden volume has been stored, there is still no way in which to determine whether more hidden volumes are still present. This has the side effect of reducing any incentive for a user to reveal the presence of any hidden volume, as doing so would not prevent an attacker from continuing to apply pressure on the user on the basis that there may be further hidden volumes.

### Practical problems with deniability

TODO:

  • repeated access (backups, wear levelling) may show changed data and reveal where data was encoded PD relies on the encoded data looking like background 'chaff'.
  • links, MRU lists
  • registry storing File System ids and device ids
  • deleted files in outer vol.
  • watermarking attacks