- David's Church Information Technology - https://infotech.davidszpunar.com -

TrueCrypt Whole-Disk Encryption: Why I Turned It Off

Last night, I decrypted my laptop. Eleven days ago, I posted about TrueCrypt’s new whole-disk encryption [1]. I encrypted my laptop and started using it. Speed didn’t seem to be an issue (or much of one, maybe it was a little bit slower overall, but that’s just my perception). But it also disabled Hibernation, forcing me to use Standby mode.

The main reason was the lack of hibernation support. I tried using standby, which seemed to work sometimes. I would verify that standby mode had been entered, and put the latpop in my bag. Less than 12 hours later, more often than not, the battery was dead and the laptop was off. Even within shorter time periods, I would sometimes take the laptop out of my bag and it would be running! This is dangerous, as carrying around a laptop when it’s off can be done much less gently than should be done when it’s on. And running in my bag prevents good heat dissipation, so it would be practically burning hot in this case (pun intended :-)

So, now hibernation works again. Which has worked well for me 99% of the time since I purchased the laptop. And it’s not encrypted, but it wasn’t in the past either. If they can make whole-disk encryption work with hibernation, and I’m not enthusiastic about the chances of this given the security implications that I think I understand but probably need to read more carefully, I’ll give it another try.

Note: I’m running Windows XP Pro on my laptop. At some point I may try Vista Ultimate, and may perhaps test Vista’s Bitlocker. I’ve heard it’s more complicated. I don’t know if it allows for hibernation or not. There’s an excellent overview of the two together [2] at 4sysops [3], a blog I highly recommend overall.

UPDATE on March 15th: The problem with hibernation support has been fixed in TrueCrypt’s beta and soon the final release of version 5.1a [4]. I am back to running an encrypted system for now!

19 Comments (Open | Close)

19 Comments To "TrueCrypt Whole-Disk Encryption: Why I Turned It Off"

#1 Comment By Kyle Sagarsee On February 18, 2008 @ 3:12 pm

Bitlocker is the way to go. I’ve never used TrueCrypt, but setting up Bitlocker takes like NO effort. Just turn it on, and save the two files it gives you to a USB key (you can take them off, just keep them somewhere safe that you can get to in case of problems) Encryption takes a few hours, and decryption does as well if it’s needed, but Hibernate works great as it’s the default “shutdown” in Vista.

#2 Comment By Anonymous On February 22, 2008 @ 8:17 pm

If you’re using disk encryption on Windows, you don’t want to do anything other than shut down anyway, when you aren’t using the machine. Anything else will keep the filesystem mounted and the key laying around unencrypted and rely on just the OS for protection of that key and filesystem (and hibernation has the added danger of then writing that unencrypted key to the hard disk). If you’re doing that, it’s nearly the same as not having any disk encryption software at all.

As some folks at Princeton just showed, even if you don’t feel like finding the latest exploit against the locking screen, if the key is in memory you can just do an end run around the OS entirely. Freeze the memory with an upside-down can of compressed air, pop the battery out of the laptop, move the memory to your own machine, boot up your own machine and dump the contents of memory to a disk, then find the encryption key in the memory dump at your leisure.
[5] has a video of the process.

Actually, that video makes BitLocker+TPM sound even more worrying than most, since it will load the key into memory on a cold boot without even needing to ask you for it, so this attack would work even against a machine that you had shutdown and hadn’t used for a month.

#3 Comment By David Szpunar On February 25, 2008 @ 10:10 pm

Interesting comments, Anonymous. Makes sense. I don’t really have time to shut down my laptop and wait for it to boot all the time, but I don’t really keep that much sensitive stuff on my laptop (at least not intentionally). This being the case, why not allow both Standby and Hibernate if both are insecure? Unless I’m making a mistake that would make such an implementation impossible, since hibernation involves writing the contents of memory to (encrypted) disk (so the power can be removed, clearing it), wouldn’t it be safer, especially if (and this is a big if) there was a way to re-prompt for the password before resuming from Hibernation and decrypting the hibernation memory file?

Perhaps that is the problem for TrueCrypt. They may not have a way (yet?) to interrupt the resume from hibernation process to request a password, and therefore cannot resume from an encrypted disk. Which makes sense. But it doesn’t invalidate the fact that leaving the computer on (in Standby or not) exposes the keys in a memory dump, and probably other attacks (why not just use malware to grab the key while the computer is on and the key is in memory?).

Anyway, thanks for the comment (and link) whoever you are! It’s much appreciated!

And thanks for the comments Kyle…I do intend to try Bitlocker at some point, perhaps when my laptop is running Vista. I hear Ultimate has a wizard (which can be obtained for other versions) that makes it easier than it is otherwise. I think I read that on 4sysops in the comments thread of the post I linked to, but I’m not sure.

#4 Comment By Jonathan On February 28, 2008 @ 7:50 am

Check out this episode of the Security Now podcast for info about FREE CompuSec which does support hibernation:
[6]

Also, hibernation support is planned for TrueCrypt
[7]

#5 Comment By David Szpunar On February 28, 2008 @ 10:01 am

Jonathan,

Ironically, I just listened to that episode of Security Now about [8] within the last two days but haven’t had a chance to post about it or try it yet. I actually found Free CompuSec from [9] before hearing about it on SecurityNow, but until SN I didn’t realize that it would do hibernation.

Thanks for the pointer to the TrueCrypt hibernation plans, I wasn’t aware of that. Also, I don’t know what the TrueCrypt overhead is, but Steve Gibson in that episode of Security Now said his tests show a 10% overhead for CompuSec encryption. That may not be too much in the grand scheme of things, but the slowdown with TrueCrypt was noticeable if not terribly annoying.

Good info, thanks!

#6 Comment By Will On March 1, 2008 @ 11:07 pm

Hi,

I’m running both products. I am running TrueCypt on my desktop PC (less than a year old – self built) and CompuSec on my laptop (less than a moth old).

Neither makes my PC any slower. Less than 2% over head compared to Steve’s 10%. Steve only tested defragging times.

I’ve tested not only defragging 4 hard disks (ide and sata) but also HD-DVD encoding/decoding, MP3/AAC/WMA encoding/decoding and also gaming. Less than 2% over head with both products.

And yes CompuSec support hibernation while true crypt will shortly. True Crypt also does not support page files either it seems. Not an issue since both PCs have 2GB of RAM.

The docs on true crypt home page are wrong. You get an error saying the page file can not be created in the event viewer when full hard drive encryption is enabled and using a page file. Page files will be supported soon as well, so it seems.

Also, I don’t seem to have the battery issue you noticed with my laptop. Then again my laptop is not even a month old. That is the battery does not die any quicker than it did without encryption.

And yes I too noticed like Steve some operations are quicker now that True Crypt is installed (seems to cache data more efficiently than default Windows functions).

So yeah besides the hibernation/page file issue for True Crypt, it rocks. And have had no problems with CompuSec. Other than the fact that if you install SP1 for Vista and then install CompuSec it kills Vista. Bad driver issue (yes same issue as to why Microsoft delayed releasing SP1 to the public). And yes my laptop is running Windows Vista RTM. Desktop is running Windows XP SP3 RC2.

Take Care,

Will

#7 Comment By David Szpunar On March 2, 2008 @ 12:51 am

Will,

Thanks for the excellent amount of information in your comment! You clarified several things for me. It’s good to know the overhead is low, 2% really isn’t bad at all. What I most likely noticed, then, was the pagefile issue with TrueCrypt which you mentioned but that I was unaware of. My laptop has 1GB of RAM with XP SP2, and Firefox tends to suck up RAM like a sponge, so I was most likely seeing some speed issues relating to that.

I have yet to try CompuSec myself, but when I get the chance I may throw it on my laptop. My desktop at work is currently unencrypted, but I just put Vista SP1 RTM on it so perhaps CompuSec is not a wise choice there. I’m not particularly worried about encryption (to the same extent) on my desktop, however. Also, the desktop is running three 10k RPM 160GB drives in RAID5, and I don’t want the possibility of encryption drivers interfering with RAID! Of course, the 2% speed penalty would be the most bearable on such a system, as well :-)

Depending on my schedule, TrueCrypt may have hibernation and pagefile support ready by the time I get around to trying CompuSec, but I may end up inspired before that. But I’m also contemplating a Vista test on my laptop over the summer (bad idea while classes are in session, I do my homework on this thing and due dates don’t change just because I’m having Vista issues!). I have no problems with Vista on my desktop after two weeks, including with SP1 RTM, but that’s one machine, brand new (Dell Precision T3400), with a quad-core proc and 4GB of RAM (3GB usable of course, with 32-bit Vista). I’m a bit hesitant with a still recent but slower system (laptop is a Core 2 Duo 2.0 GHz, 1GB RAM, Lenovo 3000 V100).

The only battery issue I’ve had with my laptop is that sometimes it would resume from Standby (when I couldn’t hibernate due to TrueCrypt encryption) and drain the battery while I wasn’t using it. Otherwise I didn’t see any difference in battery one way or the other, but I didn’t take any measurements, either.

Thanks again!

#8 Comment By Joel On March 11, 2008 @ 12:27 am

Just released today: [10], with support for hibernation.

#9 Comment By David Szpunar On March 11, 2008 @ 12:38 am

Thanks for the heads-up, Joel! I knew from listening to [11] (after my above post) that TrueCrypt was working on hibernation support as a top priority, but I had no idea it would come out so fast! Additionally, the release notes at your link mention that they’ve improved AES encryption speed by 30-90% depending on the platform, which is a pretty amazing increase. That and a few other pretty major fixes are quite a feat in such a short time frame. I may have to try it again! Especially given that Steve Gibson’s file defragmentation tests show a double-digit percentage improvement in disk speed when running TrueCrypt vs. no encryption (which is interesting because I felt my system was anecdotally a bit slower while encrypted, but I’m not sure).

#10 Pingback By New TrueCrypt 5.1 Does Hibernation, Kind Of On March 11, 2008 @ 12:03 pm

[…] just released version 5.1, adding support for hibernation (see prior post) to an encrypted system partition (thanks to Joel for letting me know). They’ve also […]

#11 Comment By tut On June 26, 2008 @ 7:33 pm

The next step to an even more secure laptop is to go to multi-factor authentication with something like [12]. This also can protect you from the cold boot attack that someone already mentioned. You can set it so that when you pull the token, it locks all the encrypted volumes — no keys left in the memory to grab.

#12 Comment By sam On July 21, 2008 @ 10:11 pm

Use BitLocker? Trust Microsoft? I thought about it, but I find it really hard to believe that there is not backdoor in there anywhere. I can’t believe that Microsoft would design whole-disk encryption in such a way that even law enforcement and federal officials could not access the data. Nor do I trust them to do it securely, even if there are no intentional backdoors. And it’s closed source, so no one can verify either way…

#13 Comment By Stuart On October 23, 2009 @ 8:37 am

I’ve been using Truecrypt since December 2008 and the version I’m running allows me to hibernate, so I’m guessing the support has been added since this article was written.

#14 Comment By Stuart On October 23, 2009 @ 8:37 am

(addendum: of course with full disk encryption)

#15 Comment By David Szpunar On October 26, 2009 @ 1:17 am

I am currently not aware of any issues, although I haven’t run with whole-disk encryption in a while myself. The newest TrueCrypt release adds full Windows 7 support; I’m contemplating if I want to whole-disk encrypt again :-) But I’m not aware of any current hibernation issues, I believe I got it working properly with a newer release, yes.

#16 Comment By entalzar On March 28, 2010 @ 1:58 pm

The newest TrueCrypt release does not support Windows 7. They admit it as well as they have had many issues with it losing encrypted partitions for no reason. DO NOT USE with Windows 7; least not until they come out with a new revision.

#17 Comment By Keith M On May 16, 2011 @ 4:31 am

I love the first comment: “Bitlocker is the way to go. I’ve never used TrueCrypt.”

Good one Kyle; perfectly balanced opinion.

I’ve personally used both and both were easy enough to set up but over the years I have settled on TrueCrypt; it handles RAID0, RAID1, and is generally very robust.

Oh, and I use it on multiple Windows 7 systems without a single problem ever, so who knows what entalazar is on about.

#18 Comment By Jeff T On August 22, 2011 @ 2:12 am

I’ve used both TrueCrypt and Bitlocker on various systems and I see Bitlock as the winner for the simple fact the unencrypted boot environment is verified by the TPM. Another awesome feature is the ability to require the TPM pin + a USB startup key. Took me a bit to set is up as you’re stuck using the manage-bde utility. If you super parnoid, I managed to use a biometric flash drive (SanDisk Cruzer Profile) to store the startup key. Since it’s capable of doing the fingerprint verification in hardware, you’re able to scan at boottime. So now you need TPM+Pin+USB Key+Fingerprint.
Of course if your computer didn’t come with a Trusted Platform Module, than they’re even. Really just depends on whether you want to enter a password (TC) or use a USB key (BL).

As far as the hibernation issues go, it solved. Microsoft finally provided an API that Truecrypt employs. So no unencrypted keys floating around as some may still think. I still see comments that reference the infamous “coldboot” attack. For starters, I know bitlocker at least can force an overwrite of memory. Regardless, if you simply wait until the computer shuts off, they wait a minute longer. Unless you’re on the arctic tundra, you can be well assured the RAM is unrecoverable at this point. Key point though, remember that standby will, by definition, keep the RAM refreshed. Hibernation writes the contents of RAM to the disk that is encrypted, therefore no issues there.

Last point is regarding backdoors. No I didn’t trace line by line thru MS code, but I am quite sure there are no backdoors. Why am I so confident? 1.) MS gains nothing. 2.) They risk their credibility. 3.) Rememeber that whole anti-trust thing?? Yeah, somehow I doubt MS will be rushing anytime soon to help the gov’t. 4.) There has never been an mandate for encryption makers to add backdoors for govt access. This is the US afterall.

#19 Comment By Keith Miller On August 22, 2011 @ 4:08 am

Here is what TrueCrypt say about TPM, fyi.

Some encryption programs use TPM to prevent attacks. Will TrueCrypt use it too?

No. Those programs use TPM to protect against attacks that require the attacker to have administrator privileges, or physical access to the computer, and the attacker needs you to use the computer after such an access. However, if any of these conditions is met, it is actually impossible to secure the computer (see below) and, therefore, you must stop using it (instead of relying on TPM).

If the attacker has administrator privileges, he can, for example, reset the TPM, capture the content of RAM (containing master keys) or content of files stored on mounted TrueCrypt volumes (decrypted on the fly), which can then be sent to the attacker over the Internet or saved to an unencrypted local drive (from which the attacker might be able to read it later, when he gains physical access to the computer).

If the attacker can physically access the computer hardware (and you use it after such an access), he can, for example, attach a malicious component to it (such as a hardware keystroke logger) that will capture the password, the content of RAM (containing master keys) or content of files stored on mounted TrueCrypt volumes (decrypted on the fly), which can then be sent to the attacker over the Internet or saved to an unencrypted local drive (from which the attacker might be able to read it later, when he gains physical access to the computer again).

The only thing that TPM is almost guaranteed to provide is a false sense of security (even the name itself, “Trusted Platform Module”, is misleading and creates a false sense of security). As for real security, TPM is actually redundant (and implementing redundant features is usually a way to create so-called bloatware). Features like this are sometimes referred to as security theater [6].

~~~~~

For me, I can download and scrutinize the TC code (and I have done this, even compiling it and running it) so I would expect that if I can do this, many people smarter than me have done so and we’d know about any back-doors in TrueCrypt by now.

With respect to M$ backdoors; how would you trace through M$ source? Personally I don’t think M$ would have a back-door either, but you have to admit that you can be less sure about that, than for TrueCrypt.