On Tue, Oct 27, 2020 at 10:02:53PM +0800, Craig Ringer wrote:
> On Tue, 27 Oct 2020, 19:15 Bruce Momjian, <bruce@momjian.us> wrote:
> We don't need to do anything except provide a way to tell OpenSSL where to get
> the KEK from, for situations where having Pg generate it internally
> undesirable.
>
> I proposed a simple GUC that we could supply to OpenSSL as a key path because
> it's simple. It's definitely not best.
>
> In my prior mail I outlined what I think is a better way. Abstract key key
> initialisation - passphrase fetching KEK/HMAC loading and all of it - behind a
> pluggable interface. Looking at the patch, it's mostly there already. We just
> need a way to hook the key loading and setup so it can be overridden to use
> whatever method is required. Then KEK operations to encrypt and decrypt the
> heap and WAL keys happen via that abstraction.
>
> That way Pg does not have to care about the details of hardware key management,
> PKCS#11 or OpenSSL engines, etc.
>
> A little thought is needed to make key rotation work well. Especially when you
> want to switch from cluster passphrase to a plugin that supports use of a HVM
> escrowed key, or vice versa.
>
> But most of what's needed looks like it's there already. It's just down to
> making sure the key loading and initialisation is overrideable.
I don't know much about how to hook into that stuff so if you have an
idea, I am all ears. I have used OpenSSL with Yubikey via pksc11. You
can see the use of it on slide 57 and following:
https://momjian.us/main/writings/crypto_hw_config.pdf#page=57
Interestingly, that still needed the user to type in a key to unlock the
Yubikey, so we might need PKCS11 and a password for the same server
start.
I would like to get this moving forward so I will work on the idea of
passing an open /dev/tty file descriptor from pg_ctl to the postmaster
on start.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee