Self-Encrypting Drives Hardly Any Better Than Software-Based Encryption (cio.com)

itwbennett writes: The main security benefit of Self-Encrypting Drives (SEDs) is that the encryption key is not stored in the OS memory, but on the disk itself, which makes it less exposed to theft. However, some attacks that work against software-based encryption products also affect SEDs, including evil maid attacks and those that bypass Windows authentication. Once a SED is unlocked, it remains in that state until the power to it is cycled or a deauthentication command is sent. When the laptop is put in sleep mode the drive state is locked, but when it resumes from sleep, the pre-boot management software, which is already loaded in memory, unlocks the drive. [A team of] researchers devised three attacks to take advantage of this situation.

Comments

Convenience is the enemy

[Anonymous Coward]

It seems that a lot of these attacks seem to take full advantage that users want convenience rather than security. Stop it. Make it hard. Security is not easy.

Re:Convenience is the enemy

[cfalcon]

Honest question- don't you do this?

I have a book of passwords. Some passwords (like forums) don't have ludicrous constraints, and those are uniform and I can remember them. Others I wouldn't want to reuse, so of course they end up written down.

Compare the following of your own passwords- you should have at least four of these, I'd assume.

Your paypal password
Your bank password
Your facebook password
Your smartphone account password
Your brokerage account password
Your credit card account password
Your ISP account password
Your primary email password
Your domain hosting account password

Is there some overlap? What's safer- memorizing all of these by having them generally be the same, or having a book and they are all different? The ideal solution, having each unique and memorized, is quite the challenge. I choose to not duplicate stuff like this remotely, because if any of these guys get hacked, I don't want to lose all the others. You generally want to assume that any remote server stores your password in plaintext, and will deliver this plaintext password to anyone with admin access to any of their machines. This may not literally be the case, but there's no legal assurance that it is not- nor any assurance that they would actually fess up to being hacked.

The other reason you need a password bank of some sort is that there's a bunch of "metapasswords". Many of the social engineering attacks go like this:

Step 1- Fraud calls up and claims to be You. Fraud forgot his password!
Step 2- Important key account, such as your domain hosting account (which holds yourname@yourdomain.com, or your website), asks "authentication questions".
Step 3- Unlike your password, which has two capitals two lowercase three specials two numbers no dictionary no repeat no keyboard pattern no sequential no common words, these "authentication questions" are available to anyone who knows the first thing about you, and / or has access to the internet. "First childhood pet" is guessable sometimes. "What was your high school" is almost always googlable. Even "first girlfriend name" can be guessed, and Fraud has plenty of tries.
Step 4- Once he has a key account, he can send "forgot my password" requests to other places. This usually can result in a multi-own type of scenario, where your now redirected email acts as a key to totally own you.

So those dumb questions normally need to be selected to be something that can't be chosen, and in some cases, you have to make something up- better write that thing down too!

Super frustrating.

Fun fact: I was creating an account earlier this week. My password for this involves two made up (non dictionary) words, and a numeric sequence. It refused the password twice- first because I "repeated a character three times" (the letter "L" appeared twice in the first word, and once in the second, not adjacent or anything), and then because it was "too long" (we all know secure passwords are 12 characters or less, I guess?).

Re:Convenience is the enemy

[interval1066]

Nope. Was keeping my passwords in a plain text file on my phone and encrypting that directory, but that got to be kind of cumbersome. Now I'm going to sound like a shill (for myself) but I decided to write my own password app. Probably not as slick as your "Keepass" thingy there, but I've looked at a number of apps and all fall short in my eyes, they usually do waay too much or waaay too little than what I need. Mine is simple; it keeps all my passwords together in one spot, and the list is exportable as an xml file (the passwords are encrypted using aes-256). I can export all my passwords to another phone (or tablet) or even to my pc if I want (which means I'll have to create a manager of some kind for the pc if I want to go that far). Its like 80% done (just wrote the export code in today in fact), and it'll be done in a few days I think. I'm not trying to shake up the world here, its just been a nice little exercise in android development and I get a nice little password database that does exactly what I need it to do. This is not a commercial app, but if you want a copy let me know and I'll post the link to it on the app store as soon as I have it done. It will be beer free and nagless. So if you find a bug FIX IT YOURSELF.

Summary lesson: Physical access trumps all.

[idontgno]

All the example attacks cited in the article, and the evil maid attack in the summary, require uninterrupted physical access to the computer. While the specific techniques are interesting, they're all just applications of the the first principle that if an attacker gets unimpeded access to the hardware they're attacking, you have no defenses left.

If your computer is stolen, the lesson here is to assume it's compromised because physical access trumps all.

Makes you wish you could install anti-tamper self destruct on such systems.

Re:Summary lesson: Physical access trumps all.

[cfalcon]

I mean, you can, but anti tamper is both expensive and subject to serious workarounds.

Re:Summary lesson: Physical access trumps all.

[reub2000]

The whole point of full disk encryption is to protect against someone who has physical access to the disk. In case it gets stolen, thrown in the trash, or sold. It does nothing against remote attacks.

Now my understanding is that the advantage self-encrypting disks is that you don't have the overhead incurred by software encryption.

Re:Summary lesson: Physical access trumps all.

[FuegoFuerte]

With SED drives, depending on the system architecture, the key to unlock them is often stored on the controller (think servers, here). So, if you steal a drive or find a drive in the rubbish bin, etc., you can't access it, but if you get the whole server or the drives + controller, you have full access, nothing else required. The big benefits to SED drives are: 1) MUCH faster than software-based FDE. The encryption basically happens at drive speed, and when you build a larger array, there's no slowdown - the encryption scales with the number of drives, since each disk has its own controller doing the encryption. 2) Instant Secure Erase - this wipes out the encryption keys in the drive's controller, rendering the original data permanently unrecoverable (assuming the encryption itself isn't broken). So, you can dispose of the drive (or RMA it) without worry that your corporate secrets are going to float out into the world. So, expensive "keep your hard drive" support plans can go away, as can expensive drive shredding services.

Self encrypting hard drives are WORSE!

[cfalcon]

Self encrypting hard drives require trusting the code in the drive to be correct. While there are places people are willing to trust proprietary code, this should not be one of them. Proprietary code creates a "break once, own anywhere" setup, in the one place where that is the most ludicrous thing.

Who has the keys? Does the manufacturer have the keys? That seems to be the case, and what your password becomes is a way to unlock the copy of the key that the device has. This means when you change the password, you aren't actually changing the encryption key (which in some of the vulnerable drives cases here, was actually available on the goddamned drive in plaintext, but in the best case is hashed, and in ALL cases is in theory known to the drive manufacturer).

If you have data worth encrypting, you should use software based encryption. It doesn't require special tools to uncover mistakes, and the mistakes that we've seen already (including *just leaving the fucking key plaintext*) are really amateur level shit.

Then we have another problem- even IF the key is properly maintained, and even IF the manufacturer doesn't have a cabinet full of keys, how did they generate those keys? How is their random number generator? Remember, it's going to be just ONE target for an attacker here, since the keys all have a common source, so any mistakes are much more likely to be discovered, and much more likely to function.

Open source software encryption or gtfo. Bonus: You can choose an algo, or stack algos. AES-128 / AES-256 not to your liking? Layer them with Twofish and Serpent, or drop it in favor of those. You may not need to take the performance hit, but shouldn't it be your choice?

Software encryption is actually encryption. Hardware encryption is someone's marketing stunt.

Re:Self encrypting hard drives are WORSE!

[Anonymous Coward]

Speaking as someone with some knowledge of SED (work on them with a manufacturer, but I will not speak for them, so leaving them as simply one of the major manufacturers), I can say that the manufacturers have access to the default password as well as the 'reset' password (which we are required to delete), the reset password will crypto-erase the drive, so there is a potential for data loss, but not data leak.

Also, there is nothing saying you can't have both hardware and software encryption, you just need to enter two passwords instead of one.

I can also say that our 'random source' for the key is pretty secure, and is based on drive 'noise'.

Re:Self encrypting hard drives are WORSE!

[larryjoe]

Self encrypting hard drives require trusting the code in the drive to be correct. While there are places people are willing to trust proprietary code, this should not be one of them. Proprietary code creates a "break once, own anywhere" setup, in the one place where that is the most ludicrous thing.

True, you have to trust the closed source firmware to do the right thing. This is hard to get around.

Who has the keys? Does the manufacturer have the keys?

Keys are generated by the device, so the manufacturer doesn't know the keys.

Then we have another problem- even IF the key is properly maintained, and even IF the manufacturer doesn't have a cabinet full of keys, how did they generate those keys? How is their random number generator? Remember, it's going to be just ONE target for an attacker here, since the keys all have a common source, so any mistakes are much more likely to be discovered, and much more likely to function.

In generating random keys, a mechanical HDD (not sure about SSDs) is perhaps ideal for generating randomness (there are patents on this). It can quickly generate true random keys without worrying about seeding entropy to generate pseudo-random keys.

Re:Self encrypting hard drives are WORSE!

[FuegoFuerte]

You've clearly never researched how SED drives work. No one has "the key for the drive," it's generated by the drive on the fly. The drive ships unsecured, and when you secure it, it generates a new encryption key using the passphrase you supply. When you Instant Secure Erase the drive, it throws out the old keys and generates new ones. You can revert the encryption settings back to factory default, but you lose all data in the process. On top of that, on the better drives, all of this is reviewed by NIST for FIPS compliance.

Software encryption requires a couple of sufficiently motivated and clever Russians to break. Proper hardware encryption requires far more motivated, clever, and trained NSA engineers.

Actually, way worse

[AdamInParadise]

On one hand, the code of software-based encryption solutions such as TrueCrypt and dm-crypt can and has been audited. It is also easy to update if a problem is found. On the other hand, a SED is a blackbox. You have no idea about what's going on inside. For all you know, the drive is just locked with a password and the data is not actually encrypted. Furthermore, the reports of people who take a peek inside the blackbox can usually be summarized as "It's crap", and this research is just one additional example. What do you expect from companies who don't have to prove that their product are secure?