Re: Transparent Data Encryption (TDE) and encrypted files

Moon, Insung <tsukiwamoon(dot)pgsql(at)gmail(dot)com> wrote:

> On Wed, Oct 9, 2019 at 2:42 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> >
> > Moon, Insung <tsukiwamoon(dot)pgsql(at)gmail(dot)com> wrote:
> >
> > > I also tried to generate IV using PID (32bit) + tempCounter (64bit) at
> > > first, but in the worst-case PID and tempCounter are used in the same
> > > values.
> > > Therefore, the uniqueness of the encryption key was considered without
> > > considering the uniqueness of the IV value.
> >
> > If you consider 64bit counter insufficient (here it seems that tempCounter
> > counts the 1GB segments), then we can't even use LSN as the IV for relation
> > pages.
>
> The worst-case here is not a lack of tempCounter, but a problem that
> occurs when PID is reused after a certain period.
> Of course, it is very unlikely to be a problem because it is a
> temporary file, but since the file name can know the PID and
> tempFileCounter, if you accumulate some data, the same key and the
> same IV will be used to encrypt other data. So I thought there could
> be a problem.

ok

> > > First, it generates a hash value randomly for the file, and uses the
> > > hash value and KEK (or MDEK) to derive and use the key with
> > > HMAC-SHA256.
> > > In this case, there is no need to store the encryption key separately
> > > if it is not necessary to keep it in a separate IV file or memory.
> > > (IV is a hash value of 64 bits and a counter of 32 bits.)
> >
> > You seem to miss the fact that user of buffile.c can seek in the file and
> > rewrite arbitrary part. Thus you'd have to generate a new key for the part
> > being changed.
>
> That's right. I wanted to ask this too.
> Is it possible to overwrite the data already written in the actual buffile.c?
> Such a problem seems to become a problem when BufFileWRite function is
> called, and BufFileSeek function is called, and BufFileRead is called.
> In other words, the file is not written in units of 8kb, but the file
> is changed in the pos, and some data is read in another pos.

v04-0011-Make-buffile.c-aware-of-encryption.patch in [1] changes buffile.c so
that data is read and written in 8kB blocks if encryption is enabled. In order
to record the IV per block, the computation of the buffer position within the
file would have to be adjusted somehow. I can check it soon but not in the
next few days.

> I also thought that this would be a problem with re-creating the
> encrypted file, i.e., IV and key change would be necessary,
> So far, my research has found no case of overwriting data in the
> previous pos after it has already been created in File data (where
> FilWrite is called).
> Can you tell me the case overwriting buffer file?

(I suppose you mean BufFileWrite(), not FileWrite()). I don't remember if I
ever checked particular use case in the PG core, but as long as buffer.c API
allows such a thing to happen, the encryption code needs to handle it anyway.

v04-0012-Add-tests-for-buffile.c.patch in [1] contains regression tests that
do involve temp file overwriting.

[1] https://www.postgresql.org/message-id/7082.1562337694@localhost

--
Antonin Houska
Web: https://www.cybertec-postgresql.com