Self-Encrypting Hard Drives and the New Security

In a recent blog post, CNet's Jon Oitsik has called for a policy shift with respect to data encryption. A new standard by the Trusted Computing Group promises the availability of self-encrypting hard drives soon, leading some to call for immediate adoption. Will this create even more security problems due to lazy custodians, or should someone responsible for keeping your information safe be required to move to the new hardware? Hopefully the new hardware comes with a warning to continue to use other data protection measures as well.

Comments

"Hopefully a warning..."

[MaxwellEdison]

Oh there's a warning, it's just been encrypted for its own protection.

Propriety Encryption

[sheddd]

Never has a backdoor!

Re:Propriety Encryption

[Shakrai]

You got a funny mod but it should be insightful. That was my first thought......

Don't worry though, it's for your protection. Think of the children/terrorists!

Re:Propriety Encryption

[dgatwood]

I wouldn't worry about back doors. Given the history of "secure" hardware devices, I'd be more worried about them turning the password trivially into a 64-bit key, using XOR with the key, and storing the key in unencrypted flash for verification....

Re:Propriety Encryption

[hweimer]

Actually, this is about a new specification created by the Trusted Computing Group, so it's fairly open stuff. However, I fail to see how this actually solves any of the problems related to recent data breaches. If you lose your notebook with all your data the attacker also gets access to the Trusted Platform Module and can decrypt the disk. If you want to securely transport your data, this is horribly inconvenient as the whole point is to be able to access the data on different machines (which this tries to prevent).

Re:Propriety Encryption

[Lumpy]

Some people say no but I have seen this in action.

We had secure laptops here with encryption and smartcard security. Bought all Dell 620's with built in smartcard slot.. all was peachy.

We tested our security. 9 out of 10 laptops had the smartcard in them in the bag. AND their pin access number was on the laptop somewhere. os the encryption and any login security was overridden by user failure.

Re:Propriety Encryption

[PitaBred]

Fire a few of them, and let people know why they were let go. Users learn pretty well when they have proper incentives. You're not asking for a lot, and if they can't perform the duties of their job, they need a new job.

Re:Propriety Encryption

[mlts]

Even though the TPM is specced to not be armored against attack, it would take someone with access to a chip fab to try to get the key off the silicon itself.

With a TPM and a hard disk that can use this the way BitLocker does (where it boots to the OS without needing any passwords, but attempts to boot to other media to access the drive require access to the volume's recovery key), this is good protection for a laptop, making the main attack front the username/password of users or administrators. One can also have the TPM require a PIN and enough wrong guesses the TPM either locks access or adds substantial increasing delays between password attempts.

One note here:

This functionality is more aimed at the enterprise than individual users. The enterprise needs to be able to have some way of regaining access to a laptop of an employee should they forget their password or leave the company. They also require access due to data retention laws.

I'm almost certain that the drives will end up tested for FIPS compliance. If not, then they won't pass a lot of DAR (data at rest) encryption specs that the US government has put in place.

As for comparing this with TrueCrypt, this and TC are apples and oranges, or more like a ball peen hammer versus a claw hammer. Both hammer nails, but one is suited to one type of job versus another. For home machines where there is only one person using them, I'd go with TrueCrypt (because TC doesn't require hardware support to provide top notch protection). For machines that have more than one user, or require access by another party due to various regulations, I'd go with TPM based functionality. Or do like I do and use both. BitLocker functionality for the boot volume, and TrueCrypt to automount external drives using a keyfile. This way, if I need to use the volumes on a machine that doesn't support BitLocker, I can just plug them in, read the keyfile off a smart card, and mount it without needing Windows Server 2008 or Vista Enterprise/Ultimate [1].

[1] I really wish Microsoft would put BitLocker in Windows 7 Professional. It is hard to beat for "install and forget" protection of data.

Decryption

[MrEricSir]

Hopefully they're also self-decrypting. Although it would certainly be more secure without this feature.

Multiple security layers

[leromarinvit]

An additional layer of encryption can't be bad. If it's a good implementation with no critical bugs and backdoors, great, you've just made it harder for someone to get your data. If it isn't, it's still no worse than storing plain text.

Just don't rely on this as your only security measure.

Re:Multiple security layers

[GMFTatsujin]

Unless it does something unexpected, such as, say, making it a nightmare to recover files off the drive for legitimate reasons.

I foresee a lot of IT departments pulling their collective hair out on this one: some Executive Director with a penchant for buying the Shiny New Thing stores mission critical data on a self-encrypting drive, some motherboard component on the computer blows up, and now the hard drive -- while fine -- is inaccessible.

Yay.

Re:Multiple security layers

[Todd Knarr]

Or worse, said Executive Director stores information on that drive that's relevant to a lawsuit. And when you have to tell the court that you've lost evidence because of this, you end up facing the possibility of losing some points in the case (or even the entire case) as sanction for spoliation of evidence. Even if the evidence would have exonerated your company. We won't even discuss the fun if it's tax- or SEC-related.

Re:Multiple security layers

[mustafap]

>you'll never see 2DES

Pity really, 'cause 2DES is very secure when hackers think it's triple DES :o)

Re:Multiple security layers

[Lord Ender]

No. Worthless security measures are bad for security because they provide a false sense of security. This influences behavior. So bad "encryption" really can be worse than plain text.

Re:Multiple security layers

[mrsteveman1]

That's why you do separate encrypted offsite backups. Encrypted transport over some cable or network to another encrypted container like a LUKS volume or something.

You should never rely entirely on one copy of data anyway, this seems to be just a way to protect drive data from theft.

self encrypting, probably self-defeating too

[petes_PoV]

And the very first thing the users will do is write down the encryption key, so they don't forget it.

After all, what's the point of having all your data on a disk that you can't access? It's far more likely that the user(s) will forget the key, than for the drive to fail. However, the result will be the same in both cases: inaccessible data and if past experience is anything to go by, no backups (which would also have to be encrypted, again with the isssue over keys).

Until the average PC user radically rethinks their attitude towards their computers - whether at work or play, this seems just one step too far.

Re:self encrypting, probably self-defeating too

[SBrach]

Like a post-it under the keyboard.

Re:self encrypting, probably self-defeating too

[Snowblindeye]

And the very first thing the users will do is write down the encryption key, so they don't forget it.

Well, Bruce Schneier recommends writing down your passwords.

Quote:

. We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet.

Re:self encrypting, probably self-defeating too

[__aasqbs9791]

I would agree with that, I was just commenting on the wallet as the best place to keep things.

I had a problem losing my wallet when I was about 14. This had two results. One, I became rather good at finding lost things. Two, I'm obsessive about knowing the location of certain things (wallet, cell phone, and keys mostly). Drives my wife nuts sometimes since she losing things all the time (actually, she's gotten much better in the last year or two) but I rarely have trouble finding anything.

hmm

[n3tcat]

if encrypted hard drives become the norm, will authorities be more apt to treat it as a protected right rather than as a method of hiding shit?

Re:hmm

[Shakrai]

My first thought was that the encrypted hard drives will probably have a back door built into them to keep us safe from all those kiddie pornographers..... Think of the children!

I want one with a removable key

[davidwr]

It's hard to do with fixed drives, but I want USB drives and memory sticks that come with their own dongle-key that plugs into the storage device, so they key can be separated from the drive. Even better if it has its own keypad or fingerprint reader for authentication. "Something you have, plus something you know."

Re:I want one with a removable key

[afidel]

Biometrics are actually pretty bad from a security perspective, they are a fact which means once exposed they cannot be changed to avoid further compromise. If a biometric system were perfectly implemented this wouldn't matter, but none of them are so it's best to just use a smartcard for the something you have portion.

Hardware crypto leads to better security? BULL!

[Chas]

Spoken (or typed in this case) like someone who's completely misunderstood the security process and thinks that [Insert Buzzword] = Security

Lock out vs lose data

[uberdilligaff]

While the focus will be on preventing data from being accessed when the PC is stolen, this will come with the rather severe side effect that a significant number of users will irreversibly lock themselves out of all their data by losing/forgetting their pass phrase. Too bad you can't reduce the first problem without increasing the second.

Re:Lock out vs lose data

[TubeSteak]

While the focus will be on preventing data from being accessed when the PC is stolen, this will come with the rather severe side effect that a significant number of users will irreversibly lock themselves out of all their data by losing/forgetting their pass phrase. Too bad you can't reduce the first problem without increasing the second.

Are the contents of your wallet at least as valuable, to you, as the content of that encrypted hard drive?
Good, then write down the passphrase and put it in your wallet.

I bet most people take a lot more care with their wallet than they do with their work passwords.

Encryption != Security

[elrous0]

If it's a proprietary system where some insecure company or insecure government agency has the keys, why even bother? If anything, it's only providing you with a dangerously false sense of "security."

Really?

[fuzzyfuzzyfungus]

I want some of what this guy is smoking. He seems to be under the impression that, because the encryption is handled in hardware, there will be no software to deal with. And what, pray tell, will configure the hardware, and set crypto keys, and hold them in escrow in case of the inevitable forgetting, and change them if needed, and so on and so forth?

Hardware encryption certainly has its advantages; but if you can't handle deploying software encryption now, I'm deeply skeptical of your ability to handle deploying hardware encryption.

How can you trust it to not have a back door?

[Eric Smith]

The big risk with FDE is that the drive may, unbeknownst to the owner, cache and store the encryption keys somewhere inside the drive, either on the media or in nonvolatile memory, making it available to those that know where to find it.

Even if the standard drive firmware doesn't do that, how would you know that the firmware of the drive wasn't modified sometime after manufacture and before purchase to install such a back door?

If you were an agent of some government that wanted to be able to access data on disk drives whose owners believe them to be encrypted, what better way to do that than to either convince the drive vendors to install a back door for you, or to let you tamper with the drives at some point in the process? That would eliminate a whole lot of hassle for you, and there are only a few drive vendors you'd have to subvert.

I think I'll stick to LUKS and dm-crypt. It's not a perfect solution, and it's still possible that someone could subvert my encryption, but doing it in the software I have some measure of control over clearly makes it harder for them than doing it in hardware that I have no choice but to trust blindly.

Am I paranoid? Sure. Probably no one is trying to steal my keys or my data. But the likelyhood of the existence of a back door has NOTHING to do with whether the bad guys (or maybe the good guys?) are interested in my data. Even if no one intends to steal my data today, once a back door exists it can be used against me in the future.

Trusted Computing Group reputation?

[steve_bryan]

I hope this proposal is considered with more than the usual amount of skeptical reserve. The name was changed more than once but I'm fairly certain that the "Trusted Computing" group was previously acting as a lackey of the entertainment cartel. They managed to introduce new points of possible breakage making computer based media more prone to failure (e.g. HDCP and the forced failure of expensive monitors purchased by early adopters).

If this is the same group then you can almost guarantee that they will include backdoors and other nastiness intended to inhibit unapproved behavior by the owner of the drive.

Re:Trusted Computing Group reputation?

[afidel]

No, the trusted computer group grew out of an effort at Microsoft to allow secure network booting of clients. Without hardware encryption and bidirectional authentication it was a feature that customers asked for but which they would never have been able to accomplish. There has been talk of using such technology to implement better DRM, but so far it has come to naught even with Vista/Win7. In fact the TPM keystore is available for anyone to use via a fully documented interface and I believe there is a Linux module that allows you to use it. The biggest problem I have is that many TPM 1.2 implementations allow the key out of the keystore along an unencrypted bus which means there is a non-trivial but attainable attack vector against them. Personally I wish Dell wasn't the only vendor supporting TPM in server class systems because I would love to use bitlocker for remote office servers but I can't stand Dell's equipment or support.

64-bit key?

[Jon.Laslow]

All of my sensitive data is double-ROT-13 encrypted!

Re:64-bit key?

[Aphoxema]

I use Quadruple-rot-13, far more effective IMHO.

Re:64-bit key?

[UnderDark]

4096 cycle rot-13 is much much more effective drain on cpu cycles

Re:64-bit key?

[sheddd]

And you get modded informative. Nice!

Re:64-bit key?

[Anonymous Coward]

I use Quadruple-rot-13, far more effective IMHO.

ROT-13 should be the new trigger for Godwin's law in Slashdot discussions.

Power Outage Hickups

[MBHkewl]

So while the disk is self-encrypting itself, what if the power went out?

Complete data corruption/loss?

Or are you gonna mandate that everyone uses a UPS?

Three problems

[Todd Knarr]

Three problems with the idea:

1. Transferring media to new systems. I've already seen a case at work where an encrypted laptop drive was fully intact and working, but the laptop it was in was dead and had to be replaced. The drive was a complete loss, because it couldn't be used as the boot drive in the new laptop (different manufacturer) and there wasn't any software that could be used to supply the boot password to the drive when connected by any other method.
2. Suspend/hibernate. We've found that a lot of the laptop models where I work don't correctly handle returning from a suspend and/or hibernate state. The most common case is that the laptop simply returns to normal operation from the suspend state without requiring re-entry of passwords. Most users simply put their laptop into suspend state rather than powering it down, which means anyone stealing the laptop can completely ignore the drive encryption. Standard Windows screen locking doesn't help much, once the laptop's unsuspended it's network interface is active and it can be remotely compromised and the screen lock disabled.
3. Law enforcement. If the drive encryption is truely secure, LEOs will insist on having a back-door to let them decrypt a suspect's drive to search for evidence even if the suspect won't give them the passwords. If such a back-door exists, it'll quickly be broken and software produced to gain access to an encrypted drive through that channel rendering the encryption useless.

#2 can be dealt with going forward in the hardware and OS. #1 can be dealt with going forward with standardized encryption and hardware protocols. #3... is intractable.

Re:Three problems

[Creepy Crawler]

Then DM_CRYPT solves all three.

1. There's a /boot partition which provides basic bootup services, like entering pass phrases. Any machine that can read standard HD's can read the dm_crypt system.

2. Hibernate is inherently unsafe, unless the hibernation itself is encrypted. And once there, why not just fresh-boot? And about standby, require as a system policy to log out before standby. Then they must hack the standard system to get even a user account. Also, you did not specify memory holes like firewire. They're equally dangerous, if not moreso.

3. Linux is open source, so we would see any attempted exploits in dm_crypt. There might be, but we'll find it eventually.

Hardware encryption...

[fractalrock]

...is worthless. Proprietary, chip-based solutions are the opposite direction we should be going. An open source solution...and there are several great ones already available...is what I use and recommend/setup for all my clients.
Any and all of today's processors can handle the exertion necessary for on-the-fly encryption; most users (including, generally, myself) don't notice the difference.
As per usual, I question SM's logic.

Re:Hardware encryption...

[afidel]

How do you deal with the key in memory problem? That's right you can't without a hardware keystore, hardware is the only way to get true unbreakable encryption.

Bill of Rights

[OldFish]

Just as important as the technology will be the legal framework that applies. Myself, I like the Bill of Rights and I want to see data storage be treated as an extension of my memory with all rights that apply to my testimony extended to the digital media that is protected by a key that is in my memory. I know, naive idealism is dumb.

Prove it's encrypted?

[noidentity]

How can a security-conscious end-user verify that my data is encrypted on one of these drives, as opposed to simply being stored in the clear and the drive just refusing to read it? Sure seems it'd be cheaper if they just left out the crypto and had the drive lie, taking only a few hundred bytes of extra firmware and no extra processing power to implement the new "encryption" command set. Who's going to know?

Re:Prove it's encrypted?

[Skapare]

How can a security-conscious end-user verify that my data is encrypted on one of these drives, as opposed to simply being stored in the clear and the drive just refusing to read it? Sure seems it'd be cheaper if they just left out the crypto and had the drive lie, taking only a few hundred bytes of extra firmware and no extra processing power to implement the new "encryption" command set. Who's going to know?

This can be done by making the actual encryption completely open, with open source reference implementations in software. The disk drive would have two operating modes. Without a set key, it would write and read the data bits in the raw. With the key set (and stored in the drive controller only in SRAM that's designed to instantly lose the key upon power loss), the drive encrypts writes and decrypts reads. The verification is to set the drive key, write some data, then erase the key, read it back, and decrypt it with the reference software. The reverse verification is to encrypt some data with the reference software, write it when the drive has no key, set the key, read it back, and see if the data is the same as the original.

What cannot be verified is if the drive actually saved the key somewhere in some inaccessible spot on the platter, encrypted by a public key hard coded in the controller ROM, which can be decrypted by whoever has the private half of that PKC pair. THIS is the big risk of using these devices. It is a risk present in any sealed encryption hardware device, even if just a separate encryption core in a CPU or GPU. Government agencies with no names wouldn't care about that, as it would be their key.

If it's self encrypting and self decrypting

[Colin Smith]

How will you know if your data was encrypted?

 

Re:Looks like DRM/proprietary lock-in (itsatrap)

[mrsteveman1]

Self encrypting would be in the drive no?

So to an operating system, once the drive has been unlocked by a firmware command it should appear as a cleartext ATA device.

My experience with encrypted media

[argent]

My experience with hardware encrypted media makes me doubt anything good will come of this technology.

We had a large number of encrypted thumb drives, at one point, and all of them died and needed to be reformatted in short order... they were simply more vulnerable to data loss when (for example) you pulled them "too soon". One vendor wouldn't even allow us to reformat them without sending them a signed letter from the CEO (on corporate letterhead) asking for the formatting utility, and then when we provided it we got no further response from them.

We turfed all the "secure" thumb drives no matter what manufacturer and went back to application layer encryption.

Flaws? So what.

[manif3st]

Personally, I can't wait for these to become commonplace. I use whole disk encryption not because I don't want my partner/friends accessing my data (my computer's on all the time anyway in an unencrypted state any business documents and porn are tucked away using TrueCrypt), not because I'm scared of LEOs or G-men (they're welcome to my files), but because I don't want some prick burgling my house, plugging in my hard drive to their computer, and posting my photographs and poking around looking for passwords to sell. So bring on the back doors, I can remember my passwords, and anyone with the knowledge to hack the hard drive to get at the data is doing it for more than my photos and old university papers. I can change my passwords faster than they can sell them.

Key escrow

[davidwr]

If there were multiple keys, each one of which could unlock the drive this would be fine. The owner, i.e. the IT dept., gets the main key and the user and others get backup keys.

One way to implement it:

The drive will accept either its on-board key or a key from a dongle. The on-board key of course will be encrypted with a passphrase that can be changed without changing the underlying key. If EITHER the passphrase is entered OR another copy of the key with ITS passphrase is present, the drive is unlocked.

Paranoid users could invalidate the on-board key, requiring the use of a dongle to unlock the drive.

Another option:
A 3-layer version, where a heavily-encrypted "super key" is on the drive, with multiple "supplemental keys" which may or may not be on the drive which decrypt the super key AND which define access, e.g. a "read only" key, a "read/write key," and an "administration key." Zero or more of these could be stored on the drive, encrypted with passphrases. Others could be stored on dongles, again, encrypted with passphrases. In this scenario, IT would control the administrator key and the person in possession of the laptop would control the read-write key and the read-only key. The read-only key would be turned over in response to subpoenas or customs officials where required by law. In draconian societies like America^H^H^H^H^H^H^H China, an additional, non-removable backdoor key would probably be held by the government.

Kiddie porn? Think cell phones.

[davidwr]

I wouldn't worry too much about children shooting porn and storing it on their laptops. Everyone knows they prefer to use cell phones.

FIPS 140-2

[Digital_Quartz]

In theory, if these drives are being used by a US government agency for encryption, then the drives need to be FIPS 140-2 certified.

In order be certified, there is a stringent list of algorithms that may be used, for both encryption and random number generation, and these algorithms need to be tested and certified themselves.

We'll have to see if the hard drive companies want to go through the headaches involved to get FIPS certification, or whether this is meant as a gimmick for consumers.

I won't touch it until the firmware is open.

[Ungrounded Lightning]

Having the disk drive processor or special-purpose logic on the drive do the encryption/decryption is a fine division of effort.

But until the firmware is open (and there's a way to check that it's what's really running) I won't use such a thing. (Except maybe in transparent mode with the REAL crypto being in software on the machine.)

There are too many opportunities for data compromise with built-in, proprietary and closed, firmware encryption: Faulty design, government back doors, and bad-guy back doors to name just three.