Re: Internal key management system - Mailing list pgsql-hackers

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.