FreeOTFE: linux-loopback-compatible Windows encryption

cross-reading encrypted data between platforms

Linux and Windows both have a variety of encryption engines available. However, the ability to encrypt and decrypt cross-platform demands a compatible pair of such programs. For the the linux loopback device with its encryption capability, a matching Windows counterpart is FreeOTFE by Sarah Dean. It understands the encrypted output produced by the loopback device and can decrypt it. OTFE stand for "on the fly encryption." You might consider FreeOTFE to be a Windows equivalent of the loopback device (among broader objectives).

In linux the loopback device can front for some other device, partition, or file, and encrypt/decrypt its entire datastream on the fly. That is, anything written it gets encrypted on the way in and when read, decrypted on the way out. If the device, partition, or file is then made available under Windows, FreeOTFE can pick it up and assume the same role as linux's loopback device. Namely, to decrypt it before passing it on to whatever driver drives it. This discussion considers an encrypted filesystem that is file-based (that is, held and written inside a file as opposed to a device or partition). The discussion applies equally in the device- or partition-based cases.

FreeOTFE, as consumer of an encrypted file created by a linux loopback device, needs details about how it was encrypted in order to decrypt it. Most centrally it must know which one of the several available encryption algorithms was applied. And of course it must know the password that was used. Several other details must be supplied, and getting any one of them wrong will prevent successful decryption of the file. As well, the file format of the encrypted filesystem should be one that is cross-readable between the two platforms. It isn't useful to make arrangements for Windows to decrypt a filesystem it doesn't know how to read! For this purpose FAT (called msdos in linux) or FAT32 (called vfat) are the most reliable choices.

The linux screenshots below show the creation of two file-based filesystems. One is unencrypted, the other encrypted with the aes algorithm. The containing files are named "straight" and "scrambled" respectively. We are interested in scrambled.

Note below that the filesystem inscription step (mkfs) is done after the losetup command makes choice of encryption algorithm. So when the mkfs command builds the filesystem directories and other structures that define vfat/fat32, via the /dev/loop2 device, inside the "scrambled" file, those structures all pass through encryption before landing inside the file. This means the inverse, decryption process needs to be correctly applied later when reading the filesystem back for there to be any hope of making sense of any portion of the contents. The encryption granularity is filesystem wide. It isn't a case of encrypting files individually on an otherwise unencrypted filesystem.

We now have a file whose name is "scrambled," whose size is 64K, and whose content is a filesystem containing a file in its root directory named "hello.txt" holding the phrase "hello world." That filesystem is encrypted using aes and whatever password the user gave in the 3rd line of the above screenshot. So now it's time to plug "scrambled" into a Windows machine. Let's do that by putting it onto a 16MB thumb drive that already has some files on it, and take it to our Windows box.

When the thumb drive is plugged into the USB port on the Windows machine, a new drive H appears, and contains scrambled:

Windows doesn't know how to open this file, but FreeOTFE does, if we just tell it the details. Invoke it and navigate to mount a file-based linux volume (filesystem):

Namely, select scrambled:

FreeOTFE must know parameters that match the way scrambled was encrypted, in order to be able to decrypt it. We supply them in the two tabbed dialogs below. Exactly the right information is necessary here or the decryption will turn the garbage in "scrambled" into more garbage, rather than a cleartext image of a properly formatted filesystem. Whatever emerges will be presented to the platform driver for filesystems, so had better walk like one and smell like a proper filesystem if it's to work.

If all is correct another new drive appears, which in this example assumes drive letter I:

And, upon opening drive I, we see a filesystem/volume containing the single file hello.txt, in turn containing the phrase "hello world."

At this point you should be impressed. The file "scrambled" contains within it a whole "disk"! Drive I is inside drive H. Yes, that's the point and why not. A real disk contains a "disk" only because of the structure of its contents, per the rules of FAT or ext2 or NTFS. And since both disks and disk files are generic data containers that can contain anything, a disk file can contain that same thing that a disk normally does, just as well. Notice also that the encryption makes the filesystem in scrambled private and protected, and with it all the files and folders it might potentially contain. The decryption, hence revelation of the contents of drive I, depended on supplying the password to FreeOTFE. The requisite password is the one that was given to the command "losetup -e aes /dev/loop2 scrambled" back in linux, setting up the algorithm and password by which the original encryption was done. Doing the decryption now needs the same.

Note that the new filesystem, drive I here in Windows, has a constraint. Its containing file is rigidly 64K in size. You can't grow it. This isn't so bad. Likewise, a filesystem in a 20GB disk partition lies in a container of fixed size (20GB) and you can't grow that either. The rigidity is normal, just the size here is a little small. But you can choose the size when you first create the file. We did that back in linux with the dd command. The filesize was determined by specifying "bs=1024 count=64." That says emit data in blocks of size 1K bytes each, and emit a total of 64 of them. If you want a bigger file, ask for it at create time by raising those numbers. Just be sure to anticipate the size limit you're going to be comfortable with.

This arrangement could be applied to a partition or whole device, instead of a file. As it is, we have a 16MB thumb drive and have devoted 64K to encrypted stuff with the balance available for normal unencrypted stuff (like the 3 unencrypted files shown). You could choose your proportions and make, say, half the drive encrypted. But instead of doing so by placing a file of that size into the thumb drive, you could split that drive into 2 equal partitions then make the loopback device correspond to one of those. There would be no file. The thumb drive would have partitions /dev/sda1 and /dev/sda2 and the command

 losetup  -e aes  /dev/loop2  scrambled

would change to

 losetup -e aes  /dev/loop2  /dev/sda1

Or, if you wanted to process the thumb drive as a whole (neither file-based nor partition-based, but device-based loopback)

 losetup -e aes  /dev/loop2  /dev/sda

The thumb drive will then be wholly and exclusively devoted to encrypted data. Whichever proportions you choose, you will be able to read the encrypted portion of your thumb drive on Windows machines that have FreeOTFE installed, and the unencrypted portion on any USB-equipped Windows machine at all.

One issue that must be addressed when using FreeOTFE is ensuring the exact matchup between the way losetup and FreeOTFE apply encryption. FreeOTFE exposes a number of the encryption procedure's detailed technical parameters, allowing and requiring the user to specify their values. losetup employs the same parameters internally but does not expose them to the user. So some guesswork about how losetup did the encrypting may be needed in order to tell FreeOTFE everything it must know to successfully decrypt. (There is ongoing development in the linux community that will eliminate the need to know this detail by recording it in a secure form along with the encrypted data. That is where the decryption software will learn how to conduct the decryption, without need for user intervention.)