On Thu, Jun 21, 2018 at 10:05:41AM +0900, Masahiko Sawada wrote:
> On Thu, Jun 21, 2018 at 6:57 AM, Nico Williams <nico@cryptonector.com> wrote:
> > On Wed, Jun 20, 2018 at 05:16:46PM -0400, Bruce Momjian wrote:
> >> On Mon, Jun 18, 2018 at 12:29:57PM -0500, Nico Williams wrote:
> >> > Note that unless the pg_catalog is protected against manipulation by
> >> > remote storage, then TDE for user tables might be possible to
> >> > compromise. Like so: the attacker manipulates the pg_catalog to
> >> > escalate privelege in order to obtain the TDE keys. This argues for
> >> > full database encryption, not just specific tables or columns. But
> >> > again, this is for the threat model where the storage is the threat.
> >>
> >> Yes, one big problem with per-column encryption is that administrators
> >> can silently delete data, though they can't add or modify it.
> >
> > They can also re-add ("replay") deleted values; this can only be
> > defeated by also binding TX IDs or alike in the ciphertext. And if you
> > don't bind the encrypted values to the PKs then they can add any value
> > they've seen to different rows.
>
> I think we could avoid it by implementations. If we implement
> per-column encryption by putting all encrypted columns out to another
> table like TOAST table and encrypting whole that external table then
> we can do per-column encryption without such concerns. Also, that way
> we can encrypt data when disk I/O even if we use per-column
> encryption. It would get a better performance. A downside of this idea
> is extra overhead to access encrypted column but it would be
> predictable since we have TOAST.
The case we were discussing was one where the threat model is that the
DBAs are the threat. It is only in that case that the replay,
cut-n-paste, and silent deletion attacks are relevant. Encrypting a
table, or the whole DB, on the server side, does nothing to protect
against that threat.
Never lose track of the threat model.
Nico
--
