Mount encrypted partition of an image file

cryptsetupluks

I've an image backup file of my harddisk, which consists of three partitions (sudo fdisk -l /mnt/hdd/19_02.img):

Device                 Start       End   Sectors   Size Type
/mnt/hdd/19_02.img1     2048   1050623   1048576   512M EFI System
/mnt/hdd/19_02.img2  1050624  34686975  33636352    16G Linux swap
/mnt/hdd/19_02.img3 34686976 976773134 942086159 449.2G Linux filesystem

The third partition ist of type crypto_LUKS. If it wouldn't be encrypted I could mount it with sudo mount -o loop,offset=$(expr 512 \* 34686976) /mnt/hdd/19_02.img /mnt/img, which results in mount: /mnt/img: unknown filesystem type 'crypto_LUKS'.

What I've tried

sudo cryptsetup luksOpen /mnt/hdd/19_02.img3 img results in Device /mnt/hdd/19_02.img3 doesn't exist or access denied.

sudo cryptsetup plainOpen --offset=$(expr 512 \* 34686976) /mnt/hdd/19_02.img img asks for my passphrase which also gets accepted, but returns with Requested offset is beyond real size of device /mnt/hdd/19_02.img.
Alright, maybe cryptsetup does multiply the offset value with the block size by itself.

sudo cryptsetup plainOpen --offset=34686976 /mnt/hdd/19_02.img img asks for my passphrase which also gets accepted and returns fine. But sudo mount /dev/mapper/img /mnt/img complains mount: /mnt/img: wrong fs type, bad option, bad superblock on /dev/mapper/img. Analysing with sudo lsblk -f /dev/mapper/img shows there is no filesystem recognized.

NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
img

The encrypted device was created by LUKS mode, so it properly makes not much sense opening it with plainOpen. But luksOpen doesn't offer an --offset option.

Doing sudo cryptsetup luksOpen --offset=34686976 /mnt/hdd/19_02.img img results in cryptsetup: Option --offset is supported only for open of plain and loopaes devices and for luksFormat. (Didn't tried luksFormat, but it sets up the LUKS device header and encrypts the master-key.)

The question after all

How to do cryptsetup luksOpen with offset on an image file?

Best Answer

fdisk is being a bit stupid here: when displaying device names for the partitions, it just takes the name of the whole-disk device given to it, and appends the partition number (prefixed with p if the last character of the whole-disk device name is also a number). It does this without checking if a device by that name actually exists or not.

In other words, if your image file is named /mnt/hdd/19_02.img and you're using fdisk to examine it directly, then partition names like /mnt/hdd/19_02.img3 are completely fictional and unusable.

Instead of trying to calculate offsets manually, you could simply attach the image file into a loop device and have it automatically detect the partitions for you:

sudo losetup -P /dev/loop0 /mnt/hdd/19_02.img

If your system is new enough to support the -P option for losetup, you should now have partition devices like /dev/loop0p1, /dev/loop0p2 and /dev/loop0p3 appearing automatically.

For older distributions with no partitioned loop device support, you can use the kpartx command (may come with the device-mapper-multipath tools if not packaged separately) for the same purpose. In that case, you'll have to perform two steps and the device names will be slightly different:

sudo losetup /dev/loop0 /mnt/hdd/19_02.img
sudo kpartx -a /dev/loop0

When using kpartx like this, the partition devices will appear under /dev/mapper, e.g. /dev/mapper/loop0p1 and so on.

Now you should be able to do either

sudo cryptsetup luksOpen /dev/loop0p3 img

sudo cryptsetup luksOpen /dev/mapper/loop0p3 img

depending on whether you used losetup -P or kpartx to handle the partition devices.

After you're done accessing the image, unmount any mounted filesystems on the partition devices, sudo cryptsetup luksClose the encrypted image, then undo the loop device binding:

If you used kpartx, first run sudo kpartx -d /dev/loop0 to release the partition devices. If you used losetup -P, this step is not needed.

Then, release the loop device: sudo losetup -d /dev/loop0.

Related Solutions

LUKS Encryption – Storing Keyfile in Encrypted USB Drive

Your approach looks good. Some remarks though:

If you want to encrypt rootfs, you'll need to use initrd (to have some minimal unencrypted system that will process the encrypted partitions).

If the USB device is removable, both initrd and kernel can be stored on the USB to heighten tamper resistance (supposing you make sure the USB won't get into unauthorized hands) - which is usually why one encrypts rootfs. Once both kernel and initrd are on a removable media, you can ensure that nobody changes the kernel (or initrd) from the running system by simply removing the media.

This is of course not an option if you want to have it inside of a server, but then again the question stands whether it makes sense to have such a device at all and not to use a small partition on one of the hard-drives. If for example all drives in the machine are in RAID, one would probably want to put rootfs on the USB as well. An interesting alternative to an internally connected USB flash device could be a CompactFlash card attached to ATA interface through an adapter, by the way.

Some distributions offer prepared solutions for encrypted root, some don't - but mostly it's question of putting a couple of lines into initrd script before it tries to mount the "real" root (see for example man pages for pivot_root, usually in sections 2 (syscall) and 8 (bonary), if you're not familiar with the process).
remember to backup the keys and passphrases in case your USB drive dies. LUKS follows rather one-sided approach when it comes to damaging its header - once a single sector of its header (key-slot to be more precise) dies, you are unable to mount it. This is to make sure that erasing the header isn't effectively thwarted by block reallocation performed by the device itself (because that's what flash-memory based devices do a lot) - the key is spread over the whole key slot and one needs all of the data to reconstruct it - there is no redundancy. See Clemens Fruwirth's website for deeper discussion.

That said, maybe a simple encrypted device on the USB would be enough (check section PLAIN MODE in man cryptsetup). Or a file encrypted with e.g. openssl enc. The former might actually be an option even for the encrypted partitions themselves.

Linux LUKS – How to Resize a LUKS Device, Revisited

You still have to resize the filesystem using the resized block device. The precise method and possible limitations depend on each filesystem.

Here are two examples to resize the filesystems to the whole available size for EXT4 and XFS. An other filesystem will require an other specific command.

An EXT4 filesystem can be enlarged online or offline (and can also be shrunk, but only offline).
```
resize2fs /dev/mapper/cryptdevice
```
An XFS filesystem can only be enlarged, and online (can't be shrunk back once done).

The filesystem must be mounted to be grown. The command requires the mountpoint rather than the block device.
```
mount -t xfs /dev/mapper/cryptdevice /mnt

xfs_growfs /mnt
```

You actually missed this step twice from the links:

Resize LUKS Volume(s)

in the question:
```
# Step 5: Resize encrypted volume (Trying to give it some space)
> resize2fs -p /dev/CryptVolumeGroup/root 101G
```
but in the answer:

Enlarge the rootfs logical volume. No need to un-mount since ext4 and be enlarged while mounted: lvresize -r -L +100G archvg/home

lvresize -r resizes automatically the underlying filesystem, hence no specific command in the answer. Resizing the filesystem for your specific case not using LVM wasn't present in this answer.

Increase the size of a LUKS encrypted partition

As a final step, the file-system needs to be expanded to the new size. With the resize2fs(8) command the file-system is extended to the new size of the LUKS volume.
$ sudo resize2fs /dev/mapper/sdb1_crypt
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/mapper/sdb1_crypt is mounted on /media/gerhard/Daten; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 4
The filesystem on /dev/mapper/sdb1_crypt is now 14647925 (4k) blocks long.

Resizing LVM-on-LUKS
Resizing the encrypted volume

Now we are going to resize the encrypted volume itself. By taking in account the total size of the logical volume minus some safety space:
```
# resize2fs -p /dev/CryptVolumeGroup/Home 208G
```