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

On Sat, Jul 27, 2019 at 12:27 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Jul 26, 2019 at 10:57 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
> >
> > Hi,
> >
> > Before my reply, I wanted to say that I've been lurking on this thread
> > for a bit as I've tried to better inform myself on encryption at rest
> > and how it will apply to what we want to build. I actually built a
> > (poor) prototype in Python of the key management system that Joe &
> > Masahiko both laid out, in addition to performing some "buffer
> > encrpytion" with it. It's not worth sharing at this point.
> >
> > With the disclaimer that I'm not as familiar with a lot of concepts as I
> > would like to be:
> >
> > On 7/25/19 1:54 PM, Masahiko Sawada wrote:
> > > On Fri, Jul 26, 2019 at 2:18 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > >>
> > >> On Thu, Jul 18, 2019 at 12:04:25PM +0900, Masahiko Sawada wrote:
> > >>> I've re-considered the design of TDE feature based on the discussion
> > >>> so far. The one of the main open question is the granular of
> > >>> encryption objects: cluster encryption or more-granular-than-cluster
> > >>> encryption. The followings describe about the new TDE design when we
> > >>> choose table-level encryption or something-new-group-level encryption.
> > >>>
> > >>> General
> > >>> ========
> > >>> We will use AES and support both AES-128 and AES-256. User can specify
> > >>> the new initdb option something like --aes-128 or --aes-256 to enable
> > >>> encryption and must specify --encryption-key-passphrase-command along
> > >>> with. (I guess we also require openssl library.) If these options are
> > >>> specified, we write the key length to the control file and derive the
> > >>> KEK and generate MDEK during initdb. wal_log_hints will be enabled
> > >>> automatically in encryption mode, like we do for checksum mode,
> > >>
> > >> Agreed. pg_control will store the none/AES128/AES256 indicator.
> > >>
> > >>> Key Management
> > >>> ==============
> > >>> We will use 3-tier key architecture as Joe proposed.
> > >>>
> > >>> 1. A master key encryption key (KEK): this is the ley supplied by the
> > >>> database admin using something akin to ssl_passphrase_command
> > >>>
> > >>> 2. A master data encryption key (MDEK): this is a generated key using a
> > >>> cryptographically secure pseudo-random number generator. It is
> > >>> encrypted using the KEK, probably with Key Wrap (KW):
> > >>> or maybe better Key Wrap with Padding (KWP):
> > >>>
> > >>> 3a. Per table data encryption keys (TDEK): use MDEK and HKDF to generate
> > >>> table specific keys.
> > >>
> > >> What is the value of a per-table encryption key? How is HKDF derived?
> > >
> > > Per-table encryption key is derived from MDEK with salt and its OID as
> > > info. I think we can store salts for each encryption keys into the
> > > separate file so that off-line tool also can read it.
> >
> > +1 with using the info/salt for the HKDF as described above. The other
> > decision will be the hashing algorithm to use. SHA-256?
>
> Yeah, SHA-256 would be better for safety.

After more thoughts, I'm confused why we need to have MDEK. We can use
KEK derived from passphrase and TDEK and WDEK that are derived from
KEK. That way, we don't need store any key in database file. What is
the advantage of 3-tier key architecture?

Regards,

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