Re: Internal key management system

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.