LUKS and LVM
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
Quoted 5 lines · 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?
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.
Quoted 3 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
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.
Quoted 10 lines · Arno Wagner
Quoted 3 lines
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
Quoted 3 lines · Eric Bauman
Quoted 3 lines
Quoted 3 lines
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
Quoted 6 lines · 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.
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.
Quoted 12 lines · Arno Wagner
Quoted 10 lines
Quoted 3 lines
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).
Quoted 7 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 3 lines · Arno Wagner
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
Quoted 11 lines · Eric Bauman
Quoted 3 lines · Arno Wagner
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Arno Wagner
(I use plain dm-crypt
Quoted 2 lines
Quoted 2 lines
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-----
Quoted 2 lines · Nicolas Bock
Why use random data to overwrite? Shouldn't
/dev/zerobe 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
Hey Milan,
Quoted 9 lines · On 19/02/2011 Milan Broz wrote:
Quoted 2 lines · Nicolas Bock
Why use random data to overwrite? Shouldn't
/dev/zerobe 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?
Quoted 8 lines
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines · Jonas Meurer
Hey Milan,
Quoted 7 lines · On 19/02/2011 Milan Broz wrote:
Quoted 2 lines · Nicolas Bock
Why use random data to overwrite? Shouldn't
/dev/zerobe enough since the crypto should produce good randomness on disk?Then you can distinguish between used blocks ("random noise") and unused blocks (remains zeroed).
Quoted 7 lines
Quoted 2 lines
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-----
On Sat, Feb 19, 2011 at 06:10:08PM +0100, Milan Broz wrote:
[...]
Quoted 8 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 10 lines · Nicolas Bock
Quoted 3 lines · Arno Wagner
(I use plain dm-crypt
Quoted 2 lines
Quoted 2 lines
with a random password and overwrite with conventional, mt19997-generated randomness).
Why use random data to overwrite? Shouldn't
/dev/zerobe 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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 7 lines · Arno Wagner
Quoted 2 lines
Why use random data to overwrite? Shouldn't
/dev/zerobe 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-----