Announcement

Collapse
No announcement yet.

OPAL Self-Encrypting Drive Support For Linux Steps Closer

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

  • #11
    I'm not aware of any news/reports of instances of SSDs being unlocked by state actors (they wouldn't tell would they?) but if you know of any credible articles describing it I would be interested. I'd say bad implementations or bugs are a lot more probable than backdoors but since they can't be audited anything goes.

    It always makes me smile when someone mentions defending against state actors, it is true you should not use things you don't trust or can't audit but if you have a state actor after you then you have bigger problems than any possible backdoor or (un)intentional bug in your encryption software of choice. Even well regarded software can have bugs, go look at the truecrypt audit, no fatal bugs have been found but it was not free of bugs.

    In the UK, now that it is mentioned, if I'm not mistaken I have only seen that they were considering making it mandatory to have "golden keys", but I don't know if that has been put into law or if "unbreakable" encryption is outlawed, what I do know is that you can be imprisoned indefinitely if you don't cough up the encryption password/keys. In other countries you may expect even less pleasant treatment, see [1].

    Regarding daesh et al, they are known to use encrypted communication channels, but I haven't seen anything about how they keep their local machines secure, keep in mind that it is public knowledge that some attacks have been coordinated with plaintext unencrypted sms so anything goes I suppose.

    You are contradicting yourself, first you say closed software cannot be trusted, but then mention iPhones and their encryption as a second protection layer, how is any SED different? Regarding DM-crypt, I don't know the implementation details but if the decryption key ever gets into ram (and it probably does since you can resume from S3) that is game over, there may also be some side channel attacks that have not been disclosed yet and if you plan to stick to old cpus you pay a heavy speed and power penalty for using it. Also don't forget that whichever state actor you are going against may wait until you unlock you encrypted volumes before moving in on you, already happened before.

    I'm not concerned about state actors, no amount of safe encryption and/or possible plausible deniability is going to help, if one is caught or a suspect it's game over, I'm more concerned about loss or theft and for that SEDs should be more than fine and don't impose speed/power penalties.

    [1] https://xkcd.com/538/

    Comment


    • #12
      I don't trust in Trusted Computing Group...

      Trusted Computing, Secure Boot...

      Is it 1984 again?

      Comment


      • #13
        And here I was hoping for something related to IBM OPAL Firmware (for POWER) ☹

        Comment


        • #14
          Originally posted by R00KIE View Post
          I'm not aware of any news/reports of instances of SSDs being unlocked by state actors (they wouldn't tell would they?) but if you know of any credible articles describing it I would be interested. I'd say bad implementations or bugs are a lot more probable than backdoors but since they can't be audited anything goes.

          It always makes me smile when someone mentions defending against state actors, it is true you should not use things you don't trust or can't audit but if you have a state actor after you then you have bigger problems than any possible backdoor or (un)intentional bug in your encryption software of choice. Even well regarded software can have bugs, go look at the truecrypt audit, no fatal bugs have been found but it was not free of bugs.

          In the UK, now that it is mentioned, if I'm not mistaken I have only seen that they were considering making it mandatory to have "golden keys", but I don't know if that has been put into law or if "unbreakable" encryption is outlawed, what I do know is that you can be imprisoned indefinitely if you don't cough up the encryption password/keys. In other countries you may expect even less pleasant treatment, see [1].

          Regarding daesh et al, they are known to use encrypted communication channels, but I haven't seen anything about how they keep their local machines secure, keep in mind that it is public knowledge that some attacks have been coordinated with plaintext unencrypted sms so anything goes I suppose.

          You are contradicting yourself, first you say closed software cannot be trusted, but then mention iPhones and their encryption as a second protection layer, how is any SED different? Regarding DM-crypt, I don't know the implementation details but if the decryption key ever gets into ram (and it probably does since you can resume from S3) that is game over, there may also be some side channel attacks that have not been disclosed yet and if you plan to stick to old cpus you pay a heavy speed and power penalty for using it. Also don't forget that whichever state actor you are going against may wait until you unlock you encrypted volumes before moving in on you, already happened before.

          I'm not concerned about state actors, no amount of safe encryption and/or possible plausible deniability is going to help, if one is caught or a suspect it's game over, I'm more concerned about loss or theft and for that SEDs should be more than fine and don't impose speed/power penalties.

          [1] https://xkcd.com/538/
          I've already had a DM-crypt encrypted computer stolen by police in a 2008 raid, and later evidence suggests they were unable to crack it. The encryption came as a complete surprise for them, and I got away with beating my chest on the Earth First! newswire that I would see them in 4,000 years with their arrest warrant, and that that was the estimated time required for the surface of the Earth covered in circa 2008 computers to brute-force the key for AES-256.

          As a political dissident, those I dissent against are the primary expected opponents. An ordinary laptop thief would not even be a worry so long as he did not get arrested with the machine in question. He would be after banking and social media credentials, I do not bank online or use the social media sites. The loss to a non-state actor would be the value of the hardware, though the possiblity that the "burglary" was actually not a burglary would have to be considered.

          About the iPhone example:no, I would not trust an iPhone for a New York second not only for encryption but not to be broadcasting my location to the FBI, Apple, and every known advertising network. Thus I do not have a smartphone. None the less, if someone else's phone needed to move a DM-crypt container that I had made into a tarball, an encrypted iPhone would not be LESS secure, would not help them beat my DM-crypt container, and who knows-maybe they can't crack that particular phone at that particular police department. To get in, they need to crack the iPhone first with the FBI's purchased hack, copy out the tarball and open it, then start running that "first password shooter" hoping to brute-force whatever throwaway passphrase I used for the container. The fact that the iPhone is also encrypted cannot help the other side unless it causes me to actually trust it and thus let data on it I otherwise would not. Since the DM-crypt container can move over a public Internet connection without being cracked, it can also move over an iPhone whether encrypted or not, I just don't have or want one of those myself.

          DM-Crypt obvious has to have the key in RAM somewhere to be able to use it, it is supposed to be locked against ever swapping to disk but the Cryptsetup documentation warns never to use unencrypted swap with encryption anyway in case of kernel bugs. Resume from suspend only shows RAM contents have been saved, it's HIBERNATION that must not work without having to re-enter the passphrase as that would imply the disk key saved to disk. None of my systems are set up to support hibernation (suspend to disk) for this reason.

          Key in RAM is not "game over" unless a third party can access the machine while it is unlocked. In the case of DM-crypt (cryptsetup) they need root access or a root exploit-and anyone who has those can change out the kernel, bootloader, or initramfs for one with a keylogger(the "evil maid attack") anyway. If third parties have physical access, the machine is considered unsafe anyway, posession=root and countermeasures can only slow down, obfuscate, or if not known in advance detect such an attack.

          About "waiting until a volume is unlocked" that is the "cold boot" attack and fails against machines never left running unattended. If a raid arrived at this very moment I would reach under the desk and pull the plug, and the power would die and the RAM contents decay faster than they could sprint up the stairs. If I am using a laptop and police with unknown intent get inside 50 feet or so I mash the power button for a forced shutdown and yank the battery if that does not respond instantly.

          As for speed penalties, the only thing I need speed for is video editing, and for that Phenom II is good enough just as it was in 2010 when I got two of them. Bulldozer is better yet, and it too is pre-PSP. In fact, video editing and libx264 is the one place Bulldozer really kicks ass. The fact that it sucks for gaming keeps it nice and cheap. I would not accept PSP stuff for a tenfold speed increase. If I still used QVGA cameras I could still use an Athon Thunderbird to edit, and I have no plans of ever replacing 1080p (requires Phenom or Core 2 Quad) with 4k video.
          Last edited by Luke; 12-21-2016, 11:51 PM.

          Comment


          • #15
            As a user how do I make use of this?

            I am using sedutl and the disk is locked/unlocked just fine, but suspend-to-RAM(S3 sleep) is not supported since it apparently requires Linux kernel integration, which I have no idea how to get done.

            For now I just use suspend-to-disk(hibernation), which is slow and inconvenient, especially considering how sedutil power cycles the machine each time after unlocking the drive.

            Comment

            Working...
            X