Plausible deniability support for LUKS

[GoogleCodeExporter]

Is it possible to start thinking about plausible deniability support for
LUKS? SOmething similar TrueCrypt already has?

Original issue reported on code.google.com by matej.ko...@gmail.com on 29 Jan 2009 at 11:56

[GoogleCodeExporter]

I vote for this as well, I personally dislike TrueCrypt as it is not as 
integrated with linux as LUKS is. 

Currently I use workarounds to get plausible deniability with linux and 
TrueCrypt, but it is nowhere near as easy 
to setup as TrueCrypt and windows is. 

Original comment by BDKoe...@gmail.com on 27 Feb 2009 at 7:44

[GoogleCodeExporter]

I would like this as well. At least a mode without a signature that can tell if 
it's
a LUKS volume or not. It's fine if it will require manual cipher selection with 
-c.

Original comment by per.wigren on 11 Mar 2009 at 3:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'd like this as well... but wouldn't it be counter productive to officially 
support
plausible deniability?

My vote is for plausibly deniable support for plausible deniability... 
seriously.

Original comment by jbland...@gmail.com on 29 May 2009 at 3:31

[GoogleCodeExporter]

I'd like plausible deniability in LUKS as well.

Original comment by Teofilis...@gmail.com on 12 Aug 2009 at 12:45

[GoogleCodeExporter]

A TrueCrypt user can change the default boot authentication passcode prompt to a
custom string like "Operating System Not Found" or "". She can make the prompt 
give
no feedback when an incorrect passcode is entered. With TC configured that way, 
an
adversary cannot easily tell an operating system even exists.

But TC's root encryption driver lives between BIOS and Windows. So there is no 
OS
processing until the correct passcode is applied. That is not the case with 
LUKS. It
betrays the OS even before authentication.

For plausible deniability, it would be nice if future LUKS operated in the same 
layer
as TC. Failing that, could cryptsetup give us an interface to obfuscate the 
passcode
prompt? Could it let us silence kernel messages preceding the passcode prompt? 
(Or is
it the kernel's job to do that?) These features would still give us a little 
extra
deniability, particularly against unsophisticated adversaries.

Original comment by idontmin...@gmail.com on 10 Jan 2010 at 4:53

[GoogleCodeExporter]

LUKS header, by design, is visible header. It cannot be used for "plausible
deniability" currently. Linux device mapper can be used to remap part of 
encrypted
device as "hidden" device with similar effect in TC hidden device.

If the LUKS2 will support similar not detectable header as TC directly, that's 
the
question...

--
Cryptsetup uses Linux device-mapper for encryption, so you cannot use this 
without
initialising Linux kernel first or emulate it somehow (like in Grub2 module).
So completely hide OS is not job for cryptsetup/dm-crypt - an extra boot loader 
have
to be written.

"obfuscating passcode prompt" is not plausible deniability. Anyway, all the 
password
query is processed in userspace (cryptsetup) and do not produce kernel message 
(only
if dm-crypt fails). You can easily use it in quiet mode when it produce no 
output (or
write really simple wrapper using libcryptsetup). Most of distros uses own 
password
entry dialog and pass the read password into cryptsetup directly.

Original comment by gmazyl...@gmail.com on 10 Jan 2010 at 9:17

[GoogleCodeExporter]

Issue 51 has been merged into this issue.

Original comment by gmazyl...@gmail.com on 27 Feb 2010 at 10:56

[GoogleCodeExporter]

Plausible deniability doesn't have to mean *no* LUKS header, or erasing system 
logs or udev. The idea is, nobody's denying that an encrypted volume exists, 
but a different filesystem is shown to the user depending on what password they 
gave. You can give a password, reveal something innocuous, and nobody will ever 
know that another password would have revealed a DIFFERENT filesystem, or that 
another one even exists. I don't believe this has to mean fundamentally 
changing the headers or how it exists on the disk. The code will have to be 
aware of the possibility, obviously, but that's why it's *plausible* 
deniability, not totally charismatic deniability.

Original comment by comb...@gmail.com on 2 Dec 2010 at 5:52

[GoogleCodeExporter]

@combyrm: You missed my point or I said it wrong:)

LUKS has information which slot is used and has master key fingerprint. So you 
know when passphrase is correct and how many passphrases are active for the 
same (one) volume key. Its design cannot easily add another master key to 
hidden fs.

(Of course there can be visible header to "visible" fs if you want that design.)

But yes, you can add some mechanism above it. Either using hidden header to 
verify passphrase or you can check for fs signature on plaintext device instead 
to verify.

In fact, you can create LUKS device over full disk. Then you can create plain 
device with some offset on the same device (first part is visible fs, using 
plain device with offset you get "hidden" fs) - and this is the exactly design 
of "hidden" disk known from TC. And you can do it today already - just it is 
not automated.

But unlocking "hidden" disk on systems today leaves many traces (various scan 
run - udev, HAL, udisks - automatically, every program can log something).
If you run forensic analysis of such system and found log message that there 
was device mapped to some part of disk - the whole idea of plausible 
deniability disappears...

Original comment by gmazyl...@gmail.com on 2 Dec 2010 at 10:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I totally agree with [http://code.google.com/p/cryptsetup/issues/detail?id=7#c6 
idontmindspamatthisaddress].

If most of people don't need this feature, they can say it straight to whoever 
wants to enter their system such as: "I'm sorry sir, I could not give you the 
password, the machine is my personal property".

But please have a look, there is a little of people, as like as me, wishing 
that this feature can be considered to be added in next version. Sometime it is 
not simple to say straight. If you don't mind, this is also the reason that why 
TrueCrypt provides the feature.

I would like to say thanks to development team a lot if you go to do this, as 
soon as possible, please.

Best regards,

Original comment by greensea...@gmail.com on 4 Mar 2011 at 6:00

[GoogleCodeExporter]

I vote for this. Please consider to add this feature.

Thank you...

Original comment by haibi...@gmail.com on 8 Apr 2012 at 4:12

[GoogleCodeExporter]

A TrueCrypt-like solution can be done as a wrapper-script around LUKS. Feel 
free to do one and contribute it. However, LUKS is not really a good basis 
for anything like this with a bit of sophistication. Even TrueCrypt has to 
stretch itself and there is a real risk of data-loss with hidden containers. 
The TrueCrypt solution is also not really sophisticated. And it has the problem
that the attacker can just assume there is a hidden volume (as TC offers the
feature) and there is no way to disprove that. 

On the security side, hidden volumes do not help. The short story is 
http://xkcd.com/538/. The longer story is that if you use a hidden volume,
you either have to make the filesystem in the container smaller (to protect 
the hidden volume from being overwritten), which is blatantly obvious, or
you have to refrain from using the actual outer container, which again is
pretty obvious. 

In both cases it is probably better to place a plain dm-crypt
volume at an offset on the disk after blanking the whole disk with strong
randomness. Then remember the offset and use it as parameter. You should
be able to get away with hiding a few MBs that way, e.g. by using 
cylinder-aligned partitions and puttong the hidden volume between them
or ath the end of the disk. Even then, the crypto-blanking can be enough
of a hint to make the approach fail in practice.

For these reasons, I am strongly opposed to put hidden volumes into
LUKS. Not only do they give a false sense of security, they also 
make LUKS more complex and may break things as a consequence.

Sorry about that. I know this seems to be a good idea on first and second
glance, but it really is not. For example, if law enforcement can force
you to hand over crypto-keys, they are already ignoring the fact that
you _can_ forget them. When the attacker has the power to ignore 
facts, no amount of logical reasoning is going to help you.  

I also have changed this to an enhancement request. It is not a defect.

Original comment by wagner.a...@gmail.com on 27 Apr 2012 at 12:59

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Please read http://www.truecrypt.org/docs/?s=hidden-operating-system to see an 
example of an existing implementation of hidden volumes and operating systems.

"...the attacker can just assume there is a hidden volume (as TC offers the
feature) and there is no way to disprove that."
- As comb...@gmail.com already stated, it makes it *plausibly* deniable. You 
can't waterboard everyone who has a truecrypt volume just because they _might_ 
have a hidden volume.

"you have to refrain from using the actual outer container, which again is
pretty obvious."
- You are preceded by TC who supposedly already solved these issues.  At least 
analyze TC's method before assuming there is no correct method.

"...they also make LUKS more complex and may break things as a consequence."
- Of course, but plausible deniability is an important part of security. It is 
implemented in many other security applications, and it is interesting that 
LUKS has not.

"if law enforcement can force you to hand over crypto-keys, they are already 
ignoring the fact that you _can_ forget them. When the attacker has the power 
to ignore facts, no amount of logical reasoning is going to help you."
- Again, that's why it's called *plausible* deniability.  If they know you use 
an encrypted volume on a regular basis, they probably won't believe you forgot 
the password.  However, you can't persecute everyone who uses TC, cooperatively 
hands over their main password, and denies having a hidden volume.

You may not currently have any need for this in your country or situation, but 
you have to consider others.  Such as, people in the many countries without 
clear constitutional rights, fair trials, or where you can be imprisoned for 
life for your religious views.

Original comment by human012...@gmail.com on 2 Sep 2012 at 1:43

[GoogleCodeExporter]

DM-Steg is a kernel module that adds steganographic encryption to the device 
mapper.

http://dmsteg.sourceforge.net/

https://lwn.net/Articles/469847/

Original comment by ondra.pe...@gmail.com on 2 Sep 2012 at 3:15

[GoogleCodeExporter]

does the method truly stop the luks header being shown leaving random data

http://www.wilderssecurity.com/showpost.php?p=2086767&postcount=15

Original comment by Nibbler...@gmail.com on 12 Oct 2012 at 3:41

[GoogleCodeExporter]

Re comment 20: For LUKS, backup header, replace with random and restore of 
course work. But I am really not sure why you want to restore it, you can use 
separated header on another device or file (so the main device is just random 
data, no header).

See --header option and 1.4.x release notes
http://code.google.com/p/cryptsetup/wiki/Cryptsetup140

(btw the link above uses fixed header size. that's wrong. always check payload 
size of size of header backup - it depends on key size, it can differ from that 
example)

Original comment by gmazyl...@gmail.com on 12 Oct 2012 at 5:33

[GoogleCodeExporter]

I would like to see a Fricosu key added to LUKS during configuration.  A 
Fricosu key is the name I give to a second decryption key.  This key would be 
used in Colorado (or elsewhere) when you are under duress.  When you enter the 
Fricosu key, the system silently and permanently loses the decryption key.  
This way it can never be decrypted.

The Ironkey FIPS 140-2 USB key has something like this, but possibly a 
different implementation.  If you enter the wrong code ten times, it either 
forgets the key, or permanently disables the key.

There are a couple of ways around this.  If the prosecutor has copied the disk, 
entering a Fricosu key would not affect the copies.  It can also be used for 
bad purposes, such as crossing the border with kiddy porn, but any good idea 
can be used for bad.

Original comment by david.pa...@davidpaige.com on 8 Mar 2013 at 3:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've been thinking about a funny idea for plausible deniability.

It needs a modified loopback device that takes an encryption key and a ratio. 
It uses the key to generate a semi-random list of blocks to be used from the 
file to be mapped: your device is not the whole file, only those blocks.

You could use it as such:

* start downloading something huge with bittorrent -- e.g. 
http://isohunt.com/torrent_details/336289965 has some decent 20+ GB mkv's in it
* when you have enough to look serious, stop the download and use the modified 
loopback driver with your key and, say, 45% for the ratio
* initialize the encrypted device and zero it -- you just ruined some of what 
you downloaded (but who cares?)
* run a "force recheck" on the torrent to make sure the overwritten parts are 
reflected by the client -- now you have an at most 55% finished download, that 
you'll never complete: you're perfect alibi

Please note that nothing stops you from layering the loopback devices, thus 
getting multiple layers of hidden devices.

All in all, it's a pretty sweet setup, and all it needs is that modified 
loopback device, which doesn't yet exist. Anybody? =] (cloop might be a good 
starting point for a quick hack.)

Original comment by dakhot...@gmail.com on 28 Mar 2013 at 10:18

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I was looking at scubed recently (http://cube.dyndns.org/~rsnel/scubed/) and 
was wondering if something similar might be an option.

Firstly, I figure there's basically no way you're going to convince someone 
that there isn't at least one encrypted partition. Thus, hiding the LUKS header 
entirely is less important than making a LUKS header tell the attacker less.

To do this, I'm thinking a few changes would do the job:
1.) Allow keyslots to have different master keys
2.) Eliminate anything that indicates whether a keyslot is unallocated
3.) Use scubed-style encrypted blocklists describing allocated regions 
(possibly via bitmap-of-extents or similar) associated with one-or-more 
keyslots, initialized to random data.

While this doesn't hide the *presence* of encrypted data, it does hide the 
*extent* of it - they can't tell how many keyslots you have, and if you do a 
random-data overwrite of the disk before you start using it then they can't 
tell what data blocks are unallocated either.

By using scubed-style partitions chunked out across the disk, we sacrifice 
performance (a very likely worsening of seek behavior) in exchange for hiding 
how many such partitions there are. That allows up to $KEYSLOTS subvolumes, 
less if you decide to have more than one keyslot with the same master key.

If you need an excuse, just say that it's unpartitioned space in case you need, 
say, a larger swap device/a different distro/etc in the future. It's at least 
vaguely plausible, although as above it's unlikely to be believed.

If you want to extend a subvolume, you need the keys for all of them or you 
might wipe something. This is pretty much inherent for any kind of hidden 
volume.

This would be utterly useless with DISCARD, would likely degrade your SSD badly 
without DISCARD, and would likely have exceedingly poor performance on spinning 
rust, but if you really need this kind of thing then those are likely not high 
on your list of priorities.

If they are high on your list of priorities, I'd recommend thinking very hard 
on whether you do, in fact, need this.

The main downside (code-wise) that I can see is the need for dm-linear.

Original comment by Eternal...@gmail.com on 23 Apr 2013 at 8:52

[GoogleCodeExporter]

This would be nice, but on the other hand where it is usefull they probably 
know so little about computers you can fool the by just booting to a fake OS by 
default and press a button for multi-boot options normally.
I am thinking like US border zone checkpoint where it seems you have to do 
without your computer for a few weeks if you refuse to unlock it. Cause they 
can do whatever they want especially to non-americans...

Original comment by arnolds...@gmail.com on 5 Jan 2014 at 10:02

[GoogleCodeExporter]

adding my 2 cents.

A few have mentioned a way of having a rudimentary hidden volume with 
cryptsetup by creating a dm-crypt volume at a certain offset.

Below is how one could achieve it.

1. Blanket the whole drive with strong crypto.
2. Create a file system or LUKS volume at the beginning of the device.The file 
system to use is FAT or any other "simple" file system.
3. Open dm-crypt mapper at an offset closer towards the end of the device.
4  Put a second file system on the mapper and you will have your "hidden" 
volume at the end of the device.

I believe this is how truecrypt does it but the only difference is that 
truecrypt adds the ability to protect the hidden volume but cryptsetup does not.

The usefulness of such a volume is debatable,but if you have one,you can now 
open it using a GUI tool called "zuluMount" shipped as part of zuluCrypt[1] 
tools 

[1] http://code.google.com/p/zulucrypt/

When you are about to mount/open a volume,just click "option" followed by "set 
volume offset" and then enter the volume offset and password.

Since there is no protection of volumes at any none zero offset,it is the 
responsibility of the user of such volumes to make sure they dont add too much 
data in previous volumes to overwrite subsequent ones and for this reason,this 
feature should be used by experts only who are ok with data loss due to volumes 
stepping over each other.

Original comment by mhogomch...@gmail.com on 24 Feb 2014 at 8:57