Difference between revisions of "Dm-crypt/Drive preparation"
(moved from Dm-crypt with LUKS/draft (unchanged))
m (Kynikos moved page Dm-crypt with LUKS/Drive preparation to Dm-crypt with LUKS/Drive Preparation: current capitalization conventions)
Revision as of 13:51, 18 November 2013
- 1 Secure erasure of the hard disk drive
- 2 Partitioning
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. For detailed instructions on how to erase and prepare a drive consult Securely wipe disk. The following methods are specific for dm-crypt/LUKS and are mentioned complementary, because they can be performed after a partition setup too.
Use LUKS container as pseudorandom number generator (alternate)
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.
# dd if=/dev/zero of=/dev/mapper/luks-container
Wipe free space with encrypted file 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.
# dd if=/dev/zero of=/file/in/luks-container # rm /file/in/luks-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.
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 de-commissioning a drive (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.
/dev/sda1in 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
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
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).
Discard/TRIM support for solid state disks (SSD)
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will not forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.
Most users will still want to use TRIM on their encrypted SSDs. Minimal data leakage in the form of freed block information, perhaps sufficient to determine the filesystem in use, may occur on devices with TRIM enabled. An illustration and discussion of the issues arising from activating TRIM is available in the blog of a
As a semi-tangential caveat, it is worth noting that because TRIM provides information to the disk firmware about which blocks contain data, encryption schemes that rely on plausible deniability, like TrueCrypt's hidden volumes, should never be used on a device that utilizes TRIM. This is probably also valid for TC containers within a LUKS encrypted device that uses TRIM.
TrueCrypt's developers also recommend against using any TC volume on a device that performs wear-leveling techniques to extend the life of the disk; most flash devices, including SSDs and USB flash drives, use mandatory wear-leveling at the firmware level. LUKS devices are probably not vulnerable to problems with wear-leveling if the entire device is blanked before the LUKS partition is initialized. See here and here for more information.
:allow-discards to the
cryptdevice option. The TRIM option may look like this:
For the main
cryptdevice configuration options before the
:allow-discards please refer to the sections following. Besides the kernel option, it is also required to mount the filesystem (e.g.
/dev/mapper/root in this example) with the
discard option in
/etc/fstab. For details, please refer to the SSD page. For LUKS devices unlocked manually on the console or via
allow-discards may be used.
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 (
- initial boot partition
/bootWill not be encrypted; the bootloader needs to access the
/bootdirectory 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,
/bootneeds to reside on its own, unencrypted partition.
This partition layout is encrypted in this example 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.