15

I have several files on my Ubuntu system, which are LUKS encrypted partitions. For my own shame up to this day I thought that simply changing binary file's extension will be enough to hide what a file really is. I.e. if I rename my LUKS partition stuff to windows.vdi then everyone would think that this is a virtual box drive, although corrupted, because an attempt to use it as the extension suggests would have definitely failed.

But today I've known about the file command, which correctly shows what a file is:

file windows.vdi 
windows.vdi: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: xxx-xxx-xxx

And the same problem is with other file-types, which I would like to hide, like keepass password files, etc.

Does anyone know any way to hide file's true purpose on a system?

The idea is that in a situation where one can not resist a demand to provide passwords (for instance if he is captured physically and tortured), he should be able to deny the very existence of any encryption just after a computer was shut down, that is without hiding any files in another ones, editing files in a binary editor etc. just because he may not have enough time to do this

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
Dmitry Koroliov
  • 281
  • 1
  • 7
  • 7
    The `file` command looks at the contents of the file. Typically the first few bytes. These are sometimes called the 'magic number'. So you'll need to change those are bytes to hide the from the command. – Neil Smithline Jul 11 '15 at 19:12
  • If you don't get a good answer here, you might find better luck at superuser.com – Neil Smithline Jul 11 '15 at 19:13
  • 1
    You could conceivably take the first few bytes of a valid `.vdi` file and use it to obfuscate your LUKS data, placing your LUKS data after it in the file. Then, to read it properly, you'd have to kill that leading few bytes. It'd be easier to merely use `chmod go-rwx windows.vdi` so that `file windows.vdi` returns `regular file, no read permission` (except to you and root). – Adam Katz Jul 11 '15 at 20:48
  • @AdamKatz, thank you for the suggestion, but as I can understand the file can be read if a disk with it is attached to another computer. I've edited the question so that it would be more clear – Dmitry Koroliov Jul 11 '15 at 21:02
  • Just try not to use LUKS but the traditional way which doesn't have a header? Be sure to record the default parameters somewhere in case of version updates. – user23013 Jul 12 '15 at 10:07
  • @user23013, yes, thank you, but, as others pointed, my question really is about deniable encryption (I did not know that when I was posting it) and such encryption is not possible now at all. So, I think, there is no sense to meddle into file's contents, because the aim won't be achieved, but possibilities of file corruption would appear. – Dmitry Koroliov Jul 12 '15 at 10:26
  • I was half expecting `windows.vdi: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: xxx-xxx-xxx, Key=Xt150sP3tt#-L1/e4M67` ;-) – Michael Jul 12 '15 at 17:44

8 Answers8

18

What you're looking for is called deniable encryption.

There are two forms of deniable encryption. The first sort is "information-theoretic" deniable encryption: encryption where no mathematical analysis an attacker can perform can prove that a file is encrypted data and not a collection of random bytes. The second sort is "real-world" deniable encryption: encryption where you can do something to convince an attacker with a $5 wrench that your file does not contain the stolen Death Star plans.

Everyone will offer you the first sort. The problem with it is that normal people do not carry around large quantities of random bytes -- finding such a file is prima facie evidence that encryption is in use. The second sort does not exist, and may be impossible -- you need encryption that lets you prove a negative.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • though every answer is useful, this one has seemed as the most clear one to me – Dmitry Koroliov Jul 12 '15 at 10:40
  • I once had type-II deniable storage. Format a floppy disk using /dev/fd0h1722 and place a FAT filesystem on /dev/fd0h1440. The contents of the FAT filesystem could be anything (but empty is suspicious). Passing the correct offsets to dd on the second device can extract the data. This is an application of the steno ideas, but I haven't found one quite so good in a long time. – Joshua Jul 12 '15 at 14:40
  • 2
    Not possible? I'd suggest that a directory full of images containing a bunch of files which have had encrypted contents added in using steghide or similar would be pretty deniable, depending on the wrench-holder. For added effect, the images with the steganographic contents could be labeled "original" and smaller versions could be in a directory named "resized." Use nature scenes or otherwise "complex" images to make it harder to detect the regular offests in typical hiding mechanisms. – dannysauer Jul 12 '15 at 21:06
  • 2
    "normal people do not carry around large quantities of random bytes". This is why, as a minuscule (frankly, homeopathic) public service, I run `dd if=/dev/urandom of=random.data bs=1M count=1K` from time to time. If only a few tens of millions of other people would do the same (with whatever sizes suit them) ;-) – Steve Jessop Jul 12 '15 at 23:18
  • 2
    Doesn't Truecrypt hidden volumes provide the second sort, in a way? Of course you can't deny the first layer of encryption but you can deny the second one. – tlng05 Jul 13 '15 at 15:38
  • @tlng05, no, it doesn't. Even ignoring the fact that the "hidden volume" functionality is a major selling point of Truecrypt, an attacker can map out which pieces of the "open" volume correspond to which files, spot a large unused area, and start asking blunt questions. – Mark Jul 13 '15 at 19:48
  • But the large unused area appears as free space, doesn't it? – tlng05 Jul 13 '15 at 21:44
  • @tlng05, it appears as free space containing random data. The problem is that you can't prove that the random data is actually random, and not an encrypted second volume. – Mark Jul 13 '15 at 21:47
  • 1
    I think the biggest difference between Hidden Volumes and regular encrypted files is that there are enough people who don't use the Hidden Volume feature that you could claim there's no hidden volume and it could plausibly be true. Many people have used Truecrypt but without hidden volumes; not many people carry random data around. – tlng05 Jul 13 '15 at 21:53
  • @tlng05, "could be true" isn't good enough for the guy with the $5 wrench. – Mark Jul 13 '15 at 21:56
  • 1
    I personally don't bother with hidden volumes 90% of the time, so if I say there's no hidden volume I'm probably telling the truth. If the truth isn't good enough for the guy, I guess that sucks for me then ;) – tlng05 Jul 13 '15 at 22:07
  • +1 for the $5 wrench, totally relevant. The andwer was asking about a real world situiation – bubakazouba Jul 14 '15 at 19:38
5

Reading at your answers, what you want is called deniable encryption.

It's done by hidding an encrypted container in another encrypted container. That is because when you encrypt, the cipher text looks like random if you don't know the key.

Just by searching random in your harddrive, someone can have a good guess that you have encrypted some data and ask you for the key.

Putting random in random lets you give the first container key and deny the existence of the second one.

You should look at the truecrypt (or forks) functionnality as an example if you are interested.

Just be aware that this can be defeated just by snapshoting your harddrive and comparing two images. Indeed, if you modify something, the "random" will change and the attacker will have a good guess that you are hiding a second container defeating your plausible deniability.

r00t
  • 1,104
  • 8
  • 16
3

What you are looking for is called steganography, it is a branch of cryptography.

You can read wikipedia just for a fast start: http://en.wikipedia.org/wiki/Steganography

Thereafter, you can find that there are a couple of open-source tools to "stego" any container into .jpg or even .avi.

Such a stego-container looks like a .jpg or .avi file. Moreover, anyone could watch this .avi or .jpg. And, inside this stego-container will be your encrypted container, called LUKS.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
stegomaniac
  • 31
  • 1
2

You could encrypt the file with a second type of encryption, say 'GPG' or similar, and then the file command would not be able to determine the 'inner' file type.

Alternatively, just do something really simple like XOR-ing the file with the same file content with a one byte offset (for example), or base64 the file etc.

It depends on how much you want to obfuscate (not really security, just an inconvenience to the person using the 'file' command) or hide (using a secondary encryption).

Finally, you could consider replacing the 'file' command with a crippled one (if you have control over the executable) that doesn't recognise your file type...

David Scholefield
  • 1,824
  • 12
  • 21
2

You could append the encrypted LUKS partition to any streamable file that is significantly larger than it, such as an mp3 file:

$ cat beethovens_9th.mp3 windows.vdi > beethovens_9th_with_partition.mp3

The file will still play in most MP3 software, and will show as an MP3 file when using the file command. You will need to know the exact size of the original MP3 file to remove from the beginning of the new file when you want to use the encrypted partition, and you will have to recreate the new file when you are done using the partition.

Note that the file size will give away the fact that an encrypted partition is appended to the MP3 file. Also, different MP3 players will have different failure modes when encountering the end of the real MP3 part and the beginning of the partition part of the file. This is far from a fool-proof plan, but merely a way to defeat the file command for the most naive use case.

dotancohen
  • 3,698
  • 3
  • 24
  • 34
  • I don't know the MP3 format, but with WAV, the headers mention the size of the file, so you could prepend a WAV file and it would be easy to know how much to remove. – Kat Jul 14 '15 at 20:39
  • @Mike: MP3 was designed specifically to be streamed, thus there is no logical "beginning" nor "end" to an MP3 file. That is why there is no header mentioning the size. – dotancohen Jul 15 '15 at 05:36
1

Actually no matter the filename and file type is changed, the content still gives the fingerprint of the file type. So if you want to hide something in a system, you better store it in your own folder, assigning the permission of access/write to the file. Although root user can still access the file, however it can prevent other users (normal users) accessing this.

FYI: File type is only a reference for user, system and software. In Windows, the file type is recognised as a format that can be viewed/opened by certain program. This is because the file type list is stored in the registry in Windows. So you can just double click on the file and launch the program that should able to open up this file. However, systems like Linux, people don't do this way as the file type is just a reference for users only. You can see README file with no file type behind because people would know this is a text file readable by human. Some program do recognise the header of file, no matter what is the name and file type of it. Here is an good example: PHP uploader, the script usually read the header of the file first to determine whether it is a image file or zip file. Some programs and scripts also verify the footer bytes or data byte in somewhere of the files to confirm the file type.

So, if you really want to hide something out, better wipe out the header/footer first, however it may cause trouble when opening up the file. If you really want to hide the file, try to search something about embedding files in other file. The old trick of this would be hiding an image file into a zip file.

DrKNa
  • 41
  • 1
  • thank you for the suggestions, the references to software which hides a file in another one will be definitely useful to someone, but I need exactly to prevent any ability to find what a file really is and to keep it working. The idea is that in a situation where one can not resist a demand to provide passwords (for instance if he is captured physically and tortured), he should be able to deny the very existence of any encryption just after a computer was shut down, that is without hiding any files in another ones etc. just because he may not have enough time to do this – Dmitry Koroliov Jul 11 '15 at 20:54
  • Ok, if you want to hide the file content or file type in a machine, no matter he is caught and challenged for what files are hiding inside this particular drive or *file*, you may need to search Anti-Forensics. However, it may goes into illegal as wasting time for investigating the file content (at least this is illegal in my place). Usually, people don't do common way or use encryption softwares online, because they are crackable or predictable. People would do make their own encryption with byte shifting to ensure that the encryption is not breakable. – DrKNa Jul 13 '15 at 01:52
1

The whole of your story consists in:

The idea is that in a situation where one can not resist a demand to provide passwords (for instance if he is captured physically and tortured), he should be able to deny the very existence of any encryption.

Your goal, even if you reach it, is seriously criticized using rubber hose cryptanalysis which could harm you even more when the nefarious agent continues attacking you even after you revealed all your cipher keys.

Jander
  • 981
  • 8
  • 12
  • Your WP link doesn't discuss rubberhose cryptanalysis in general, it discusses a particular piece of software called "rubberhose." –  Jul 12 '15 at 13:17
1

For luks particularly there is a way to detach the luks header from the rest of the data. I've often used it as a sort of 2fa for fully encrypted systems.

First copy the luks header somewhere else:

cryptsetup luksHeaderBackup windows.vdi --header-backup-file header.img

Then erase it from the original location:

dd if=/dev/urandom of=windows.vdi bs=1M count=2

To access the data now use cryptsetup with the --header command line option:

cryptsetup luksOpen --header header.img windows.vdi windows

Of course, storing the header along with the image would defeat the whole purpose.

Also, keep in mind that this header plus your passphrase can be used to decrypt your volume even if you change the passphrase in the future. Treat your luks header at least as carefully as your private pgp or ssh key. When in doubt, reencrypt and shred.

GnP
  • 2,299
  • 1
  • 15
  • 25