Re: Internal key management system

Hello Masahiko-san,

I'm not sure I understood your concern. I try to answer below.

> If I understand your idea correctly we put both DEK and KEK
> "elsewhere", and a postgres process gets only DEK from it.

Yes, that is one of the option.

> It seems to me this idea assumes that the place storing encryption keys
> employees 2-tire key hierarchy or similar thing.

ISTM that there is no such assumption. There is the assumption that there
is an interface to retrieve DEK. What is done being the interface to
retrieve this DEK should be irrelevant to pg. Having them secure by a
KEK looks like an reasonable design, though. Maybe keys are actually
stored. Maybe thay are computed based on something, eg key identifier and
some secret. Maybe there is indeed a 2-tier something. Maybe whatever.

> What if the user wants to or has to manage a single encryption key?

Then it has one key identifier and it retrieve one key from the DMS.
Having a "management system" for a singleton looks like overkill though,
but it should work.

> For example, storing an encryption key for PostgreSQL TDE into a file in
> a safe server instead of KMS using DEK and KEK because of budgets or
> requirements whatever.

Good. If you have an interface to retrieve a key, then it can probably
contact said server to get it when needed?

> In this case, if the user does key rotation, that encryption key would
> need to be rotated, resulting in the user would need to re-encrypt all
> database data encrypted with old key.

Sure, by definition actually changing the key requires a
decryption/encryption cycle on all data.

> It should work but what do you think about how postgres does key
> rotation and re-encryption?

If pg actually has the DEK, then it means that while the re-encryption is
performed it has to manage two keys simultenaously, this is a question for
what is done on pg server with the keys, not really about the DMS ?

If the "elsewhere" service does the encryption, maybe the protocol could
include it, eg something like:

REC key1-id key2-id data-encrypted-with-key1
-> data-encrypted-with-key2

But it could also achieve the same thing with two commands, eg:

DEC key1-id data-encrypted-with-key1
-> clear-text-data

ENC key2-id clear-text-data
-> data-encrypted-with-key2

The question is what should be put in the protocol, and I would tend to
think that some careful design time should be put in it.

--
Fabien.