Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: The Cost Of Ubuntu Disk Encryption

  1. #11
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,199

    Default

    If you need to ask that, then you're not the one encrypting your data in the first place.

  2. #12

    Default

    How does /home encryption fare if you have it on a separate drive?

  3. #13
    Join Date
    Mar 2010
    Location
    Cambridge, UK
    Posts
    75

    Default

    Quote Originally Posted by curaga View Post
    @speculatrix

    Sure, this would kill the SSD faster, but at least you can trust it. How can you trust the chip inside does the right thing?

    in theory a suitable SSD would carry the OPAL TCG sticker, or one of the FIPS accreditations.

    however, I seem to remember long ago that Intel had to offer to replace a particular model of SSD because they had bad firmware in it which didn't encrypt the data to the required standard, and due to the way the drive's microcontroller was programmed, it wasn't possible to reprogram it.

    ahah, finally found it after much googling:
    http://www.desktopreview.com/default...ecall+SSDs+LSI

  4. #14
    Join Date
    Oct 2012
    Posts
    294

    Default

    Quote Originally Posted by speculatrix View Post
    encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.
    what are you talking about? since when does it matter writing long continues 1s (or 0s)?

    the only thing where external encryption can affect the liftetime of a ssd is on controlers that do compression. it hinders compression which means that you write more bytes than with compression. in such a case it would be better to first compress and then encrypt which means that the compression must also be dones externally (e.g. by software).

    but this has nothing to do with long runs of 1s or 0s. such data is actually extremly good compressable.

    maybe i understood you wrong.

  5. #15
    Join Date
    May 2013
    Posts
    577

    Default For some work you MUST encrypt, no matter what the penalty

    Quote Originally Posted by speculatrix View Post
    encrypting in the OS onto an SSD is bad practise. if you need disk encryption determine how to use the embedded crypto in an SSD - most have them, it's actually a useful feature so as to achieve the randomisation of data to avoid writing long contiguous 1's or 0's to flash.

    if your SSD doesn't allow you to easily control encryption, you bought the wrong one!
    My experience is encrypting an SSD or a flash drive works fine and stays reasonablly fast as long as you set aside about a third of it as unallocated space. This makes sure that the controller can find unused blocks to erase. If you don't do this, all cheap flash drives can become very slow once the encrypted partitions have ever been filled. This problem doesn't seem to be as bad on SSDs but they still do slow down when filled in this way.

    As for lifespan, for what I do an early wearout is far to be preferred to the consequences of not using encryption. I had a computer stolen by a police raid, I was damned glad that one was encrypted, so this is something I don't compromise on.

    I would not trust encryption provided by the drive, since for my work the NSA is the presumed worst-case adversary and hardware back doors into that are likely, just as was the case for ATA security set passwords. There was even a criminal conviction in the US where someone thought their data was protected by setting an ATA disk access password which the FBI was able to quickly bypass with the help of some kind of master key the manufacturer provided.

    If you don't encrypt the OS, there are just too many places an attacker with physical access while you are out could drop a keylogger or a replaced binary, as physicall access=root. Encryption is the only thing that can write protect a disk against an attacker booting from something else. When the OS is encrypted too, only the /boot partition can be usefully written to, in what is known as an "evil maid" attack. The /boot partition is a hell of a lot easier to hash check than a whole operating system, so long as you do not mount it after booting and before hash checking.
    Last edited by Luke; 05-20-2013 at 09:39 PM.

  6. #16
    Join Date
    Mar 2010
    Location
    Cambridge, UK
    Posts
    75

    Default

    Quote Originally Posted by a user View Post
    what are you talking about? since when does it matter writing long continues 1s (or 0s)?
    ...
    maybe i understood you wrong.
    I might be wrong. Though I've used up my allowance of errors for this year :-)

    I was too lazy to find the citation, but since you challenged me...

    http://www.anandtech.com/show/6891/h...h-crucial-m500

    "Most modern SSDs come with some form of hardware encryption. On these drives with hardware encryption, itís usually permanently turned on - all data written to the NAND is typically stored in encrypted form. This stems from the fact that all writes to NAND had to be scrambled to begin with (writing long repeated strings of data to NAND can cause problems for data retention)."

    Phew, I'm right. As usual. :-D

  7. #17
    Join Date
    May 2013
    Posts
    21

    Default

    If anyone is to encrypt their data, why not do it the way it's most secure and leaves the least open risks with reasonable effort?

    IMO, this excludes the proprietary mechanisms in place in practically all current SSD's that have some sort of built-in encryption functionality. Mostly because the built-in features are almost impossible to enable unless you've bought a corporate laptop or desktop that already has all the required components in it. Secondly, because government controlled backdoors are not fantasy:

    http://news.bbc.co.uk/2/hi/uk_news/politics/4713018.stm

    Open-source encryption software can be easily reviewed for any such backdoors whereas closed-source firmware based solutions can hold nasty surprises in them.

  8. #18
    Join Date
    May 2013
    Posts
    3

    Smile

    Quote Originally Posted by ObiWan View Post
    OCZ Vertex 2 is a SandForce SSD, SandForce Chips are slower when data can't be compressed.

    So part of the performance hit is the SSD Controller, not the CPU
    I do agree encrypting in the OS onto an SSD is bad practise. It ain't ethical to target the controllers.There is a lot that goes into this & there could be some undisclosed SF compatibility issues with the hardware manufacturerers

  9. #19
    Join Date
    Jan 2012
    Posts
    65

    Cool

    Quote Originally Posted by Luke View Post
    If you don't encrypt the OS, there are just too many places an attacker with physical access while you are out could drop a keylogger or a replaced binary, as physicall access=root. Encryption is the only thing that can write protect a disk against an attacker booting from something else. When the OS is encrypted too, only the /boot partition can be usefully written to, in what is known as an "evil maid" attack. The /boot partition is a hell of a lot easier to hash check than a whole operating system, so long as you do not mount it after booting and before hash checking.
    If you use a program installed on /boot to hash check /boot you are no better off.

    You really need to keep /boot on a USB drive that you always keep with you and boot from that.

    Also, a keylogger could be installed into the BIOS or EFI firmware so you need Secure Boot and a TPM to prevent firmware modifications.

    And none of that protects against low tech but effective key logger attacks like putting something slightly sticky and UV glowy on the case so you get it on your fingers and then type on the keys. Then they've got your likely passphrase when they bust in and confiscate everything.

    You just can't be too paranoid! :-)

  10. #20
    Join Date
    May 2013
    Posts
    577

    Default Countermeasures

    Quote Originally Posted by Zan Lynx View Post
    If you use a program installed on /boot to hash check /boot you are no better off.

    You really need to keep /boot on a USB drive that you always keep with you and boot from that.

    Also, a keylogger could be installed into the BIOS or EFI firmware so you need Secure Boot and a TPM to prevent firmware modifications.

    And none of that protects against low tech but effective key logger attacks like putting something slightly sticky and UV glowy on the case so you get it on your fingers and then type on the keys. Then they've got your likely passphrase when they bust in and confiscate everything.

    You just can't be too paranoid! :-)

    Well, you CAN be so paranoid you assume no defense is possible, so you use none and get on Facebook with Windows and hope the cops raid someone else. Short of that, you structure your setup to put as little trust in your hardware and the environment around it as is necesary to operate it. I've already had one encrypted machine taken in a raid beat attempts by the cops to get into it, I must be doing something right.

    Whenever there is a hardware you buy vs open source software choice to be made, go with the software every time. This reduces the number or possible hardware-based attack vectors and increases the odds that your opponent can't get in because the controller of that backdoor can't admit to having it. That last consideration does NOT apply to "Top Secret" but applies to all lower classifications of data.

    A TPM is hardware-and a lot more likely the NSA and "Trusted Computing Group" would admit to a backdoor in a TPM in a courtroom than that a motherboard maker would be willing to admit to keylogging all their customers so the FBI can get video of, say, protesters storming a fur shop.

    Since /boot is considered easily compromised, a hash check after booting with a program living on encrypted / makes the attack much more difficult, though not impossible. You detect the attack, you change the pasphrase and re-image the OS. Anyone setting up a raid, BTW, will greatly fear the
    detection of this sort of preparation, as this means staging a raid where the attackers are expected.

    The flash drive approach is good, used it myself in some highly untrusted environments, but it does not protect against the "evil cook" BIOS reflash. Neither does my hash check, but to attack the BIOS requires one visit to determine the board in use, another to change the BIOS, then the harvest raid.

    Obviously the ROOM in which a machine is used is an attack vector, a camera is more reliable than glowing UV dust likely to get on every key. Public places, idenify cameras and sit where they can't see the screen. Home and offices, "sweep" the areas from which the keyboard can be seen for cameras. Consider all "smartphones" etc to be malicious, don't let them watch you boot!

    One more thing: when they can't get into an encrypted machine, they might offer to give it back. That should ALWAYS be considered malicious, harboring at least a keylogging BIOS. Take it so they can't keep working on it, then SMASH it and throw it in the dumpster.
    Last edited by Luke; 05-22-2013 at 12:32 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •