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

From Bruce Momjian
Subject Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Date
Msg-id 20190727203412.v3hubcsbu6m5yxls@momjian.us
Whole thread Raw
In response to Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Sehrope Sarkuni <sehrope@jackdb.com>)
List pgsql-hackers
On Sat, Jul 27, 2019 at 03:02:02PM -0400, Sehrope Sarkuni wrote:
> On Sat, Jul 27, 2019 at 1:32 PM Bruce Momjian <bruce@momjian.us> wrote:
> > Uh, I listed the three options for the CRC and gave the benefits of
> > each:
> >
> >         https://www.postgresql.org/message-id/20190725200343.xo4dcjm5azrfn6zr@momjian.us
> >
> > Obviously I was not clear on the benefits.  To quote:
> >
> >         1.  compute CRC and then encrypt everything
> >         3.  encrypt and then CRC, and store the CRC encrypted
> >
> > Numbers 1 & 3 give us tampering detection, though with the CRC being so
> > small, it isn't totally secure.
> >
> > > Are you worried about an attacker forging the page checksum by
> > > installing another encrypted page that gives the same checksum?  I'm not
> > > sure how that attack works ... I mean why can the attacker install
> > > arbitrary pages?
> >
> > Well, with #2
> >
> >         2   encrypt and then CRC, and store the CRC unchanged
> >
> > you can modify the page, even small parts, and just replace the CRC to
> > match your changes.  In #1 and #3, you would get a CRC error in almost
> > all cases since you have no way of setting the decrypted CRC without
> > knowing the key.  You can change the encrypted CRC, but the odds that
> > the decrypted one would match the page is very slim.
> 
> Regarding #1 and #3, with CTR mode you do not need to know the key to
> make changes to the CRC. Flipping bits of the encrypted CRC would flip
> the same bits of the decrypted one. This was one of the issues with
> the older WiFi encryption standard WEP[1] which used RC4 + CRC32. It's
> not the exact same usage pattern, but I wouldn't be surprised if there
> is a way to make in place updates and matching CRC32 changes even if
> it's encrypted.

I see.

> Given the non-cryptographic nature of CRC and its 16-bit size, I'd
> round down the malicious tamper detection it provides to zero. At best
> it catches random disk errors so might as well keep it in plain text
> and checkable offline.

OK, zero is pretty low.  ;-)  Let's just go with #2 then, and use CTR
mode so it is easy to skip the CRC bytes in the page.

> More generally, without a cryptographic MAC I don't think it's
> possible to provide any meaningful malicious tamper detection. And
> even that would have to be off-page to deal with page replay (which I
> think is out of scope).

Yeah.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: tap tests driving the database via psql
Next
From: Peter Geoghegan
Date:
Subject: Re: Testing LISTEN/NOTIFY more effectively