1

For security purposes we are required to implement full filesystem encryption on an upcoming server installation. We use the default encryption settings shipped with CentOS 7.

My question: as our servers use SSD drives, should I be concerned that the encryption/decryption system places additional strain on the drives in terms of extra read/writes for standard I/O access? I have a hunch that, if anything, it should strain the CPU rather than the SSDs, but I wanted to understand it in detail.

Improve this question

1 Answer 1

Reset to default
0

The answer depends on how the encryption is designed. Most block level encryptions have a 1:1 mapping between logical and physical sectors. That means reading one plaintext sector from the logical device translates to reading one ciphertext sector from the physical device. And writing one plaintext sector to the logical device translates to writing one ciphertext sector to the physical device. I expect the default on CentOS to fall into this class.

This is a compromise between efficiency and security. There are certain kinds of leaks in this approach, but solving those adds lot of complexity and quite some overhead. To any cryptographer it is obvious, that since the plaintext and ciphertext have the exact same size, you cannot get semantic security.

At first it sounds like this approach means the encryption layer does not change the I/O efficiency at all. However you do lose the ability use the TRIM command. The lack of TRIM support can reduce the efficiency and lifetime of an SSD. If you are using a file system that does not support TRIM anyway, you will be losing nothing in terms of I/O from using encryption.

There is nothing preventing an encryption layer from passing the TRIM command through to the physical layer, but doing so will leak some information about the structure of data on the file system. Here you can see some documentation of an implementation which supports this, but does not enable it by default.

More advanced storage encryption schemes are possible, which have a cost in terms of I/O and storage capacity but have fewer opportunities for data leaks. Such schemes could even support TRIM without leaking data.

Improve this answer
6
  • 2
    You do not lose TRIM, you can enable it at the cost of some security.
    – user186340
    Sep 6, 2014 at 10:21
  • @AndréDaniel Hard to quantify exactly how much security is lost by enabling it. Whether it is a problem certainly depends on what you are trying to protect against. If you had some compromising file on the disk and delete it, then an adversary looking on the disk after the fact could identify a region exactly the size of the compromising file had been trimmed. Still that is not as bad as the leak that could happen from zeroing a watermarked file. My answer is still accurate for the default configuration.
    – kasperd
    Sep 6, 2014 at 10:55
  • That wiki says enabling TRIM may allow someone to determine what type of file system is used on the disk, which is problematic when you need to hide the fact that the disk contains data at all (vs. random data), for example in jurisdictions where encryption is illegal. However if you're just looking to protect against data theft (if the drive is stolen for example) then I'm pretty sure the data itself is still safe.
    – user186340
    Sep 6, 2014 at 11:07
  • @AndréDaniel It is mostly safe. For most users it is probably good enough. The security implications of enabling TRIM are not clear cut. Enabling TRIM could work around some of the leaks caused by the simplistic 1:1 mapping, but OTOH TRIM introduces other leaks of its own. It would potentially leak information about file sizes, including sizes of recently deleted files, and which file system you are using. It would not leak actual contents of the files, but it can't be completely ruled out that an adversary could have crafted a file and later figure out if it was on the encrypted media.
    – kasperd
    Sep 6, 2014 at 11:15
  • The blog post linked in the wiki article is interesting. Basically enabling TRIM leaks info about unused blocks in the file system, but that's about it. Problematic for "plausible deniability" (the disk doesn't look like random data anymore) but safe otherwise.
    – user186340
    Sep 6, 2014 at 11:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .