Re: Proposed patch for key managment

On Wed, Dec 16, 2020 at 04:32:00PM -0500, Stephen Frost wrote:
> Greetings,
> 
> * 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, 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..?  That

Yes, that is what I suggested in an earlier email.

> 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.

How is that diffeent from what we have now?  Did you read my reply today
to Alastair with the AWS script?

> > > ...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 guess that the risk you're talking about here is encryption with a
> > bogus key and bricking the data? In a world where the wrapped keys are
> > opaque to the application, a key would be validated through a
> > roundtrip: request the unwrapping of the key, encrypt a known string,
> > request the unwrapping again, decrypt the known string, compare. If
> > any of those steps fail, don't use the wrapped key provided.
> > Validating that the stored keys have not been fiddled/damaged is the
> > KMS/HSM's responsibility.
> 
> I'm not really sure what the validation concern being raised here is,
> but I can understand Bruce's point about having to set up an API that
> allows us to ask for two distinct DEK's- but I'd think that keeping the
> two keys we have today as sub-keys addresses that as I outline above.

Right, how is a passphrase different than subkeys?

> > >... I don't think this can be accomplished by a contrib module, but
> > > would actually be easy to implement, but perhaps hard to document
> > > because the user API might be tricky.
> > 
> > If integration through a pipeline isn't good enough (it would be a
> > pain for the passphrase, with multiple prompts), what else do you see
> > an API having to provide?
> 
> I certainly agree that it'd be good to have a way to get an encrypted
> cluster set up and running which doesn't involve actual prompts.

Uh, two of my four scripts do not require prompts.

> > > I think my big question is about your sentence, "A key feature of these
> > > key management approaches is that the application handling the
> > > encrypted data doesn't get the KEK, the HSM/KSM passes the DEK back
> > > after unwrapping it."  It is less secure for the HSM to return a KEK
> > > rather than a DEK?  I can't see why it would be.  The application never
> > > sees the KEK used to wrap the DEK it has stored in the file system,
> > > though that DEK is actually used as a passphrase by Postgres.  This is
> > > the same with the Yubikey --- Postgres never sees the private key used
> > > to unlock what it locked with the Yubikey public key.
> > 
> > The protocols and practices are designed for a lot of DEKs and small
> > number of KEK's. So the compromise of a KEK would, potentially, lead
> > to compromise of thousands of DEKs. In this particular case with 2
> > DEKs wrapped by one KEK, it doesn't sound like much of a difference, I
> > agree. From an acceptance and adoption point of view, I'm just
> > inclined to use the security ecosystem in an established and
> > understood way.
> 
> 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...).

What it does is to encrypt the passphrase on boot, store it on disk, and
then pass the file to the Yubikey to be decrypted and the passphrase
passed to the server.

> Are we sure we're talking about the same thing here..?  That's really
> the question I'm asking myself.

Seems so.
> 
> 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.

Agreed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee