Digital Origin - Encrypted Disks from the Cloud

Working with Encrypted Disks from the Cloud

We’ve all hear about the Cloud. It’s on the Internet somewhere and some people must believe its just magic – or something like that. Technically, Cloud Servers are just Virtualized Servers. Like a Russian doll, its a Server in a Server. The big difference is that one Bare Metal server (the physical hardware) can host many Virtual Servers. This idea is what gives way to the idea of – queue dramatic music – “the Cloud”. Most Cloud Servers are not encrypted so the concept of Working with encrypted disks is kind of rare.

If you learned something from this first paragraph then that’s great! This is just a warning – the rest of this will be very technical in comparison. It will include Linux commands that deal with low-level file systems, disk encryption, and others.

There are only a few cases where using full disk encryption is a bad idea. These include… well, if you don’t know how to work with them. Working with encrypted disks, whether in the cloud or not, there will come a time when you need to conduct digital forensics, data recovery, data backup, or even just a simple data transfer – You’ll need to know how to work with these types of disk images before server downtime occurs.

Most disk encryption solutions use whats called Luks encryption. Luks stands for Linux Unified Key Setup and was initially developed in 2004. It’s the defacto disk encryption for the Linux Operating System and it’s what we’ll be talking about today.

A presumption that we’re using here is that you already have your disk image in a RAW format. Different Cloud Platforms use different disk formats. VMWare uses the VMDK format. XenServer uses OVA/OVF formats. KVM uses qcow2 and RAW formats. Hyper-V uses the VHD format. And so on and so on. The RAW format can be considered the most natural format to work with. It uses open standards and is widely used and understood.

When you have your encrypted RAW disk image (Cloud_Server_encrypted_disk.img) you’ll first need to know if there are multiple partitions in the image. We’ll use the fdisk command to find this out. If there are, then we need to find out the offset before mounting.

# fdisk -l Cloud_Server_encrypted_disk.img 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xREMOVED

	Device            Boot   Start       End   Sectors  Size Id Type
	Cloud_Server_encrypted_disk.img1 *       2048   1026047   1024000  500M 83 Linux
	Cloud_Server_encrypted_disk.img2      1026048 104857599 103831552 49.5G 83 Linux

The results here are interesting. We know that the type is of the linux format. We also know that there are two different partitions in this image. The first image, which is 500MB, is bootable. This tells us that this is the boot image. There is typically zero data you’d like on here – we’ll ignore it moving forward.

The second partition, which is 49.5GB, is likely where the data you want lives. Take note of the “Start” section which is 1036048. We’ll also take note of the size of each sector. This number represents the amount of sectors needed to skip to get to the start of the specific partition.

Now that we know the offset – 1026048*512 – we can mount the image as a loop device. 

# losetup -o $((1026048*512)) /dev/loop0 Cloud_Server_encrypted_disk.img

As long as there are no errors your disk is mounted and ready to be decrypted and accessed for backup purposes. The following commands, in the order provided (note the ‘&&’ which ties commands in sequence as long as there are no errors from the previous command). You’ll be prompted for a password to decrypt the disk image, then will ensure the required Linux Kernel Module is loaded, then will update Linux Volume information for changes, display information about the Linux Volumes, then finally mount the now accessible disk image to a folder of your choosing.

# cryptsetup luksOpen /dev/loop0 _FILES_BACKUP && modprobe dm-mod && vgchange -ay && lvscan && mount /dev/vg_centos65/lv_root /mnt/existing_folder/

Enter passphrase for /home/username/Cloud_Server_encrypted_disk.img: 
  2 logical volume(s) in volume group "vg_centos65" now active
  3 logical volume(s) in volume group "pve" now active
  ACTIVE            '/dev/vg_centos65/lv_root' [45.60 GiB] inherit
  ACTIVE            '/dev/vg_centos65/lv_swap' [3.91 GiB] inherit
  ACTIVE            '/dev/pve/swap' [8.00 GiB] inherit
  ACTIVE            '/dev/pve/root' [58.00 GiB] inherit
  ACTIVE            '/dev/pve/data' [147.34 GiB] inherit

You’ll then be able to navigate through the filesystem just like any other folder. Once you’re done backing up your data, or with whatever else you need to do with a backup image, you can unmount the disk using the following commands.

# umount /mnt/sdb/ && dmsetup remove vg_centos65-lv_root && dmsetup remove vg_centos65-lv_swap && cryptsetup luksClose /dev/mapper/_FILES_BACKUP && losetup -d /dev/loop0

There is some things to note here. Specifically, this works on linux – specifically a CentOS v6.5 installation of Linux. If you’re accessing a Debian, Ubuntu, or other flavors of Linux, your commands will likely be slightly different.

We hope that you find this helpful but if you require further information, or assistance, then feel free to contact us. We’re looking forward to helping.