{"id":1170,"date":"2012-05-23T21:44:53","date_gmt":"2012-05-24T01:44:53","guid":{"rendered":"https:\/\/lowtek.ca\/roo\/?p=1170"},"modified":"2012-05-23T21:44:53","modified_gmt":"2012-05-24T01:44:53","slug":"how-to-add-second-drive-to-luks-ubuntu","status":"publish","type":"post","link":"https:\/\/lowtek.ca\/roo\/2012\/how-to-add-second-drive-to-luks-ubuntu\/","title":{"rendered":"How To: Add 2nd drive to LUKS on Ubuntu"},"content":{"rendered":"

\"\"<\/a><\/p>\n

One of my work machines runs Ubuntu, to protect the data stored on this machine an encrypted file system is used. The file system encryption is LUKS<\/a> based and is applied to a filesystem at creation time, thus to encrypt the system drive it is applied at install time. In my case encryption was an option built into the installer I used.<\/p>\n

After running the system for a while I wanted to add a 2nd drive for additional storage and backup. One solution would be to follow this post<\/a>\u00a0or this one<\/a>, both use a key file stored on the first drive to open the second. Ideally I want the crypt password supplied once on boot to unlock both drives.<\/p>\n

It seems from searching around that this can<\/a> be done<\/a>, but it isn’t clear if hacking the stock scripts is needed or not. I also found the posts to be somewhat lacking step-by-step details. So I’ll try to provide a better how-to here.<\/p>\n

Phase 1<\/strong> – gather some data about our current system.<\/p>\n

Determine which disk I want to change. Be very careful, modifying the wrong physical disk could be very bad.<\/span><\/p>\n

$ sudo fdisk -l<\/code><\/p>\n

Disk \/dev\/sda: 250.1 GB, 250059350016 bytes
\n255 heads, 63 sectors\/track, 30401 cylinders
\nUnits = cylinders of 16065 * 512 = 8225280 bytes
\nSector size (logical\/physical): 512 bytes \/ 512 bytes
\nI\/O size (minimum\/optimal): 512 bytes \/ 512 bytes
\nDisk identifier: 0xe3e5464a<\/code><\/p>\n

Device Boot Start End Blocks Id System
\n\/dev\/sda1 * 1 34 273073+ 83 Linux
\n\/dev\/sda2 35 30401 243922927+ 83 Linux<\/code><\/p>\n

Disk \/dev\/sdb: 250.1 GB, 250059350016 bytes
\n255 heads, 63 sectors\/track, 30401 cylinders
\nUnits = cylinders of 16065 * 512 = 8225280 bytes
\nSector size (logical\/physical): 512 bytes \/ 512 bytes
\nI\/O size (minimum\/optimal): 512 bytes \/ 512 bytes
\nDisk identifier: 0x51e1dd3f<\/code><\/p>\n

Device Boot Start End Blocks Id System
\n\/dev\/sdb1 1 30401 244196001 7 HPFS\/NTFS<\/code><\/p>\n

So the plan is to change \/dev\/sdb<\/strong> into a new encrypted volume.<\/p>\n

Let’s now look at the existing encrypted file system to determine how it is configured. I happen to know mine is called lvm_crypt<\/strong>, you should be able to sort this out by looking in \/dev\/mapper.<\/p>\n

$ sudo cryptsetup status lvm_crypt
\n\/dev\/mapper\/lvm_crypt is active:
\ncipher: aes-xts-plain
\nkeysize: 512 bits
\ndevice: \/dev\/sda2
\noffset: 4040 sectors
\nsize: 487841815 sectors
\nmode: read\/write<\/code><\/p>\n

We’ll want to mimic the cipher and keysize to keep\u00a0things at the same security level.<\/p>\n

Phase 2<\/strong> – creating an encrypted filesystem<\/p>\n

It appears from my experience that the type of the partition doesn’t matter, but for completeness we’ll repartition the drive to be a Linux partition. Again, when doing this be very careful you are specifying the correct disk – it will destroy information.<\/span><\/p>\n

$ sudo fdisk \/dev\/sdb<\/code><\/p>\n

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
\nswitch off the mode (command 'c') and change display units to
\nsectors (command 'u').<\/code><\/p>\n

Command (m for help): d
\nSelected partition 1<\/code><\/p>\n

Command (m for help): n
\nCommand action
\ne extended
\np primary partition (1-4)
\np
\nPartition number (1-4): 1
\nFirst cylinder (1-30401, default 1):
\nUsing default value 1
\nLast cylinder, +cylinders or +size{K,M,G} (1-30401, default 30401):
\nUsing default value 30401<\/code><\/p>\n

Command (m for help): w
\nThe partition table has been altered!<\/code><\/p>\n

Calling ioctl() to re-read partition table.
\nSyncing disks.<\/code><\/p>\n

Now we have a newly partitioned disk. The above may seem somewhat cryptic, we’re simply removing the one existing partition and creating a new one. The default fdisk partition type is a Linux partition suitable for our needs.<\/p>\n

Now we create the encrypted filesystem on the new partition, supplying additional parameters to match the key size and cipher of the system volume.<\/p>\n

$ sudo cryptsetup luksFormat \/dev\/sdb1 --key-size=512 --cipher=aes-xts-plain
\n<\/code>
\nWARNING!
\n========
\nThis will overwrite data on \/dev\/sdb1 irrevocably.
\n<\/code>
\nAre you sure? (Type uppercase yes): YES
\nEnter LUKS passphrase:
\nVerify passphrase:
\n<\/code>
\nI used the same passphrase as the system volume for convenience (and the hope that I could type it in once on boot).<\/p>\n

Now we open it and give it a \/dev\/mapper name, and then format the volume.<\/p>\n

$\u00a0sudo cryptsetup luksOpen \/dev\/sdb1 data_crypt
\n$ sudo mkfs.ext4 \/dev\/mapper\/data_crypt
\n<\/code>
\nAt this point we could get paranoid and fill the new volume with random data to prevent any latent zeros on the disk from reducing the set of data an attacker would need to examine. I’m not that paranoid about this system.<\/p>\n

Phase 3<\/strong> – mounting the encrypted filesystem at boot time<\/p>\n

We’ll be messing with a couple of files: \/etc\/crypttab, \/etc\/fstab\/ and the initramfs. My working theory is that \/etc\/crypttab is used to mount the crypt’d filesystems and\u00a0\/etc\/fstab is used to mount the parititions (in that order). The initramfs is stored on the unencrypted boot volume and contains a snapshot of the configuration files we need to bootstrap. I found this post<\/a> somewhat helpful in figuring this part out.<\/p>\n

First we use blkid to determine the UUIDs.<\/p>\n

$ sudo blkid \/dev\/sda1
\n\/dev\/sda1: UUID=\"a7357d62-71ad-47d5-89cb-fd0f42576644\" TYPE=\"ext4\"
\n$ sudo blkid \/dev\/sda2
\n\/dev\/sda2: UUID=\"e4ff5a5f-39f7-4f3e-a45e-737229d95e10\" TYPE=\"crypto_LUKS\"
\n$ sudo blkid \/dev\/sdb1
\n\/dev\/sdb1: UUID=\"06114da2-138f-401c-9c84-d4a2e6e83bd1\" TYPE=\"crypto_LUKS\"<\/code><\/p>\n

So we add the following line to \/etc\/crypttab:<\/p>\n

data_crypt UUID=06114da2-138f-401c-9c84-d4a2e6e83bd1 none luks
\n<\/code>
\nAnd we now add one line to \/etc\/fstab:<\/p>\n

\/dev\/mapper\/data_crypt \u00a0 \u00a0 \u00a0 \u00a0\/data \u00a0 \u00a0 \u00a0 \u00a0ext4 \u00a0 \u00a0 \u00a0 \u00a0defaults \u00a0 \u00a0 \u00a0 \u00a00 \u00a0 \u00a0 \u00a0 \u00a02<\/code><\/p>\n

Before we reboot, we need to update the initramfs so these configuration changes will be seen at boot time.<\/p>\n

$ sudo update-initramfs -u
\n<\/code>
\nAssuming all went as planned, you’re done. Reboot and test it out.<\/p>\n

My journey wasn’t “as planned”, I made several silly mistakes. Providing the wrong UUID causing a failure to open the encrypted volume, and using the wrong name in fstab. Both easy to diagnose by reading the error messages (and logs) carefully and walking through the steps manually. Measure twice, cut once has an application here.<\/p>\n

I wasn’t successful in getting to a single password entry on boot. I’m prompted twice for the passphrase at boot time, this is easy enough to do. I’m sure I could crawl in and modify the boot scripts to remember and re-try but that’d result in a non-standard configuration causing upgrade pain the in future. Not worth it for a system I rarely reboot.<\/p>\n

Phase 4<\/strong> – bonus marks, testing recovery via LiveCD<\/p>\n

I wanted to verify that I could recover from a failure resulting in an inability to boot the system from the hard disk.<\/p>\n

This turned out to be really easy. Boot the Live CD, then unlock the volumes:<\/p>\n

$ sudo cryptsetup luksOpen \/dev\/sda2 lvm_crypt
\n$ sudo cryptsetup luksOpen \/dev\/sdb1 data_crypt<\/code><\/p>\n

Now mount them. My system volume is a LVM<\/a>, and the new volume is just plain old ext4. I found a helpful post<\/a> on mounting LVMs from rescue mode:<\/p>\n

$ sudo lvm vgscan -v
\n$ sudo lvm vgchange -a y
\n$ sudo lvm lvs --all
\n$ sudo mount \/dev\/mapper\/ubuntu-root \/mnt<\/code><\/p>\n

Mounting the ext4 partition is simply<\/p>\n

$ sudo mount \/dev\/mapper\/data_crypt \/mnt2<\/code><\/p>\n

That’s it, a second volume added to an existing LUKS system – and confidence we can mount both volumes from a LiveCD in the case of failure.<\/p>\n","protected":false},"excerpt":{"rendered":"

One of my work machines runs Ubuntu, to protect the data stored on this machine an encrypted file system is used. The file system encryption is LUKS based and is applied to a filesystem at creation time, thus to encrypt the system drive it is applied at install time. In my case encryption was an … Continue reading “How To: Add 2nd drive to LUKS on Ubuntu”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,12],"tags":[],"class_list":["post-1170","post","type-post","status-publish","format-standard","hentry","category-computing","category-how-to"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1170","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=1170"}],"version-history":[{"count":6,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1170\/revisions"}],"predecessor-version":[{"id":1177,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1170\/revisions\/1177"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=1170"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=1170"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=1170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}