RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

From: "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Date: 2019-05-13 05:09:34
Message-ID: 201DD0641B056142AC8C6645EC1B5F62013C186A25@SYD1217
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Masahiko,

> Let me briefly explain the current design I'm thinking. The design employees 2-tier key architecture. That is, a database cluster has one
> master key and per-tablespace keys which are encrypted with the master key before storing to disk. Each tablespace keys are generated
> randomly inside database when CREATE TABLESPACE. The all encrypted tablespace keys are stored together with the master key ID to the
> file (say, $PGDATA/base/pg_tblsp_keys). That way, the startup process can easily get all tablespace keys and the master key ID before
> starting recovery, and therefore can get the all decrypted tablespace keys.

Your design idea sounds very similar to the current Fujitsu Enterprise Postgres (FEP) implementation of TDE.

FEP uses a master encryption key (MEK) for the database cluster. This MEK is stored in a file at some GUC variable location. This file is encrypted using a “passphrase” known only to the administrator.

There are also per-tablespace keys, which are randomly generated at the time of CREATE TABLESPACE and stored in files. There is one tablespace key file per tablespace. These tablespace key files are encrypted by the MEK and stored at the location specified by CREATE TABLESPACE.

Not all tablespaces use TDE. An FEP extension of the CREATE TABLESPACE syntax, creates the tablespace key file only when encryption was requested.
e.g. CREATE TABLESPACE my_secure_tablespace LOCATION '/home/postgre/FEP/TESTING/tablespacedir' WITH (tablespace_encryption_algorithm = 'AES256');

The MEK is not currently got from a third party. It is randomly generated when the master key file is first created by another added function.
e.g. select pgx_set_master_key('passphrase');

Kind Regards,
Peter Smith
Fujitsu Australia
Disclaimer

The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof.

Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.

If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscribe(at)fast(dot)au(dot)fujitsu(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2019-05-13 05:51:12 Re: New EXPLAIN option: ALL
Previous Message Thunder 2019-05-13 04:45:25 PANIC :Call AbortTransaction when transaction id is no normal