Re: Internal key management system

On Sat, 13 Jun 2020 at 05:59, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
>
> Hello Masahiko-san,
>
> > Summarizing the discussed points so far, I think that the major
> > advantage points of your idea comparing to the current patch's
> > architecture are:
> >
> > * More secure. Because it never loads KEK in postgres processes we can
> > lower the likelihood of KEK leakage.
>
> Yes.
>
> > * More extensible. We will be able to implement more protocols to
> > outsource other operations to the external place.
>
> Yes.
>
> > On the other hand, here are some downsides and issues:
> >
> > * The external place needs to manage more encryption keys than the
> > current patch does.
>
> Why? If the external place is just a separate process on the same host,
> probably it would manage the very same amount as what your patch.

In the current patch, the external place needs to manage only one key
whereas postgres needs to manages multiple DEKs. But with your idea,
the external place needs to manage both KEK and DEKs.

>
> > Some cloud key management services are charged by the number of active
> > keys and key operations. So the number of keys postgres requires affects
> > the charges. It'd be worse if we were to have keys per table.
>
> Possibly. Note that you do not have to use a cloud storage paid as a
> service. However, you could do it if there is an interface, because it
> would allow postgres to do so if the user wishes that. That is the point
> of having an interface that can be implemented differently for different
> use cases.

The same is true for the current patch. The user can get KEK from
anywhere they want using cluster_passphrase_command. But as I
mentioned above the number of keys that the user manages outside
postgres is different.

>
> > * If this approach supports only GET protocol, the user needs to
> > create encryption keys with appropriate ids in advance so that
> > postgres can get keys by id. If postgres TDE creates keys as needed,
> > CREATE protocol would also be required.
>
> I'm not sure. ISTM that if there is a KMS to manage keys, it could be its
> responsability to actually create a key, however the client (pg) would
> have to request it, basically say "given me a new key for this id".
>
> This could even work with a "get" command only, if the KMS is expected to
> create a new key when asked for a key which does not exists yet. ISTM that
> the client could (should?) only have to create identifiers for its keys.

Yeah, it depends on KMS, meaning we need different extensions for
different KMS. A KMS might support an interface that creates key if
not exist during GET but some KMS might support CREATE and GET
separately.

>
> > * If we need only GET protocol, the current approach (i.g.
> > cluser_passphase_command) would be more simple. I imagine the
> > interface between postgres and the extension is C function.
>
> Yes. ISTM that can be pretty simple, something like:
>
> A guc to define the process to start the interface (having a process means
> that its uid can be changed), which would communicate on its stdin/stdout.
>
> A guc to define how to interact with the interface (eg whether DEK are
> retrieved, or whether the interface is to ask for encryption/decryption,
> or possibly some other modes).
>
> A few function:
>
>   - set_key(<local-id:int>, <key-identifier:bytea>);
>     # may retrieve the DEK, or only note that local id of some key.
>
>   - encode(<local-id:int>, <data:bytea>) -> <encrypted-data:bytea>
>     # may fail if no key is associated to local-id
>     # or if the service is down somehow
>
>   - decode(<local-id>, <encrypted-data>) -> <data>
>     # could also fail if there is some integrity check associated
>
> > This approach is more extensible
>
> Yep.
>
> > but it also means extensions need to support multiple protocols, leading
> > to increase complexity and development cost.
>
> I do not understand what you mean by "multiple protocols". For me there is
> one protocol, possibly a few commands in this protocol between client
> (postgres) and DMS. Anyway, sending "GET <key-id>" to retreive a DEK, for
> instance, does not sound "complex". Here is some pseudo code:
>
> For get_key:
>
>    if (mode of operation is to have DEKS locally)
>      try
>        send to KMS "get <key-id>"
>        keys[local-id] = answer
>      catch & rethrow possible errors
>    elif (mode is to keep DEKs remote)
>      key_id[local-id] = key-id;
>    else ...
>
> For encode, the code is basically:
>
>    if (has_key(local-id))
>      if (mode of operation is to have DEKs locally)
>         return some_encode(key[local-id], data);
>      elif (mode is to keep DEKs remote)
>         send to KMS "encode key_id[local-id] data"
>         return answer; # or error
>      else ...
>    else
>       throw error local-id has no associated key;
>
> decode is more or less the same as encode.
>
> There is another thing to consider is how the client "proves" its identity
> to the KMS interface, which might suggest some provisions when starting a
> process, but you already have things in your patch to deal with the KEK,
> which could be turned into some generic auth.
>
> > * This approach necessarily doesn’t eliminate the data leakage threat
> > completely caused by process compromisation.
>
> Sure, if the process as decrypted data or DEK or whatever, then the
> process compromission leaks these data. My point is to try to limit the
> leakage potential of a process compromission.
>
> > Since DEK is placed in postgres process memory,
>
> May be placed, depending on the mode of operation.
>
> > it’s still possible that if a postgres process is compromised the
> > attacker can steal database data.
>
> Obviously. This cannot be helped if pg is to hold unencrypted data.
>
> > The benefit of lowering the possibility of KEK leakage is to deal with
> > the threat that the attacker sees database data encrypted by past or
> > future DEK protected by the stolen KEK.
>
> Yes.
>
> > * An open question is, as you previously mentioned, how to verify the
> > key obtained from the external place is the right key.
>
> It woud succeed in decrypting data if there is some associated integrity
> check.
>
> Note that from a cryptographic point if view, depending on the use case,
> it may be a desirable property that you cannot tell whether it is the
> right one.
>
> > Anything else we need to note?
>
> Dunno.
>
> I would like to see some thread model, and what properties you would
> expect depending on the hypothesis.
>
> For instance, I guess that the minimal you would like is that stolen
> database cold data (PGDATA contents) should not allow to recover clear
> contents, but only encrypted stuff which is the whole point of encrypting
> data in the first place. This is the "here and now".
>
> ISTM that the only possible achievement of the current patch is the above.
>
> Then you should also consider past data (prior states of PGDATA which may
> have been stored somewhere the attacker might recover) and future data
> (that the attacker may be able to recover later).
>

The current patch can protect old data and future data from theft
using KEK rotation for the case of KEK theft. The user needs to rotate
KEK on a regular basis.

> Now what happens on those (past, present, future) data on:
>
>   - stolen DEK
>
>   - stolen KEK
>
>   - stolen full cold data (whole disk stolen)
>
>   - access to process & live data
>     (pg account compromission at some point in time)
>
>   - access process & live data & ability to issue more commands at some
>     point in time...
>
>   - access to full host live data (root compromission)
>
>   - ...
>
>   - network full compromission (eg AD has been subverted, this is the usual
>     target for taking down everything on a network if every
>     authentication and authorization is managed by it, which is often
>     the case in a corporate network).
>
>   - the pg admin is working for the attacker...
>
>   - the sys admin is working for the attacker...
>
>   - ...
>
> In the end anyway you would lose, the question is how soon, how many
> compromissions are necessary.
>
> > Finally, please understand I’m not controverting your idea but just
> > trying to understand which approach is better from multiple
> > perspectives.
>
> The point of a discussion is basically to present arguments.

My point is the same as Bruce. I'm concerned about the fact that even
if we introduce this approach the present data could still be stolen
when a postgres process is compromised. It seems to me that your
approach is extensible and can protect data from threats in addition
to threats that the current patch can protect but it would bring some
costs and complexity instead comparing to the current patch. I'd like
to hear opinions from other hackers in the community.

I think the actual code would help to explain how your approach is not
complexed.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services