- Research Notes
- Open Source
- SSD Linux benchmarks
- Git cheat sheet
- Home directory version control
- Austrian "Buergerkarte" under Linux
- Debian on a Thinkpad T42p
- (K)Ubuntu on a Dell Latitude XT
- Debian on a Gericom Phantom
- Encrypted home directories
- Automounting with hotplug
- Aladdin eToken under Linux
- Encrypted container under Linux and Windows
- SpeedTouch 330 ADSL USB modem with kernel 2.4
- Combining an open WLAN hotspot with private IPsec
- How to make a USB stick bootable
- Encrypted suspend-to-disk with Debian
- Import old emails into a Cyrus spool
- IPsec/L2TP gateway for Android and iPhone
- Nokia N900 synchronization with Egroupware
- Suspend and wakeup under Linux
- Android applications
- Debian Root CAs for KDE4
Howto use an encrypted container under Windows XP/7 and Linux
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
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.