Truecrypt versus built-in SSD encryption

Thanks all for the thoughtful discussion!

Yes, it's not funny to lose everything and I agree that people need to get the message: read the manual, or don't use the software. I long for the day when computers are like TVs: you buy it, plug it in, turn it on, and use it -- no support necessary.

I did read the TrueCrypt manual when I first installed it, and the sections on hidden volumes made me not want to risk using them.

Agreed, and that's about my only concern with trusting TC. But then if there were a black market for TC-encrypted data because someone up the chain could access a back door, I don't think that kind of activity could remain unheard of for long.

To me, that's a critical point (the potential for lost data) moreso than plausible deniability. I don't use system encryption or hidden volumes, so it's a non-issue. My other critical point is performance.

But I also realized that one other deciding factor for me is portability of data. With a TC-encrypted drive I can take it to any other PC (and other OSes) and mount the volume without any extra hassle; with hardware encryption, it's not so straightforward -- at the very least, you have to mess around with the bios to enter a master password (would it even work, or is it dependent upon the exact hardware in which it was created?).

About TRIM, the only thing I don't know is how efficient TRIM can be with encrypted data; if TC writes random data throughout the volume, what percentage of the volume is unused at any time? If that percentage is low, then TRIM wouldn't have much to work with.

 

I think it's important to say that it's the belief of most that pay attention to this stuff that any "backdoor" would only be used in the most serious of cases. Think national security risks of the highest order. There's no way they would be used to gather information to prosecute normal criminal cases as the exposure would be the end-game for that particular piece of software/encrypted drive brand, etc.

 

a) I really don't think there's a "black market" for any encrypted data due to some kind of back door.

b) "wouldn't remain unheard of for long" is kind of what I meant by "things like that wouldn't stay hidden for long (particularly for a security-related program)."

As to worrying about a TrueCrypt backdoor, that's basically what I had in mind when I said that. People can claim "virtually nobody has the expertise to verify the source code! You have to be a cryptographer AND a programmer!" all they want. But the reality is TC has been around for basically a decade, and is probably the most well-known source-available encryption program. No single person has to be knowledgeable and meticulous enough to spot any possible line of bad code. Again, as I said, with enough eyes on it, mistakes or malice will be outed eventually.

The Ubuntu Privacy Remix team, for example, has been analyzing the source code since version 4.2a. Here's their latest writeup. And as others have said, if you really want some assurance, just go read through all the court cases mentioning how the various three-letter agencies never seem to be able to get inside TC volumes.

System encryption has little to do with plausible deniability. And neither of those necessarily have anything to do with TrueCrypt.

I actually see it the other way around. With TC, you need to be logged in as administrator to run the program. This limits the machines you can encrypt/decrypt on. With hardware encryption, the whole idea is that the encryption is part of the hardware. I'm not sure why you would need to mess with BIOS. A Western Digital MyBook external USB drive, for example, works just like any other external...you just plug it in, and if you have a password set, it prompts you for it. Same thing with a hardware encrypted USB thumbdrive.

I'm actually not quite sure what you're thinking about.

The TC manual briefly discusses TRIM, but mostly in the context of plausible deniability.

As for performance, here's a pretty good writeup.

And, incidentally, it looks as though at least one brand of hardware encryption is safe.

 

One of the main points of not using TrueCrypt on an SSD is that it may defeat plausible deniability, and I was just pointing out that deniability is not a concern for me.

To quote from Wear-leveling:

And I'm also not concerned about an adversary finding an old compromised header on the volume (as mentioned on the same page), and I interpret that those are the only reasons refered to by "Due to security reasons, we recommend that TrueCrypt volumes are not created/stored on devices (or in file systems) that utilize a wear-leveling mechanism".

The Plextor SSD (and others, not sure if they all work this way) uses a BIOS drive password to protect the key. I'm still fuzzy on how it works, but encryption is essentially on all the time, and enabling the bios password is what engages the key. If you want to use the drive on another computer, you have to go into the BIOS to set the drive password.

From here:

Thanks for those links, it led me to others (and reminded me that I can look outside of Wilders for answers too *gasp*)...

"Truecrypt 7.0a FDE on SSD" had some interesting notes on leaving an unused partition on the drive to allow for TRIM to work. A few years out of date, but I'm sure it's still applicable today and gives me a starting point for more research. It basically confirms my suspicion that if you use TrueCrypt to encrypt an entire drive, it doesn't leave room for TRIM to work efficiently.

 

Yep, I'm finding many SSD mfr's are rather "fuzzy" in their description on how this works.

I found a very interesting post on this web site by vxlabs that makes a distinction on how SSD HW based FDE is implemented. It describes what is a "usable", and lists the ones they currently (as of Dec 2012) understand to be "usable".

 

A subtle fact I missed in all this discussion, and I don't think I had seen it expressed here, is the idea that the SEDs are "always" encrypting themselves.

The encryption key is separate from the authentication key, so one does not get to "turn on" encryption, only whether authentication is required to access the drive. Have I got this correct?

Assuming so, using one of these puppies along with encryption software such as TrueCrypt, one is getting "double" encryption: First by the software, then again by the hardware.

Is this an added security benefit when using this software, assuming one sets and manages an authentication key for the SED?

Taking that a set further, getting past the authentication to access the SED, if one is using the dual TC drives, the "fake" os drive does not need a password set - and would appear for all intents and purposes "normal", without suspicion (vs a TC only solution). Also, it resolves the backdoor issue (should your drive fall into the wrong hands), as the "real" os is hidden/encrypted separately.