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

On Mon, Jul 15, 2019 at 03:55:38PM -0400, Bruce Momjian wrote:
>On Mon, Jul 15, 2019 at 03:47:59AM +0200, Tomas Vondra wrote:
>> On Sun, Jul 14, 2019 at 12:13:45PM -0400, Joe Conway wrote:
>> > We could check the CRC prior to encryption and throw an ERROR if it is
>> > not correct. After decryption we can check it again -- if it no longer
>> > matches we would know there way a corruption or change of the
>> > ciphertext, no?
>> >
>> > Hmm, I guess the entire page of ciphertext could be faked including CRC,
>> > so this would only really cover corruption, not an intentional change if
>> > it were done properly.
>> >
>>
>> I don't think any of the schemes discussed here provides protection
>> against this sort of replay attacks (i.e. replacing a page with an older
>> copy of the page). That would probably require having some global
>> checksum or something like that.
>
>Uh, I think the only thing we could do is to add the page number into
>the nonce so the page would have to be replaced in the same place in the
>table, but it hardly seems worth it.
>
>> > > Which seems pretty annoying, because then the checksums won't verify
>> > > data as sent to the storage system, and verify checksums would require
>> > > access to all keys (how do you do that in offline mode?).
>> >
>> > Given the scheme above I don't see why that would be an issue. The keys
>> > are all accessible via the MDEK, which is in turn available via the KEK.
>> >
>>
>> I just don't know how the offline tools will access the KMS to get the
>> keys. But maybe that's not an issue. But even then I think it's kinda
>> against the idea of checksums that they would not checksum what was sent
>> to the storage system.
>
>Oh, I see your point now. pgchecksum will look at the page and think it
>is corrupt. It would need access to the keys to verify it, and only for
>whole-cluster encryption or if there is a per-page flag (it can't easily
>do system table lookups).
>
>The crazy seems more sane now --- "encrypt the page with CRC contents as
>zero" (which we probably already do to compute the CRC), then compute
>the CRC, and modify the page CRC.
>

Huh? So you want to

1) set CRC to 0
2) encrypt the page
3) compute CRC
4) set CRC to value computed in (3)
5) encrypt the page again

That seems pretty awful from performance POV, and it does not really
solve much as we'd still need to decrypt the page while verifying the
checksums (because the CRC is in the page header, which is encrypted).

regards

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