TrueCrypt® is a multi-platform on-the-fly drive encryption tool. It allows you to encrypt all your data in a filesystem and still use everything normally. On Windows, it supports encrypting the system (boot) partition (or the entire boot drive); you can even make TrueCrypt® encrypt your existing partitions live and continue working (though the I/O performance sucks until it’s finished encrypting everything), pause and resume the encryption process (even across reboots). In short: it’s rather useful.
Even though TrueCrypt® introduced Windows system encryption in version 5.0 in February 2008 (that’s five months ago), its Linux version still doesn’t support accessing these encrypted partitions at all (it does mount “normal” TrueCrypt® volumes though). Since I recently encrypted my entire Windows drive but couldn’t live without the music files stored on it, I now humbly present the result of two wasted nights: a solution.
This just in!
A letter from the friendly folks over at truecrypt.org (®?) notified me that they don’t like my using their trademark TrueCrypt® in the name of my tool. To help avoid uncomfortable situations, I would like to point out to everybody that this tool is called dmsetup-tc and not dmsetup-TrueCrypt®.
To demonstrate that I take trademarks very seriously, I have taken great care in this article to give the trademark all the attention it undoubtedly deserves.
Before you join the fun…
I’d love to take a dive into technical details now but you’ll probably go away before I even get myself warmed up properly, so I’ll try and appease myself by mentioning that I learned lots of new things, including the gory details of XTS and PKCS#5/PBKDF2. Oh, and I first tried patching this stuff into TrueCrypt® but failed mainly due to two reasons: first, TrueCrypt® is written in C++ and it shows in the architecture; second, C++ itself. When I had everything but the correct initialization of the XTS tweak working, I gave up and started writing a separate tool. The positive side: it compiles in about a second and is snappier than TrueCrypt® when it runs, too (and it doesn’t do whatever weird things TrueCrypt® does with FUSE).
Oh, right, I wanted to keep the details out of this. Sorry.
What you need
- A computer with a little-endian architecture (rule of thumb: if Windows runs on it, you’re fine). Support for big-endian architectures will be added if someone else writes a patch. ;)
- A Windows sytem partition or drive that has been encrypted (completely; partial encryption is absolutely not supported) with TrueCrypt®. Normal TrueCrypt® partitions are not supported; after all, TrueCrypt® for Linux works fine for them.
- A Linux system that you want to access the partition(s) from.
- libgcrypt (tested with version 1.2.4) and its development files.
- GNU make.
- A C compiler (tested with GCC 4.2.3).
- Optionally, experience with C and so on if you want to track down (and fix) bugs or add features.
Install it
- Download the source code: dmsetup-tc-0.2.tar.bz2.
- Extract it somewhere.
- Run make. You know the drill.
- Put the resulting binary wherever you like.
Use it
Now, suppose you’ve got an encrypted system drive on /dev/sda and you want to mount the partition /dev/sda1. Then you just do the following (as root):
.../dmsetup-tc /dev/sda /dev/sda1 | dmsetup create win1
This will create a DM device /dev/mapper/win1. You can now mount it. Assuming it’s got an NTFS filesystem (and you actually have a mountpoint called /media/win1):
mount -t ntfs-3g -o uid=(your numeric uid),umask=077 /dev/mapper/win1 /media/win1
There, all done. After umounting, remember to remove the DM device so that even root can’t get at your data anymore:
dmsetup remove win1
Important: don’t use dmsetup-tc on its own; always pipe its output directly into dmsetup! It outputs your volume master keys. You don’t want anybody to get a hold of those. There is a certain security risk to piping the data, too (it might get paged out and end up in your swap, which is problematic if you don’t use encrypted swap; additionally, the data from the pipe might reside somewhere in your physical memory for some time, possibly allowing root to read the master key even after you have removed the DM device). You have been warned.
Contribute
I’m developing the tool in a Git repository and you can join in! See the repository page for details.
You can also contribute by sending me feedback, but my capacity for actively adding new features to this tool is very limited.
In either case, thank you very much!
make
gcc -O3 -c main.c
In file included from main.c:43:
pkcs5.h:4:20: error: gcrypt.h: No such file or directory
In file included from main.c:43:
pkcs5.h:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘gcry_pbkdf2’
main.c: In function ‘crypt_init’:
main.c:181: error: ‘GCRYCTL_INIT_SECMEM’ undeclared (first use in this function)
main.c:181: error: (Each undeclared identifier is reported only once
main.c:181: error: for each function it appears in.)
main.c: In function ‘crypt_derive_key’:
main.c:192: error: ‘GCRY_MD_RMD160’ undeclared (first use in this function)
make: *** [main.o] Error 1
Cchild, you need the libgcrypt header files and so on to be able to compile it. In Debian and Ubuntu that’s the libgcrypt11-dev package.
Got it working–needed libgcrypt. But still having trouble creating a mapper device and mounting it.
Thanks
I mistakenly override the truecrypt boot-loader and the rescue disc to my foolishness is an image file located in my documents directory in windows, the drive that is fully encrypted.
This is a bit inconvenient as a chat system, isn’t it? ;)
If it dies without an error message or anything like that, it may be helpful to compile it differently: change the CFLAGS line in Makefile to CFLAGS = -O3 -DDEBUG and re-run make.
If something doesn’t work right, you’ll need to be a bit more specific.
Things may be salvagable with dmsetup-tc IFF you didn’t overwrite too much. The volume header resides in sector #62; dmsetup-tc should be able to mount the partition if that is still untouched.
# ./dmsetup-tc /dev/sda /dev/sda1 | dmsetup create foobar
Enter passphrase for encrypted volume:
dmsetup-tc: fatal error: Success
The above means it works correct–at least creating the mapper device?
No, that means something doesn’t work correctly but my error handling isn’t good enough to properly tell you what it was (sorry). Please send me an e-mail or subscribe to the blog feed to hear about updates. I’ll have another look at it tomorrow or so.
In the meantime, you can do the -DDEBUG recompile I suggested above to get a bit more information about where it fails.
PS. the name of the tool needed to be changed due to trademark issues; I have taken the liberty to slightly edit your comment to reflect this.
I noticed the post on the forum was removed–and I figured it was probably due to naming.
It looks as if I may have to reinstall windows–the only other rescue disk I have is for another system. I used it to restore the truecrypt boot-loader, but it won’t accept my password. I will subscribe to your blog and maybe shoot you an email.
Bad news, I think: using another rescue disk to restore the bootloader trashes the volume master keys (every rescue disk has a copy of the volume-specific encrypted header, so using the wrong rescue disk restores the wrong header and the wrong keys).
I think you’re *really* screwed now. If so, you have my sympathy.
So in other words, I must reinstall the OS?
I’m not a certified expert or anything but yes, that’s what it looks like to me.
Reinstall should not be a problem–My data is backed up. I may hay a handful files in my Windows home directory that I will lose.
This is how it happened. I was upgrading (clean install) from openSUSE 10.3 to openSUSE 11.0 and forgot one crucial check–I forgot to tell the boot-loader not to allow writing mbr to disk–since grub currently does not support truecrypt boot-loader.
Attempted to use dmsetup-tc on Ubuntu Hardy Heron.
Drive structure:
hda: TrueCrypt MBR
hda1: TrueCrypt system encrypted Windows XP (fully encrypted)
hda2: GRUB bootloader (chainloads hda1 if pwd supplied at TrueCrypt MBR; also boots Ubuntu)
Ubuntu 8.04 Hardy Heron
hda3: swap
Compiled with: CFLAGS = -O3 -DDEBUG
Tried to do:
# dmsetup-tc /dev/hda /dev/hda1 | dmsetup create hda1
Enter passphrase for encrypted volume:
Loading header from /dev/hda…
Deriving header key…
Decrypting header…
dmsetup-tc: fatal error: Success
#
/dev/mapper/hda1 is created, but I cannot mount it.
To get a clue, I tried redirecting the output of dmsetup-tc to a file: out.txt.
The file is empty after running the command.
I tried permutations of my passphrase, with same result. (Inspecting the main.c file, I think I’d have gotten a little further feedback if the command was working, but I had entered a bogus passphrase.)
I’ve verified after these attempts that I can successfully restart, enter my passphrase at the TrueCrypt MBR prompt, and boot into Windows XP.
Using TrueCrypt 6.0a on hda1.
Any suggestions where I might be going wrong?
[...] Creative Engineering « How to use TrueCrypt®-encrypted Windows system drives on Linux [...]
Thanks a lot for the program Jan. Unfortunately, it doesn’t work for me (on a Gentoo Linux system already using DM-Crypt + Luks for Linux system encryption). I actually think your program is fine only when the output is piped to dmsetup that one fails and replies that the device or resource is busy. Can’t figure out what it is, any ideas ? The system layout is Windows system encryption on hda1 (not the entire hard drive, only on that one), plus 2 more partitions encrypted using DM-Crypt + Luks. Maybe it interferes somehow ? Or I got the parameters wrong, why do I have to give the partition and on top of it the disk device ? Can’t that be deduced ? Or is it because your program needs something from the MBR which might be somewhere else ? Thanks a lot. ;)
For reference, here’s a rough summary of the reply I sent to J.C.’s comment: 1) check the syslog (including dmesg logfile) for relevant information. 2) I vaguely recall that at some point, the loop driver was unable to support multiple loop devices unless compiled as a module.
[...] public links >> truecrypt How to use TrueCrypt-encrypted Windows system drives on Linux Saved by jannideath on Wed 05-11-2008 Useful Software - Truecrypt Saved by omifan92 on Sun [...]
Ok, my problem is fixed, and has been for some time. I am really sorry, for not reporting back, but I totally forgot about the question I posted here. Thanks a lot for your mail Jan, but since it is not my regular e-mail I only found it now and was reminded of this.
Here is the solution, it was very simple: My kernel was simply lacking XTS crypto support, even though the error message given by dmsetup did not give any indication of that at all. You might wanna mention that in the program requirements, though. My current kernel (2.6.25) still has XTS marked as Experimental, but my previous one (.23) didn’t have it at all. So, I guess I am not the only one out there that need to do a kernel update for that. For completeness sake, my system has both the regular loopback device as well as the device mapper crypto target (not the crypto-loop device) coded into the kernel and this works just fine with multiple encrypted volumes. Adding an abitrary number in form of encrypted USB disks seems to work, too. So, I guess there is no limitation.
Once again I wanna thank Jan for this wonderful tool. I have it running on two computers now, without any problems, and I still keep using it in spite of the new TrueCrypt version claiming to offer the same functionality. I just like the slickness with which it perfectly integrates into my automount scripts. Contrary to this, I HAVE to use the official TC for my non-System windows drives and the way it messes up my mtab with those weird fuse mounts is just bad and not pretty at all.
Finally, Jan’s program came in very handy when I was struggling to understand the TC Volume Specification, in order to make a low-level backup of all my MBRs, partition tables and crypto headers. Btw, I recommend doing that to everyone, in DMCrypt+Luks the single availability of the header is the single point of failure and TC only has the backup burned to the Rescue CD (apparently, there is no backup volume header on the driver for system encrypted drives).