Re: WIP: Data at rest encryption

Hi all,

I've noticed this thread got resurrected a few days ago, but I haven't
managed to read all the messages until today. I do have a bunch of
comments, but let me share them as a single consistent message instead
of sending a thousand responses to individual messages.

1) Threat model
---------------

Firstly, I think the thread would seriously benefit from an explanation
and discussion of the threat model - what types of attacks it's meant to
address, and what attacks it can't defend against.

My understanding is that data-at-rest encryption generally addresses
only the "someone stole the disk" case and pretty much nothing else.

Moreover, I claim that encryption implemented at the database-level is
strictly weaker compared to LUKS or encrypted disks, because it simply
reveals a lot more information even without decryption (file sizes,
timestamps, etc.)

That is a serious issue in practice, and researches have been proving
that for a long time now. I do recommend this paper from Cornell Tech as
a great starting point (it cites many papers relevant to this thread):

Why Your Encrypted Database Is Not Secure
Paul Grubbs, Thomas Ristenpart, Vitaly Schmatikov
http://eprint.iacr.org/2017/468.pdf

The paper explains how encryption schemes on general-purpose databases
fail, due to exactly such side-channels. MVCC, logging and other side
channels turn all attackers into "persistent passive attackers".

Now, this does not mean the feature is useless - nothing is perfect, and
security is not a binary feature. It certainly makes attacks mode
difficult compared to plaintext database. But it's untrue that it's
basically LUKS, just implemented at the database level.

I'm not suggesting that we should not pursue this idea, but the threat
model is a crucial piece of information missing in this thread.

2) How do other databases do it?
--------------------------------

It was repeatedly mentioned that other databases support this type of
encryption. So how do they deal with the hard parts? For example how do
they get and protect the encryption key?

I agree with Stephen that we should not require a full key management
from v1 of the patch, that's an incredibly difficult thing. And it
largely depends on the hardware (e.g. it should be possible to move the
key to TrustZone on ARM / SGX on Intel).

3) Why do users prefer this to FDE?
-----------------------------------

I suppose we're discussing this feature because we've been asked about
it by users/customers who can't use FDE. Can we reach to them and ask
them about the reasons? Why can't they use FDE?

It was mentioned in the thread that the FDE solutions are not portable
between different systems, but honestly - is that an issue? You probably
can't copy the datadir anyway due locale differences anyway. If you're
running multiple operating systems, FDE is just one of many differences.

4) Other solutions?
-------------------

Clearly, FDE (at the block device level) and DB-level encryption are not
the only solutions. There are also filesystems-level solutions now, for
example.

ext4 (since kernel 4.1) and f2fs (since kernel 4.2) allow encryption at
directory level, are transparent to the user space, and include things
like key management (well, that's provided by kernel). NTFS can do
something quite similar using EFS.

https://lwn.net/Articles/639427/

https://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html

Of course, if you happen to use another filesystem (e.g. XFS), this
won't work for you. But then there's eCryptfs, for example:

https://en.wikipedia.org/wiki/ECryptfs

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services