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.
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.
Is this one of the attacks?
https://xkcd.com/538
Sebfgl Cvff!
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.
Welcome to the Panopticon. Used to be a prison, now it's your home.
no wonder we've turned to POT (Personal Open Terminal) we're all on 24/7... 99.9999% of us are up to mostly good.... talk about a fixed race?
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 the keyboard (Oh, you're going to TPM that too? Fine, we install a sensor under every key.)
- The evil maid watches you type in the password (Oh, you looked for that? You didn't notice teddy bear left in your room. It has a camera in it.)
I would argue both of those are actually a lot easier than whipping up some custom firmware.
The evil maid attack is on the same level as the $5 wrench attack: If you're going to these sorts of lengths, why not just hire goons to break your legs and offer to let you keep the legs of the rest of your family intact if you give them your password and laptop.
these attacks rely on the user leaving their device unlocked and unattended....... What exactly is the story here?
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.
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?
Nobox: Only simple products.
A different aspect of security has been overlooked. Encrypted files are secured but they cannot be used without being decrypted. Once decrypted, they are no longer protected, at least for the duration of usage until they get encrypted again.
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.
Isn't the expectation of this stuff, that it's generally going to be not as good as what your OS does?
From the OS' point of view, hard drive encryption is met with a smirk and "anything you can do, I can do better." The upper bound of hard drive encryption is that some day, it may become as good as OS encryption. But that's the upper bound: you will normally expect it to be inferior.
What about speed? I'd expect the security/encryption to be roughly the same between hardware and software encrypted drives, though the article suggests hardware is worse. But, encryption/decryption takes time and CPU.
I'd expect the big advantage with self encrypting drives to be the hardware based encryption/decryption speed and lack of need for CPU cycles. However, I have seen several drives that advertise themselves as self encrypting that simply have TrueCrypt like software already on the drive, but the processing still happens in the CPU. I can see no advantage to these.
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?
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.
Moderated Usenet
This just illustrates that the most secure system is the most inconvenient. Sure you could require a password with every read/write, but then it'd be useless.
"Self-Encrypting Drives Hardly Any Better Than Software-Based Encryption "
Another way of saying that is, "Self-Encrypting Drives Slightly Better Than Software-Based Encryption"
Get physical access to the drive and you know exactly where the key can be read off it and accessed every time. These wouldn't protect you from government snoopers at all. Even with the known weaknesses truecrypt would be more likely to defeat the FBI than one of these.
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.
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 "personally" is yourself or the relative whose computer you'll be fixing over Thanksgiving.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I think it's remarkable that KPMG is attempting to profit from the research of others -- they have not presented novel research but have merely repackaged the following: https://www1.informatik.uni-erlangen.de/filepool/projects/sed/seds-at-risks.pdf
Intriguing also that if KPMG truly believed this vulnerability had been recently "discovered" by their team, why they would expose their own clients to security risk by releasing this information publicly before a patch had been issued by the vendor.
Firmware based encryption, has it been externally audited?
Software HAS been audited (TrueCrypt code base)
This is the real issue, trust not performance.