DiskCryptor – Open Source Whole Disk Encryption for Windows

Bruce Sterling has said he’s been using Symantec’s Endpoint Encryption software for full disk encryption ever since the demise of TrueCrypt. I used Symantec’s product — which is really just a commercialization of PGP — many years ago before TrueCrypt became so popular. It worked well and I’m sure it is still a great solution IF you can afford the $85/workstation license.

So instead, I’ve been using the open source DiskCryptor for all of my whole disk encryption needs for Windows.So far I haven’t had any issues with it and from what I can tell it is a least as secure as TrueCrypt was (i.e., it’s likely to stymie local cops, but state actors have many ways to obtain passphrases if they want to devote sufficient resources — not sure they’re likely to do so for my porn collection, however).




Is Full Disk Encryption Too Good?

This paper by four security researchers on the effects of whole disk encryption on forensic investigations garnered a lot of press after it suggested that the increasing use of full disk encryption tools is hampering some investigations. According the paper’s abstract (emphasis added),

The increasing use of full disk encryption (FDE) can significantly hamper digital investigations, potentially preventing access to all digital evidence in a case. The practice of shutting down an evidential computer is not an acceptable technique when dealing with FDE or even volume encryption because it may result in all data on the device being rendered inaccessible for forensic examination. To address this challenge, there is a pressing need for more effective on-scene capabilities to detect and preserve encryption prior to pulling the plug. In addition, to give digital investigators the best chance of obtaining decrypted data in the field, prosecutors need to prepare search warrants with FDE in mind. This paper describes how FDE has hampered past investigations, and how circumventing FDE has benefited certain cases. This paper goes on to provide guidance for gathering items at the crime scene that may be useful for accessing encrypted data, and for performing on-scene forensic acquisitions of live computer systems. These measures increase the chances of acquiring digital evidence in an unencrypted state or capturing an encryption key or passphrase. Some implications for drafting and executing search warrants to dealing with FDE are discussed.

The sentences I added emphasis to are interesting. Once a laptop or computer that has been encrypted with FDE is shut off, gaining access to the data is going to be extremely difficult unless the password/passphrase used is very weak or easily guessable, or if the owner can be persuaded, compelled or tricked into surrendering it. On the other hand, if the machine is left on when investigators arrive, there are a number of ways to recover the key, including using a cold boot attack where the RAM is preserved and copied in an effort to recover the key.

So if your computer is likely to be the focus of one of these attacks, ideally there needs to be a way to shut it down as quickly as possible, ideally one that doesn’t require user intervention.

Toni Korpela offers an interesting solution for quickly and automatically shutting down a computer that you still have physical access to without appearing to be shutting it down. He has written a script for his Fedora laptop that executes at user logon,

When the script is executed it starts looping a check where it checks first if my SD-Card is mounted at /media/DATA/ then it checks if file /media/DATA/.key exists if the key exists then it opens it and reads the contents and compares the “password” stored in the file to another hash stored in the hard drive. If any of these steps fail the system will initiate the Linux shutdown command. If everything passes the script will make the loop sleep few seconds to lessen CPU usage. Thought he sleep is not enough long to do much anything on the PC if the SD-Card is not mounted.

Very clever.

I’m not sure that the silly three letter agencies have much to worry about, however, as most people I know a) don’t see any value in full disk encryption, and b) if they did would likely used incredibly weak/easily guessable passwords.

I’d also think that unless there were an imminent risk of some violent action by the subject of such an investigation, that there are several fairly easy ways to grab the key, from installing a keylogger on the system by modifying the bootloader, to installation of a camera or other recording device to physically record the keys being press on bootup. Full disk encryption certainly raises the costs for any attacker to access information on an encrypted disk, but it by no means render such access impossible.

(With that said, I use full disk encryption on every disk I use, with an extremely long passphrase that I’ve never shared with anyone).

TrueCrypt 7.0

In July, TrueCrypt 7.0 was released which includes hardware acceleration for AES, assuming you have one of the supported Intel processors, and support for automatic mounting of encrypted volumes,

A volume can now be configured to be automatically mounted whenever its host device gets connected to the computer (provided that the correct password and/or keyfiles are supplied).  (Windows)

Note: For example, if you have a TrueCrypt container on a USB flash drive and you want to configure TrueCrypt to mount it automatically whenever you insert the USB flash drive into the USB port, follow these steps: 1. Mount the volume. 2. Right-click the mounted volume in the drive list in the main TrueCrypt window and select ‘Add to Favorites‘. 3. The Favorites Organizer window should appear. In it, enable the option ‘Mount selected volume when its host device gets connected‘ and click OK.

Also note that TrueCrypt will not prompt you for a password if you have enabled caching of the pre-boot authentication password (Settings > ‘System Encryption‘) and the volume uses the same password as the system partition/drive. The same applies to cached non-system volume passwords.

That is very cool. I use TrueCrypt for WDE on all of my laptops, and then also encrypt any Flash drives or external USB hard drives using the same passphrase I use on the WDE drives. I assume (though am not an expert on cryptography so I could be wrong) that this probably increases the risk that someone could guess or compromise my passphrase. On the other hand, I’m just trying to protect myself against snoopy passers-by and the worst case scenario where a drive or laptop is lost or stolen. I’m prepared to concede the NSA is probably going to pwn my drives if they really want to.

Enabling pre-boot authentication and then auto mounting drives that use that passphrase is a nice addition to the system.

TrueCrypt Deniable File System Broken

The other day, Bruce Schneier had some post about securing data for border crossings and in the comments someone asked why not just use TrueCrypt’s deniable file system, which in TrueCrypt’s implementation hides an encrypted file system within a TrueCrypt encrypted volume. Schneier responded that he didn’t trust TrueCrypt’s deniable file system, and today he reveals why — he and several other researchers are publishing a paper announcing they were able to break that particular feature of TrueCrypt.

ABSTRACT: We examine the security requirements for creating a Deniable File System (DFS), and the efficacy with which the TrueCrypt disk-encryption software meets those requirements. We find that the Windows Vista operating system itself, Microsoft Word, and Google Desktop all compromise the deniability of a TrueCrypt DFS. While staged in the context of TrueCrypt, our research highlights several fundamental challenges to the creation and use of any DFS: even when the file system may be deniable in the pure, mathematical sense, we find that the environment surrounding that file system can undermine its deniability, as well as its contents. Finally, we suggest approaches for overcoming these challenges on modern operating systems like Windows.

TrueCrypt has apparently addressed many of the specific issues raised by the paper in their 6.0 release, but Schneier’s claim is that there are inherent problems to creating a deniable file system so even though the techniques outlined in the paper will not work against TrueCrypt 6.0, even the deniable file system there should be treated as untrusted. Better to go with whole disk encryption, which loses the deniability but is more secure.

The entire paper is avaialble as a PDF download.