15

What tools can be used to make truly deniable encryption? Suppose, authorities can use any force to make you open your passwords.

Truecrypt can have only one hidden container, which means that authorities will not stop, until you reveal this second password, even if you did not create hidden container.

So, is there any way to create many hidden containers, so that authorities could not even tell how many passwords they should beat out of you. And it is desirable that this way should be secure enough against other, more intelligent decryption methods like statistical analysis of used clusters and so on.

Here http://en.wikipedia.org/wiki/Deniable_encryption i've found info about rubberhose, but it is not maintained since 2000, so i dont know how much it is reliable.

Another way I found is to write to hard disk with different offsets using for example similar scripts http://sourceforge.net/projects/stlth/files/

But this way, as far as i understand, data is not mixed physically, so it is vulnerable to that smart statistics methods. I.e. if authorities see that you heavily used the part of drive that is not revealed using passwords you already gave then they continue to try to get the passwords. Rubberhose, accorging to documentation, has protection against these methods, but the project is too old.

What another tools could you advise to make several hidden containers on disk?

valentinas
  • 1,038
  • 8
  • 10
onetuser
  • 281
  • 2
  • 6
  • 2
    What ever happened to "I can't recall my password". – k to the z Apr 22 '13 at 15:27
  • 5
    Maybe someone's mom would be satisfied with this answer, but not the man with a soldering-iron who knows that you must give him exactly one more password as in case of truecrypt. Are you sure that your body will hold out longer than your tongue? – onetuser Apr 22 '13 at 15:59
  • 5
    Ha. Sorry. I thought we were in a situation where it was a legal requirement and there wasn't the threat of torture. – k to the z Apr 22 '13 at 19:41
  • Soldering Iron Anal-ogies eh? – NULLZ May 13 '13 at 11:58
  • 1
    @doom123 The solution to not reveal the password would be to make yourself forget the password and destroy the keyfiles. You'll still have to deal with the soldering iron though! – Ufoguy Jan 19 '14 at 13:17
  • 2
    I've not been interrogated with a soldering-iron during the last 40 years. The fact that you seem to worry about this becoming a reality for you suggests that _you should not write on the internet about it_. I mean, seriously, are you the head of a terror cell, or why do you think anyone cares enough about your petty secrets to torture you? – Damon Nov 16 '14 at 20:29
  • Hmm... Soldering iron Man is a pretty serious threat. Would cutting off your tongue be considered an option? – hola May 28 '21 at 15:45

7 Answers7

19

If you write random bytes to an entire device, and then create a headerless (no LUKS or TrueCrypt) encrypted block at a random point on the device, then this is not something that can be detected.

For example on Linux;

  1. Take a 100GB HDD.

  2. Fill it with random data:

    dd if=/dev/urandom of=/dev/sda bs=4K

  3. Create an encrypted loopback device at a 'random' point on the disk:

    losetup --offset $RNDOFFSET --sizelimit 5G -e aes -k 256 /dev/loop0 /dev/sda

  4. Make your filesystem:

    mkfs.ext4 /dev/loop0

  5. And mount it:

    mount /dev/loop0 /mnt/secret

The purpose of all this is that encrypted data should be indistinguishable from random bytes. This way your encrypted 5GB block is camouflaged against the random noise. Any crypto-disk headers, such as LUKS, would show clearly where the block resides, so bare encryption must be used.

Provided you keep $RNDOFFSET secret (don't go writing it to your fstab) the presence of an encrypted filesystem should be very difficult to detect.

And you can always say that the device is just a scratchpad or swap area that you use with a key that is randomly generated at each boot.

lynks
  • 10,646
  • 5
  • 29
  • 54
  • 1
    With the exception of `losetup`, each of those commands is pretty easy to understand; `dd` is just for copying data, and I use it here to copy random bytes onto the HDD, `mkfs` is equivalent to 'format' on windows, and is just used to create a file system, `mount` does not really have a windows equivalent but is pretty much like assigning a drive letter (eg X:\) to your encrypted filesystem so that you can read and write to it normally. For more info on `losetup` head over to http://en.wikipedia.org/wiki/Loop_device Also drop by the DMZ (`chat` at the top of this page) for any related queries – lynks Apr 22 '13 at 15:45
  • Thanks. 1. Is it possible to create several filesystems at different points on disk with linux system commands only? In a way they wont interrupt each other. At few points you can keep relatively inoffensive data that can satisfy a foe. 2. We need to fill random data periodically so that the foe wont be able to detect what bytes are used more often (method that uses magnetic tails that are higher on used bytes or smth. like that). Hence, to keep real data we need mount file systems first. Can we fill remain space with linux commands only? Or some utils are required? – onetuser Apr 22 '13 at 15:52
  • 1. Yep, but you will need to use one of more EBRs to create an unlimited number of filesystems. This is because each partition can only contain one filesystem at a time. 2. Yes you can write to the 'background noise' without disturbing the encrypted block, just through careful use of the `dd` command and the `bs` and `count` options. – lynks Apr 22 '13 at 16:20
  • 1
    Sorry, i ment not file systems on disk, but serveral loopback devices. File systems are created in each of them, according to your answer. Ok, looks like it is possible, thanks! – onetuser Apr 24 '13 at 16:32
  • To continue the discussion: i've created a new question. http://security.stackexchange.com/questions/35826/making-undeterminable-containers-inside-existing-file-system Shortly, if we create some file system on the original partion (too keep openly some files here), and then use a few loopback devices inside it, then original file system's metadata will be erased, wich indirectly indicates that there are hidden containers on the disk. How to avoid it? – onetuser May 13 '13 at 11:13
  • I have found a solution. Make open/hidden TrueCrypt containers on a disk. Put there some data. Make loopback device inside the disk. TC headers are kept in the begining and the end of the disk, so they wont be affected. Under tortures give both TC passwords. Thats all. 1. "Why is disk filled with random data?" It is truecrypt container. 2. "Give your passwords". Here they are. 3. "What? Only gay porn? Is there anything also?" Nope, truecrypt allows only 2 containers, sorry. – onetuser May 16 '13 at 17:12
  • Yep that would probably do it. You have to make sure your access patterns are realistic (set all disks to `noatime` so file access time is not written to disk to make this easier, you can just say you are worried about disk lifetime). – lynks May 16 '13 at 17:13
  • The above question about fs data is still actual. About fs in truecrypt containers now. Ok, will have to search infoabout fs sturcture for myself. – onetuser May 22 '13 at 10:25
  • 1
    I don't get the point of using a random offset. Any filesystem header should look indistinguishable under AES encryption, whatever its location. What's the advantage of avoiding the start of the disk? – loopbackbee Feb 18 '14 at 13:15
  • `dd if=/dev/urandom ...` is about 10x slower than `openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt – KrisWebDev Mar 19 '16 at 21:48
  • @loopbackbee you're correct about the filesystem header - I mention the crypt header, which is typically a set of data structures which exist before the encrypted region starts. In LUKS, this contains things like a master-salt, passphrase slots etc (you can have multiple passphrases per LUKS partition). But in plain-mode, I guess you're absolutely right, now that I think about it. – lynks Jun 07 '21 at 08:06
13

Disclaimer: I'm the author of cryptsetup-deluks and grub-crypto-deluks.

Deniable encryption is only a part of the solution. There's no perfect solution to protect yourself and your data if you get caught by an adversary. You can hardly avoid the suspicion of encryption, even if the adversary can't prove it. I'll list the issues and solutions.

Short partial answer

Long complete answer

Defeating torture

xkcd.com/538

Torture in this case is also known as rubber-hose cryptanalysis. The good news is that torture is often inefficient. Your resistance to torture is key, or at least your ability to provide unverifiable fake facts (like the key to decrypt a decoy O.S.). Ideally, to stop torture, you should also be able to prove that you can't decrypt the data.

Deniable encryption doesn't solve the rubber-hose problem.

Solutions fall in 2 categories. See Technology that can survive a “Rubber-Hose attack” for details.

  1. You don't have the key: the key could be split and its parts owned by several friends or hidden servers, acting as authenticators to check that you are not in a rubber-hose situation.
  2. The key was destroyed: self-destructed (alarm system) or manually destroyed (chompable microSD card, etc). Harder to put in place and time-critical, but more resistant to yourself after torture.

Hiding the encryption header

Don't use an (unencrypted) LUKS header, it's not deniable.

Solutions:

  • Plain encryption: (plain dm-crypt, losetup, etc) DON'T use it unless you have a very strong password. It has no protection against brute-force attack, rainbow-table attack and the password can't be changed unless you re-encrypt the whole payload data. Something you can do to harden plain encryption is to use the password to decrypt a given sector, and use this decrypted sector as the key to decrypt the payload data; but the drawback is that you have to remember a randomly-chosen sector number. The recommended Linux tool for plain encryption is cryptsetup --type plain as it is maintained.
  • Truecrypt/Veracrypt: Truecrypt header is deniable, especially when used as full disk encryption. Truecrypt uses a salt and a fixed number of password hash iterations (PBKDF2) to decrypt the header containing the key so it's not prone to rainbow-table attack and considerably slows down brute-force attacks. However, the fixed number of hash iterations makes it less evolutive against brute-forcing than LUKS (as computing power increases, the number of password hash iterations should increase). Compared to LUKS, Truecrypt has no support for multiple keys and no GRUB (Linux bootloader) support.
  • DeLUKS: A Deniable version of LUKS, for Linux. Mostly like Truecrypt, but with a support for GRUB bootloader, cryptsetup, multiple keys and an evolutive number of hash iterations.

Hiding the encrypted payload

Of course, you wouldn't put your data in a file called Hey I'm encrypted.bin. But even with full disk encryption, the simple existence of random-looking data could be used against you. See: In The UK, You Will Go To Jail Not Just For Encryption, But For Astronomical Noise, Too.

It's worth to note that, whatever the solution, there must be at least 1 decoy (fake) O.S. on your computer to not look totally suspicious.

Solutions have various levels of credibility and none is perfect. So, how do you explain this random-looking data?

  • Manually generated random data:
    • Disk wipe: That's the n°1 explanation for a fully-encrypted drive. But is it sufficient?
    • Noise recording: It could be a file containing astronomical noise. You'd better have a capture device.
    • Etc.
  • By-default software behavior:
    • Truecrypt/Veracrypt hidden volume: Truecrypt always wipes a newly created encrypted volume payload with random data. So it leads to a suspicion about the existence of a hidden volume in the Truecrypt container, that can't be proven under good circumstances.
  • Steganography: This is the practice of concealing a file, message, image, or video within another file, message, image, or video. Impractical for system encryption, so it's better used for transmitting messages rather than storing them.
  • Hardware solutions:
    • Hardware-encrypted drives: The presence of random data could be due to the manufacturer initial wipe. But these drives may not be optimized to be used in a deniable encryption way.
    • Low-level data storage: We could imagine to write data to the drive with a low magnetic level, near the noise level, to make the data appear as 0 under normal circumstances. I don't know any proof of concept of this.
  • "Cloud"-stored data: Not really practical if it doesn't fit in your RAM size and needs to be written to your local disk. Moreover, it can be subject to a block cipher mode attack if the adversary has access to the encrypted data.

The not-so-deniable bootloader

System encryption is key to protect your data. Don't forget that your RAM is sometimes written to the on-disk swap and that your system keeps logs and tracks of opened files, etc. So it's advisable to use system encryption, and a bootloader that supports it.

At this time, all major O.S. bootloaders don't support natively plain encryption or deniable encryption headers. So the presence of a bootloader supporting deniable encryption can be used against you.

The known bootloaders with deniable encryption support are:

  • Veracrypt bootloader: Plausible, you think?

HEY, I'm an encrypted system, and trust me, there's no hidden volume!

  • grub-crypto: (a bootloader that supports plain-mode encryption) At least the GUI looks like GRUB but the binary code betrays it.
  • grub-crypto-deluks: (grub-crypto fork with DeLUKS support) Same as grub-crypto.

Solutions:

  • Decoy deniably-encrypted O.S.: You explain the presence of the bootloader because there is another, decoy, encrypted O.S. And you only give the key to open this decoy O.S.
  • Loading the initramfs from a Live O.S.: I don't know if it's even feasible. The idea is to use cryptsetup in plain-mode from a Live CD to decrypt the real O.S. Then you load the initramfs from the Live O.S. (and not from GRUB) to boot the real O.S.
  • Bootloader on a stick: The bootloader with deniable encryption support is put on a USB stick. I don't believe in this but some people believe it is safer. It supposes your USB stick won't be seized along with your computer.

Currently inexistant solutions:

  • Deniable encryption support in mainstream bootloaders: Unless you're a GRUB developer, you can just vote on the 2+ years old grub pull requests to merge grub-crypto.
  • Toolbox bootloader: It would be helpful to have a toolbox bootloader (like GRUBS Reanimated USB Boot Stick) with, among other functionalities, the deniable encryption support. The presence of this special bootloader version would be explained by the other functionalities.

About network activity

Extract from Veracrypt: Security Requirements and Precautions Pertaining to Hidden Volumes:

The computer may be connected to a network (including the internet) only when the decoy operating system is running. When the hidden operating system is running, the computer should not be connected to any network, including the internet (one of the most reliable ways to ensure it is to unplug the network cable, if there is one). Note that if data is downloaded from or uploaded to a remote server, the date and time of the connection, and other data, are typically logged on the server. Various kinds of data are also logged on the operating system (e.g. Windows auto-update data, application logs, error logs, etc.) Therefore, if an adversary had access to the data stored on the server or intercepted your request to the server (and if you revealed the password for the decoy operating system to him), he might find out that the connection was not made from within the decoy operating system, which might indicate the existence of a hidden operating system on your computer.

Pang
  • 185
  • 6
KrisWebDev
  • 265
  • 2
  • 8
  • 2
    "*In The UK, You Will Go To Jail Not Just For Encryption, But For Astronomical Noise, Too.*" I can only hope no one will go to jail because there is a /dev/random on their computer.... – Calmarius May 04 '18 at 15:00
3

Under OP's circumstances, the best approach is storage that can easily be destroyed, perhaps even while the adversary is watching. Micro SD cards are quite small and thin. It would take only a few seconds to destroy one by chewing, and then spit out. OP might well be punished, but there would be no point in torture (for a password, anyway).

mirimir
  • 726
  • 4
  • 11
2

I will present an initial attempt at a solution at Blackhat Asia 2014:

Outline of my talk

We are interested in the ability to lie convincingly about the contents of an encrypted file, a variation of "deniable encryption" from the cryptography literature. A reasonable scenario may involve a businessman traveling through dangerous territory with sensitive documents, who, if kidnapped or under duress, wants to be able to convincingly lie to his kidnappers about the contents of his documents.

We will thus release a tool that allows users to encrypt a text in such a way that it can be decrypted not just to the original text (using the correct key), but also to other possible texts (using decoy keys). For example, with one key, the text might decrypt to "Don't cry for me Argentina", but with the right key, it would decrypt to "Don't try to meet Angelina."

Community
  • 1
Ari Trachtenberg
  • 842
  • 7
  • 14
  • 2
    Ari - I have updated your answer, as link only answers aren't useful here. This is the sort of detail we expect in an answer. Admittedly, this one does seem a lot like self promotion, so what I'd like to see is some of the content from the talk once you have presented it - you can come back and edit it in. – Rory Alsop Feb 17 '14 at 22:24
0

A bit of thermite on the drive rigged in such a way that any unauthorised access sets it off and melts the drive. Good luck recovering anything from that. A device rigged to send a large EMP towards your drives will accomplish the same thing.

Of course this will probably get you in jail for destruction of evidence/obstruction of justice or something related.

You can also keep data wanted by government x in a country hostile to x (so if you have lots of data against the USA keep it in Russia/China since they will most likely give the USA the finger and vice versa, data against Putin is probably quite safe in the USA).

Or there is also steganography which can conceal encrypted data in pictures/movies of your cat. The simplest and easily detectable algorithm would make a bmp with the least important bit containing the encrypted data. Visually such an image will look a tad uglier than the original but the difference is close to non perceptible. Real steganography software uses much more advanced algorithms and is thus also much harder to find.

schroeder
  • 125,553
  • 55
  • 289
  • 326
Mr. C
  • 131
  • 1
  • 1
    Welcome to infosec SE. I have to say, you're not really answering the question. Do you have a good grasp of the concept? You're mentioning physical destruction. The asker didn't. That is in no way deniable. Like you said you'll go to jail. And it's ste-ga-nography, stenography is shorthand writing. – J.A.K. Jan 15 '17 at 23:30
  • Image steganography has been and continue to be much researched together with analysis (ways of detection). My humble personal view is that hiding informations that way is very efficient in terns of stegobit embedding rates but not sufficiently secure with respect to resourceful adversaries. But that trade-off is in conformance to the Principle of No Free Lunch. If however the volume of materials to be hidden is very small, a good linguistic steganography might be applied IMHO. (I recently wrote such a software: s13.zetaboards.com/Crypto/topic/9024439/1/ ) – Mok-Kong Shen Jan 16 '17 at 15:07
  • Unfortunately I do understand the concept. The only truly sure way to make it impossible to prove that some data existed is to physically destroy the drive at the very least. Why do you think various 3 letter agencies don't just wipe the drives and auction them off when they buy new ones but destroy them? – Mr. C Feb 02 '17 at 00:27
0

You can use Sekura.

Unlike Truecrypt you can have as many partitions as you like and noone except you knows how many partitions exists and therefore how many passwords they need to extract from you.

Disclaimer: I am the author of Sekura

Cookie04
  • 291
  • 2
  • 7
0

Use the LUKS Nuke method, it will destroy the LUKS header - which includes the key used for decryption - upon entering a specific password.

Once the adversary enters this Nuke Password, the LUKS header will be destroyed and it will be impossible to decrypt the drive even if the real decryption password is beaten out of you, since the header is not existent anymore.

for more info read this: https://www.kali.org/how-to/nuke-kali-linux-luks/

random
  • 11
  • 1
    What prevents the adversary from cloning the encrypted hard drive first before typing any passwords? (E.g., if a nuke password is given, just copy the clone again); – dr jimbob Nov 14 '14 at 21:59
  • 2
    First law in forensics is to make a read-only clone so multiple tries may be attempted. Upon finding the LUKS header trashed, they'd be smart enough to put 2 and 2 together to look 4 more answers from you. They've seen enough Wile E Coyotes out there who always are trying to out-trick themselves. – Fiasco Labs Nov 15 '14 at 02:30
  • If your adversary is using a vanilla copy of Cryptsetup, entering the "nuke" password will simply give an "incorrect password" error rather than destroying anything. – Mark Nov 15 '14 at 03:26