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).

SpiderOak — Like Dropbox, Except They Don’t Lie to You

I’m not a fan of Dropbox ever since it was clear they had deceived customers. I work on a freelance project where everyone uses Dropbox (after I go them hooked on it), and giving it up for that isn’t really an option. For everything else I was using Dropbox for, however, I long ago removed all of my files off their service.

Instead I’m using SpiderOak. Like Dropbox, SpiderOak is intended as tool to backup files to the cloud and then sync those files with other computers and devices such as smart phones.

What SpiderOak has that Dropbox doesn’t is the option for genuine encryption — my SpiderOak account is set up so that nobody, including SpiderOak employees, can access my files without my password. Dropbox promised users this capability, but it turned out they were not telling the truth and their employees could access user files at any time (or accidentally expose them for a couple hours to the entire Internet as they did earlier this year).

Of course with great power comes great complexity, and this is the major downside to SpiderOak. Dropbox is dead simple to install and use — it took me no time at all to get people who barely understood how to use their computer to install and use Dropbox with no problem. SpiderOak, on the other hand, requires a lot more thinking about what you’re doing.

So in SpiderOak, first you have to create a Backup set (for example, all files in a directory), and then the application backs that up. Then you need to go in and sync the backup, authorizing specific devices and/or specific directories or files. Don’t get me wrong — it is not that SpiderOak is obsessively complex, but rather that it is just not drop dead simple like Dropbox is.

On the other hand, SpiderOak is much cheaper than Dropbox — I’m currently paying $10/month for 100gb of space (and, like Dropbox, there is a free account with a 2gb limit).

The only other thing I’d add is that I think the Dropbox app for Android is crap. the SpiderOak app wasn’t much better until recently, but the latest version does a nice job of letting me pick and choose which files, directories, etc. I want my phone to keep in sync.

Dropbox Lied. End of Story.

For the past couple years, I’ve paid for a 50gb Dropbox account and actively promoted the service among friends and colleagues. Drobpbox has been extremely useful in managing some freelance projects I’m involved in. So when potential security issues surrounding Dropbox emerged back in April, I was concerned about just how private and secure the files I was sharing were.

Since April, there seems to be two basic schools of thought on Dropbox. The first is that Dropbox’s problems are really no big deal. That fact that employees of Dropbox can potentially access files are inherent to any synced system. On the other side are folks who have shut down their Dropbox accounts and forsworn the service forever.

Here’s what I take away from the debacle: Dropbox lied, both to me and to the other folks to whom I recommended their system. When I signed up for Dropbox, the service promised that all of my files were encrypted and that,

Dropbox employees aren’t able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents).

When the security concerns emerged, Dropbox weaseled out of the above promise by clarifying that Dropbox employees are, in fact, able to access user files, but they are typically not granted access to do so. As Dropbox put it in a response to this issue,

In our help article we state that Dropbox employees aren’t able to access user files. This is not an intentionally misleading statement — it is enforced by technical access controls on our backend storage infrastructure as well as strict policy prohibitions. The contents of a file will never be accessed by a Dropbox employee without the user’s permission. We can see, however, why people may have misinterpreted “Dropbox employees aren’t able to access user files” as a statement about how Dropbox uses encryption, so we will change this article to use the clearer “Dropbox employees are prohibited from accessing user files.”

Whether they intended to or not (and it is hard not to see the original statement as intentionally misleading), Dropbox lied about its security model. I and others took those assurances seriously and assumed our files were being encrypted client side.

Regardless of whether this or that feature or security option is a good or bad idea, the fact remains that I simply don’t trust Dropbox anymore. I have better things to do than worry about when/if Dropbox is going to have to release another “sorry, we didn’t mean to mislead you, but …” statement.

I already set my account up so it reverts to the basic free version once the renewal date hits later this summer. I’m moving everything out of Dropbox except for my Keepass file and any other files which are already encrypted, and for working with clients who are going to continue to use the service despite the security risks. I’m currently testing SpiderOak — which is like Dropbox but uses a client-side encryption model — for all my cloud-based file syncing needs.

Colin Percival on Flaws in Jungle Disk’s Security

Colin Percival has an in-depth look at some security issues with Jungle Disk.

A lot of people, including me, have recommended Jungle Disk to people because the cloud-based backup system encrypts your files before it uploads them to Amazon’s S3 service (as opposed to something like Dropbox which encrypts them after the files are uploaded — meaning Dropbox has the key to unencrypt your files if it wants to or is ordered to by a legal authority).

The problem that Percival points out is that they way Jungle Disk handles that client-side encryption is weak to the point where there is a clear path for attackers to follow in either corrupting data stored on the system; replacing data stored on the system; or, ultimately, cracking your password and having free reign.

I used Jungle Disk for a couple years to as a cloud-based backup of my main data hard drive. I used a 20 character passphrase. As Percival notes in a handy chart he provides, a 10 character strong password would take about 95,000 years to crack using current techniques and a $1,000 off-the-shelf laptop. A $10,000 GPU-based password cracking box is going to reduce that to 95 years, and the CIA’s going to be able to put together a system that could rip through that in 2 years. Given that, why not emulate Alfred E. Neuman — what, me worry? But, as Percival writes,

Now, maybe you don’t have any data stored which Joe Cracker would be willing to spend 10 hours decrypting. Maybe you trust Amazon and Rackspace’s internal procedures and security measures to ensure that nobody — either breaking in from outside, or working for those companies — will have access to your “encrypted” data. Depending on who you are and what data you have stored (your credit card numbers? bank statements? how about last year’s income tax return, complete with your national tax ID number?) you might be justified in such trust. But I would say that this is profoundly missing the point: With good cryptography, you wouldn’t need to trust them.

Anyone who doubts the level of computing resources that an individual or small group of people would be willing to throw at a complex problem based entirely on speculation about the value of doing so need only take a look at some of the crazy rigs and setups being built to do nothing but mine Bitcoins. And, of course, the cost of cracking passwords is only declining with every day that passes.

Again, the best solution with cloud backup or sync in general is for the user to encrypt the files before uploading them. Unfortunately, this increases security but at the cost of convenience (and maximizing convenience is apparently why Jungle Disk has these potential issues in the first place).

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.

Cory Doctorow on Real World Key Escrow

This is the story of my life: Cory Doctorow and I have the same problem, only he’s actually sat down and thought of a solution while I was busy wasting my life in World of Warcraft.

Anyway, the problem is encryption. Now, for the most part encryption is a solution. I have terabytes of personal data that I would like to remain personal for now. So if my laptop gets stolen or my house gets broken into and someone makes off with the server, I don’t want my personal data ending up as a Torrent (not that anyone would really care, but still…) So, like Doctorow, I’ve encrypted it all using 128 bit AES and a long-ass passphrase that a) I’ve never written down and b) I’ve never told anyone.

Great, but as my wife has asked me on occasion — what the hell happens when I keel over from a heart attack or suffer an injury where I can no longer remember or communicate the password. How is she supposed to access the data? Hmm…good point.

Doctorow actually worked out a fairly elegant solution, though sadly it does involve lawyers.

Finally, I hit on a simple solution: I’d split the passphrase in two, and give half of it to my wife, and the other half to my parents’ lawyer in Toronto. The lawyer is out of reach of a British court order, and my wife’s half of the passphrase is useless without the lawyer’s half (and she’s out of reach of a Canadian court order). If a situation arises that demands that my lawyer get his half to my wife, he can dictate it over the phone, or encrypt it with her public key and email it to her, or just fly to London and give it to her.

As simple as this solution is, it leaves a few loose ends: first, what does my wife do to safeguard her half of the key should she perish with me? The answer is to entrust it to a second attorney in the UK (I can return the favour by sending her key to my lawyer in Toronto). Next, how do I transmit the key to the lawyer? I’ve opted for a written sheet of instructions, including the key, that I will print on my next visit to Canada and physically deliver to the lawyer.

A related issue that Doctorow raises in passing is how we ensure our heirs take care of what we leave behind digitally. As an author, Doctorow raises the issue of a future descendant who intentionally tries to sabotage is literary legacy. With me a bigger risk is the wife deleting my words of wisdom for the ages when she stumbles across the pron collection.

The Problem with ‘Encrypted’ Drives

Aluratek Tornado Plus

If you look through any computer magazine, typically you’ll find a half dozen or so advertisements for “encrypted” hard drives . . . typically Flash drives or portable 2.5″ hard drives that promise they’ve got some sort of hardware-based encryption baked in. What could be better than that for hiding your data from prying eyes?

Well, as Tom Olzak points out over at Tech Republic, too often these hard drives don’t really offer much in the way of encryption at all and, more importantly, reviews of such drives don’t tend to get into the nuts and bolts of just how the hard drive is being encrypted and just how likely it is for someone in possession of the drive to successfully attack the encryption scheme.

Olzak is specifically writing about the Aluratek Tornado Plus Drive which is a portable 2.5″ hard drive that advertises itself as having hardware encryption. The Tornado Plus’s hook is that it also has a portable RFID key fob — simply pass the key near the drive and the key fob passes along the key to the hard drive and your data is unencrypted.

Olazak read about the drive and decided to call Aluratek for more information on the encryption scheme,

My first discussion was with a sales guy. I asked about the encryption method. He didn’t know. I asked about how the key was protected. Again, no idea. I began to suspect that this was not the person I needed to speak with, and I asked for a “technical” person. After a short wait, another sales guy got on the phone. He knew a little more. For example, the encryption method is to XOR the key with the data. Those of you in the security profession know my reaction to this news. For those of you still coming up to speed, XORing a key with data to encrypt sensitive information is bad. Very bad.

Although disappointed, I had enough interest left to ask about key management. The new sales guy had no idea. I was transferred to an “engineer.” I should have known after having to explain to the engineer (we’ll call him Anthony) why I thought key protection is important that I was still not speaking with someone with a good grasp of disk encryption. However, he didn’t believe the key was encrypted on the RFID chip nor that the transmission of the key to the drive was protected. In other words, anyone with the key fob could access the encryption key. Also, the right equipment in the right place could intercept the key as it’s transmitted to the drive.

Moreover, as Olzak notes, just by making that call he’s done far more than many of the computer journalists or bloggers who have written “glowing reports” about the release of the Tornado Plus.

Serious Google Calendar Encryption with GnuPGP

IBM’s Nathan Harrington has written an article outlining how to use the GnuPGP Firefox extension to create encrypted events within Google Calendar. This isn’t just accessing Google Calendar securely, but rather encrypting event details locally before passing that text on to Google Calendar. Anyone who compromises your Google account then would know the time of events, but would only see encrypted text for the actual event detail as in the example below,

That is frackin’ awesome. Now if there were only a GnuPGP plugin for my Blackberry calendar so I could sync the events meaningfully.

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.