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.