Self-Encrypting Hard Drives and the New Security 205
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.
self encrypting, probably self-defeating too (Score:5, Insightful)
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:hmm (Score:3, Insightful)
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!
Re:Propriety Encryption (Score:5, Insightful)
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!
I want one with a removable key (Score:5, Insightful)
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:Propriety Encryption (Score:5, Insightful)
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....
Encryption != Security (Score:5, Insightful)
Really? (Score:5, Insightful)
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? (Score:3, Insightful)
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.
Re:Multiple security layers (Score:5, Insightful)
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.
Three problems (Score:5, Insightful)
Three problems with the idea:
#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:Multiple security layers (Score:4, Insightful)
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:Lock out vs lose data (Score:4, Insightful)
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.
Re:Multiple security layers (Score:5, Insightful)
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:Three problems (Score:4, Insightful)
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.
Re:Looks like DRM/proprietary lock-in (itsatrap) (Score:4, Insightful)
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.
Re:Multiple security layers (Score:3, Insightful)
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.
Re:Trusted Computing Group reputation? (Score:4, Insightful)
Re:64-bit key? (Score:2, Insightful)
Re:Propriety Encryption (Score:1, Insightful)
That is not user failure, it is a design failure.
What do you expect when you give a user a portable, a smart card and a pin code while telling them "you need the card and the code to access the computer" ?
The typical user / office drone will be much more concerned about not being able to use the portable when he accidentally leaves the card at home, or forgets the code, than he is about the possibility of data theft.
He perceives the chance of this happening to be much higher than the chance of the portable being stolen.
Combine that with the fact that he will be lambasted by his boss if he forgets the card, and can not work because of it, and it is easy to see why the user sees data theft as the lesser problem of the 2.
(Especially because typically he is not blamed for the portable being stolen, those things "just happen".)
The only thing to make ANY security system with "users" secure, is to make sure that the users have an incentive to keep it secure by following the proper procedures.
That means rewarding compliance and/or heavy sanctions for non-compliance and an audit procedure for the lot. (for example, in your case you could randomly check peoples bags when they go home and take disciplinary actions when they are non-compliant)
I won't touch it until the firmware is open. (Score:3, Insightful)
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.