DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt <dm-crypt@saout.de>
Subject: Re: [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data
Date: Sat, 29 Dec 2012 08:06:19 +0100	[thread overview]
Message-ID: <20121229070619.GA21827@tansi.org> (raw)
In-Reply-To: <50DDF171.1080807@gmail.com>

On Fri, Dec 28, 2012 at 08:22:25PM +0100, Milan Broz wrote:
> On 12/28/2012 04:04 PM, Arno Wagner wrote:
> > I am thinking about a "basic LUKS setup" section for the FAQ 
> > that is more in the nature of a mini-howto. Things like blanking
> > a previously used partition before a LUKS install seem to be 
> > not obvious to many people. Step-by-step instructions may help.
> 
> Wiping (whole) device (with some crypt random way) is still on TODO list.

You can just wipe with zeros on the mapped device. They will be
encrypted after all. That could leak a tiny bit of information 
to an attacker that has access to the encrypted container
multiple times, but such an attacker can likely do far worse 
things anyways. If that is a concern, just use a different
master key for the zero-wipe, e.g. a one-time key derived in the 
same way as the LUKS master key. 

> But I believe that common signatures are wiped during LUKS format already
> (we had several bugs related to this already) so it should never
> happen that device contains ext4/swap/whatever signature parallel with
> LUKS. (If so, please let me know, it is a bug.)

Ext2 superblock signatures are all not wiped. Test I ran:

-----
# head -c 100M /dev/zero > test
# losetup /dev/loop0 test
# mke2fs -q /dev/loop0
# hd /dev/loop0 | grep "53 ef"
00000430  8b 7d de 50 00 00 18 00  53 ef 01 00 01 00 00 00 |.}.P....S.......|
00800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430  8b 7d de 50 00 00 18 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
# cryptsetup luksFormat /dev/loop0
[...]
# hd /dev/loop0 | grep "53 ef"
00009970  53 ef 3d 36 73 85 da 1e  20 cb bc 48 e9 e3 d9 b6  |S.=6s...
# ..H....|
00012c80  a2 f1 f6 53 ef b9 0c 30  75 60 6c c5 14 0b 6a 6b |...S...0u`l...jk|
00800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
01800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
02800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
03800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|
04800430  bf 7d de 50 00 00 15 00  53 ef 00 00 01 00 00 00 |.}.P....S.......|

-----
The 5 superblock backups are still there. That should at least make 
e2fsck require some kind of override option. However, the primary 
superblock is just between the LUKS header and first keyslot. If I 
remember correctly, older versions of cryptsetup did not wipe that 
area (1.5.1 does). Maybe that is what happened here. 

As for the superblock backups, I would say wiping them should be 
part of a full device wipe to be done on a previosuly used partition. 
I just added a "LUKS Container Setup mini-HOWTO" in the FAQ as item
2.1 that explains this. (That this is a TODO for cryptsetup also
noted.)

> fsck can possibly use blkid and warn user
> "Warning: device seems to contain xyz signature, do you really want...."
> but this is feature for fsck (util-linux), not for cryptsetup.
> (Anyway, I can ask util-linux maintainer later next year:)

That would be nice. Things are pretty safe right now, but
further improvement is always welcome.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell

  reply	other threads:[~2012-12-29  7:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-27  6:12 [dm-crypt] Avoiding fsck.ext4 destruction of crypto_luks data Emily Williams
2012-12-27  9:35 ` ken
2012-12-27  9:52 ` Arno Wagner
2012-12-28 14:46   ` Sven Eschenberg
2012-12-28 15:04     ` Arno Wagner
2012-12-28 19:22       ` Milan Broz
2012-12-29  7:06         ` Arno Wagner [this message]
2012-12-29  9:05           ` Milan Broz
2012-12-29 11:52             ` Arno Wagner
2012-12-30  8:42         ` Sven Eschenberg
2012-12-30  9:39           ` Milan Broz
2012-12-30 10:53             ` Arno Wagner
2012-12-30 12:08               ` Sven Eschenberg
2012-12-30 12:25                 ` Milan Broz
2012-12-30 13:19                   ` Arno Wagner
2012-12-30 16:59       ` Emily Williams
2012-12-30 18:49         ` Matthias Schniedermeyer
2012-12-30 19:45         ` Arno Wagner
2012-12-31  6:37           ` Sven Eschenberg
2012-12-31 12:40         ` Richard
2012-12-27 20:29 ` Richard

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=20121229070619.GA21827@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox