Announcement

Collapse
No announcement yet.

OPAL Self-Encrypting Drive Support For Linux Steps Closer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OPAL Self-Encrypting Drive Support For Linux Steps Closer

    Phoronix: OPAL Self-Encrypting Drive Support For Linux Steps Closer

    An Intel developer has sent out the latest version of his patches for implementing the Self-Encrypting Drive (SED) protocol support for the Linux kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Typo:

    Originally posted by phoronix View Post
    Trusted Computing Grouo's

    Comment


    • #3
      Originally posted by tildearrow View Post
      Typo:
      Fixed, thanks.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        Ummmmmmmmmmmmmmm......... thanks but nope.

        not trusting a firmware (and even less a proprietary one) to:

        1. run encryption reliably (i.e. not lock up or fuck up and lose my data)

        2. be actually secure.

        Comment


        • #5
          Originally posted by starshipeleven View Post
          Ummmmmmmmmmmmmmm......... thanks but nope.

          not trusting a firmware (and even less a proprietary one) to:

          1. run encryption reliably (i.e. not lock up or fuck up and lose my data)

          2. be actually secure.
          You do realize that any SED drive is always encrypting the data, the only difference is if you need to provide a password to unlock it or not. I've been using the encryption feature of my ssd and so far I've had no problems.

          These kernel patches do seem interesting as they will provide S3 support, they do open a new attack vector though, the password will be stored in ram at all times. It also seems to me this might be trying to do a bit too much, there is already sedutil[1] for setting up and managing SED drives and implementing more than needed to unlock the drive does seem like feature creep.

          [1] https://github.com/Drive-Trust-Alliance/sedutil

          Comment


          • #6
            You know what makes me think these hardware encrypting options are backdoored? You never hear about the FBI whining that they can't get in (like they do about iPhones).

            Hardware encryption is the best. And it saddens me greatly that the only one I trust with it is Apple. Would love for someone to prove me wrong.

            Comment


            • #7
              Originally posted by R00KIE View Post
              You do realize that any SED drive is always encrypting the data, the only difference is if you need to provide a password to unlock it or not.
              Yes. Does not make a closed firmware more trustworthy.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                Yes. Does not make a closed firmware more trustworthy.
                I never said it did, I was only pointing out that SEDs are not data eating evil devices, a lot of people use them and if there was any big data loss problem we would have heard about it by now. Also point us to _any_ modern hard disk or SSD that does not have a closed firmware, by your logic that makes them all untrustworthy and unusable. If you want to go down that route you should also avoid any modern CPU or GPU.

                Comment


                • #9
                  Uh? What's the point of these patches? What do they add that sedutil already doesn't?
                  SED is very useful, but I don't trust the firmware. That's why I also use software encryption on my linux partition.
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #10
                    I agree: if these things had no backdoors you'd see news articles about Daesh et all using them and the government being unable to unlock them. In some countries like the UK the manufacturers could even face criminal charges for selling unbreakable encryption commercially unless key disclosure laws exempt OEMs. Even in the absence of intentional cooperation it only takes one programmer on the team who is compromised by a government agency to leave a backdoor. Maybe paid off, maybe offered a pass on a drug charge, could be anything.

                    No form of encryption can be trusted unless it is auditable by mutually opposing parties. There is a good reason the NSA itself does not attempt to use closed cipher algorithms, instead holding open competitions leading to standards like AES. From the NSA's viewpoint, the "one compromised programmer" problem would otherwise still apply, only the identity of the outside attacker changing.

                    It is for this reason that for use against state-level attackers any closed commercial encryption can only be trusted as en extra layer of encryption with its own separate keys and own separate passphrase, like encrypting an iPhone which in turn is carrying an encypted DM-Crypt container between two locations. That iPhone may or may not be crackable, a failed attempt to get in means the passphrase on your DM-crypt container does not get put to the test, so long as it is not the same or similar to the key for the iPhone.

                    Many DO avoid the newer chips (post 2008 Intel/Post 2013 AMD) due to the management engine/PSP issues. This was a big reason for me to stop updating CPU's.
                    Last edited by Luke; 19 December 2016, 11:42 PM.

                    Comment

                    Working...
                    X