USB sticks become increasingly common to carry around. When one keeps confidential data on such an USB medium, it should be protected against loss (and it should also be possible to use it for transferring files to and from an untrusted machine, just for convenience). An encrypted container that is usable under Windows XP, (Vista, ) Windows 7, and Linux as a virtual drive is a good way to do that. There are many uses for such a container, I use it to carry high-resolution scans of my most important documents with me on my USB stick, so that a potential loss/theft of my physical passport will not leave me stuck somewhere abroad. Any Windows XP or recent Linux machine should be enough to access those data. Am I worried about identity theft when I lose my USB stick or when somebody copies the container file when I lend them my USB stick? No, I am not that paranoid - if somebody wants to try to brute-force the AES-256 encryption, then be it….
One central requirement for such an encrypted volume is of course that
it is secure; therefore, the old ZIP file encryption and other weak
methods should not be used. But fortunately, an encrypted volume that
can be mounted as a virtual drive can be accomplished in a
cross-platform manner with open source software.
Under Linux, LUKS is, at the time of this writing, one of the best options for creating secure containers. This works very much like I described it for encrypted home directories, and creating such a volume (with 20MB for this example) is simple:
- dd if=/dev/urandom of=/tmp/container.bin bs=1024 count=20000
- sudo losetup /dev/loop2 /tmp/container.bin
- sudo cryptsetup -c aes -s 256 –verify-passphrase luksFormat /dev/loop2
- sudo cryptsetup luksOpen /dev/loop2 container
- sudo mkdosfs /dev/mapper/container
- sudo mount /dev/mapper/container /mnt/ (optional, just to verify that mounting works)
- sudo umount /mnt/ (optional)
- sudo cryptsetup luksClose container
- sudo losetup -d /dev/loop2
Here I assume that /dev/loop2 is a free loopback device. The next free
one can be found with losetup -f. Of course, if you are logged in as
root (which is not recommended), sudo will not be needed - I have added
it to the above list to illustrate where root privileges are required.
The only catch is that only “-c aes” is supported by FreeOTFE (under
Windows) at the moment, but that the more secure ESSIV is not (yet).
After the above steps have been executed, /tmp/container.bin can be copied to any location, e.g. to a USB stick. For mounting and using it, I have written a small shell script that takes care of the necessary steps. It will find the next free loopback device and figure out the location of the container.bin file automatically as long as the shell script is kept in the same directory. After mounting the encrypted container to a temporary directory (and obviously asking for the necessary passphrase in that process), it will wait for a key press and the unmount it again. Therefore, it should be kept running as long as the encrypted container is accessed, and then a key should be pressed to let the script perform the unmount. Here is an example:
rene@styx:/tmp$ sh /media/sda1/documents/mountit.sh Not executed as root, re-executing myself with sudo.... Enter LUKS passphrase: key slot 0 unlocked. ------------------------------------------- Encrypted container mounted at /tmp/tmp.6oBzy6 Press any key to unmount ------------------------------------------- done
In this case, I explicitly call a shell to execute the script, because my USB stick is (by default, as described here) mounted with noexec, preventing the direct execution of the script.
Windows XP / Windows 7
Under Windows XP, (Vista, ) and Windows 7, the fabulous tool
FreeOTFE provides virtual drives for
encrypted containers and is, in recent versions, compatible with the
LUKS container format that was created by the above steps under Linux.
In its “portable mode”, it does not require any installation at all, but
can be used directly from the USB stick to access the encrypted
container. I use it in conjunction with
SecureTrayUtil, but this is
not strictly necessary.
It is sufficient to just extract the FreeOTFE archive to the portable medium and execute the freeotfe.exe file. Then select “Tools” - “Use portable mode drivers” to temporarily install the virtual file system drivers (administrator privileges necessary) and “File” - “Linux volume”
- “Mount file” to open the container. Attention: Just using “File” - “Mount file” will not work, you need to use “Linux volume” (yes, it is obvious after blindly trying the icon for opening a file for half an hour….).
Loading the drivers on Windows 7
Windows Vista and Windows 7, especially for the 64 Bit versions, enforce driver signing. That is, FreeOTFE can no longer load its own drivers, which are not signed by Microsoft at this time. The simple fix is to enable “test signing” mode under Windows 7 to enable loading unsigned drivers. This is documented widely and requires using the bcdedit tool in an administrative shell. However, I kept getting this error, whose solution is certainly not as widely documented:
C:\Windows\system32>bcdedit.exe -set TESTSIGNING ON The boot configuration data store could not be opened. The system cannot find the file specified.
The reason seems to be that my systems are typically dual-boot, running Linux (>95% of their time) and Windows (currently Windows 7 64 Bit, <5 of their time). bcdedit then (for some reason I don’t know) needs another parameter to find the location of its BCD data:
C:\Windows\system32>bcdedit.exe /store c:\boot\bcd /set TESTSIGNING ON The operation completed successfully.