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

On Wed, Jul 10, 2019 at 01:04:47PM -0400, Alvaro Herrera wrote:
> On 2019-Jul-10, Bruce Momjian wrote:
>
> > * Using the LSN as part of the nonce fixes both problems, and has a
> > third benefit:
> >
> > * We don't need to decrypt/re-encrypt during CREATE DATABASE since
> > the page contents are the same in both places, and once one
> > database changes its pages, it gets a new LSN, and hence a new
> > nonce/IV.
> >
> > * For each change of an 8k page, you get a new nonce/IV, so you
> > are not encrypting different data with the same nonce/IV
> >
> > * This avoids requiring pg_upgrade to preserve database oids.
>
> An ignorant question -- what is it that gets stored in the page for
> decryption use, the nonce or the IV derived from it? I think if you
> want to store the nonce, you'd have to store the database OID, because
> otherwise how do you know which database OID to use to determine the
> full nonce after cloning a database? You already have the table OID in
> the catalog and the LSN in the page header, so you're only missing the
> database OID. (Assuming you make the nonce be database OID || relation
> OID || page LSN)

You are right that if you used the database oid in the nonce, you would
need to decrypt/re-encrypt the data during CREATE DATABASE, or store
the original database oid in the page.

The new approach is that a single key would be used for all databases
and the WAL, and use the LSN instead of the database oid, so there is no
need to know which database originally encrypted the page --- any
database can decrypt it.

> Also, how are key changes handled? Do we need to store a key identifier
> in each page?

Uh, we have not started discussing that yet. I am thinking we might
need to store the key identifier in the pg_class table and then create a
command to re-encrypt tables. We can re-key a page at a time, but we
would still need to know when all pages/tables are no longer using the
old key, so doing it just at the table/index level seems appropriate.

--
Bruce Momjian <bruce(at)momjian(dot)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 +