Self-Encrypting Drives Hardly Any Better Than Software-Based Encryption (cio.com) 73
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.
Convenience is the enemy (Score:2)
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: (Score:2)
The flip side, is if security is too hard, people will be more lax with it.
There isn't any perfect security, at best you can diversify your threats so any one type of attack will have limited scope.
Re: (Score:2)
Re: (Score:3)
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 accou
Re: (Score:3)
Re: (Score:1)
Holy shit if you're serious you need to visit keepass.info right fucking now.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That's worst advice about security I've ever heard.
Re: (Score:2)
Well, yes, the drive remains unlocked in sleep mode but locks if you hibernate. Someone with hardware that doesn't suck cloud easily resume from sleep, let the bios unlock the drive and then switch the hardware over to the PC of choice and copy off the decrypted data.
This is not a strike against the encrypting drives, it's a question of user training: the drive is locked in these situations and unlocked in those. If you want it locked, do this not that.
Re: (Score:2)
Put another way, the article complains that your car isn't secure when the key is in the ignition and the car is idling in the garage. True. So what?
Oblig XKCD (Score:1)
https://xkcd.com/538
Summary lesson: Physical access trumps all. (Score:4, Interesting)
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: (Score:3)
I mean, you can, but anti tamper is both expensive and subject to serious workarounds.
Re: (Score:3)
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: (Score:2)
"Apply directly to your hard drive!"
"Apply directly to your hard drive!"
"APPLY DIRECTLY TO YOUR HARD DRIVE!"
It's still software encryption (Score:2)
Sure, it's done in the little microcontroller that runs the hard drive instead of the CPU, and might even have ASIC help, but it's still software encryption, and from a crypto perspective there's the question of "how badly did they store the keys?"
The real advantage of self-encrypting disk drives is that you don't have to depend on the administrator remembering to install a decent software encryption system in the OS. (This applies both to corporate laptops and to personally administered ones, whether "per
Re: (Score:2)
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.
I thought the entire point of full disk encryption was to keep your data safe even if the computer is stolen. If FDE is not effective against that, then why bother? It's not like FDE protects you from online attacks so if it can't protect you from physical theft, what can it protect you from?
Re: (Score:2)
It's not like a deadbolt prevents your house from being broken into, or a locked door on your car, but it's a lot better than nothing.
Drive encryption likely stops the casual thief, but it's not perfect. And like the XK
Re: (Score:2)
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
Re: (Score:2)
From TFA:
The attacks they demonstrated show that the Opal and eDrive standards can't guarantee the security of data in situations where a laptop is in sleep mode and not turned off completely.
No shit. If you use the best software encryption available and they get to your machine while the encrypted drive is mounted and the key is in memory, you are screwed. For once the summary and headline are accurate. Self encrypting drives are not any more secure, just faster because there is virtually zero loss of performance.
Re: (Score:2)
> there is virtually zero loss of performance
[citation needed]
Re: (Score:2)
If your computer is stolen, the lesson here is to assume it's compromised because physical access trumps all.
If your computer is stolen while the drive is in an unlocked state. If you steal my encrypted drive when it's powered down, and you don't have my password, and my password is good, and the implementation of the key derivation function doesn't suck, you're out of luck even with complete physical control.
Yes, there are a lot of ifs there. Defeating an attacker with physical possession is not easy. It's not impossible, though.
Shitty article (Score:1)
The shitty article about "evil maids" is idiotic. If we assume that you are granting physical access to the machine to someone, and that someone will be messing about with the software or hardware on the machine in such a way as they can steal your key, the answer given in the article is shit. Trusted computing is not a useful answer. Making the computer unable to boot because the software plugs only one evil maid attack vector. Here are some more evil made attack vectors:
- A bug is implanted in
In short (Score:2)
Re: (Score:2)
Correct.
If you don't maintain positive control of your hardware, there is little you can really count on security wise. Drive encryption is nice, but if you give physical access to an attacker, all you've done is made his job a bit harder.
Re: (Score:2)
these attacks rely on the user leaving their device unlocked and unattended.......
What exactly is the story here?
That people might have been under the already clearly false illusion that their data was protected when the laptop wasn't shutdown properly. I could see people closing a laptop lid and the laptop goes to sleep (but not shutdown) and people think they are being protected by an encrypted drive... when really the simple rule to follow with an encrypted drive is that you need to fully shutdown your laptop if you are going to leave it unattended.
Self encrypting hard drives are WORSE! (Score:5, Insightful)
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: (Score:2)
I'll add something to this- an open hardware platform, with the code and chips available to review, would avert this. Then hardware encryption would have merit, and even some advantages over software. To the best of my knowledge, this in no way exists.
Re: (Score:2, Interesting)
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 t
Re: (Score:2)
I'm glad to hear that there's a physical generation for the random numbers, but do all the manufacturers do this?
If you use JUST software encryption, your vulnerability is to something scooping the RAM while you are mounted, or cold boot attacking your RAM.
If you use JUST hardware encryption, you face similar attacks, but to the hard drive itself, which seems more secure- but the flipside is all the stuff about password banks.
I guess my point is- prove to me that the encryption key itself is not stored by t
Re: (Score:1)
Does the manufacturer have the keys? That seems to be the case, ... and in ALL cases is in theory known to the drive manufacturer.
Have you got any evidence of this? It would be a major news if *every* HDD manufacturer was back-dooring their drives in this way. Although it certainly sometimes happens [vice.com].
How is their random number generator?
Hardware RNGs are preferred to software CSPRNGs
Re: (Score:2)
> Have you got any evidence of this?
I'm pointing out a theoretical problem, and I call it out as such. Here's the issue: if they have access to the encryption key at any point, they could store it and have it later. That's a fundamental vulnerability with a system like this- why on earth would you trust anyone else but you to make your encryption key? It seems so unlikely that they wouldn't get NSLed to keep all the keys in case of later subpeona, at the very least.
Here's how you can disprove this th
Re: (Score:2)
Sorry, 32 bytes. Argument unchanged, but two many 8s in my head.
Re: (Score:3)
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: (Score:2)
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.
There's no point in random keys for this application, in fact they're a bad idea unless you have some sort of tamper-resistant hardware in which to store them, and even then it's questionable. If you generate random keys, they have to be stored in the drive firmware, which makes them accessible to an attacker who has physical possession of the drive.
In this application, the keys should be derived from a user-provided password which must be entered at boot. The drive's firmware should use a good password-b
Re: (Score:3, Informative)
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 N
Re: (Score:1)
"No one has "the key for the drive," it's generated by the drive on the fly."
You don't know that for sure. That is the entire point. You are ASSUMING that is the case. You can't see the code so you don't know.
Re: (Score:1)
You're making some pretty big assumptions yourself, there.
Re: (Score:2)
No, he's not. If you google, you find that the architecture seems to be: key is created by manufacturer. Key is ideally locked up behind a user passphrase. User enters passphrase, key is available to drive. But you can't change the key, and they were the ones that made it.
Like here:
http://www.extremetech.com/com... [extremetech.com]
Why not post a link to something that shows another hard drive with a key that is variable and never exposed in plaintext to the manufacturer?
Re: (Score:1)
http://www.trustedcomputinggro... [trustedcom...ggroup.org]
Real SED drives implement this standard, which includes the disk changing the key - it's how Instant Secure Erase works, among other things (old key is thrown out, new key is generated by the hard drive). If the WD product really behaves as described in that link, then I'd agree - that implementation of the controller is flawed (and also, not TCG/Opal compliant, I'd wager). More than likely, the drive inside the enclosure implements the standards correctly (or nearly so),
Re: (Score:2)
> No one has "the key for the drive," it's generated by the drive on the fly.
Well, who knows? I mean, here's this:
http://www.extremetech.com/com... [extremetech.com]
Ok, lets look at some of this text:
"Passport drives that use the USB bridge for encryption rely on either AES-128 or AES-256 to create an encryption key. The researchers refer to this as the DEK (Data Encryption Key). The DEK is set at the factory (all of the drives tested used a 256-bit DEK). The user is then allowed to set an individual password, called the
Actually, way worse (Score:3)
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?
Missing something (Score:1)
Whereas, on disk level encryption, even if a file (encrypted by software) gets decrypted, it's still inhering another encryption level at disk as a whole.
Re: (Score:1)
What about TPM? (Score:2)
My laptop has a tpm chip - I understand that on balance this is supposed to help, but where does this fit into the landscape compared with the two alternatives in the summary?
Re: (Score:2)
Hardly Any Better != worse (Score:1)
Hardly Any Better
doesn't mean worse. Basically this is saying that while SEDs are not vulnerable to a “cold boot attack” like software encryption, it is vulnerable to equivalent attacks.
The answer to all these attacks is to always completely shut down, never sleep, your laptop.
Re: (Score:2)
Or you can just unplug your encrypted drive, or set it to power down.
Security v Convenience. (Score:2)
Self-Encrypting Drives Hardly Any Better Than Soft (Score:1)
Another way of saying that is, "Self-Encrypting Drives Slightly Better Than Software-Based Encryption"
Better? Sounds worse. (Score:2)
This was a known limitation (Score:1)
I was a sales engineer for a company that sold software that managed the Opal SED's. We knew, and told, customers that Sleep mode completely bypassed the drive authentication. Our software disabled Sleep mode in Windows and forced Hibernate instead because of this. It's been 4-5 years at this point so who knows if that's still the case. My point is though this is less "discovery" as much as a known limitation that anyone doing a POC or asking good questions in a demo would have know about.