On Thu, 11 Jun 2020 at 16:07, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > > Hello Bruce, > > Sorry for the length (yet again) of this answer, I'm trying to make my > point as clear as possible.
Thank you for your explanation! > > >> 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. Why we should not put KEK in pg process but it's okay for other processes? I guess you're talking about a threat when a malicious user logged in OS (or at least accessible) but I thought there is no difference between pg process and other processes in terms of the process being compromised. So the solution, in that case, would be to outsource encryption/decryption to external servers as Bruce mentioned. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
