Hello Masahiko-san,
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?
My point is "elsewhere".
Indeed, it could be on another process on the same host, in which case I'd
rather have the process run under a different uid, which means another
compromission would be required if pg is compromissed locally ; it could
also be in a process on another host ; it could be on some special
hardware. Your imagination is the limit.
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.
Processes are isolated based on uid, unless root is compromised. Once a id
is compromised (eg "postgres"), the hacker has basically access to all
files and processes accessible to that id.
So the solution, in that case, would be to outsource
encryption/decryption to external servers as Bruce mentioned.
Hosting stuff (keys, encryption) on another server is indeed an option if
"elsewhere" is implemented.
From a design point of view:
0. KEK, DEK & crypto are managed by pg
1. DEK & crypto are managed by pg,
but KEK is outside pg.
2. eveything is managed out of pg.
I think that both 1 & 2 are valid options, which do not require the same
interface. If you have 1, you can do 0 by giving KEK to a pg process.
How DEK are identified and created with the KEK should also be something
open, left to the implementation, the interface should not need to know.
--
Fabien.
