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.

Re:"Hopefully a warning..."

[breyonmark]

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

grateeeeeee...... http://trypu.com/

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

[eean]

Is anyone talking about propriety encryption though? I mean the NSA has standards for encryption that obviously the Federal government would follow, but so does most of the industry.

Re:Propriety Encryption

[Anonymous Coward]

Those damn child terrorist bug the hell out of me. Good thing someone is finally telling me to think about them... again.

Re:Propriety Encryption

[mrsteveman1]

You would have forgotten, and they are small enough to sneak up on you. You should be thankful for all the warnings.

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

[Anonymous Coward]

Of course not! Even referring to one's back door is the height of impropriety.

Re:Propriety Encryption

[s0litaire]

Just to annoy them i'd use PGP encrypted files in a trucrypt container on the encrypted hard drive...

Re:Propriety Encryption

[Anonymous Coward]

If you lose your notebook with all your data the attacker also gets access to the Trusted Platform Module and can decrypt the disk.

This probably takes care of the cases of using a portable drive, and for when a machine is decommissioned: you don't have to worry about wiping the disk if you separate it from motherboard. There have been a few stories of stand-alone, used disks being sold on eBay and various flee markets with personal information.

Nothing is stopping you for using software (OS-level, PGP) encryption in addition to whatever is in the hardware.

Re:Propriety Encryption

[PCM2]

If you lose your notebook with all your data the attacker also gets access to the Trusted Platform Module and can decrypt the disk.

Yes, but on the other hand, this seems like it could help prevent cases where employees steal the hard drives out of servers. (It's a lot easier to walk out the front door with a couple of hard drives in a duffel bag than it is to make off with two or three complete rack-mount servers.)

Re:Propriety Encryption

[Anonymous Coward]

9 out of 10 laptops had the smartcard in them in the bag

A phone company guy working on my line had a laptop with a SecurId card taped to the laptop so it was easy to type in the number.

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.

Re:Propriety Encryption

[Anonymous Coward]

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)

Re:Propriety Encryption

[MoralHazard]

What you've described is a theoretical risk that basically never happens in the real world. I would guess that it's mostly because of the comparative risks of getting caught, versus the alternative means of getting data out the door.

First of all, racked servers are generally behind a lock door in a restricted area. Whether its fear of data theft, equipment theft, or just downtime due to a careless janior unplugging a server, most companies are smart enough to know that you don't want random juggalos with physical access to your racks. So the only people with access are management and IT.

Second, pulling drives out of running servers tends to get noticed, fast. Even if it's a fully mirrored RAID array, the monitoring software will probably notice and start complaining loudly to the on-call alert address, or wherever your alerts go. If it's not mirrored, well, would you mind stopping by the helpdesk and opening a trouble ticket on your way out?

So even if you had access to the servers, why would you physically steal the drives? It's highly visible so it'll be noticed quickly, and the pool of potential suspects is really small. I would posit that there is a strong correlation between those two factors and jail.

Here's a more likely alternative: Plug an innocuous USB thumb drive into the back of your workstation and copy the data from the server drive to your USB stick, over the network. Then walk out the door. If necessary, alter logs, etc. as needed to cover your tracks. The company might never find out about the theft, and even if they did, they'd have to pull you out of a larger pool of suspects. You'll probably get to keep your job.

(Bonus lulz: Alter the logs to frame your jackass boss, but only after spending a couple of weeks sucking up to HIS boss, so that you get promoted when he gets the v&.)

Re:Propriety Encryption

[neapolitan]

I was totally with you until your (faulty) conclusion. Creating a draconian police-state is not a way to improve productivity, and will just make people hate you. I would not work at any place where they check my bags at the exit (other than the FBI/NSA/CIA, etc.)

Our hospital had the same problem as you - they gave us all SecureID RSA keyfobs, and everybody hated it. It was annoying to have to have something with you all the time.

What they did to replace it, is (IMHO) a very good compromise - VPN access with a system of "recognizing" the computer (Juniper proprietary -- I assume it is some sort of certificate) and enforced strong passwords. You have to answer a bunch of questions to register the computer, but then afterward it is simple username/password signon. Secure enough for banking online, and secure enough for our corporation / hospital.

Re:Propriety Encryption

[garutnivore]

What they did to replace it, is (IMHO) a very good compromise - VPN access with a system of "recognizing" the computer (Juniper proprietary -- I assume it is some sort of certificate) and enforced strong passwords. You have to answer a bunch of questions to register the computer, but then afterward it is simple username/password signon. Secure enough for banking online, and secure enough for our corporation / hospital.

I'm going to assume that if they require the use of passwords, they have designed a security system in which passwords must remain secret. If it is so, then how do they get users to keep their passwords secret?

Or if it is the case that the system does not rely on the secrecy of passwords for security, then why ask for passwords in the first place?

To put it another way. If after the initial registration only one password is needed by a legitimate user to enter the system and that password is put on a post-it note stuck to the laptop, then what level of security do you actually end up with? You're in the same scenario as what the GP post is talking about. The solution is not to add yet another layer of security which ultimately hinges on users keeping a secret when in fact they are unable or unwilling to do so.

There is no security solution I know of which does not depend on the users behaving in a secure fashion. This does not mean that all solutions are equally likely to help users behave properly. A company which requires their employees to require 10 passwords would do well to switch to a one password system because the inconvenience of managing 10 passwords encourages unsafe behavior.

At any rate, if a system is dependent on user behavior then there has to be a way to enforce proper behavior. I agree that draconian me1asures should be avoided but there has to be a way to verify that the users are behaving properly.

Re:Propriety Encryption

[GargamelSpaceman]

Sanctions? That will never work. Likely Joe user has an incling that if they lose sensitive data that gets used to hurt the company in a public way will get them canned if there has been any breach of company security policy. Canned is the death penalty sanction of the work world.

Security must not overly inconvenience the user or the user will do what they can to get around it. If it's not inconvenient, then the user will see the security as an asset to them personally, and work to make it effective. There has to be a compromise between effectiveness and convenience. It's better to get 95% of the security possible than to reach for 99.999% of the security that could be had and end up with zero percent security because of fed up users.

Taping the smart card to the laptop is ok as long as there is also a password required. If the password is compromised via phishing or other subterfuge, it won't do any good without the smart card. If the laptop is stolen the smartcard won't do any good without the password. Good password policy will ensure the password is not written down. Good password policy is as follows: Keep the number of passwords a user must memorize to one or two NO MORE ( I'm thinking one that encrypts the hard disk and is never changed ( unless the user chooses to do so ) and one network/everything else password ). Enforce excellent password choice, but don't force the user to change their passwords more than once or twice a year if at all.

When the laptop is reported stolen, the card can be deactivated anyway. That means a criminal would have to learn the user's password for both the hard disk and the network and then steal their laptop with smartcard to be able to use it, which they must do within a short window before the theft is reported. You may as well just grab the employee, stick a gun to their head and force them to type their password in theirself. At some point the badguys CAN break your security if they really want to. If it's national security, then don't let employees take their laptops home at all. Forget thiefs, if it's THAT valuable, then the EMPLOYEE could just take the data, sell it or whatever and then claim it was stolen, moving to Tahiti to enjoy their massive wealth after you fire them. Why do they have access to it in the first place?

Re:Propriety Encryption

[Anonymous Coward]

You are right that the spec is open. If you had actually read it you would realize your worry is bosh. There are several ways of using the new spec to solve problems. The first is secure disposal - you change the base encryption key before you throw it away. Problem solved. The encryption is AES by the way. In ATA compatibility mode, you can use a password to encrypt the encryption key, and then the drive does not actually have the encryption key when not in use. If the machine is stolen, the key is NOT THERE. It is NOT in the TPM . Where did you get that idea?

Decryption

[MrEricSir]

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

Re:Decryption

[youthoftoday]

at last! secure /dev/null !

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

[Jamu]

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:Multiple security layers

[hedwards]

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

[fuzzyfuzzyfungus]

Depends on the scheme. ROT13 is obviously a toy example; but DES isn't(outmoded, yes) and, while you'll see DES and 3DES, you'll never see 2DES, for that reason.

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

[leromarinvit]

IANAC (I am not a cryptographer), but isn't that only a problem if you use the "inverse" of the first key for the second encryption, where DES(key2) == DES^-1(key1)?

Re:Multiple security layers

[afidel]

And even 3DES needs modification from the base algorithm, just applying straight DES three times does leave you less secure. This was one of those interesting things that the general public didn't find out until decades later but the NSA actually suggested a modification to the S-box in DES for use with triple DES. Turns out that modification prevented a particular class of EC analysis against 3DES, a technique that wasn't available in academic circles until almost two decades after the NSA change.

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.

Re:Multiple security layers

[Anonymous Coward]

If it's insecure and involves a performance overhead then yes it is worse than storing plain text. The security onion is a good principle but each layer comes at a price.

Re:Multiple security layers

[profplump]

Actually you'll never see 2DES because it only adds a trivial amount of security -- with a meet-in-the-middle attack it only provide about 57 bits effective key length, a mere one bit more than 1DES. Even 3DES only provides 112 effective key bits due to the same attack.

But 2DES is not less secure the 1DES, it's just not enough better to bother. 3DES also has the advantage of a encrypt-decrypt-encrypt mode with a single key, which allows you to use the same hardware to do both 1DES and 3DES.

Re:Multiple security layers

[icebike]

An additional layer of encryption can't be bad.

Probably not with different encryption schemes.

My understanding is that dual (or any multiple) encryption provides no additional
protection because brute forcing the product is no more difficult than brute forcing
the first encryption.

Re:Multiple security layers

[profplump]

Where did you get this information? 3DES uses the same algorithm as 1DES, just applied three times. In fact, one of the design goals of 3DES was that in EDE (encrypt-decrypt-encrypt) mode, using the same key for all three stages, it was functionally equivalent to 1DES, thus allowing you to use the same hardware for both 1DES and 3DES. 3DES has also be implemented in EEE models, which are no less or more secure than the EDE model.

The only thing 3DES leaves you "less secure" than is perhaps a naive assumption of complexity -- while you might expect 168 effective key bits you really only get about 112, due to the meet-in-the-middle attack. But 112 is still a lot more than the 56 effective bits you get with 1DES.

Re:Multiple security layers

[lucifig]

You must not work for an executive. As an IT wageslave, I find it very easy to tell the average user what they have to do...not so much for the VPs.

Re:Multiple security layers

[GMFTatsujin]

Execs tend to take the same approach to rules as Congress does: they make 'em but are for the most part exempt from their effects. They take, shall we say, "liberties." I have always worked for businesses where the execs determined "as I say, not as I do" IT policies.

They are dumb that way. Yes. But that's who I end up working for. Maybe it's just me.

I suspect it's not just me, though. I can't believe Scott Adams wrote the PHB just for my benefit.

Your point about backups is well-taken, but applying the above to an exec's laptop means they will insist on putting important things in stupid places, all in the interest of security, accessibility, and convenience. Ultimately, they will end up deprived of all, and at their own hand.

Re:Multiple security layers

[afidel]

Ok, I had my facts slightly skewed, they made changes to the S-box to allow DES and more importantly 3DES to stand up to differential cryptoanalysis. It also turns out IBM's group that modified LUCIFER to come up with DES independently discovered the differential attacks in 1974 before the algorithm was published but that specific s-box values that were used were selected by the NSA ( I would guess because they were found to be even more resistant than the values that IBM had selected, perhaps because the NSA did more analysis or perhaps because they knew of even more techniques internally). The point is if weak s-box values had been selected performing additional rounds of DES encryption (as implied by 3DES) can actually weaken the keystrength through the introduction of twiddles or weakened bits.

Re:Multiple security layers

[mattwarden]

Tell that to the TSA.

Re:Multiple security layers

[BikeHelmet]

There's no way in hell that I'd buy a HDD locked to a specific motherboard. :?

I swap HDDs far too much for system-specific encryption to work for me.

Re:Multiple security layers

[nunoloureiro]

"If it isn't, it's still no worse than storing plain text".

That's not necessarily true. If it gives a false perception of security, then it is a lot worse than storing plain text. I'll give you an example. I use PGP to encrypt some files I have on my hard drive. If I had my entire disk encrypted and I trusted the system, I would not have those files encrypted with PGP.

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

[John Hasler]

> 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:self encrypting, probably self-defeating too

[icebike]

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:self encrypting, probably self-defeating too

[0100010001010011]

You say that like it's a bad thing. If it was a matter of losing everything I owned, I'd write the key down somewhere. I currently keep all my passwords on a hand written piece of paper in a safety deposit box at my house in case I die so someone can access my shell / accounts.

It's more than likely that someone is going to grab my laptop at the airport than when I'm sitting at it writing the password down.

Re:self encrypting, probably self-defeating too

[SBrach]

Like a post-it under the keyboard.

Re:self encrypting, probably self-defeating too

[Anonymous Coward]

I have one of these Full-Disc Encryption drives in my corporate laptop, it is exactly as you said, you use the key every time you start the computer, (and I, insecurely use the same pw as I use for windows start-up) so even if I don't remember the pw, my fingers do.

If I am incapacitated, however, the data is lost to my corporation, not sure if they took that into account.

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]

That would suck if you got mugged (or like some people I know, have a habit of losing any small object you own at a moment's notice :sigh: ).

I don't mean that the muggers have your password, but more that if I write something down I tend to not remember it quite as well. After all, I have it written down, so why bother remembering it? I don't actually think that consciously, but it does seem to be the case (for me anyways).

Re:self encrypting, probably self-defeating too

[wastedlife]

If I am incapacitated, however, the data is lost to my corporation, not sure if they took that into account.

Are you sure your corporate IT staff does not have access to a master key/backdoor that could unlock your laptop in the case of you being unable to (i.e. you die, get fired, wind up in coma, etc)? Also, if your corp is worried about losing data, they should really have some sort of backup plan. Maybe encrypted backup over a VPN link so the data remains secure?

Re:self encrypting, probably self-defeating too

[Anonymous Coward]

Different AC here.

At the place I work, we have to give our disc-encryption password on a piece of paper to HR. They lock it away, so then they have a record of my notebook's drive password if I'm ever incapacitated. Then I have a different password that changes every 90 days on my Windows account, which obviously can be easily reset by the IT guys.

In addition, we use an encrypted backup system like the one you mention.

Re:self encrypting, probably self-defeating too

[spidr_mnky]

That's a good point. You should probably keep a copy of that little piece of paper (and, if applicable, all your other little pieces of paper) on a big piece of paper at home, in a safe if it's extremely important, or more likely just some place safe, like a fireproof box.

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.

Re:self encrypting, probably self-defeating too

[Chris Burke]

Way to give it away. Now I have to move my post-it.

Re:self encrypting, probably self-defeating too

[dwarfsoft]

Our users tend to use a PostIt taped to the monitor, just below the screen. But I suppose it's not like we handle confidential data (or Patient Medical Records) or anything... *sigh*

Re:self encrypting, probably self-defeating too

[Anonymous Coward]

But, I write the encryption keys on the bottom of the laptop so it WON'T get lost!! Are you suggesting there is a better way? ROFLMAOA

Re:self encrypting, probably self-defeating too

[Logic Worshiper]

Why have a password then? Just save yourself the trouble.

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!

Re:hmm

[wastedlife]

Think of the children!

Why are these people always thinking about children? Jeez, you'd think they were pedophiles or something.

Re:hmm

[powerlord]

Think of the children!

No! Think of the terrorists!

Heck, lets compromise ...

Think of the Children-Terrorists!

Old hat

[flyingfsck]

Self encrypting drives have been available for years already. However, they are always behind the curve - small and slow.

Re:Old hat

[flyingfsck]

Now why was I marked flamebait? I do military work and has to know about this stuff. There are manufacturers like Flagstone (http://www.flagstonesecure.com/), who makes drives with various levels of security. The top models are Type 1 Crypto certified and can only be purchased by the military of certain countries. However, the drives are always a generation or two behind in terms of capacity, since it takes them a long time to get it certified by the NSA or CSE. Consequently we still had to do software encryption and get that certified ourselves - and yes, we use Linux.

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.

Re:I want one with a removable key

[Chabo]

Plus there's the "Demolition Man"-style method of bypassing biometric scans: steal the person's eyeball.

Or, for Terminator: TSCC fans, you also have to protect against your "future self" coming back in time and accessing things as you.

Re:I want one with a removable key

[Anonymous Coward]

To be clear, biometrics are perfectly fine for identification if you trust the scanner. A fingerprint reader on a laptop is easy to trick. A fingerprint reader with a guard standing next to it takes a bit more ingenuity to get past. That is the type of situation were biometrics are actually a good solution: if the readers work right when used properly and it is easy to tell if someone is using the reader properly, then they are useful for when someone is making sure the reader is used properly and stopping other people.

Note that a fingerprint reader and a pin/password can be an okay login mechanism, and having extra checks to make sure the reader is being used properly is a good thing to look into (for example, some fingerprint readers check for heat).

Re:I want one with a removable key

[lazarusdishwasher]

How about an external drive wit a pin?
http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:item.detail?GroupID=38&Code=43R2018&current-category-id=2478535BAB3C417CA9D77F5867D31462

Re:I want one with a removable key

[darrylo]

This has already happened, but with a finger: http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm

Re:I want one with a removable key

[mlts]

Biometrics can replace the username, not the password. Using biometrics alone is foolish. Using biometrics along with a PIN, a smart card, or some type of key, can add substantial security.

Usual three things with security: Something you own, something you know, something you are. Biometrics can't replace the other two, but they can augment.

Re:I want one with a removable key

[Anonymous Coward]

You can with Truecrypt. Using a 'keyfile' as part of the password which can be stored separately on a memory stick and do whole disk encryption on your USB drive.

Re:I want one with a removable key

[RiotingPacifist]

Hasn't luks been able to do that for years?, i know it was an option when i first installed ubuntu 3-4 years ago, since then I've realized there is nothing i want to keep secret enough to take a performance hit.

Re:I want one with a removable key

[Anonymous Coward]

Biometrics are inherently insecure. No implementation can make it perfect. Finger print can be photographed and reproduced and pasted on intruders finger. The same can be done with Retina and Face recognition.

Re:I want one with a removable key

[Tuoqui]

That is why security should never rely on a single type of authentication.

Something you HAVE: Smart Cards, USB Dongle, Swipe Card, RFID tag, etc...
Something you KNOW: Password, Mothers Maiden Name, Your Address, etc...
Something you ARE: Biometric Information.

So if you need to secure something then using biometric data such as a fingerprint (pretty weak) in combination with a smart card and password creates a triangle of security. If you are missing any of the three you lose as only the person authorized would possess all three at once. Naturally if there was a particularly dedicated attacker the person themselves would be the target of the attacker so they could presumably try to get all three at once. This is why a number of electronic locks also have a key. Putting in the right number lets you try the key.

Re:I want one with a removable key

[Anonymous Coward]

"I assume your handprint will open this door whether you are conscious or not."

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.

Re:Lock out vs lose data

[ACMENEWSLLC]

For the average user what would be nice is if somehow this encryption talked wireless to a device I had tethered to my key chain.

Perhaps when I boot, I have to click on a button to unlock the encryption, just like I do to open my car.

While that is not governmental level security, it is something a user can understand. It means I don't have to remember anything other than my keys, which I already am use to. It also lets IT make backup devices (car lots can make you another key fob) in case the user looses theirs, the user quits, or IT needs access.

This would solve part of the lost laptop data problem. Of course, if the user just puts the laptop to sleep, that's an issue.

Re:Lock out vs lose data

[Kirth Gersen]

TubeSteak:

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

Unfortunately, a lot of *other* people *also* think that your wallet is much more valuable than your work password.

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

Re:Encryption != Security

[Anonymous Coward]

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

For most people and organizations the government isn't the real risk you're trying to guard against.

I'm guessing you're in the US: the citizens of a lot of other countries aren't as paranoid as many Americans are when it comes to their governments.

Re:Encryption != Security

[elrous0]

Actually, lately it seems like Australia, the UK, and a lot of other European countries' governments are becoming way worse than the U.S. The U.S. government is far from a beacon of freedom, but at least our government isn't trying to firewall the whole country (not yet anyway).

Re:Encryption != Security

[Chabo]

I'm guessing you're in the US: the citizens of a lot of other countries aren't as paranoid as many Americans are when it comes to their governments.

I couldn't decide which of two possible replies to make, so I'll do both:

Reply #1: If you're not paranoid about your government, you should be.

Reply #2: Have you seen our government? I hope it's understandable why we're this paranoid.

Re:Encryption != Security

[Cyberax]

TPMs are pretty secure - TPM spec mandates independent audit of chip manufacturers. TPMs themselves are constructed in a way to make hardware reverse-engineering very hard.

Probably, a high-level government agency could obtain manufacturer's private key. Or it could somehow add a 'backdoor' into TPM hardware. But if you are THAT paranoid - you'd better use completely software solution.

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.

Re:Really?

[bit01]

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.

Even more there's generally speaking no such thing as "hardware encryption", just software encryption running on different hardware platforms. There are some low level hardware encryption engines available but even those are typically dedicated one-chip computers.

In this case why on earth do I want my encryption software running on a very low end, inaccessible CPU in my hard drive with poor, probably buggy access and needlessly basic functionality instead of my high performance, flexible main CPU with full OS support and updates? The main CPU is usually waiting for the hard drive anyway.

"Hardware encryption", like a lot of "hardware x"'s such as "hardware RAID" and "hardware high level network cards", are typical of the creeping featureitis of developers not thinking clearly and not doing the numbers.

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

Re:Really?

[Cyberax]

Humans. There's no need for software apart from setting initial TPM owner keys (and possibly dumping generated keys for backup purposes).

The rest of encryption, key generation and negotiation with hard drive can be handled in hardware. All user intervention can probably be reduced to entering 'owner key' in BIOS and turning on 'encrypt HD' option.

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.

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

[icebike]

> if you were an agend of some government...

You wouldn't have to "tamper" with drives after manufacture.
You would already have your built in back door.

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

[Zerth]

If it is anything like the various encrypted USB sticks, it'll be trivially cracked with a logic probe and maybe soldering on another controller/copying the firmware from another drive for which the key is known.

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

[Eric Smith]

Depends on what government and how much leverage you have over the vendor. You might get the vendor to install the back door for you, or you might intercept the drives in shipping and install the back door.

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

[Eric Smith]

The idea behind the recently approved standards for FDE are that real crypto is used. The drive should only remember the key until it is powered down or told to forget the key. The problem is that there is no way to be sure that it forgets the key.

Encrypted laptop drives from online stores

[mikael]

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 serial numbers/original encryption keys just in case.

If not, how would data recovery service be able to recover the data off a disk drive in a clean-room environment without the dedicated firmware?

Re:Encrypted laptop drives from online stores

[corychristison]

If not, how would data recovery service be able to recover the data off a disk drive in a clean-room environment without the dedicated firmware?

That's the risk you run. If the data could be recovered by removing the platters and extracting the data, what's the point? If the data is sensitive enough someone would be willing to send it off to a recovery center to get the data they want.

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.

Re:Trusted Computing Group reputation?

[mlts]

tboot comes to mind for Linux. Also, IBM has documentation and source code about use of the TPM as an onboard smart card.

I agree with you about TPM chips being useful. When building systems, its difficult to find TPM enabled motherboards, other than server class ones. They are out there, but finding them is a pain because TPM 1.2 capability isn't usually a spec listed, and one has to cross-check the mobo with the maker's site.

I wish other server operating systems had BitLocker like functionality where they would offer the option to store the encryption keys in the TPM to allow an OS to boot unattended. This would provide excellent security for remote servers where console access is hard or impossible to obtain. This also would provide security from people stealing drives out of servers (which does happen... especially the 2.5" ones that are pretty easy to stuff in a lunch bag.)

Re:Trusted Computing Group reputation?

[Cyberax]

Linux supports booting using TPM. Sort of.

I got recently involved in a flame-war on grub.devel mailing list then I offered to add TPM support to the mainline GRUB2 - http://article.gmane.org/gmane.comp.boot-loaders.grub.devel/9367

Re:Trusted Computing Group reputation?

[mlts]

This is IMHO, but that functionality you offered to write would help ease Linux into a number of installations. I personally can see some useful areas for this, such as servers that are at remote branch locations where there isn't anyone with administrative authority, or there is a risk of theft of a server.

Right now, if I want this functionality, my only choice is to use Windows Server 2008 and BitLocker (using Hyper-V for Linux VMs), or find some way of getting a console that plugs in over Ethernet (which can be a security risk, as I'm trusting an unknown third party adapter). Linux having BitLocker like functionality would allow for a lot more flexibility, especially in locations that are not manned and where equipment is vulnerable to theft.

Re:Trusted Computing Group reputation?

[Cyberax]

Well, try to explain this to Grub developers :)

I'm going to finish TPM support, even if it's rejected from the mainline. It looks like I can get away with only with MBR modification, the rest can be done as modules.

Re:Trusted Computing Group reputation?

[afidel]

Most of the systems with TPM today are laptops. Dell and IBM have a range of desktops that have or support TPM modules. I'm hoping the upcoming Proliant G6 series from HP has TPM support.

Speed

[qoncept]

My work hard drive is encrypted with Safeboot and it's slow as hell. If hardware encryption can improve the performance it'd be worth it for me.

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?

[Anonymous Coward]

64-ROT-26 is where the money is. Backdoor proof.

Re:64-bit key?

[sheddd]

And you get modded informative. Nice!

Re:64-bit key?

[kalirion]

I'm sorry, I couldn't read your post. Could you post the algorithm and key to unencrypt it?

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.

Re:64-bit key?

[Anonymous Coward]

This did not just get modded informative!

Where the heck is the mods' sense of humour?!

Re:64-bit key?

[Anonymous Coward]

Informative? C'mon!

Re:64-bit key?

[swillden]

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

This is what comes of applying cryptography naively.

You really need to learn about the "meet in the middle attack". Read the link for full details, but what it boils down to is that when applying any cipher multiple times, the attacker can work both ends towards the middle, trading space against time.

See, THIS is why even the most competent engineers should defer cryptographic design to the real experts.

Quadruple-ROT-13... Bah.

Re:64-bit key?

[Chris Burke]

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

Can anyone make sense of this? I think it's encrypted with double-rot-13, or possibly even quadruple. Any help cracking this secret message would be appreciated.

Re:64-bit key?

[MobileTatsu-NJG]

And you get modded informative. Nice!

This is precisely why you don't use Informative to give a funny post karma.

Re:64-bit key?

[hobbit]

Please stop telling that joke: it really isn't funny any more, if indeed it ever was.

Re:64-bit key?

[Aphoxema]

anmv

Re:64-bit key?

[Aphoxema]

Are you trying to tell me that Rot13 is ineffective as an encryption scheme?

Re:64-bit key?

[dna_(c)(tm)(r)]

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

Can anyone make sense of this? I think it's encrypted with double-rot-13, or possibly even quadruple. Any help cracking this secret message would be appreciated.

Actually, [a-zA-Z] + [-] + [0-9] are 37 characters, let's add [+()] then we could go ahead with QuadruPle+ROT-10(nOT-binary) encryption.

Re:64-bit key?

[swillden]

No, no. ROT-13 is fine. It's just Quadruple ROT-13 that's pointless. If ROT-13 doesn't give you enough security, go to Triple ROT-13, or Quintuple ROT-13.

Re:64-bit key?

[Anonymous Coward]

oh, please... quadruple is ssooo passe...

i've been using 2*n-tuple rot13 encryption for all my files so that one can't simply quadruple-decode it, they would have to brute-force the n value first...

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?

Re:Power Outage Hickups

[wastedlife]

I'm pretty sure the drive just encrypts and decrypts on the fly at the block level as it writes and reads the data. If the hardware is designed correctly, you would be at no more risk of data loss due to power loss than you are with a regular drive. Did you think it runs through and encrypts the whole drive at shutdown and runs a decrypt at startup?

Re:Power Outage Hickups

[mikael]

The encryption will be done transparently - it will be pipelined so there will be no noticable delay between the time a CPU core sends a write request to the drive, to the time the data is written onto the platter.

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.

Re:Three problems

[Aqualung812]

This standard they're working on would help with 1 and 2.

Going with OSS would fix #3.

Re:Three problems

[themacks]

For #1, wouldn't putting the drive in another of the same model laptop work?

Re:Three problems

[blueg3]

#3 is pure paranoia. There are plenty of commercial and open-source encryption products out there, including full-disk hardware and software encryption. They don't have law enforcement backdoors.

Sometimes hardware encryption implementations are absurdly broken (e.g., encrypting using single-key XOR), but if this is an intentional law enforcement backdoor, LE agencies are being awfully inefficient by reverse-engineering the devices to find ways to bypass the encryption (or paying commercial researchers to).

Re:Three problems

[Anonymous Coward]

Number 3 can be resolved by using both encrypted and hidden partions.
For instance I have a encrypted drive with the password secret. This acts as the cover for a hidden encrypted partion on the drive that has a password of supersecret. The hidden partion contains my designs for the the best mouse trap ever. In the space that is unused in my hidden partion is written random data to prevent its detection.

In the encrypted partion I keep data that is less important but would appear that i want to keep it safe.
Now someone forces me to reveal my password for the encrypted drive I give me the password secret. To the observer the data is now available to view in the encrypted partion but the hidden partion just appears as empty space within that partion.
Since there is no reason to believe that another encrypted partion is on the drive the only data that is revealed is the data i really didn't care about anyway.
Understand that the prompting for the system is the same for the standard encrypted partion and the hidden one. The system attempts to decrypt the hidden partion and when then that fails then trys to decrypt the standard partion. With anyone watching over your shoulder there is no way to tell you are only giving them limited access. To further this you could require a key file from a USB drive with a supersecret password to access the hidden partion.

Re:Three problems

[Todd Knarr]

It probably would. Assuming that the company had more of that model of laptop, or that the manufacturer was still making that model with the same internal hardware. But the company doesn't have any spares of that model and the manufacturer doesn't make it anymore, so you can see the obvious problem.

Re:Three problems

[Anonymous Coward]

1: If the drives use a standard ATA spec, this wouldn't be a problem. Virtually all laptops can use the existing mechanism to password-lock any drive put in.

2: This has been addressed in a number of ways. Hibernation files in BitLocker are encrypted as part of the rest of the system volume. Microsoft's System Integration Team's blog has some good info on this.

3: This is a nonissue for the most part. Rubber hose cryptography can "decode" pretty much anything regardless of algorithm.

Re:Three problems

[bbasgen]

2. Hibernate is inherently unsafe, unless the hibernation itself is encrypted. And once there, why not just fresh-boot? Not sure why hibernation is inherently unsafe. Anyway, there is nothing particularly special to encrypted hibernation. Hibernation writes everything in RAM to the HDD. All you need to do is encrypt it. Products like Pointsec do this. No big deal. As to your second question -- the answer is simply user convenience. Some prefer hibernation over a cold boot. I don't care either way, so long as the data stays encrypted, I'm happy.

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.

Re:Hardware encryption...

[Skapare]

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.

However, the hardware could encrypt the key with the public half of a PKC pair, store it in flash, making all your data available without needing to do any breaking at all, to whoever (agencies that don't exist) generated that pair and kept the private half.

You don't even know that your CPU isn't doing that today. It could have some circuitry, or parallel acting firmware, that detects certain common instruction patterns that indicate software encryption is happening, and grab the key just like described above.

Re:Hardware encryption...

[kefler]

I agree with the OP. The purpose of this encryption capability is more for data at rest, and for secure erase of data. I'd say this is a good feature just for the fact that wherever the drive ends up after I've used it, the bits on the platters are not in plaintext.

Re:Hardware encryption...

[Anonymous Coward]

http://www.gnu.org/software/libtool/manual/libc/Locked-Memory-Details.html

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.

Re:Bill of Rights

[blueg3]

It's a much more reasonable analogy to treat information on digital media in the same way you would treat information written on paper, recorded on video- or audiotape, etc. Your memory (with current technology) is not objective physical evidence, wheras these others most certainly are.

Re:Bill of Rights

[OldFish]

I respectfully disagree. What if I write encrypted documentation on paper? The key is in my memory, only my direct testimony can recover the encrypted contents. The encrypted hard drive case is identical to the encrypted hardcopy document: what you see is what you get. The only physical evidence is the encrypted file, any decrypted content is a product of my testimony, my memory. I think my position is quite solid.

Re:Bill of Rights

[blueg3]

For one, this depends on your memory being the only source for the encryption key. (Given how modern cryptographic programs are implemented, of course, your memory generally isn't storing the encryption key to the data itself, but a key used to encrypt the real encryption key. Presumably this is an unimportant detail.)

Even if the encryption key is in your memory, it's not subjective testimony, since whether or not you provided a correct decryption key (or, more generally, an adequate decryption procedure) can be verified. (If you happen to be encrypting maximum-entropy data with encryption software that performs no sort of key verification, this is no longer true.)

Looks like DRM/proprietary lock-in (itsatrap)

[Khopesh]

Oh good, so now I need a special driver with which to decrypt my hard drive, so it won't work with the Linux or BSD kernels.

I would buy such a product (encrypted HDD or encrypted SATA/SAS [RAID] controller) if it were completely open (as in GPL-compatible) firmware, open specs, and solid assurances of fair play with respect to patents, etc. Especially if the encryption/decryption is performed on a dedicated chip so as to keep resource costs from growing.

... and battery back-up (like other hw RAID controllers), confirmed writes via journal for data integrity, ... hmm, I have some high demands. Maybe I'll just stick with TrueCrypt.

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.

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

[Khopesh]

And what do you do when the drive is stuck in the middle of a write when something crashes? Without the proper ~journal/cache and a battery to ensure it has time to complete, you risk losing your data. When it comes to encrypted data, some malformed data can mean EVERYTHING is lost. This is not acceptable.

Also, I fully expect them to skimp on the implementation. Fully driver-transparent encryption would require the device itself (or the controller, if that's where it is implemented) to handle the encrypting and decrypting, which means an extra chip in the equation. Take a look at how fully WinModems flew when the computation was pulled from modems into the main CPU via software drivers. Too much cost savings. Maybe it's a smaller difference these days?

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.

Re:Prove it's encrypted?

[Anonymous Coward]

With no due respect, that's asshattery. Companies would be putting themselves at HUGE risk by blatantly cheating customers. The more likely scenario is that they implement weak/flawed encryption in secret due to pressure from authorities.

Trusted Computing Group

[Anonymous Coward]

Nothing like a generic, corporate, marketing-driven name to inspire my utter distrust.

Re:Trusted Computing Group

[Skapare]

Remember, no matter what the name, if they have to tell you something in the name, the opposite is the reality.

if open firmware and algorithm modules

[electrogeist]

Self-encrypting hard drives would be a great thing IF they have a flexible and open firmware, with interchangable open source modules for algorithms. After a simple command to pass the key its accessed as a regular drive with no additional overhead for the computer.

With a closed proprietary approach those who need it will be too skeptical to use it, and it may just cause more trouble than it is worth.

Re:if open firmware and algorithm modules

[Skapare]

Self-encrypting hard drives would be a great thing IF they have a flexible and open firmware, with interchangable open source modules for algorithms. After a simple command to pass the key its accessed as a regular drive with no additional overhead for the computer.

With a closed proprietary approach those who need it will be too skeptical to use it, and it may just cause more trouble than it is worth.

And you won't know what else it does with the key, such as encrypting it with the public half of some PKC pair that some non-existing agency generated, and saving that in some unreachable parts of the platter.

If it's self encrypting and self decrypting

[Colin Smith]

How will you know if your data was encrypted?

 

Re:If it's self encrypting and self decrypting

[MrEricSir]

Don't worry, just send me the hard drive and the password, and I'll check for you.

Re:If it's self encrypting and self decrypting

[Anonymous Coward]

Send me $20 and I will set your drive to automatically encrypt and decrypt with the activation of your power button. You don't even need to know a password, seamless integration! ;)

Re:If it's self encrypting and self decrypting

[mlts]

If it uses a TPM, disable the chip in BIOS, and see if you get a "Recovery passphrase please" dialog.

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.

Re:My experience with encrypted media

[Creepy Crawler]

Who's "them"? I want to know who to avoid.

Re:My experience with encrypted media

[argent]

I can't tell you who "them" is, this was back before I left $VBC, three jobs ago. But even the "best" (least worst?) hardware encryption was terribly fragile.

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.

Re:Flaws? So what.

[Anonymous Coward]

You're missing the point.

I don't want backdoors. I don't want anyone to have access to my precious datas unless it's on my terms and on my hardware. If my laptop is ever stolen, all the thief is going to get is a moderately powerful machine with absolutely no way to recover what's on the drive without me.
They also get a small module that SMS messages me the laptop's coordinates every half hour, on it's own battery. If a small-time crook wants to steal my baby, he's going to have to work for it.

If there are backdoors, only you are happy. If there are no backdoors, both of us are happy, and your own security is improved, even if you never need it. Why compromise your personal security when it isn't necessary?

Re:Flaws? So what.

[Anonymous Coward]

That is so simple. Problem is what will happen when you would forget your frequently changed password. Any mitigation for password recovery will be the weakest link. That will not require a black cat hacker to break-in.

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.

Re:Key escrow

[pavon]

What you described is very similar to how the current seagate drives work, minus the external keyfob.

Out of the box the drives store a single copy of the non-encrypted key. When you set an administrator password, that key becomes encrypted using that password. You can create up to 4 additional user accounts. Doing so creates an copy of the key (still on the drive) this time encrypted with their password. The commands to change settings on the drive require the administrator password (don't know how the security on that is implemented).

One advantage of doing this all on-drive, is that there is are no commands to read the encryption keys, and thus they can never exist off the drive in unencrypted form.

Re:Key escrow

[Anonymous Coward]

The owner, i.e. the IT dept., gets the main key and the user and others get backup keys.

Most PC's don't have IT departments. You're falling into the common fallacy of automatically assuming the scenario you're familiar with is the only scenario.

Re:Key escrow

[Cyberax]

TPM works like that.

There's a notion of TPM owner - ownership change requires proof of physical presence, and during ownership change you need to enter passphrase.

You can later use this passphrase to extract almost all keys from the TPM module.

Also, I bet there'll be a possibility to dump generated passphrase and print it out.

the unmentioned scary TPM?

[frontloader]

surely the worst part of any of this is the prospect of only 'certified' software applications able to do I/O on one of these hardware based encryption discs - think region encoded DVDs. i bet RIAA and the rest of the IP hounds cant wait for this one to go mainstream.

#3 is not intractable

[davidwr]

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.

#3... is intractable.

The solution is to create a society where LEOs do not insist on having a back-door.

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.

they exist...

[Mr 44]

http://cooldrives.stores.yahoo.net/xb2usb20enha.html

I'll wait until the 3rd generation.

[Anonymous Coward]

It seems reasonable to wait until the third generation of self-encrypting drives. Let everyone else experience the lost data.
Until then, Truecrypt is fine, and has the advantage of not being proprietary. Since the government believes it can operate in secret, proprietary systems may be forced to install back doors.

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.

It is still accessible.

[pavon]

I have one of the seagate encrypted drives. There is nothing about them that is tied to a specific motherboard or TPM chip. The encryption keys are protected by a password, and there are a couple of ways to provide the password to the drive. The computer manufacturer can implement this functionality in the BIOS, and have it prompt for the password on boot (this is what Lenevo does). Alternately the MBR is not encrypted, so you can install a boot loader that prompts for the password, passes it onto the drive and then continues booting (this is what Dell does, using software from Wave Systems).

As long as you remember the password, you can access the drive in another computer. Furthermore, the drive can have upto 5 passwords - an administrator password, and 4 user passwords. A competent computer support center will set the administrator password when they image the machine, handling proper key management across the organization, and have the user select a separate user password. This should should make the chances of not being able to access an encrypted drive low enough for practical purposes.

Re:It is still accessible.

[GMFTatsujin]

Sounds nice. How does it work in external enclosures?

Re:It is still accessible.

[pavon]

I haven't tried yet. I actually have one on order as we speak to try it out. From what I understand, the software from Wave Systems allows you to unlock and lock internal non-boot drives in Windows. I don't see any reason why an eSATA enclosure would be any different, but I don't expect USB enclosures to work.

AFAIK, no one has written Linux client software for doing this or any other password administration yet.

Re:It is still accessible.

[nahdude812]

Most likely the password only decrypts the true encryption key, which is then used for disk access.

I can't say what your setup is like, but the PC laptops where I work have full disk encryption from Safeguard Easy. The actual encryption key is known by the laptop (encrypted with the user's password), and by central management software provided by the software vendor. If a user calls the company's help desk because they forgot their disk encryption password, the laptop offers a challenge which the user can read over the phone to the support tech. That tech enters the challenge and reads a response back to the user to enter.

This challenge/response is an asymmetrically encrypted version of the disk encryption key (so the laptop never has everything it needs to know the disk key unless the user has either first entered their password, or the challenge/response has been successfully performed), which is refreshed each time the authentication happens successfully to protect it from a replay attack.

So this way users can lose their password and IS can still get the laptop to boot, but the laptop is protected from interception by a third party (unless they manage to convince IS Support to unlock it for them with social engineering).

And if such a laptop is stolen

[Skapare]

If the key or passphrase is coded into the system configuration, the perp can see the data, anyway. So surely they would set up these systems so it is required for the assigned user to enter a passphrase for access, perhaps even periodically instead of just when booting or waking up. Then we are back to the weakness of people. Just flip the laptop over and get the key written on the bottom, or just find out the person's spouse's mother's dog's name.

common stupidity dictates...

[cenc]

In my limited experience, what will happen if this was adopted on a wide scale is millions of people will loose their only copy of the grandkids photos and it will be a complete pain. Drives fail more often then they are hacked or used for something that needs that level of security. More typically the whole machine is stolen. It would not for example protect you from a OS level virus, or general internet stupidity.

How often is data stolen from the average user, where the thief has access to the hard drive, and also the knowledge and interest to go dumpster diving in to say a stolen laptop?

My point is that it should be a totally optional or specialized segment thing, not something used across all stock hard drives.

Same as any security exploit in proprietary tools

[pavon]

If it is not securely implemented then people will break it and eventually one of these people will be a white-hat, and will let the community know. If the manufacturer had advertised that the drives were encrypted, and they were in fact not, they will be hit with some pretty damn big lawsuits. Even if the exploit was just a mistake they will likely lose a good number of sales over it.

I don't think this is a risk that any of the major drive makers would be willing to take of for a quick buck. El-cheapo flash drive makers, sure, but not Seagate, Western Digital, or Hitachi.

I got in using

[Technopaladin]

Joshua

Great! More ways to deprive me of my data.

[Anonymous Coward]

I just lost a brand new Samsung 120G drive because my laptop happened to (somehow) send a random password to the ATA drive lock mechanism. Now the drive is a brick :(

AVFS

[sgt scrub]

I'd prefer mandatory antivirus file system for windows machines.

Re: Biometrics are actually pretty bad

[Anonymous Coward]

Hence, the "plus something you know" part.

Re: Biometrics are actually pretty bad

[afidel]

A compromised biometric system is no better than a plain password so it's better to use a smartcard to start with and not risk the biometric hole. Think of biometrics as an unchangeable PIN.

Just about any 5 year old boy

[Anonymous Coward]

Think of the Children-Terrorists!

Were you my babysitter when I was 5?

Sorry about setting your hair on fire and spilling Kool-Aid on your books.

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.

This is no security enhancement.

[jbn-o]

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.

Proprietary encryption is always a bad idea. It doesn't matter what the proprietor's claims are (including what algorithm they claim to use). The only way to verify that there are "no critical bugs and [no] backdoors" is to either verify and compile source code yourself or have a trusted party do this on your behalf. Any software to do this job is complex and all complex software has bugs. You need the freedom to inspect, modify, share, and run the program any time you want. I doubt that software-based encryption is what slows people's read or write access to modern hard drives with modern computers.

Also, as for other people getting your data it really depends on who those other people are. Threats of physical harm or imprisonment (which aren't mutually exclusive) has been very good at getting people's security credentials from them.

Err...

[Anonymous Coward]

I honestly can't tell if you think he was serious and are replying seriously, or if you're just trying to lead everyone else along... *head scratch*

Re:Err...

[Aphoxema]

A little of everything.

good to write down passphrase

[Anonymous Coward]

I think it is a good idea to write down the passphrase and store it in your wallet.

I have several written down and stuck on the back of an expired credit card. The passphrases were generated randomly and consist of at least 8 random chars (upper/lower & digits).

That is the first part of the passphrase, the other is a smaller less secure portion that I remember.

Together I feel this is very strong, because I keep good tabs on my wallet and even if lost, the total passphrase remains unknown (unless I'm tortured). It is unlikely that I will lose both my laptop and my wallet together though.

This verifies that the passphrase can withstand strong brute force. and that the total passphrase is never written down.

I was just reading the EFF suggestions and saw this: https://ssd.eff.org/your-computer/protect/passwords (notice: "Carry your passwords on paper, in your pocket")

Re: Biometrics are actually pretty bad

[Achromatic1978]

Because someone who has taken your little finger to circumvent biometric security might somehow have a moral dilemma about torturing you for your password/PIN? Or that you're going to feel a desire to risk more limb and life for the sake of this security? (Obviously, if you're USSS, maybe...)

But what about a master key?

[SashaMan]

But in corporate environments, I could imagine a case where the drives could be decrypted with two different keys: a user key specific to the drive, and a master key maintained by the IT department. For the master key, different people know different parts of the key (or, for example, half the key is stored in one safe deposit box and the other half in a different box where access to the boxes is by different people). Then, on the disk, the data is encrypted with the user's key, and the user's key is also placed on the disk, itself encrypted with the master key.

Now, if a user forgets their key, it's possible to still get their data, albeit it's more of a pain in the ass.

Marketting dept...

[ieatcookies]

Jim: lets sell self-encrypted harddrives Bob: too whom? Are there people that wander around with plain ole harddrives in their briefcases. Jim: No, but the average Joe will buy them, especially when we scare them with threats of invasion just because they their taxes on thier pc. Jim: profit. Sure, it may prevent your hd from being raped when it's stolen by some goon that peddles crack on the corner. But if someone really wants your data AND has your hd, it's a matter of time.

Biometrics

[Beryllium Sphere(tm)]

>once exposed they cannot be changed to avoid further compromise

Biometrics don't have to be secret. The picture on your driver's license is a biometric.

We're used to thinking in terms of secrecy because passwords have to be secret. They have to be secret because that's the only way to ensure an exclusive relationship between a person and a password. Your exclusive relationship with your face, retinal blood vessel pattern, or fingerprint depends only on having them attached to you (a dependency which leads to one of the real attacks on biometrics).

You need secrecy to make a password usefully secure. To make biometrics secure you need a trusted reading system that can distinguish between copies and originals. A "reading system" can include the human security guard at the entrance who will stop people from holding severed hands up to the handprint reader.

If you depend on keeping biometrics secret then you're doing it wrong.

Offer you cannot refuse

[Voline]

Hello,

I'm From The Federal Government Purchasing Authority. As You Know, The Federal Government Is The Largest Purchaser Of Hard Disk-Equipped Devices In The World. We'd Love To Put Your New Self-Encrypting Hard Drive On Our List Of Devices Approved For Purchase, But First We Require Your Cooperation In Implementing Some Features.

The Nsa And Fbi Have Some Concerns That This Particular Product May Be Used To Facilitate Illegal Behavior: Terrorism, Child Pornography, Piracy Of Major Feature Films, Among Other Threats To Public Safety. So, They'll Require A Way To Decrypt Any Such Device Without The Consent Of It's Owner. Only Then Will We Be Able To Make Our Sizable Initial Purchase Of Your Devices.

Should You Choose Not To Cooperate With Us In This, We May Be Forced To Re-Open Any Previous Approvals We've Given Other Products That You Produce. Also, The Irs May Have Some Questions About Certain Of Your Executive Compensation Practices.

As Businessmen And Patriots, We're Sure We Can Count On Your Cooperation In This.

Sincerely,

John Apparatchik
Purchasing Requirements Conformity Director
National Institute of Standards and Technology
United States Department of Commerce

Wrong target here...

[Anonymous Coward]

I find this wrongly directed. What is really needed is not an encrypted drive that has a password that can be forced from you, by legal or illegal pressure, but a drive that decrypts one way (innocent stuff on it) with one password and another way (the really good stuff on it) with another password. The bad guys, whether they are DHS goons or real terrorists, will always be able to get the goods on you, your real need is something that looks innocent but hides your real stuff elsewhere.

What for?

[KlausBreuer]

It's not only that you cannot trust companies with encryption (the state will insist on a secret backdoor, every time), but if you are caught with a laptop at, say, the border while entering the USA, these guys will do one of two things (or both):

a) confiscate the laptop
b) Force you to give them the key: http://xkcd.com/538/

Encryption might be useful to hide data from your kids/cow-orkers/opponents, but that's about it.

TCG

[Anonymous Coward]

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.

Trusted Computing Group is about implementing a DRM platform. To protect their copyrighted material from you, the owner of the hardware.

Locked out

[AmherstburgVision]

I'd surely end up locked out of my own data.

Just another way to steal your data

[Anonymous Coward]

This is a backdoor into DRM of your own data - systemic agency theft.

TCG is an oxymoron