Re: Internal key management system

Hello Masahiko-san,

> This key manager is aimed to manage cryptographic keys used for
> transparent data encryption. As a result of the discussion, we
> concluded it's safer to use multiple keys to encrypt database data
> rather than using one key to encrypt the whole thing, for example, in
> order to make sure different data is not encrypted with the same key
> and IV. Therefore, in terms of TDE, the minimum requirement is that
> PostgreSQL can use multiple keys.
>
> Using multiple keys in PG, there are roughly two possible designs:
>
> 1. Store all keys for TDE into the external KMS, and PG gets them from
> it as needed.

+1

> 2. PG manages all keys for TDE inside and protect these keys on disk
> by the key (i.g. KEK) stored in the external KMS.

-1, this is the one where you would need arguing.

> There are pros and cons to each design. If I take one cons of #1 as an
> example, the operation between PG and the external KMS could be
> complex. The operations could be creating, removing and rotate key and
> so on.

ISTM that only create (delete?) are really needed. Rotating is the problem 
of the KMS itself, thus does not need to be managed by pg under #1.

> We can implement these operations in an extension to interact
> with different kinds of external KMS, and perhaps we can use KMIP.

I would even put that (KMIP protocol stuff) outside pg core.

Even under #2, if some KMS is implemented and managed by pg, I would put 
the stuff in a separate process which I would probably run with a 
different uid, so that the KEK is not accessible directly by pg, ever.

Once KMS interactions are managed with an outside process, then what this 
process does becomes an interface, and whether this process actually 
manages the keys or discuss with some external KMS with some KMIP or 
whatever is irrelevant to pg. Providing an interface means that anyone 
could implement their KMS fitting their requirements if they comply with 
the interface/protocol.

Note that I'd be fine with having the current implementation somehow 
wrapped up as an example KMS.

> But the development cost could become high because we might need 
> different extensions for each key management solutions/services.

Yes and no. What I suggest is, I think, pretty simple, and I think I can 
implement it in a few line of script, so the cost is not high, and having 
a separate process looks, to me, like a security win and an extensibility 
win (i.e. another implementation can be provided).

> #2 is better at that point; the interaction between PG and KMS is only
> GET.

I think that it could be the same with #1. I think that having a separate 
process is a reasonable security requirement, and if you do that #1 and #2 
are more or less the same.

> Other databases employes a similar approach are SQL Server and DB2.

Too bad for them:-) I'd still disagree with having the master key inside 
the database process, even if Microsoft, IBM and Oracle think it is a good 
idea.

> In terms of the necessity of introducing the key manager into PG core,
> I think at least TDE needs to be implemented in PG core. And as this
> key manager is for managing keys for TDE, I think the key manager also
> needs to be introduced into the core so that TDE functionality doesn't
> depend on external modules.

Hmmm.

My point is that only interactions should be in core.

The implementation could be in core, but as a separate process.

I agree that pg needs to be able to manage the DEK, so it needs to store 
data keys.

I still do not understand why an extension, possibly distributed with pg, 
would not be ok. There may be good arguments for that, but I do not think 
you provided any yet.

>> Also, I'm not at fully at ease with some of the underlying principles
>> behind this proposal. Are we re-inventing/re-implementing kerberos or
>> whatever? Are we re-implementing a brand new KMS inside pg? Why having
>> our own?
>
> As I explained above, this key manager is for managing internal keys
> used by TDE. It's not an alternative to existing key management
> solutions/services.

Hmmm. This seels to suggest that interacting with something outside should 
be an option.

> The requirements of this key manager are generating internal keys,
> letting other PG components use them, protecting them by KEK when
> persisting,

If you want that, I'd still argue that you should have a separate process.

> and support KEK rotation. It doesn’t have a feature like
> allowing users to store arbitrary keys into this key manager, like
> other key management solutions/services have.

Hmmm.

> I agree that the key used to encrypt data must not be placed in the
> same host. But it's true only when the key is not protected, right?

The DEK is needed when encrypting and decrypting, obviously, so it would 
be there once obtained, it cannot be helped. My concern is about the KEK, 
which AFAICS in your code is somewhere in memory accessible by the 
postgres process, which is a no go for me.

The definition of "protected" is fuzzy, it would depend on what the user 
requires. Maybe protected for someone is "in a file which is only readable 
by postgres", and for someone else it means "inside an external hardware 
components activated by the fingerprint of the CEO".

> In
> this key manager, since we protect all internal keys by KEK it's no
> problem unless KEK is leaked. KEK can be obtained from outside key
> management solutions/services through cluster_passphrase_command.

Again, I do not think that the KEK should be in postgres process, ever.

>>
>> Also, implementing a crash-safe key rotation algorithm does not look like
>> inside pg backend, that is not its job.
>
> The key rotation this key manager has is KEK rotation, which is very
> important. Without KEK rotation, when KEK is leaked an attacker can
> get database data by disk theft. Since KEK is responsible for
> encrypting all internal keys it's necessary to re-encrypt the internal
> keys when KEK is rotated. I think PG is the only role that can do that
> job.

I'm not claiming that KEK rotation is a bad thing, I'm saying that it 
should not be postgres problem. My issue is where you put the thing, not 
about the thing itself.

> I think this key manager satisfies the fist point by
> cluster_passphrase_command. For the second point, the key manager
> stores local keys inside PG while protecting them by KEK managed
> outside of PG.

I do not understand. From what I understood from the code, the KEK is 
loaded into postgres process. That is what I'm disagreeing with, only 
needed DEK should be there.

[...]

-- 
Fabien.