All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
Date: Tue, 1 Nov 2011 05:36:12 +0100	[thread overview]
Message-ID: <20111101043612.GA26090@tansi.org> (raw)
In-Reply-To: <4EAF1E95.1070203@freesources.org>

On Mon, Oct 31, 2011 at 11:17:57PM +0100, Jonas Meurer wrote:
> Am 31.10.2011 08:18, schrieb Arno Wagner:
> > In addition, any kind of automatic header backup breaks the LUKS
> > security model and needs to come with a very clear warning if
> > automatized (as in an installer). The problem is that old
> > passphrases will be stored and will survive deletion in the active
> > LUKS header. That is not good at all.
> 
> While I agree with you, that cryptsetup already does a lot to prevent
> data (i.e. header) loss, I don't see a reason why (optional) header
> backup at some random place on the device would be such a big security
> problem.

And here is the problem. If it is optional, it will not help
in a careless installer. A fareful installer can offer to do 
a backup already, using "cryptsetup luksHeaderBackup". It can
also check whether something is a LUKS device via 
"cryptsetup isLuks". 

I really don't think this is a cryptsetup issue, excapt maybe
that the documentation (mostly the FAQ and man-page) could 
warn more. But I think looking into the FAQ is non-optional
and I have no idea how to make the warnings even clearer.
Especially somebody doing an installer that can do LUKS
should read the FAQ!

> For sure the exact place of backup header would be stored in the first
> header, and any cryptsetup action which changes/whipes (parts of) the
> header, would need to do this for the backup header as well.
> 
> Overwriting the first kbytes of device would no longer be sufficient.
> Instead overwriting the header would require to actually overwrite
> both first and backup header. But that's the only drawback I can see
> so far.
> 
> I guess that I missed something important.

In principle that could work. However there is good reason to place
the header at the start, so the backup would need to go right after 
it. This would decrease LUKS anti-forensic strength. In order to
keep passphrases secure, both headers would always need to be 
synchronized. This would make things perceptibly slower. Usability
(and speed) is very important in cryptographic tools, after all
a tool that is not used because people do not like it can never
offer any security improvement.

Then there are the ways people damage their header. One is putting 
a FAT filesystem on top. Now, say your FAT filesystem is 4GB in
FAT32. Then clsuter size would be 4kB, i.e. around 1'000'000 clusters.
This givesd a size of the actual FAT table of 4MB which is stored twice,
i.e. 8MB. The LUKS header is 1MB (or 2MB with xts). So the
FAT table gets wiped together with its backup. 

Another option would be to place the header at the end of the 
device. But this would be problematic for several reasons. One
is that it is certainly a bad idea to replicate the incredible
mess the md people have made with their headers. An other is that 
fast header wiping becomes hard. A third is that device resizing 
becomes hard. And a fourth is that suddenly LUKS would need to 
know about device sizes.

The other thing is that all this would not help for the installer 
problem, as an installer would definitely need to wipe the backup 
as well on creating a new LUKS container. For an installer, the 
only real solution is to clearly warn the user and possibly do that
header backup inless the user explicitely says no. And, as said 
above, it is easy to detect whether there is already a LUKS 
container on a device.

At this time the FAQ even has a warning at the beginning that some
installers are not clear enough on what they are doing. I guess
somebody wanting to be careful when creating an installer has
all the help needed (and can definitely ask here as well!). Somebody
that does not care or does not see the problem will manage to
botch it anyways and there is not really anything cryptsetup can do.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

  parent reply	other threads:[~2011-11-01  4:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-28 15:23 [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation Aleksander Swirski
2011-10-28 15:37 ` Rick Moritz
2011-10-28 15:48   ` Aleksander Swirski
2011-10-28 15:53 ` Marc Ballarin
2011-10-28 16:03   ` Arno Wagner
2011-10-28 16:05     ` Aleksander Swirski
2011-10-28 16:24       ` Arno Wagner
2011-10-28 16:38         ` Aleksander Swirski
2011-10-28 17:20           ` Heinz Diehl
2011-10-28 18:14             ` Aleksander Swirski
2011-10-29  7:43               ` Arno Wagner
2011-10-30 16:08                 ` Aleksander Swirski
2011-10-30 17:32                   ` Arno Wagner
2011-10-30 18:56                     ` Aleksander Swirski
2011-10-30 22:25                       ` Jonas Meurer
2011-10-31  0:30                         ` Aleksander Swirski
2011-10-31  3:30                           ` ingo.schmitt
2011-10-31  7:18                             ` Arno Wagner
2011-10-31 22:17                               ` Jonas Meurer
2011-10-31 22:34                                 ` Claudio Moretti
2011-10-31 22:48                                   ` Jonas Meurer
2011-10-31 23:46                                     ` Claudio Moretti
2011-11-01  5:02                                       ` Arno Wagner
2011-11-01  4:45                                     ` Arno Wagner
2011-11-01  4:36                                 ` Arno Wagner [this message]
2011-10-31  8:47                           ` Quentin Lefebvre
2011-10-31 22:56                             ` Jonas Meurer
2011-10-31 22:40                           ` Jonas Meurer
2011-10-29  8:15               ` Yves-Alexis Perez
2011-10-30 19:03                 ` Aleksander Swirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111101043612.GA26090@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.