Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)

On Wed, May 1, 2019 at 9:30 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> Replying to myself to resend to the list, since my previous attempt
> seems to have been eaten by a grue.
>
> On Tue, Apr 30, 2019 at 1:01 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Tue, Apr 30, 2019 at 1:38 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > It seems to me that encrypting table data in WAL with multiple keys
> > > reduces damage in case where a key is theft. However user who has an
> > > access privilege of reading WAL can obtain all keys encrypting table
> > > data in WAL in the first place.
> >
> > That better not be true.  If you have a design where reading the WAL
> > lets you get *any* encryption key, you have a bad design, I think.

How does the startup process decrypt WAL during recovery without
getting any encryption key if we encrypt user data in WAL by multiple
encryption keys?

> > If
> > you have a design where reading the WAL lets you get *every*
> > encryption key, that's truly terrible.  That's strictly worse than
> > full-disk encryption, which at least protects against the disk being
> > stolen.
> >
> > > So as long as postgres's access
> > > control facility works fine it's the same as having single encryption
> > > key dedicated for WAL.
> >
> > I think of postgres's access control facility works fine there is no
> > need for encryption in the first place.  If we can just use REVOKE to
> > block access, we should do that and forget about encryption.  The
> > value of encryption only enters the picture when someone can bypass
> > the database server permissions in some way, such as by reading the
> > files directly.

Yes, I agreed.

> >
> > > Or do you mean the case where a malicious user
> > > steals both WAL and key A? It completely depends on from what threat
> > > we want to protect data by transparent data encryption but I think we
> > > should rather protect from such threat by the access control in that
> > > situation. I personally don't think the having an encryption key
> > > dedicated for WAL would increase risk much.
> >
> > Well, what threat are you trying to protect against?

Data theft bypassing PostgreSQL's ACL, for example a malicious user
thefts storage devices and reads datbase files directly.

I'm thinking that only users who have an access privilege of the
database object can get encryption key for the object. Therefore, when
a malicious user stole an encryption key by breaking the access
control system if we suppose data at rest encryption to serve as a yet
another access control layer we have to use the same encryption key
for WAL as that we used for database file. But I thought that we
should rather protect data from that situation by access control
system and managing encryption keys more robustly.

> >
> > > FWIW, binary log encryption of MySQL uses different encryption key
> > > from a key used for table[1]. The key is encrypted by the master key
> > > for binary log encryption and is stored in each file headers.
> >
> > So, if you steal the master key for binary log encryption, you can
> > decrypt everything, it sounds like.

Yes, I think so.

> >
> > > If we use the same key to encrypt the WAL for the table and indexes
> > > and TOAST table for the table, what encryption key should we use for
> > > temporary files for an intermediate result?
> >
> > For temporary files, we can just use some temporary key that is only
> > stored in server memory and only for the lifetime of the session.
> > Once the session ends, we don't ever need to read that data again.
> >

Agreed.

> > > And should we use each
> > > different encryption keys for WAL other than table and indexes
> > > resource manager?
> >
> > Data other than table and index data seems like it is not very
> > security-sensitive.  I'm not sure we need to encrypt it at all.  If we
> > do, using one key seems fine.

Agreed. But it seems not to satisfy some user who require to encrypt
everything, which we discussed before.

> >
> > > The advantage of having the dedicated key for WAL
> > > encryption would be to make WAL encryption more simple. If we do that,
> > > we can encrypt the whole WAL page by key A like the patch proposed by
> > > Antonin does).
> >
> > Yeah.  His design is simpler because it is coarse-grained: the whole
> > cluster is encrypted, so there's no need to worry about encrypting
> > data differently for different tables.
> >
> > > Also the advantage of having multiple tablespace keys
> > > would be to make postgres enable to re-encryption without rebuilt
> > > database cluster.
> >
> > I don't understand this part, sorry.

I wanted to say that if we encrypt whole database cluster by single
encryption key we would need to rebuilt the database cluster when
re-encrypt data. But if we encrypt data in tablespaces by per
tablespace encryption keys we can re-encrypt data by moving
tablespaces, without rebuilt it.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center