Announcement

Collapse
No announcement yet.

The Performance Impact Of Linux Disk Encryption On Ubuntu 14.04 LTS

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

  • #16
    Originally posted by FourDMusic View Post
    Why is eCryptfs so slow (or alternatively LUKS faster)? At first I thought it was that the decryption wasn't being hardware accelerated, but according to https://wiki.archlinux.org/index.php/Disk_Encryption, it has the feature. Is the file system implemented in eCryptfs that bad? I can almost believe it from the compile benchmark, but I'm not familiar with this space at all.
    Maybe it's an older version? Or the Ubuntu build doesn't have that feature enabled.

    Comment


    • #17
      Originally posted by jakubo View Post
      so can it be worked around by creating a home partition? And does Full disk mean full disc or does it mean full partition?
      Full disk does always mean full partition.

      Originally posted by FourDMusic View Post
      Why is eCryptfs so slow (or alternatively LUKS faster)? At first I thought it was that the decryption wasn't being hardware accelerated, but according to https://wiki.archlinux.org/index.php/Disk_Encryption, it has the feature. Is the file system implemented in eCryptfs that bad? I can almost believe it from the compile benchmark, but I'm not familiar with this space at all.
      eCryptfs does encrypt files where full disk encryption encrypts a bytestream so it has a lot less to deal with,
      and can store the stuff right away where eCryptfs have to hand it back to the FS.

      Comment


      • #18
        Performance, security both favor full disk encryption

        I had a computer full of encrypted data defeat police forensics after a 2008 raid on my house, so I always encrypt any computer that will ever work with my photos, videos, or other material. I won't even go online with an unencrypted machine except by running the browser entirely in RAM the way a live disk does it.

        The most important thing in encryption is security, you need to encrypt or keep in RAM anything that could ever hold sensitive information. Speed is secondary, but yes, encrypting 4+ GB of video files into a netbook on the road does get painfully slow. Now I find that had I used ecryptfs it might have been impractically slow to the point of forcing me to keep the files on the unencrypted camera cards until I could reach an encrypted desktop. On older Atom netbooks, a big encrypted file transfer job can use almost all the CPU capacity, on a multicore desktop even moving data from an SSD to a RAID won't. Especially slow on the Atom is moving files from an encrypted hard drive to an encrypted flash drive.

        A home directory only system is a security issue in itself as well. This is especially bad if you are using any KDE applications that stash private information in /var/tmp. I don't know if any still do, but I heard years ago that KDE was even stashing emails there. Also remember that encrypted partitions cannot easily be written to by an attacker with offline physical access.

        Comment


        • #19
          Originally posted by raineee View Post
          I don't use Ubuntu & friends, but I would assume that the comment regarding to /tmp is moot; /tmp is ordinarily a tmpfs these days.
          Probably, but the spirit of the comment also applies to places like /var/tmp and /var/log. If user FOO writes to tempfs, does anything prevent user BAR from reading it besides -r perms? Can root read it?

          For me, the bigger question is whether to use full-disk-encryption, or simply encrypt the VM using Fusion (or whatever HVisor the customer happens to use).

          Comment


          • #20
            What encryption algorithms do these use? If they're compatible, can they use Intel's AES-NI to accelerate the encryption/decryption or was it already enabled?

            Comment


            • #21
              /var/tmp et all are written to disk

              Originally posted by russofris View Post
              Probably, but the spirit of the comment also applies to places like /var/tmp and /var/log. If user FOO writes to tempfs, does anything prevent user BAR from reading it besides -r perms? Can root read it?

              For me, the bigger question is whether to use full-disk-encryption, or simply encrypt the VM using Fusion (or whatever HVisor the customer happens to use).
              On tempfs, content is lost at poweroff, preventing the MSS, FBI or other thieves from reading what was stored there. On the other hand, /var/log and /var/tmp are on disk. If logs were on RAM, you'd lose your logs at every reboot, making some things impossible to diagnose. KDE at least used to store emails in /var/tmp, a serious security issue when /home is encrpyted. A simple workaround for this is to create directories owned by root in /home and bind mount them on /var/tmp, /var/spool (print jobs, etc) and /var/log (records of what you mounted, etc). That's what I did before I switched to encrypting everything but /boot, something I did to reduce the attack surface for an enemy installing malicious software to a powered down machine.

              With only /boot encrypted, there are ways to check post-boot for tampering. You can counter that checking with a smart enough "evil maid" attack, but that requires knowing what you are up against, etc and at that point a BIOS or hardware keylogger gets easier to install. There are of course detection methods and defenses for those as well.

              Do keep in mind I use encryption to foil governmental forensics, if protecting your data from street thieves other than organized crime is your reason for encrypting a computer you may need less security than that required to defeat the FBI and Secret Service and especially less than that needed to defeat the NSA. Speaking of that, if the NSA was ever able to decrypt a randomly picked disk encrypted with AES dropped into their laps, there would soon be stories about US government and military contractors being told not to use AES anymore, for fear of other governments also finding the same crack. As of now they are permitted to use it even for Top Secret stuff.

              Comment


              • #22
                Originally posted by raineee View Post
                I don't use Ubuntu & friends, but I would assume that the comment regarding to /tmp is moot; /tmp is ordinarily a tmpfs these days.
                That would be a dangerous assumption. Data in a tmpfs can be swapped out to disk in low memory conditions. If you have an unencrypted swap partition in use, then data from files, which you thought were safely gone from /tmp by the time power was cut, may still be available in raw form somewhere on the swap partition.

                Comment


                • #23
                  Unencrypted swap is never safe with encryption

                  Originally posted by oyvind View Post
                  That would be a dangerous assumption. Data in a tmpfs can be swapped out to disk in low memory conditions. If you have an unencrypted swap partition in use, then data from files, which you thought were safely gone from /tmp by the time power was cut, may still be available in raw form somewhere on the swap partition.
                  This is also true of any encrypted data stored anywhere you may have loaded into RAM and worked on. The key is supposed to be protected from being swapped out, but a bug in memlock combined with using only an encrypted flash drive could theoretically get a key swapped out. On an machine with unencrypted swap, run sudo swapoff -a before mounting any encrypted device
                  and power down before using swap again,

                  Comment


                  • #24
                    Originally posted by Luke View Post
                    This is also true of any encrypted data stored anywhere you may have loaded into RAM and worked on. The key is supposed to be protected from being swapped out, but a bug in memlock combined with using only an encrypted flash drive could theoretically get a key swapped out. On an machine with unencrypted swap, run sudo swapoff -a before mounting any encrypted device
                    and power down before using swap again,
                    If you use full disk encryption in Ubuntu it will set up an encrypted swap.

                    Comment


                    • #25
                      How does Ubuntu handle swap with ecryptfs encrypted /home?

                      Originally posted by Pajn View Post
                      If you use full disk encryption in Ubuntu it will set up an encrypted swap.
                      I'm not sure how Ubuntu handles swap when the "encrypted user's home directory" is selected. I generally set up encryption manually onto pre-prepared encrypted partitions.

                      The simplest way to fix this is to set up swap to use a non-LUKS partition encrypted with a random key and then mkswap run on it at each boot. For a machine with reasonable
                      CPU speed that will ever handle encrypted volumes (/home or otherwise). this is a sound precaution and does not require an additional passphrase entry at boot.

                      Another thing: if ecryptfs is so slow, Ubuntu should so encrypted /home directories by a separate /home partition using DM-crypt simply for reasons of performance. The option
                      to do so would have to move to the partitioning phase, of course.

                      Comment


                      • #26
                        Originally posted by Luke View Post
                        I'm not sure how Ubuntu handles swap when the "encrypted user's home directory" is selected. I generally set up encryption manually onto pre-prepared encrypted partitions.

                        The simplest way to fix this is to set up swap to use a non-LUKS partition encrypted with a random key and then mkswap run on it at each boot. For a machine with reasonable
                        CPU speed that will ever handle encrypted volumes (/home or otherwise). this is a sound precaution and does not require an additional passphrase entry at boot.

                        Another thing: if ecryptfs is so slow, Ubuntu should so encrypted /home directories by a separate /home partition using DM-crypt simply for reasons of performance. The option
                        to do so would have to move to the partitioning phase, of course.
                        If you set up LUKS in the installer (vary simple, check a checkbox that this partition should be encrypted and enter a passphrase) it will do that random key encrypted SWAP automatically. You can create that LUKS on /, /home or whatever you like. So Ubuntu supports both very easily.

                        Comment


                        • #27
                          Originally posted by guido12 View Post
                          What encryption algorithms do these use? If they're compatible, can they use Intel's AES-NI to accelerate the encryption/decryption or was it already enabled?
                          Most likely AES. In the case of dm-crypt/LUKS, it just uses the kernel's crypto API, so it depends on what was enabled with that. I'm not positive, but I think AES-NI would have to be enabled at kernel compile time.

                          Comment


                          • #28
                            Basically the unencrypted /boot partition is itself an attack vector for evil maid attacks, you could use a grub partition or use grub from EFI partition to avoid that. It does not fix the possibilty of EFI rootkits or modfied grub loaders however but changeing the initrd to store the pw after entering it is very easy. As example how to boot that way look at
                            http://kanotix.com/files/fix/crypto/
                            It is possible to store the pw on the encrypted part but thats optional. If you don't it works as well but you enter the pw twice. If you install with /boot or /boot/efi partition in custom mode while using luks you get the same as Ubuntu with the new installer. I would test it in a VM first...
                            http://nightly.kanotix.acritox.com/latest/

                            Comment


                            • #29
                              Originally posted by Kano View Post
                              Basically the unencrypted /boot partition is itself an attack vector for evil maid attacks, you could use a grub partition or use grub from EFI partition to avoid that. It does not fix the possibilty of EFI rootkits or modfied grub loaders however but changeing the initrd to store the pw after entering it is very easy. As example how to boot that way look at
                              http://kanotix.com/files/fix/crypto/
                              It is possible to store the pw on the encrypted part but thats optional. If you don't it works as well but you enter the pw twice. If you install with /boot or /boot/efi partition in custom mode while using luks you get the same as Ubuntu with the new installer. I would test it in a VM first...
                              http://nightly.kanotix.acritox.com/latest/

                              Unencrypted /boot doesn't create an attack vector in the form of Evil Maid. Evil Maid works whether the data is encrypted or not, unless you're using authenticated encryption, which pretty much no FDE implementation does. XTS mode comes close enough for this attack, though (manipulating the ciphertext has unpredictable effects on the plaintext). In any case, if you want data integrerty, the answer is a MAC, not encryption.

                              Comment


                              • #30
                                Password entry from GRUB transfers trust to BIOS/UEFI

                                Originally posted by Kano View Post
                                Basically the unencrypted /boot partition is itself an attack vector for evil maid attacks, you could use a grub partition or use grub from EFI partition to avoid that. It does not fix the possibilty of EFI rootkits or modfied grub loaders however but changeing the initrd to store the pw after entering it is very easy. As example how to boot that way look at
                                http://kanotix.com/files/fix/crypto/
                                It is possible to store the pw on the encrypted part but thats optional. If you don't it works as well but you enter the pw twice. If you install with /boot or /boot/efi partition in custom mode while using luks you get the same as Ubuntu with the new installer. I would test it in a VM first...
                                http://nightly.kanotix.acritox.com/latest/
                                The value of this depends on the kind of attack you expect. It reduces the danger of an evil maid attack, but increases the danger from a pre-existing malicious BIOS. Assume an attacker who does not already know your computer expects you to be using Windows. With Truecrypt using the BIOS/UEFI keyboard driver during bootloader to unlock the disk, the author of a malicious BIOS might not bother with adding code to keep the keyboard driver running and logging after the kernel takes over keyboard entry. In a UEFI machine he might not bother to prevent ExitBootServices from functioning due to added work and detectability. In DM-crypt/LUKS, if the firmware keyboard driver is not running, a simplest-code bug in it will miss the passphrase entirely because unlike in Truecrypt the full Linux kernel loads first and takes over the keyboard driver function.

                                Of course, if someone with no access to the machine before you got it is the only possible attacker, this situation changes. For encryption against state-level attackers the BIOS is not trusted, against a thief in a hotel room after credit card numbers it may well be, barring a thief that can visit once to identify your board, again to reflash your BIOS, and a third time to harvest the machine and all it's data. A hardware keylogger is easier than this, even in a laptop. If you suspect that kind of danger, epoxy the keyboard down on laptops, nobody can cut the glue without leaving obvious marks.

                                Comment

                                Working...
                                X