Slashdot Mirror


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.

73 comments

  1. Convenience is the enemy by Anonymous Coward · · 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.

    1. Re:Convenience is the enemy by jellomizer · · Score: 1

      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.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    2. Re:Convenience is the enemy by PRMan · · Score: 1

      Security is a circle. If you make it too hard, the person will just write out all the steps (including the passwords) on a legal pad and keep it in their briefcase.

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    3. Re:Convenience is the enemy by Anonymous Coward · · Score: 0

      if security is too hard, people will be more lax with it.

      Toughen the &#$% up, Nancys! Security is hard. If you're being lax with it, you're doing it wrong. There should be a computing security bootcamp complete with a drill sgt.

    4. Re:Convenience is the enemy by aaaaaaargh! · · Score: 1

      That's worst advice about security I've ever heard.

    5. Re:Convenience is the enemy by Anonymous Coward · · Score: 0

      Perhaps someone who isn't serious about security shouldn't be allowed to take a position in which they are responsible for sensitive information.

    6. Re:Convenience is the enemy by Spazmania · · Score: 1

      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.

      --
      Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
    7. Re:Convenience is the enemy by cfalcon · · Score: 2

      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?).

    8. Re:Convenience is the enemy by Spazmania · · Score: 1

      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?

      --
      Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
    9. Re:Convenience is the enemy by Anonymous Coward · · Score: 0

      Uhhh, never heard of Keepass? It is cross platform. Put the databases on Dropbox then you can access them on all your devices.

    10. Re:Convenience is the enemy by Anonymous Coward · · Score: 0

      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.

      Yup, that's why I use paper for anything important. Lock the door throw away the key, then burn the room.

    11. Re:Convenience is the enemy by interval1066 · · Score: 2

      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.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    12. Re:Convenience is the enemy by sexconker · · Score: 0

      Holy shit if you're serious you need to visit keepass.info right fucking now.

    13. Re:Convenience is the enemy by interval1066 · · Score: 1

      Why? You make it sound like your ass is on fire.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    14. Re:Convenience is the enemy by arglebargle_xiv · · Score: 1

      Yeah, sorry about that, it was the chili. I'll have to remember to make it less hot next time.

  2. Oblig XKCD by Mantrid42 · · Score: 0

    Is this one of the attacks?

    https://xkcd.com/538

  3. Sebfgl Cvff! by Anonymous Coward · · Score: 0

    Sebfgl Cvff!

  4. Summary lesson: Physical access trumps all. by idontgno · · Score: 3, 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.

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
    1. Re:Summary lesson: Physical access trumps all. by cfalcon · · Score: 2

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

    2. Re:Summary lesson: Physical access trumps all. by Anonymous Coward · · Score: 0

      Unless, of course, the system is completely shut down. Then you are having to overcome some pretty substantial roadblocks, unless, of course, you return the computer, properly infected, to the user.

    3. Re:Summary lesson: Physical access trumps all. by reub2000 · · Score: 2

      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.

    4. Re:Summary lesson: Physical access trumps all. by Anonymous Coward · · Score: 0

      And Head-on is sold to treat headaches. Magnet bracelets are supposed to help with joint pain. Herbal medicines are supposed to do...anything.

      Just because its "The whole point" doesn't make it effective.

    5. Re:Summary lesson: Physical access trumps all. by Anonymous Coward · · Score: 0

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

      Except these attacks don't apply to such a situation at all. They all require compromising the computer, then getting the user to enter the password/key. If you just steal the computer, then you won't have the key to decrypt the drive.

    6. Re:Summary lesson: Physical access trumps all. by hawguy · · Score: 1

      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?

    7. Re:Summary lesson: Physical access trumps all. by PRMan · · Score: 1

      "Apply directly to your hard drive!"

      "Apply directly to your hard drive!"

      "APPLY DIRECTLY TO YOUR HARD DRIVE!"

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    8. Re:Summary lesson: Physical access trumps all. by cdrudge · · Score: 1

      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?

      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 XKCD comic, if they REALLY want the contents of your drive, they're going to use a $5 wrench as the master key.

    9. Re:Summary lesson: Physical access trumps all. by FuegoFuerte · · 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 - 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.

    10. Re:Summary lesson: Physical access trumps all. by AmiMoJo · · Score: 1

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    11. Re:Summary lesson: Physical access trumps all. by swillden · · Score: 1

      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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    12. Re:Summary lesson: Physical access trumps all. by Anonymous Coward · · Score: 0

      True but at this point things like AES-NI make "software" encryption a non-issue. My old little cheap i3-4130T processor can do 256-bit XTS AES at over 2 terabytes per second and 512-bit XTS at over 1.5 TiB/s. There is no point in moving this to the hard-drive where you can damn well expect serious security flaws because hard-drive firmware is developed almost exclusively by hardware engineers that can't write software for shit and it's difficult to patch.

    13. Re:Summary lesson: Physical access trumps all. by allo · · Score: 1

      > there is virtually zero loss of performance
      [citation needed]

  5. imaginary secrets can kill us? by Anonymous Coward · · Score: 0

    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?

  6. Shitty article by Anonymous Coward · · 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 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.

    1. Re:Shitty article by Anonymous Coward · · Score: 0

      You complain it is too hard to get some custom firmware, something you can just download as a script-kiddie after the hard work was done once by some bored hacker. But then you suggest putting a bug in the keyboard, which might require custom hardware for a laptop if going with the hotel room example? At least using a camera can use cheap, off the shelf hardware, but still more than just a thumbdrive. You might as well have included a TEMPEST style attack in your list.

      But why worry about people running around with extra hardware pretending to be spies, when ignoring how putting random thumbdrives into computers has been an actual problem in the wild?

    2. Re:Shitty article by Anonymous Coward · · Score: 0

      Keyloggers are not expensive nor complicated:

      http://www.amazon.ca/Keyllama-4MB-USB-Value-Keylogger/dp/B004ZGXU48

      (Yes, I'm aware it would be more complicated for a hotel room laptop, but then we can go for the camera)

      http://www.amazon.ca/Security-TB300-Teddy-Camera-Hardwired/dp/B00W8JI3XC/ref=sr_1_1?s=electronics&ie=UTF8&qid=1447446285&sr=1-1&keywords=teddy+bear+camera

      Clicking on buy isn't exactly electrical engineering! :)

      The article is simply worrying about high level spy stuff. If we are going into that territory, custom hardware isn't a big deal.

  7. In short by phishybongwaters · · Score: 1

    these attacks rely on the user leaving their device unlocked and unattended....... What exactly is the story here?

    1. Re:In short by bobbied · · Score: 1

      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.

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    2. Re:In short by bigpat · · Score: 1

      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.

  8. Self encrypting hard drives are WORSE! by cfalcon · · Score: 4, 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.

    1. Re:Self encrypting hard drives are WORSE! by cfalcon · · Score: 1

      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.

    2. Re:Self encrypting hard drives are WORSE! by Anonymous Coward · · Score: 0

      This is one of the reasons I do not trust phones (SoC).

    3. Re:Self encrypting hard drives are WORSE! by Anonymous Coward · · 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 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'.

    4. Re:Self encrypting hard drives are WORSE! by kevlar_rat · · 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.

      How is their random number generator?

      Hardware RNGs are preferred to software CSPRNGs

    5. Re:Self encrypting hard drives are WORSE! by larryjoe · · Score: 2

      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.

    6. Re:Self encrypting hard drives are WORSE! by FuegoFuerte · · 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 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.

    7. Re:Self encrypting hard drives are WORSE! by cfalcon · · Score: 1

      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 the manufacturer. That seems like it would be hard even if you worked there (what if they don't want it common knowledge, but want to be able to respond to warrants?), and it seems REALLY hard to say it in general- even if the guys you work with are totally privacy oriented, that doesn't help us about them in 10 years, and it doesn't help us about every other company now.

      I agree you'd get more security from hardware and software (with two passwords) than just one- but if you are going to have just one, the answer is an open source software solution, without any hesitation or argument.

    8. Re:Self encrypting hard drives are WORSE! by Anonymous Coward · · 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.

    9. Re:Self encrypting hard drives are WORSE! by FuegoFuerte · · Score: 1

      You're making some pretty big assumptions yourself, there.

    10. Re:Self encrypting hard drives are WORSE! by swillden · · Score: 1

      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-based key derivation function to make brute force harder, and it must not store either a copy of the plaintext key anywhere, or even anything easily derived from the key. If the drive wants a quick way to check if the password is correct, it should store a secure hash of the derived key.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    11. Re:Self encrypting hard drives are WORSE! by cfalcon · · Score: 1

      > 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 theory: find some legally binding document that states that these keys are not being kept, preferably with large civil penalties attached explicitly or implied.

      Why would you trust some machine you don't control, in a known location for an adversary to attack, to not keep the key? Think how easy that is, how small that key is. 256 bit key is just 8 precious bytes. That's smaller than the serial number- trivial to keep a hold on anywhere in that machine.

      I don't need to prove they are keeping the keys for it to be a theoretical vulnerability. Each manufacturer needs to prove they aren't keeping the keys.

    12. Re:Self encrypting hard drives are WORSE! by cfalcon · · Score: 1

      Sorry, 32 bytes. Argument unchanged, but two many 8s in my head.

    13. Re:Self encrypting hard drives are WORSE! by cfalcon · · Score: 1

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

      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 KEK. The factory-set DEK is itself protected by a static hash value, common to all WD Passport drives, called the KEK8. The KEK8 is hard-coded into the firmware of every drive. once you’ve cracked one WD Passport, you’ve cracked the DEK on every Passport. "

      Ok! So, this this is crapping on the fact that once you have cracked the "KEK8" (kek!), then you can use that to get the DEK on any drive. Once you have the DEK, you can decrypt the data.

      Now, pretend that they didn't fuck this up (which they did), but instead had a unique KEK8 on every drive. This vulnerability wouldn't exist then, and presumably all these articles would not have happened...

      But...

      The DEK is still HARDCODED. It is, absolutely, the key to the drive, and it is, absolutely, set at the factory. Now, why wouldn't they keep this little 32 bit value? You know, in case.

      So, here's one drive type, from a major manufacturer, who generates the DEKs at factory, one for each drive, and they never ever change.

      At no point does the drive generate a new encryption key with the password you supply- the DEK is constant for the life of the drive.

    14. Re:Self encrypting hard drives are WORSE! by cfalcon · · Score: 1

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

      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?

    15. Re:Self encrypting hard drives are WORSE! by FuegoFuerte · · Score: 1

      http://www.trustedcomputinggro...

      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), and the problems are in the USB controller side of things. SED drives are not very user-friendly, and WD was probably trying to mask that.

  9. Actually, way worse by AdamInParadise · · Score: 2

    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.
  10. Missing something by sentiblue · · Score: 1

    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.

    1. Re:Missing something by kevlar_rat · · Score: 1

      You're thinking of 'WinZip' style encryption, there are apps nowadays that do 'virtual drive' encryption and encrypt/decrypt on the fly, like a SED.

  11. Why would anyone take this seriously? by Anonymous Coward · · Score: 0

    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.

  12. What About Speed? by Anonymous Coward · · Score: 0

    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.

    1. Re:What About Speed? by Anonymous Coward · · Score: 0

      Except for SSDs and maybe 10k+ RPM drives the reality is that modern CPUs can perform AES *way* faster than the drive can read or write most data, except maybe long continuous chunks. There's a small hit on writing the first block since it has to be encrypted before the drive can begin, but once that's sent to the drive the CPU has all the cycles in the world.

  13. What about TPM? by pr100 · · Score: 1

    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?

    1. Re:What about TPM? by neo-mkrey · · Score: 1

      The Phantom Menace sucked.

    2. Re:What about TPM? by Anonymous Coward · · Score: 0

      If using Windows, turn it on, enable it (tpm.msc is the command) and turn on BitLocker (saving the recovery key off just in case.) Transparent encryption. Just make sure to suspend BitLocker before rebooting when you do a Windows update or add a feature like Hyper-V.

      You can also add a PIN/password that is enforced by the TPM, and because the TPM will just keep adding exponentially longer delays, and since it unwraps the key, barring someone who can decap a security chip without triggering a zeroize function, brute force PIN guesses are effectively impossible.

  14. Hardly Any Better != worse by kevlar_rat · · 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.

    1. Re:Hardly Any Better != worse by NostalgiaForInfinity · · Score: 1

      Or you can just unplug your encrypted drive, or set it to power down.

  15. Security v Convenience. by blueshift_1 · · Score: 1

    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.

  16. Self-Encrypting Drives Hardly Any Better Than Soft by blogagog · · Score: 1

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

  17. Better? Sounds worse. by shaitand · · Score: 1

    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.

  18. This was a known limitation by xijix · · 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.

  19. It's still software encryption by billstewart · · Score: 1

    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
  20. KPMG Taking Credit for Vulnerability Research by Anonymous Coward · · Score: 0

    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.

  21. performance vs trust? by Anonymous Coward · · Score: 0

    Firmware based encryption, has it been externally audited?

    Software HAS been audited (TrueCrypt code base)

    This is the real issue, trust not performance.