Difference between revisions of "Dm-crypt/Drive preparation"

From ArchWiki
Jump to: navigation, search
(Wipe LUKS header: justify the presence of this section in /Drive Preparation)
m (Typo terrabyte -> terabyte)
(11 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
[[Category:Security]]
 
[[Category:Security]]
 
[[Category:File systems]]
 
[[Category:File systems]]
{{Stub|This article is currently under heavy restructuring: for its latest stable revision see [[Dm-crypt with LUKS]]}}
+
Back to [[Dm-crypt]].
Back to [[Dm-crypt with LUKS/draft]].
+
  
 
== Secure erasure of the hard disk drive ==
 
== Secure erasure of the hard disk drive ==
Line 10: Line 9:
  
 
In deciding which method to use for secure erasure of a hard disk drive, remember that this needs only to be performed once for as long as the drive is used as an encrypted drive.
 
In deciding which method to use for secure erasure of a hard disk drive, remember that this needs only to be performed once for as long as the drive is used as an encrypted drive.
 +
 +
{{Warning|Make appropriate backups of valuable data prior to starting.}}
 +
 +
{{Tip|The process of filling an encrypted drive can take over a day to complete on a multi-terabyte disk. It is therefore suggested to do it from another installation rather than the Arch installation media.}}
  
 
=== Generic methods ===
 
=== Generic methods ===
 
For detailed instructions on how to erase and prepare a drive consult [[Securely wipe disk]].
 
For detailed instructions on how to erase and prepare a drive consult [[Securely wipe disk]].
  
=== LUKS-specific methods ===
+
=== dm-crypt specific methods ===
The following methods are specific for dm-crypt/LUKS and are mentioned complementarily, because they can be performed after a partition setup too.  
+
The following methods are specific for dm-crypt and are mentioned complementarily, because they are very fast and can be performed after a partition setup too.  
  
==== Use LUKS container as pseudorandom number generator ====
+
The [http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects cryptsetup FAQ] mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.  
The [http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects cryptsetup FAQ] mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.
+
  
{{bc|1=
+
==== dm-crypt wipe before installation ====
# dd if=/dev/zero of=/dev/mapper/luks-container}}
+
First, create a temporary encrypted container on the partition ({{ic|sdXY}}) or the full disk ({{ic|sdX}}) you want to encrypt, e.g. using default parameters
 +
# cryptsetup open --type plain /dev/sdXY container
 +
Second, check it exists
 +
{{hc|# fdisk -l|Disk /dev/mapper/container: 1000 MB, 1000277504 bytes
 +
...
 +
Disk /dev/mapper/container does not contain a valid partition table}}
 +
Finally, wipe it with pseudorandom (encrypted data), a use of {{ic|/dev/urandom}} is not required as the encryption cipher is used for randomness: 
 +
{{hc|# dd <nowiki>if=/dev/zero of=</nowiki>/dev/mapper/container|
 +
dd: writing to ‘/dev/mapper/container’: No space left on device}}
 +
Now the next step is [[#Partitioning]].
  
==== Wipe free space with encrypted file after Installation ====
+
==== dm-crypt wipe free space after installation ====
  
The same effect can be achieved if a file is created on each encrypted partition that fills the partition completely after the system is installed, booted and filesystems mounted. That is because encrypted data is indistinguishable from random.
+
The same effect can be achieved if a file is created on an encrypted partition that fills the free space of the partition completely after the system is installed, booted and filesystems mounted. That is because encrypted data is practically indistinguishable from random.
  
 
{{bc|1=
 
{{bc|1=
# dd if=/dev/zero of=/file/in/luks-container
+
# dd if=/dev/zero of=/file/in/container
# rm /file/in/luks-container}}
+
# rm /file/in/container}}
 
+
The above process has to be repeated for every container created.
+
 
+
==== Wipe LUKS keyslots ====
+
#cryptsetup luksKillSlot <device> <key slot number>
+
  
This will only wipe a single keyslot.
+
The above process has to be repeated for every partition blockdevice created.
  
 
==== Wipe LUKS header ====
 
==== Wipe LUKS header ====
Line 67: Line 73:
  
 
::*[[Partitioning|Standard partitions]]
 
::*[[Partitioning|Standard partitions]]
::*[[#LVM:_Logical_Volume_Manager|LVM]]
+
::*[[#LVM: Logical Volume Manager|LVM]]
 
::*[[RAID]]
 
::*[[RAID]]
  
Line 80: Line 86:
 
; initial boot partition: {{ic|'''/boot'''}} Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.
 
; initial boot partition: {{ic|'''/boot'''}} Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.
  
This partition layout is encrypted in [[Dm-crypt_with_LUKS#Encrypting_a_system_partition|this example]] and can be refined according to needs, e.g. by separating partitions or adding an encrypted swap-partition.
+
This partition layout is encrypted in [[dm-crypt/Encrypting_an_Entire_System|these examples]] and can be refined according to needs, e.g. by separating partitions or adding an encrypted swap-partition.
  
 
====Single Disk Systems====
 
====Single Disk Systems====
Line 92: Line 98:
 
===LVM: Logical Volume Manager===
 
===LVM: Logical Volume Manager===
  
The LVM allows for systems that require complex hard disk configurations. [[LVM|Knowledge of using LVM]] is a requisite to continue with [[Dm-crypt_with_LUKS#Encrypting_a_LVM_setup|setting up LUKS with LVM]] later in this article.  
+
The LVM allows for systems that require complex hard disk configurations. [[LVM|Knowledge of using LVM]] is a requisite to continue with [[Dm-crypt/Encrypting_an_Entire_System#LVM_on_LUKS|setting up LUKS with LVM]].  
  
{{Tip|Btrfs has a built-in [[Btrfs#Subvolumes|Subvolume-Feature]] that fully replaces the need for LVM if no other filesystems are required. An encrypted swap is not possible this way and swap files are [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F not supported] by btrfs up to now.}}
+
{{Tip|Btrfs has a built-in [[Btrfs#Sub-volumes|Subvolume-Feature]] that fully replaces the need for LVM if no other filesystems are required. An encrypted swap is not possible this way and swap files are [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F not supported] by btrfs up to now.}}

Revision as of 23:19, 3 January 2014

Back to Dm-crypt.

Secure erasure of the hard disk drive

Before encrypting a drive, you should perform a secure erase of the disk by overwriting the entire drive with random data. To prevent cryptographic attacks or unwanted File Recovery, this data should be completely indistinguishable from all data later written by dm-crypt.

In deciding which method to use for secure erasure of a hard disk drive, remember that this needs only to be performed once for as long as the drive is used as an encrypted drive.

Warning: Make appropriate backups of valuable data prior to starting.
Tip: The process of filling an encrypted drive can take over a day to complete on a multi-terabyte disk. It is therefore suggested to do it from another installation rather than the Arch installation media.

Generic methods

For detailed instructions on how to erase and prepare a drive consult Securely wipe disk.

dm-crypt specific methods

The following methods are specific for dm-crypt and are mentioned complementarily, because they are very fast and can be performed after a partition setup too.

The cryptsetup FAQ mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.

dm-crypt wipe before installation

First, create a temporary encrypted container on the partition (sdXY) or the full disk (sdX) you want to encrypt, e.g. using default parameters

# cryptsetup open --type plain /dev/sdXY container

Second, check it exists

# fdisk -l
Disk /dev/mapper/container: 1000 MB, 1000277504 bytes
...
Disk /dev/mapper/container does not contain a valid partition table

Finally, wipe it with pseudorandom (encrypted data), a use of /dev/urandom is not required as the encryption cipher is used for randomness:

# dd if=/dev/zero of=/dev/mapper/container
dd: writing to ‘/dev/mapper/container’: No space left on device

Now the next step is #Partitioning.

dm-crypt wipe free space after installation

The same effect can be achieved if a file is created on an encrypted partition that fills the free space of the partition completely after the system is installed, booted and filesystems mounted. That is because encrypted data is practically indistinguishable from random.

# dd if=/dev/zero of=/file/in/container
# rm /file/in/container

The above process has to be repeated for every partition blockdevice created.

Wipe LUKS header

The partitions formatted with dm-crypt/LUKS contain a header with the cipher and crypt-options used, which is referred to dm-mod when opening the blockdevice. After the header the actual random data partition starts. Hence, when re-installing on an already randomised drive, or de-commissioning one (e.g. sale of PC, switch of drives, etc.) it may be just enough to wipe the header of the partition, rather than overwriting the whole drive - which can be a lengthy process.

Wiping the LUKS header will delete the PBKDF2-encrypted (AES) master key, salts and so on.

Note: It is crucial to write to the LUKS encrypted partition (/dev/sda1 in this example) and not directly to the disks device node. If you did set up encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID then write to RAID respectively.

A header with one single default 256 bit size keyslot is 1024KB in size. It is advised to also overwrite the first 4KB written by dm-crypt, so 1028KB have to be wiped. That is 1052672 Byte.

For zero offset use:

#head -c 1052672 /dev/zero > /dev/sda1; sync

For 512 bit key length (e.g. for aes-xts-plain with 512 bit key) the header is 2MB.

If in doubt, just be generous and overwrite the first 10MB or so.

#dd if=/dev/zero of=/dev/sda1 bs=512 count=20480
Note: With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.

When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup FAQ 5.19).

Partitioning

After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.

There are multiple ways to create disk partitions:

LUKS can be used with systems that require LVM and/or RAID and is compatible with all regular partitioning standards in Linux.

Creating Disk Partitions

There are two required partitions for a basic encrypted system setup:

root file system
/ Will be encrypted and store all system and user files (/usr, /bin, /var, /home, etc.)
initial boot partition
/boot Will not be encrypted; the bootloader needs to access the /boot directory where it will load the initramfs/encryption modules needed to load the rest of the system which is encrypted (see Mkinitcpio for details). For this reason, /boot needs to reside on its own, unencrypted partition.

This partition layout is encrypted in these examples and can be refined according to needs, e.g. by separating partitions or adding an encrypted swap-partition.

Single Disk Systems

If there are additional partitions desired, these can be individually created by defining separate primary or extended/logical partitions. It is possible to encrypt separate partitions (e.g. /home, /var) while leaving others (e.g. /usr) unencrypted as required. However, a standard install would also require separate passphrases or keys to open each encrypted partition during boot.

Multiple Disk Systems

In systems with multiple hard disk drives, the same options exist as a single disk system. After the creation of the /boot partition, the remaining free space on the physical disks can be divided up into their respective partitions at this level. For encrypted partitions that span multiple disks, LUKS must be used with RAID or LVM.

LVM: Logical Volume Manager

The LVM allows for systems that require complex hard disk configurations. Knowledge of using LVM is a requisite to continue with setting up LUKS with LVM.

Tip: Btrfs has a built-in Subvolume-Feature that fully replaces the need for LVM if no other filesystems are required. An encrypted swap is not possible this way and swap files are not supported by btrfs up to now.