Is it possible to prevent a file type from being determined in a Linux system?

Question

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

Answer 1

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.

Answer 2

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.

Answer 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.

Answer 4

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...

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.