The preceding post looked at a naïve approach for combining local file encryption using EFS with cloud storage, explaining why that mixture does not accomplish the intended objective. Here we look at an alternative design that does work as expected. There are three ingredients:
- Virtual disk images (also known as VHD files, after the extension used by MSFT virtualization software for this type of image)
- BitLocker-To-Go full volume encryption (“BL2G”)
- Any remote storage/backup system that relies on syncing a local folder to the cloud. For these examples we will use MSFT SkyDrive, but the same approach works for DropBox, Google Drive or any other service patterned on keeping a local folder synchronized
“All problems in computer science can be solved by adding one more layer of indirection” goes one popular CS aphorism. Virtualization happens to be one of the more broadly applicable ways of adding indirection. Virtual disk files are typically used to represent images for virtual machines. In this case, they solve a slightly different problem of bridging abstraction levels. The encryption scheme we plan to use operates on entire drives. Meanwhile cloud storage solutions typically work at the level of folders and files. There are many ways to make a directory appear as a full disk drive– for example sharing the folder and then making a loopback connection to that network share will mount it as a drive. But that approach will present the “disk” in the wrong representation, as a remote SMB share not directly controlled by the local OS. By contrast BL2G requires disks directly addressable at block level.
This is where the ability to mount VHDs as removable drives comes in handy. In effect what looks like a single file to the cloud synchronization software appears as a removable drive to the operating system, much like a USB thumb drive that can be connected and disconnected at will. Better yet, Windows BL2G encryption feature is directly applicable to this type of disk. (For completeness: VMware also has a comparable VMDK format for disk images. However manipulating these requires additional software installation while VHD is natively supported out of the box.)
Creating the disk image
The first step then is creating the VHD. There are different ways of doing this based on the operating system version. For Windows 7, one needs the Storage Manager snap-in. This can be either added to any MMC console, or it can be accessed directly by right-clicking on “Computer” and choosing the Manage option. Right-clicking on storage manager brings up a context menu with the option to create a new VHD:
While the location of the VHD file is not important, it helps to choose a modest size due to limitations of the synchronization process that will be discussed in greater detail later. After the file is created, the virtual disk has to be initialized and formatted, as described in this tutorial. These steps only need to be performed once. Once the VHD image is initialized with a file system, it can be mounted/unmounted multiple times.
Mounting the disk image
The other half of the puzzle is mounting an existing VHD which has been downloaded from the cloud. In other words, we want to get to a point where Windows views that file as an ordinary disk drive with a letter assigned such as R. In that state we can browse into that folder in Explorer and drag-and-drop files for cloud storage. In Windows 8 this is as simple as double-clicking the VHD file. Windows 7 requires more work, as the file extension is not recognized natively. Going back to the Disk Manager snap-in, the same context menu for creating new VHD images also has an option to attach existing ones, as illustrated in the above screenshot.
(In a more polished flow, these steps could be automated with diskpart utility present in Windows out-of-the-box. It is possible to write scripts that automatically mount and unmount the VHD compatible with either OS, and even associating that for handling the extension.)
With the VHD mounted as disk drive, it is now possible to open that drive in Explorer and move any files there. But doing so would result in those files getting backed up to the cloud provider as cleartext without encryption. Since our objective is to protect data from mishaps associated with the cloud provider, BL2G must be enabled first before using the virtual disk.