We will install Linux Unified Key Setup (LUKS) software and create an encrypted LUKS volume.
General disclaimer applies, no liability will be accepted for any loss or damage, use at your own risk and do frequent backups!
Also, likely a good idea to keep this in mind (credit goes to xkdc.com):
It is strongly advised to read cryptsetup FAQ first: http://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions.
Installation
We’ll be using a Debian Wheezy server. Update packages list and install cryptsetup:
# apt-get update && apt-get install cryptsetup
Load the kernel module:
# modprobe dm_crypt
Install the pv package for progress monitoring that will be used later:
# apt-get install pv
Setup LUKS Partition
Our disk partition table looks like this:
# fdisk -l | grep -i "/dev/sd"
Disk /dev/sda: 32.0 GB, 32017047552 bytes
/dev/sda1 * 2048 60547071 30272512 fd Linux RAID autodetect
/dev/sda2 60547072 62531583 992256 82 Linux swap / Solaris
Disk /dev/sdb: 32.0 GB, 32015965696 bytes
/dev/sdb1 * 2048 60547071 30272512 fd Linux RAID autodetect
/dev/sdb2 60547072 62531182 992055+ 83 Linux
We will be setting up a LUKS volume on a 1GB partition /dev/sdb2
.
Create LUKS Partition
We want to verify the passphrase twice, use the verbose mode and set the cipher string:
# cryptsetup -v -y --cipher "aes-xts-plain64:sha512" \ --key-size 512 --hash sha512 --iter-time 5000 \ --use-random luksFormat /dev/sdb2 WARNING! ======== This will overwrite data on /dev/sdb2 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Command successful.
[UPDATE]: release 1.6.0 of cryptsetup changed the defaults to an AES cipher in XTS mode. It is advised against using the previous default cipher aes-cbc-essiv because of its known issues and practical attacks against them.
Unlock LUKS Partition
Having created the partition, let us go and to unlock it:
# cryptsetup luksOpen /dev/sdb2 data Enter passphrase for /dev/sdb2:
The above command should create the following mapper:
/dev/mapper/data
Format LUKS Volume and Create a Filesystem
We want to overwrite the LUKS volume with zeros to ensure that outside world sees the encrypted container as random data – it protects against disclosure of usage patterns.
Since we have an encrypted LUKS volume, it has a master key that will be used to encrypt the stream onto the disk. What we think to be zero is not zero on the disk.
# pv -tpreb /dev/zero | dd of=/dev/mapper/data bs=1M dd: writing `/dev/mapper/data': No space left on device 966MB 0:00:58 [16.6MB/s] 0+7729 records in 0+7728 records out 1012924416 bytes (1.0 GB) copied, 70.8432 s, 14.3 MB/s
Note that filling an encrypted volume with zeroes is the recommended method for overwriting a disk in the cryptsetup FAQ (see section 2.19).
When the format operation is complete, we can go ahead and create a filesystem (ext4 in this case):
# mkfs.ext4 /dev/mapper/data -L data mke2fs 1.42 (29-Nov-2011) Filesystem label=data OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 61824 inodes, 247296 blocks 12364 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=255852544 8 block groups 32768 blocks per group, 32768 fragments per group 7728 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done
Mount LUKS Volume
Create a new mountpoint for the LUKS volume:
# mkdir /data
Mount the volume:
# mount /dev/mapper/data /data
The LUKS volume can be dismounted and closed this way:
# umount /data # cryptsetup luksClose data
Next thing on a list: add a backup key and backup the LUKS header.
The last command should be
# cryptsetup luksClose data
without the /dev/mapper/
You’re right, thanks. However, it works both ways.
“We want to overwrite the LUKS volume with zeros to ensure that outside world sees this as random data – it protects against disclosure of usage patterns”
Could you please explain?
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. That is because encrypted data is practically indistinguishable from random.
I have been struggling with this problem for quite some time, and wondering if you can help me on this. Thank you!
created a LUKS2 partition for a device of ~6 M in size:
sh-4.4# cryptsetup luksFormat –type luks2 /dev/mmcblk2gp0p6
sh-4.4# cryptsetup luksDump /dev/mmcblk2gp0p6
LUKS header information
Version: 2
Epoch: 3
Metadata area: 16384 [bytes]
Keyslots area: 6258688 [bytes] <<<<<<<<<<<<<<<<<<< does this mean keyslots really take all 6 M device space?
UUID: 7153e1b7-f287-4b38-be05-70226b5d5ac2
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)
Data segments:
0: crypt
offset: 6291456 [bytes] <<<<<<< does this really means offset of user data space?
I tried to map the luks partition:
sh-4.4# cryptsetup open –type luks /dev/mmcblk2gp0p6 blk2gp0p6
Enter passphrase for /dev/mmcblk2gp0p6:
Requested offset is beyond real size of device /dev/mmcblk2gp0p6. <<< does this really caused by big luks header?
Thank you very much!
It it says that the keyslots area takes 6258688 bytes, then it probably does.
Thanks Tomas!
For my other bigger partitions, a few hundreds M or a few G in size, the total Luks overhead takes exactly 10 M space. It seems very consistent. I don’t know why LUKS2 document didn’t say this rather significant fact, especially for embedded system.
correction – the size is 0x10000000 which should be 16 M not 10 M. And it seems default value for LUKS2.sd Hope this also help others.