Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) - Mailing list pgsql-hackers
| From | Sehrope Sarkuni |
|---|---|
| Subject | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
| Date | |
| Msg-id | CAH7T-aqY6dU0k-H5qSPaCiBPzZ4kkYkJz_0JWeOEgWquT+km8Q@mail.gmail.com Whole thread Raw |
| In response to | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Masahiko Sawada <sawada.mshk@gmail.com>) |
| List | pgsql-hackers |
On Tue, Jul 30, 2019 at 10:06 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
On Tue, Jul 30, 2019 at 5:03 AM Sehrope Sarkuni <sehrope@jackdb.com> wrote:
>
> On Mon, Jul 29, 2019 at 9:44 AM Bruce Momjian <bruce@momjian.us> wrote:
>>
>> > Checking that all buffers using a single LSN are from the same
>> > relation would be a good idea but I think it's hard to test it and
>> > regard the test result as okay. Even if we passed 'make checkworld',
>> > it might still be possible to happen. And even assertion failures
>>
>> Yes, the problem is that if you embed the relfilenode or tablespace or
>> database in the encryption IV, you then need to then make sure you
>> re-encrypt any files that move between these. I am hesitant to do that
>> since it then requires these workarounds for encryption going forward.
>> We know that most people will not be using encryption, so that will not
>> be well tested either. For pg_upgrade, I used a minimal-impact
>> approach, and it has allowed dramatic changes in our code without
>> requiring changes and retesting of pg_upgrade.
>
>
> Will there be a per-relation salt stored in a separate file? I saw it mentioned in a few places (most recently https://www.postgresql.org/message-id/aa386c3f-fb89-60af-c7a3-9263a633ca1a%40postgresql.org) but there's also discussion of trying to make the TDEK unique without a separate salt so I'm unsure.
>
> With a per-relation salt there is no need to include fixed attributes (database, relfilenode, or tablespace) to ensure the derived key is unique per relation. A long salt (32-bytes from /dev/urandom) alone guarantees that uniqueness. Copying or moving files would then be possible by also copying the salt. It does not need to be a salt per file on disk either, one salt can be used for many files for the same relation by including the fork number, type, or segment in the TDEK derivation (so each file on disk for that relation ends up with a unique TDEK).
If we can derive unique TDEK using (database, tablespace, relfilenode)
as info I think it's better to use it rather than using random salt
per relations since it doesn't require additional information we need
to store. As described in HKDF RFC[1], if the input key is already
present as a cryptographically strong key we can skip the extract part
where use a salt.
[1] https://tools.ietf.org/html/rfc5869
Yes a random salt is not required for security reasons. Any unique values mixed into the HKDF is fine and the derived keys will still be unique. The HKDF ensures that uniqueness.
The separate salt allows you to disconnect the key derivation from the physical attributes of the file. The physical attributes (ex: database, tablespace, file node) are very convenient as they're unique and do not require additional storage. However using them prevents copying or moving the encrypted files as one or more of them would be different at the destination (so the derived key would no longer decrypt the existing data). So you would have to decrypt / encrypt everything as part of a copy.
If copying raw files without a decrypt/encrypt cycle is desired then the key derivation cannot include physical attributes (or per Bruce's note above, there would be no separate key derivation relation). I thought it'd be a nice property to have as it limits the amount of code that needs to be crypto aware (ex: copying a database or moving a table to a different tablespace would not change beyond ensuring the salt is also copied).
pgsql-hackers by date: