[dm-crypt] LUKS and LVM

[dm-crypt] LUKS and LVM

[Eric Bauman]

Hi,

When using LVM with LUKS, is it more secure to:
1 - have a single container containing LVM, or
2 - LVM containing multiple containers?

I typically randomise my block device before creating a LUKS container 
on it. Option 2 would seem to reduce the effectiveness of this because 
LVM will give clues to where real data might be.

Thoughts?

Thanks,
Eric

Re: [dm-crypt] LUKS and LVM

[Arno Wagner]

On Sat, Feb 19, 2011 at 03:39:07AM +1100, Eric Bauman wrote:
> Hi,
>
> When using LVM with LUKS, is it more secure to:
> 1 - have a single container containing LVM, or
> 2 - LVM containing multiple containers?

Technologically, security is the same. Reliability is
lower on (2) as you have more headers you can damage and
lose. 

As with RAID, encryption should sit on top, not somewhere 
in between.

With regard to interface and usability (allways _very_ important
in security!), (1) is a lot better, since (2) requires you
to unlock multiple containers and keep multiple passowrds or
enter the same password multiple times.

That makes option (1) the thing to do and option (2) 
a curiosity that violates a number of principles, among them
simplicity, crypto as last/highest layer below the filesystem,
leas amount of credentials, least exposure of the credentials. 

> I typically randomise my block device before creating a LUKS container  
> on it.  Option 2 would seem to reduce the effectiveness of this because  
> LVM will give clues to where real data might be.

I don't follow. That encrypted data is present is obvious from
the LUKS header. What is in the container(s) is as opaque in
(1) as it is in (2), given that cryptographically strong
randomness is used for the overwrite (I use plain dm-crypt
with a random password and overwrite with conventional,
mt19997-generated randomness).

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 

Re: [dm-crypt] LUKS and LVM

[Eric Bauman]

Thanks for the reply!

With regards to the multiple containers, the configuration I'd run 
across was one container per partition, with the key for each stored in 
/. When the system was booted, the passphrase was entered, and each 
partition's container opened and mounted automatically.

On 19/02/2011, Arno Wagner wrote:
>> I typically randomise my block device before creating a LUKS container
>> on it.  Option 2 would seem to reduce the effectiveness of this because
>> LVM will give clues to where real data might be.
>
> I don't follow. That encrypted data is present is obvious from
> the LUKS header. What is in the container(s) is as opaque in
> (1) as it is in (2), given that cryptographically strong
> randomness is used for the overwrite (I use plain dm-crypt
> with a random password and overwrite with conventional,
> mt19997-generated randomness).

I meant not that the data protection of one was better than the other, 
but rather in (2) LVM will store in plain-text both the start and end 
offset of the partition. So perhaps an attacker would have a better idea 
of where data is. Comparing knowing the partition starts at X and ends 
at Y, there is probably some encrypted data in there somewhere, versus a 
giant container with no indication of structure (could be encrypted data 
or could be random garbage).

Thanks,
Eric

Re: [dm-crypt] LUKS and LVM

[Milan Broz]

On 02/18/2011 06:53 PM, Eric Bauman wrote:
>>> I typically randomise my block device before creating a LUKS container
>>> on it.  Option 2 would seem to reduce the effectiveness of this because
>>> LVM will give clues to where real data might be.

The information where the partition (LVs) start is something
that should not cause security problems.

For LUKS over LVM you will see LVM metadata in plain form,
for LVM over LUKS you will see only LVM PV data offset (LVM metadata
are encrypted).

Both methods are used, both works. Depends on you preference.

I had some pictures how the disk layout looks like for both cases
http://mbroz.fedorapeople.org/talks/LinuxAlt2008-eng/
(the slides are not perfect though:-)

Milan

Re: [dm-crypt] LUKS and LVM

[Arno Wagner]

On Sat, Feb 19, 2011 at 04:53:20AM +1100, Eric Bauman wrote:
> Thanks for the reply!
>
> With regards to the multiple containers, the configuration I'd run  
> across was one container per partition, with the key for each stored in  
> /. When the system was booted, the passphrase was entered, and each  
> partition's container opened and mounted automatically.

If they are not combined into something larger, that is fine.
If they are (RAID or other LVM action), then I would allways
forst construct the whole device and then encrypt, i.e.
encryption on top of block layer and below filesystem.

> On 19/02/2011, Arno Wagner wrote:
>>> I typically randomise my block device before creating a LUKS container
>>> on it.  Option 2 would seem to reduce the effectiveness of this because
>>> LVM will give clues to where real data might be.
>>
>> I don't follow. That encrypted data is present is obvious from
>> the LUKS header. What is in the container(s) is as opaque in
>> (1) as it is in (2), given that cryptographically strong
>> randomness is used for the overwrite (I use plain dm-crypt
>> with a random password and overwrite with conventional,
>> mt19997-generated randomness).
>
> I meant not that the data protection of one was better than the other,  
> but rather in (2) LVM will store in plain-text both the start and end  
> offset of the partition. So perhaps an attacker would have a better idea  
> of where data is. Comparing knowing the partition starts at X and ends  
> at Y, there is probably some encrypted data in there somewhere, versus a  
> giant container with no indication of structure (could be encrypted data  
> or could be random garbage).

LUKS has a header per container. Also, knowing were the encrypted 
data is does not help the attacker, unless he/she can repeatedly
access the computer. In that case, all is luikely lost anyways.

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 

Re: [dm-crypt] LUKS and LVM

[Eric Bauman]

On 19/02/2011, Arno Wagner wrote:
>Also, knowing were the encrypted
> data is does not help the attacker, unless he/she can repeatedly
> access the computer. In that case, all is luikely lost anyways.
Forgive my ignorance, some sources say suggest randomising the disk 
before creating a container so that it's not possible to determine what 
is data and what is garbage. So I assumed the visible LVM header would 
reduce some of this benefit. Is there merit to this disk randomisation 
or does it just sound good but do nothing, spread by misinformed people 
such as myself? :)

Thanks,
Eric

Re: [dm-crypt] LUKS and LVM

[Arno Wagner]

On Sun, Feb 20, 2011 at 01:01:18AM +1100, Eric Bauman wrote:
> On 19/02/2011, Arno Wagner wrote:
>> Also, knowing were the encrypted
>> data is does not help the attacker, unless he/she can repeatedly
>> access the computer. In that case, all is luikely lost anyways.

> Forgive my ignorance, some sources say suggest randomising the disk  
> before creating a container so that it's not possible to determine what  
> is data and what is garbage. So I assumed the visible LVM header would  
> reduce some of this benefit. Is there merit to this disk randomisation  
> or does it just sound good but do nothing, spread by misinformed people  
> such as myself? :)

There is one merits to randomisation with crytographically
strong randomness: An attacker cannto tell how much data is
in a crypto container and where exactly it is. It is conceivable
that without ramdomisation an attacker could guess the filesystem,
the size of some files and the overall data size. That is typically
hard to do, limited to 512 byte (sector size) or 4096 byte 
(filesystem block size) precision and the information gained 
in the worst case is not a lot. Side note: The LVM header only 
describes the size of the container, not where exactly the data 
is. Container-size is typically not information that helps the 
attacker at all.

There is a second benefit to overwriting: You make sure no old data
is retained.

So, while not absolutely critical, it is good practice to
overwrite with crypto-randomness. Except in special cases,
you do not need to obfuscate the size of partitions or
containers, i.e. the attacker can have access to LVM/LUKS/RAID
headers and superblocks without negative effect on security.

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 

Re: [dm-crypt] LUKS and LVM

[Nicolas Bock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 02/18/11 13:07, Arno Wagner wrote:
> (I use plain dm-crypt
>>> with a random password and overwrite with conventional,
>>> mt19997-generated randomness).


Why use random data to overwrite? Shouldn't /dev/zero be enough since
the crypto should produce good randomness on disk?

nick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1f88wACgkQf15tZKyRylI/HACdHUaYyhGQf9bmBNaoLUSjwTuJ
okkAoI0DPaJBq76g6uz/UZpWCw5p/gBN
=8V+K
-----END PGP SIGNATURE-----

Re: [dm-crypt] LUKS and LVM

[Milan Broz]

On 02/19/2011 05:46 PM, Nicolas Bock wrote:
> Why use random data to overwrite? Shouldn't /dev/zero be enough since
> the crypto should produce good randomness on disk?

Then you can distinguish between used blocks ("random noise") and
unused blocks (remains zeroed).

So filling with zero guarantees that old data are wiped, but also
leaks info which blocks were overwritten later.


Question: Is it good idea to add "wipe" option to cryptsetup luksFormat?

So it optionally can wipe all the space with random data?
(probably using some fast RNG provided by crypto backend or by
encryption zero data with the same algorithm as in luksFormat
but using one-time random key)

If so, I'll add this to my todo list.

Milan

Re: [dm-crypt] LUKS and LVM

[Jonas Meurer]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Hey Milan,

On 19/02/2011 Milan Broz wrote:
> On 02/19/2011 05:46 PM, Nicolas Bock wrote:
> > Why use random data to overwrite? Shouldn't /dev/zero be enough since
> > the crypto should produce good randomness on disk?
> 
> Then you can distinguish between used blocks ("random noise") and
> unused blocks (remains zeroed).
> 
> So filling with zero guarantees that old data are wiped, but also
> leaks info which blocks were overwritten later.

If I got Arno right, he, first setups a plain dm-crypt device for the
to-be-encrypted partition, and then fills the encrypted device with
random data. In this case it should be enough to fill the encrypted
device with zeros, shouldn't it?

> Question: Is it good idea to add "wipe" option to cryptsetup luksFormat?
> 
> So it optionally can wipe all the space with random data?
> (probably using some fast RNG provided by crypto backend or by
> encryption zero data with the same algorithm as in luksFormat
> but using one-time random key)
> 
> If so, I'll add this to my todo list.

I think that would be a great new feature, it eases secure setups for
users.

greetings,
 jonas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [dm-crypt] LUKS and LVM

[Arno Wagner]

On Sat, Feb 19, 2011 at 09:46:04AM -0700, Nicolas Bock wrote:
> 
> 
> On 02/18/11 13:07, Arno Wagner wrote:
> > (I use plain dm-crypt
> >>> with a random password and overwrite with conventional,
> >>> mt19997-generated randomness).
> 
> 
> Why use random data to overwrite? Shouldn't /dev/zero be enough since
> the crypto should produce good randomness on disk?

It is only marginally slower this way and there may be issues
with initialisation vectors in disk encryption. There are
no that I know of with the current cryptsetup defaults. This
is just a very cheap additional layer of protection.

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 

Re: [dm-crypt] LUKS and LVM

[Arno Wagner]

On Sat, Feb 19, 2011 at 06:10:08PM +0100, Milan Broz wrote:
[...]
> Question: Is it good idea to add "wipe" option to cryptsetup luksFormat?
> 
> So it optionally can wipe all the space with random data?
> (probably using some fast RNG provided by crypto backend or by
> encryption zero data with the same algorithm as in luksFormat
> but using one-time random key)
> 
> If so, I'll add this to my todo list.

I think it is a good idea. Make sure it can be run quiet
and with progress output.

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 

Re: [dm-crypt] LUKS and LVM

[Nicolas Bock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 02/19/11 11:17, Jonas Meurer wrote:
> Hey Milan,
> 
> On 19/02/2011 Milan Broz wrote:
>> On 02/19/2011 05:46 PM, Nicolas Bock wrote:
>>> Why use random data to overwrite? Shouldn't /dev/zero be enough since
>>> the crypto should produce good randomness on disk?
>>
>> Then you can distinguish between used blocks ("random noise") and
>> unused blocks (remains zeroed).
>>
>> So filling with zero guarantees that old data are wiped, but also
>> leaks info which blocks were overwritten later.
> 
> If I got Arno right, he, first setups a plain dm-crypt device for the
> to-be-encrypted partition, and then fills the encrypted device with
> random data. In this case it should be enough to fill the encrypted
> device with zeros, shouldn't it?

That's how I understood Arno's email too. The zeros will be written as
"random noise" to disk since they go through the cipher first. I could
see though that the extra paranoid would use a random source :)

nick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1gFdAACgkQf15tZKyRylLAPwCfW0bYHV6GpOnkx4LmYm1Y4iw2
LokAn0UbYJi/uox26XTD8+sXaq6C8hG7
=yEjW
-----END PGP SIGNATURE-----

Re: [dm-crypt] LUKS and LVM

[Nicolas Bock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 02/19/11 12:08, Arno Wagner wrote:
>> Why use random data to overwrite? Shouldn't /dev/zero be enough since
>> the crypto should produce good randomness on disk?
> 
> It is only marginally slower this way and there may be issues
> with initialisation vectors in disk encryption. There are
> no that I know of with the current cryptsetup defaults. This
> is just a very cheap additional layer of protection.

Ah, thanks...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1gFgQACgkQf15tZKyRylIGeQCdEzUOWrmcHbkHc6TmbFsrhTFI
5iAAn1kjrp+1DSHVH39h9naETPNi19Xq
=Ljq9
-----END PGP SIGNATURE-----