Re: Internal key management system
| От | Craig Ringer |
|---|---|
| Тема | Re: Internal key management system |
| Дата | |
| Msg-id | CAGRY4nzt2R0iTwoU2L54d+eGqR_+kfQFJeNfgTHs5bAk58Xn_Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Internal key management system (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
| Ответы |
Re: Internal key management system
(Stephen Frost <sfrost@snowman.net>)
Re: Internal key management system (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
On Mon, Oct 19, 2020 at 11:16 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote:
The patch introduces only key management infrastructure but with no
key. Currently, there is no interface to dynamically add a new
encryption key.
I'm a bit confused by the exact intent and use cases behind this patch. https://www.postgresql.org/message-id/17156d2e419.12a27f6df87825.436300492203108132%40highgo.ca that was somewhat helpful but not entirely clear.
The main intent of this proposal seems to be to power TDE-style encryption of data at rest, with a single master key for the entire cluster. Has any consideration been given to user- or role-level key management as part of this, or is that expected to be done separately and protected by the master key supplied by this patch?
If so, what if I have a HSM (or virtualised or paravirt or network proxied HSM) that I want to use to manage my database keys, such that the database master key is protected by the HSM? Say I want to put my database key in a smartcard, my machine's TPM, a usb HSM, a virtual HSM provided by my VM/cloud platform, etc?
As far as I can tell with the current design I'd have to encrypt my unlock passphrase and put it in the cluster_passphrase_command script or its arguments. The script would ask the HSM to decrypt the key passphrase and write that over stdio where Pg would read it and use it to decrypt the master key(s). That would work - but it should not be necessary and it weakens the protection offered by the HSM considerably.
I suggest we allow the user to supply their own KEK via a cluster_encryption_key GUC. If set, Pg would create an SSLContext with the supplied key and use that SSLContext to decrypt the application keys - with no intermediate KEK-derivation based on cluster_passphrase_command performed. cluster_encryption_key could be set to an openssl engine URI, in which case OpenSSL would transparently use the supplied engine (usually a HSM) to decrypt the application keys. We'd install the cluster_passphrase_command as an openssl askpass callback so that if the HSM requires an unlock password it can be provided - like how it's done for libpq in Pg 13. Some thought is required for how to do key rotation here, though it matters a great deal less when a HSM is managing key escrow.
For example if I want to lock my database with a YubiHSM I would configure something like:
cluster_encryption_key = 'pkcs11:token=YubiHSM;id=0:0001;type=private'
The DB would be encrypted and decrypted using application keys unlocked by the HSM. Backups of the database, stolen disk images, etc, would be unreadable unless you have access to another HSM with the same key loaded.
If cluster_encryption_key is unset, Pg would perform its own KEK derivation based on cluster_passphrase_command as currently implemented.
I really don't think we should be adopting something that doesn't consider platform based hardware key escrow and protection.
В списке pgsql-hackers по дате отправления: