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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 08:01:16
Message-ID: CAD21AoD4W6SMP21rpa+sD6zY0E1cBXtGmHapdVVLYW7JdhMUOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 13, 2019 at 2:09 PM Smith, Peter <peters(at)fast(dot)au(dot)fujitsu(dot)com> wrote:
>
> 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.
>

Yeah, I studied the design of TDE from FEP as well as other database
supporting 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');

Thank you for explaining!

I think that the main difference between FEP and our proposal is the
master key management. In our proposal postgres can get the master key
from the external key management server or services such as AWS KMS,
Gemalto KeySecure and an encrypted file by using the corresponding
plugin. We believe that this extensible architecture would be useful
for applying postgres to various systems.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-05-13 08:10:18 Re: PANIC :Call AbortTransaction when transaction id is no normal
Previous Message Kuntal Ghosh 2019-05-13 07:55:19 Re: PANIC :Call AbortTransaction when transaction id is no normal