Re: Internal key management system
Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Bruce Momjian <bruce@momjian.us>, Cary Huang <cary.huang@highgo.ca>, Ahsan Hadi <ahsan.hadi@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Moon, Insung" <tsukiwamoon.pgsql@gmail.com>,
Robert Haas <robertmhaas@gmail.com>, Sehrope Sarkuni <sehrope@jackdb.com>, cary huang <hcary328@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Joe Conway <mail@joeconway.com>
Date: 2020-06-11T08:39:35Z
Lists: pgsql-hackers
On Thu, 11 Jun 2020 at 16:07, Fabien COELHO <coelho@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