Hello Bruce,
Sorry for the length (yet again) of this answer, I'm trying to make my
point as clear as possible.
Obviously it requires some more thinking and design, but my point is that
postgres should not hold a KEK, ever, nor presume how DEK are to be managed
by a DMS, and that is not very difficult to achieve by putting it outside of
pg and defining how interactions take place. Providing a reference/example
implementation would be nice as well, and Masahiko-san code can be rewrapped
quite easily.
Well, the decrypted keys are already stored in backend memory,
The fact that if the pg process is compromised then the DEK and data
encrypted are compromised is more or less unavoidable (maybe only the data
could be compromised though, but not the DEK, depending on how the
encryption/decryption operates).
so what risk does haveing the KEK in memory for a brief period avoid?
My understanding is that the KEK does not protect one key, but all keys,
thus all data, possibly even past or future, so it loss impacts more than
the here and now local process.
If the KEK is ever present in pg process, it presumes that the threat
model being addressed allows its loss if the process is compromised, i.e.
all (past, present, future) security properties are void once the process
is compromised.
This may be okay for some use cases, but I can easily foresee that it
would not be for all. I can think of use cases where the user/auditor says
that the KEK should be elsewhere, and I would tend to agree.
So my point is that the implementation should allow it, i.e. define a
simple interface, and possibly a reference implementation with good
properties which might fit some/typical security requirements, and the
patch mostly fits that need, but for the possible isolation of the KEK.
ISTM that a reasonable point of comparision is the design of kerberos,
with a central authority/server which authenticate parties and allow them
to authenticate one another and communicate securely.
The design means that any compromised host/service would compromise all
its interaction with other parties, but not communications between third
parties. The compromission stays local, with the exception is the kerberos
server itself, which somehow holds all the keys.
For me the KEK is basically the kerberos server, you should provide means
to allow the user to isolate that where they think it should be, and not
enforce that it is within postgres process.
Another point is that what I suggest does not seem very hard from an
implementation point of view, and allows extensibility, which is also a
win.
Lastly, I still think that all this, whatever the design, should be
packaged as an extension, unless it is really impossible to do so. I would
also try to separate the extension for KMS interaction with the extension
for actually using the keys, so that the user could change the underlying
cryptographic primitives as they see fit.
--
Fabien.
