Re: Proposed patch for key managment - Mailing list pgsql-hackers

Greetings,

* Alastair Turner (minion@decodable.me) wrote:
> On Wed, 16 Dec 2020 at 21:32, Stephen Frost <sfrost@snowman.net> wrote:
> > * Alastair Turner (minion@decodable.me) wrote:
> > > On Wed, 16 Dec 2020 at 00:12, Bruce Momjian <bruce@momjian.us> wrote:
> > > > The second approach is to make a new API for what you want....
> > >
> > > I am trying to motivate for an alternate API. Specifically, an API
> > > which allows any potential adopter of Postgres and Cluster File
> > > Encryption to adopt them without having to accept any particular
> > > approach to key management, key derivation, wrapping, validation, etc.
> > > A passphrase key-wrapper with validation will probably be very useful
> > > to a lot of people, but making it mandatory and requiring twists and
> > > turns to integrate with already-established security infrastructure
> > > sounds like a barrier to adoption.
> >
> > Yeah, I mentioned this in one of the other threads where we were
> > discussing KEKs and DEKs and such.  Forcing one solution for working
> > with the KEK/DEK isn't really ideal.
> >
> > That said, maybe there's an option to have the user indicate to PG if
> > they're passing in a passphrase or a DEK, ...
>
> Some options very much like the current cluster_passphrase_command,
> but that takes an input sounds to me like it would meet that
> requirement. The challenge sent to the command could be just a text
> prompt, or it could be the wrapped DEK. The selection of the command
> would indicate what the user was expected to pass. The return would be
> a DEK.

If I'm following, you're suggesting something like:

cluster_passphrase_command = 'aws get %q'

and then '%q' gets replaced with "Please provide the WAL DEK: ", or
something like that?  Prompting the user for each key?  Not sure how
well that's work if want to automate everything though.

If you have specific ideas, it'd really be helpful to give examples of
what you're thinking.

> > ...but we otherwise more-or-less
> > keep things as they are where the DEK that the user provides actually
> > goes to encrypting the sub-keys that we use for tables vs. WAL..?  ...
>
> The idea of subkeys sounds great, if it can merge the two potential
> interactions into one and not complicate rotating the two parts
> separately. But having Postgres encrypting them, leaves us open to
> many of the same issues. That still feels like managing the keys, so a
> corporate who have strong opinions on how that should be done will
> still ask all sorts of pointy questions, complicating adoption.

This really needs more detail- what exactly is the concern?  What are
the 'pointy questions'?  What's complicated about using sub-keys?  One
of the great advantages of using sub-keys is that you can rotate the KEK
(or whatever is passed to PG) without having to actually go through the
entire system and decyprt/re-encrypt everything.  There's, of course,
the downside that then you don't get the keys rotated as often as you
might like to, but I am, at least, hopeful that we might be able to find
a way to do that in the future.

> > ...That
> > avoids the complication of having to have an API that somehow provides
> > more than one key, while also using the primary DEK key as-is from the
> > key management service and the KEK never being seen on the system where
> > PG is running.
>
> Other than calling out (and therefore potentially prompting) twice,
> what do you see as the complications of having more than one key?

Mainly just a concern about the API and about what happens if, say, we
decide that we want to have another sub-key, for example.  If we're
handling them then there's really no issue- we just add another key in,
but if that's not happening then it's going to mean changes for
administrators.  If there's a good justification for it, then perhaps
that's alright, but hand waving at what the issue is doesn't really
help.

> > > > ...It would be
> > > > similar to the cluster_passphrase_command, but it would be simple in
> > > > some ways, but complex in others since we need at least two DEKs, and
> > > > key rotation might be very risky since there isn't validation in the
> > > > server.
> > >
> ...
> >
> > I'm not quite following this- I agree that we don't want PG, or anything
> > really, to see the private key that's on the Yubikey, as that wouldn't
> > be good- instead, we should be able to ask for the Yubikey to decrypt
> > the DEK for us and then use that, which I had thought was happening but
> > it's not entirely clear from the above discussion (and, admittedly, I've
> > not tried using the patch with my yubikey yet, but I do plan to...).
> >
> > Are we sure we're talking about the same thing here..?  That's really
> > the question I'm asking myself.
>
> I'd describe what the current patch does as using YubiKey to encrypt
> and then decrypt an intermediate secret, which is then used to
> generate/derive a KEK, which is then used to unwrap the stored,
> wrapped DEK.

This seems like a crux of at least one concern- that the current patch
is deriving the actual KEK from the passphrase and not just taking the
provided value (at least, that's what it looks like from a *very* quick
look into it), and that's the part that I was suggesting that we might
add an option for- to indicate if the cluster passphrase command is
actually returning a passphrase which should be used to derive a key, or
if it's returning a key directly to be used.  That does seem to be a
material difference to me and one which we should care about.

> > There's an entirely independent discussion to be had about figuring out
> > a way to actually off-load *entirely* the encryption/decryption of data
> > to the linux crypto system or hardware devices, but unless someone can
> > step up and write code for those today, I'd suggest that we table that
> > effort until after we get this initial capability of having TDE with PG
> > doing all of the encryption/decryption.
>
> I'm hopeful that the work on abstracting OpenSSL, nsstls, etc is going
> to help in this direct.

Yes, I agree with that general idea but it's a 'next step' kind of
thing, not something we need to try and bake in today.

Thanks,

Stephen