Slashdot Log In
Self-Encrypting Hard Drives and the New Security
Posted by
ScuttleMonkey
on Mon Mar 09, 2009 01:04 PM
from the you-can't-protect-against-stupid dept.
from the you-can't-protect-against-stupid dept.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
"Hopefully a warning..." (Score:5, Funny)
Propriety Encryption (Score:5, Funny)
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!
Parent
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....
Parent
64-bit key? (Score:3, Funny)
Re: (Score:3, Funny)
I use Quadruple-rot-13, far more effective IMHO.
ROT-13 should be the new trigger for Godwin's law in Slashdot discussions.
FIPS 140-2 (Score:3, Interesting)
In theory, if these drives are being used by a US government agency for encryption, then the drives need to be FIPS 140-2 [nist.gov] 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.
Re:Propriety Encryption (Score:5, Informative)
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).
Parent
Re:Propriety Encryption (Score:5, Informative)
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.
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
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 a
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.
Parent
Decryption (Score:3, Funny)
Hopefully they're also self-decrypting. Although it would certainly be more secure without this feature.
If it's self encrypting and self decrypting (Score:5, Funny)
How will you know if your data was encrypted?
Parent
Multiple security layers (Score:5, Informative)
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 (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.
Parent
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.
Parent
Re: (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: (Score:2)
An additional layer of encryption can't be bad.
Probably not with different encryption schemes. If it's the same encryption scheme applied twice though, couldn't the encryption be easier to break? This is obviously the case for a trivial scheme like ROT13, but what about more practical schemes like AES?
Re: (Score:3, Funny)
Pity really, 'cause 2DES is very secure when hackers think it's triple DES
Re: (Score:2)
Except for the first clause of your second sentence. It's pretty much guaranteed that there'll be critical bugs or back doors. And more likely than not it'll be cracked soon after release leading to other problems.
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.
Parent
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: (Score:2)
> And the very first thing the users will do is write down the encryption key, so they
> don't forget it.
That's exactly what they should do, unless it's a corporate machine subject to central key management. They also should, of course, put the key somewhere secure and seperate from the computer.
Re: (Score:3, Funny)
Re: (Score:2)
I don't see it that way. Its no worse than a password protected account on a machine.
Do you write down a password you use every day?
If this implemented on a wide scale, you wouldn't need any other passwords on a single user machine such as a laptop.
Clearly, on a corporate or multi-user machine, its a problem (additional password), because you end up having to give it to every user.
Re: (Score:3, Informative)
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. [schneier.com]
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.
hmm (Score:5, Interesting)
Re: (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!
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:I want one with a removable key (Score:5, Informative)
Parent
Hardware crypto leads to better security? BULL! (Score:4, Interesting)
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 (Score:5, Interesting)
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.
Parent
Key escrow (Score:3, Interesting)
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.
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.
Encrypted laptop drives from online stores (Score:2)
Some of the online stores are already selling "encrypted hard disk drives". The firmware stores an encryption key that is used to process all data as it goes on and comes off the disk drive platters, so the data is encrypted at all times. When you want to erase the drive, you just change/erase the encryption key.
It sounds like a good idea, but can the encryption key be recovered. Is it really erased, or just shuffled to an alternative backup array encryption keys? Or does the manufacturer keep a list of ser
Trusted Computing Group reputation? (Score:5, Interesting)
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? (Score:4, Insightful)
Parent
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: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.
Parent
Bill of Rights (Score:3, Interesting)
Prove it's encrypted? (Score:4, Interesting)
Re: (Score:3, Informative)
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 d
My experience with encrypted media (Score:4, Informative)
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. (Score:4, Interesting)
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.
Re: (Score:3, Interesting)