Re: Proposed patch for key managment

On Tue, Dec 15, 2020 at 11:13:12PM +0000, Alastair Turner wrote:
> Since it's exciting stuff, I've been trying to lash together a PoC integration
> with the crypto infrastructure we see at these customers. Unfortunately, in
> short, the API doesn't seem to suit integration with HSM big iron, like Thales,
> Utimaco, (other options are available), or their cloudy lookalikes.
> 
> I understand the model of wrapping the Data Encryption Key and storing the
> wrapped key with the encrypted data. The thing I can't find support for in your
> patch is passing a wrapped DEK to an external system for decryption. 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. Google have a neat illustration of their approach, which is very
> similar to others, at https://cloud.google.com/kms/docs/envelope-encryption#
> how_to_decrypt_data_using_envelope_encryption
> 
> So instead of calling out to a passphrase command which returns input for a
> PBKDF, Postgres (in the form of initdb or postmaster) should be passing the
> wrapped DEK and getting back the DEK in plain. The value passed from Postgres
> to the external process doesn't even have to be a wrapped DEK, it could be a
> key in the key->value sense, for use in a lookup against Vault, CredHub or the
> Kubernetes secret store. Making the stored keys opaque to the Postgres
> processes and pushing the task of turning them into cryptographic material to
> an external hepler process probably wouldn't shrink the patch overall, but it
> would move a lot of code from core processes into the helper. Maybe that helper
> should live in contrib, as discussed below, where it would hopefully be joined
> by a bridge for KMIP and others.

Well, I think we can go two ways with this.  First, if you look at my
attached Yubikey script, you will see that, at boot time, since
$DIR/yubipass.key does not exit, the script generates a passphrase,
wraps it with the Yubikey's PIV #3 public key, and stores it in the live
key directory.  The next time it is called, it decrypts the wrapped
passphrase using the Yubikey, and uses that as the KEK to decrypt the
two DEKs.  Now, you could modify the script to call the HSM at boot time
to retrieve a DEK wrapped in a KEK, and store it in the key directory. 
On all future calls, you can pass the DEK wrapped by KEK to the HSM, and
use the returned DEK as the KEK/passphrase to decrypt the real DEK.  The
big value of this is that the keys are validated, and it uses the
existing API.  Ideally we write a sample script of how to this and
include it in /contrib.

The second approach is to make a new API for what you want.  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 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.

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.

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

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