Truecrypt contains a feature that let's you create a hidden volume. It's said that it can't be proven if a hidden volume exists. However, is it possible to infer from the state of the data on the disk that a hidden volume is very likely to exist? Firstly, if the non-hidden partition didn't take up the whole disk, that's a pretty good clue right there. Also, the non-used portion likely wouldn't contain random (random looking because it's encrypted) but rather bits and pieces of old files (because the OS doesn't really overwrite data when deleting). Doesn't the existence of a bunch of random empty space in your drive infer that there is likely a hidden partition, similar to how they state that when using file hosted partitions, there is no plausible deniability because there is no reason, other than an encrypted file, to have file full of random data on your disk.

I wonder how a frequency distribution of the "random" data in the "empty space" on this volume would look compared to the frequency distribution of the random data in the actual empty space of a volume. Makes me think of Benford's law.
–
George MitchellMay 29 '14 at 17:20

3 Answers
3

Plausible deniability in the context of hidden encrypted volumes is a bit of a misnomer. “Possible deniability” would be a better name. There is no way to confirm the existence of such volumes without knowing the passphrase, but there are certainly ways to infer their existence.

If the hidden volume is not inside a plain volume, the presence of completely random unoccupied space will be a red flag. If the hidden volume is inside a plain volume, less so; since TrueCrypt volumes can't be resized, it's perfectly plausible that you created a 20GB volume just for future-proofing even if you're now only using 2GB.

A simple active action to infer the existence of a hidden volume is to attempt to fill that empty-looking space. If you object or twitch, if you show any attachment to that empty-looking space, you've confirmed the suspicion that there is indeed a hidden volume. So if you have a hidden volume, you'd better be comfortable with the idea that it can be deleted at any time.

A general technique to infer the existence of an empty volume is to look for traces of access to an absent drive. Your recent document history, your command line history, your system logs might contain references to that volume, possibly (especially with respect to the system logs, or inconsistencies between the system logs and application logs) in a way that shows that the volume was not a removable drive that you don't happen to have on your person. So you'd better not access that hidden volume with your regular operating system.

You can hide a whole operating system on the hidden volume. Then what might be suspicious is when you did not use your normal operating system. So you took a computer into the country and never booted it? Suspicious! A good cover story for that would be to make your apparent operating system execute only in RAM and save nothing to disk (“it's just for web and mail, and my mail is stored on the server, this way I'm not worried about viruses”).

The very existence of hidden volumes is in fact a bit of a disservice, because you cannot easily refute their presence. The best you can do is be willing to fill your empty-looking space on demand, which may not completely alleviate any suspicion that you did have a hidden volume.

If you want to hide some data, the empty space of an apparent encrypted volume is ideal from the pure cryptography point of view, but not so much when you look at the bigger security picture. There's too much discrepancy between the apparent emptiness and the actual valuable content stored there. I would suggest hiding data inside naturally-occurring large files, such as videos; that at least gives you a reason for the space to be occupied by data that you might plausibly consider valuable.

You can only have a hidden volume in an existing volume. It can be possible to detect a truecrypt volume, but to infer if there is a hidden volume or not?

If you don't make the contents of the outer volume believable, then people may well infer there is a hidden volume that actually contains valuable stuff. There is no way to prove that, however your question is about inferring.

If someone manages to find a truecrypt container, guesses the password for the outervolume and finds a bunch of easily replaceable not at all valuable files then they would probably infer that there is a hidden volume. The idea of a hidden volume only works if you can convince people that the outer volume is the only volume, which means it would need to contain stuff worth encrypting.

...so, with proper maintenance (i.e.; Using a "non-hidden" OS regularly, if you have a hidden OS.) the answer should be "no"?
–
IsziNov 20 '11 at 3:48

@Iszi, with the hidden volume, there should be no maintenance required.
–
mikeazoNov 20 '11 at 3:52

2

For a regular hidden volume, perhaps no. And, when the hidden volume contains an OS, there is no maintenance to be done on the hidden volume, true. But, if the hidden volume does contain an OS you need to make sure that you use the host volume's OS at least as often as you use the hidden volume. Otherwise, the data on the host volume may appear "stale" which could lead one to infer that the host volume isn't the real prize -thereby prompting them to dig deeper. See here: truecrypt.org/docs/hidden-operating-system
–
IsziNov 20 '11 at 3:55

@Iszi, That's cool I didn't know about hidden oses! I do see what you mean now. I suppose that could be use to infer a hidden OS. There are things you could do though to cast doubt on using a "stale" OS to infer a hidden OS (e.g., disable automatic updates)
–
mikeazoNov 20 '11 at 4:00

But, even with automatic updates disabled, why would a security-conscious individual (i.e: One who would bother encrypting their drive at all in the first place.) allow a system that presumably holds sensitive data to become outdated? Also, there are plenty of other indicators which can tell an investigator that the system actually hasn't been used (updated or not) in awhile.
–
IsziNov 20 '11 at 4:25