Using Loopback-Encrypted Filesystems on JumpDrives
by OSIN
This article is to teach you how to use the Loopback Encrypted filesystem in a way in which it was probably not intended to be used.
I won't be teaching you how to set it up though, because that requires you to rebuild the Linux kernel, and that in itself would take several pages to explain. I encourage everyone to review the how-to located at www.faqs.org/docs/Linux-HOWTO/Loopback-Encrypted-Filesystem-HOWTO.html. You should also probably review the how-to on rebuilding the Linux kernel at www.digitalhermit.com/~kwan/kernel.html.
I have my own instructions on how to build the kernel to use Loop-AES, but they are not up to date. However, if anyone out there would like to read them, they can go to uk.geocities.com/osin1941/encryptfs.html, assuming Yahoo! doesn't kill that account. And while you're there, check out my projects.
Anyway, I think one of the best developments in modern technology is the advent of those JumpDrive storage devices that you can find just about anywhere. And the prices have fallen to the point that any kid can afford them. No longer does one have to store their most sensitive information on the hard drive of their computer or laptop which might get stolen. They also are handy in wardriving scenarios, but I in no way condone illegal enterprises. Oh, and I almost forgot, you can format these drives as swap in case your laptop has limited drive space.
The JumpDrives are pretty much well supported under the Linux kernel. I've rarely had trouble getting them to work. Normally, when you plug them into the USB port, you can mount them under the /mnt section by issuing a mount command. But first, you must create a mount point, and for the purposes of this article I will use: /mnt/jumpdrive
So, to mount the drive after you plug it in, you would use this command:
Those of you who are using SCSI hard drives or have a drive array setup may have to use /dev/sdb1, /dev/sdc1, /dev/sdd1, etc. in order for this to work.
Assuming the mount worked, you have several options. One is to reformat the drive as an EXT3 filesystem, or to leave it as a stinking VFAT version that one normally finds on these things. I leave that as an exercise to the reader since formatting filesystems is not really the subject of this article.
O.K., so what does this have to do with encrypted filesystems?
Using the Loop-AES method, you can build what is essentially an encrypted file system on these JumpDrives. The filesystem is actually an encrypted file itself which holds the data that you would normally have moved into some directory. You mount this file like you would any other partition under the Linux kernel. So, the first thing we must do is to create the file which will be used as the filesystem. Now you do have the option to use the entire JumpDrive as your encrypted file system, which is normally what I do, but for the purposes of this article I will only be creating a filesystem of size 2 MB. You'll understand later.
Assuming you are now booted into the Loop-AES version of your Linux kernel and you have successfully mounted the JumpDrive, you start by creating the encrypted filesystem by issuing this command:
This will create a file called "encrypt" about the size of 2 MB.
Now, we must build an EXT3 filesystem going through the loopback device. For the purposes of this article I will be using /dev/loop0. You can use any of the "loop" versions under the /dev directory.
Before we build the EXT3 filesystem, we must first use the new version of losetup that was created when you rebuilt the Linux encrypted kernel.
You do that by issuing this command:
At this point, you will be prompted to enter a password that is at least 20 characters long.
Don't forget this password, otherwise you won't be able to mount the encrypted filesystem. I normally use a phrase from books or TV shows. So, now you must make the EXT3 filesystem on the loopback device:
At this point you can mount this filesystem, but first you must create a mount point for it. For the purposes of this article, I will use: /mnt/jumpdrive2
Issue these two commands:
Issue a df -k command and you should see both the physical JumpDrive and the encrypted filesystem mount points. You can now begin to move files into the /mnt/jumpdrive2 mount.
If you are following along with this article while working on your computer, go ahead and fill up the encrypted filesystem with text files and images. You'll understand why as we enter The Twilight Zone.
For now, go ahead and unmount the encrypted filesystem after you've filled it up.
Issue a umount /mnt/jumpdrive2 command followed by losetup -d /dev/loop0 command.
From now on, anytime you want to get back into your encrypted filesystem, mount your physical JumpDrive first, then issue this command (all on one line):
At that point you will be prompted for the 20+ character password you set originally for this file.
The Twilight Zone
I know I'm probably dating myself, but there was a time when computer programs were punch cards and storage devices were cassette tapes.
The early days of computers didn't leave much for storage. As time progressed, there became a need to break up binary files into pieces so that they could be stored on multiple floppies. So the split command on Linux-like systems has probably not seen a lot of use in the past few years. I think that should change. What's old is now new again.
So, could the encrypted file we built be split into say, three pieces and reconstituted? The answer is yes it can.
Before we delve into this, if your encrypted filesystem is currently mounted, go ahead and unmount it so that it is back in its encrypted form. That command is umount /mnt/jumpdrive2 in this case.
Back up your current encrypt file for now. You can call it something like encrypt.back. Make sure you are in the /mnt/jumpdrive directory where your encrypted file should be located if you followed the instructions above.
Now you are going to issue the split command to break up your encrypted binary file into three pieces:
After running that command, do ls in the /mnt/jumpdrive directory and you should see three new files called xaa, xab, and xac.
These are the split sections of your encrypted filesystem. I chose to just use three pieces which is why I picked 750k as a size to split out this file. To create more pieces, just use a lower number.
So now, let's reassemble the pieces.
First, delete the encrypt file we created earlier. Now, we are going to use cat to reassemble the encrypt file.
Run this command:
Now try to remount it with this command (all on one line):
Enter your password.
Your encrypted filesystem should still be intact and you should be able to cd into it and see any files you put there. But here's a thought...
What would happen if you mounted just the first piece of your encrypt file?
Unmount the /mnt/jumpdrive2 directory, then run this command (all on one line):
Hmm... It worked.
The odd thing is that when you do the ls command within the jumpdrive2 directory, you see your files listed there.
Now, if you followed my directions, try to vi one of those text files I asked you to store in jumpdrive2.
Now try to view one of the images. You shouldn't be able to, at least, I was not able to get to the data.
I found that if you cat xab >> xab together and mount that you will get to some of the files, but not others.
If you noticed when you did the df -k earlier, the filesystem we created before any files were put into it was already around 55% full. This is probably journaling system information in my case, since I am using a Red Hat distribution. This would explain why mounting xaa alone (it was only around 750k) would yield no information, but mounting a second piece with xaa yields more information.
The point is the larger your encrypted file system and the more pieces you have, you could conceivably reveal more information than you would like if your password were discovered or the encryption cracked. But why would we want to split the encrypted file system up in the first place? Follow me, as I wish us deeper into the cornfield.
In The Cornfield
Let's say you are someone with information that once used to be legal, but now is illegal.
And let's say a repressive entity such as Iran, North Korea, or the U.S. Secret Service (shouts out to the SS!) want to find that information. Wouldn't it be handy if you could store those chunks of your encrypted filesystem in other places? Perhaps three other external countries? Ah, but wait! Some servers may scour binaries if they find them in users' directories. Wouldn't it be nice if there was a way to store these pieces out on the web? Well, there is.
Years ago, a lot of images would be Base64-encoded when the web was young and the newsgroups were wild.
There is an old program that has been around for a while called uuencode. It also has a partner called uudecode. What uuencode does for you is essentially encode your binaries as Base64. This was a handy program that allowed attachments to be sent via email. But now, you can use that same program to convert your encrypted pieces to Base64 characters in a flat text file.
To do that, you would need to run commands similar to this:
For some reason, I had to use the above commands to get it to work, even though the man page for uuencode hints that the command structure is different.
Damned Red Hat... Anyway, refer to your distribution's man page for uuencode. You also might want to edit one of those files just so that you can get a feel for how the file is structured. That format (the first and last lines) is critical if you are going to reassemble the sections later. Also, keep in mind that these files are going to be larger than their binary counterparts.
Now that you have your HTML files, they can be put anywhere that you have web space, provided you have accounts. Note that you don't have to call your files xaa.html, xab.html, etc.
I just used those names as examples, but just don't name them index.html and don't link to them from another webpage. Also, you must remember the order in which the files go, so don't forget that. In order to decode those files, you could use GNU Wget going through the Tor system (you did read my article in 22:3, didn't you?) to retrieve them.
Then, to convert them back into binary, you would run something like this:
After that, all you need to do is cat the three binary files, xaa, xab, and xac back into your complete encrypted file, then run the mount command as we did in the above examples.
One word of warning though.
If you use free websites like GeoCities to store your files, you will have to edit the HTML files before you run the uudecode command. That is because GeoCities inserts HTML code at the bottom when a call is made to that HTML file. Edit the file carefully and keep in mind the format is critical. I hope this helps spur some thought for you.
You may now leave my cornfield. >:)