Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20190719120213.venacoihf2cab6qv@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) (Antonin Houska <ah@cybertec.at>) |
Список | pgsql-hackers |
On Fri, Jul 19, 2019 at 01:32:01PM +0200, Antonin Houska wrote: >Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > >> On Mon, Jul 15, 2019 at 06:11:41PM -0400, Bruce Momjian wrote: >> >On Mon, Jul 15, 2019 at 11:05:30PM +0200, Tomas Vondra wrote: >> >> On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote: >> >> > On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote: >> >> > > One extra thing we should consider is authenticated encryption. We can't >> >> > > just encrypt the pages (no matter which AES mode is used - XTS/CBC/...), >> >> > > as that does not provide integrity protection (i.e. can't detect when >> >> > > the ciphertext was corrupted due to disk failure or intentionally). And >> >> > > we can't quite rely on checksums, because that checksums the plaintext >> >> > > and is stored encrypted. >> >> > >> >> > Uh, if someone modifies a few bytes of the page, we will decrypt it, but >> >> > the checksum (per-page or WAL) will not match our decrypted output. How >> >> > would they make it match the checksum without already knowing the key. >> >> > I read [1] but could not see that explained. >> >> > >> >> >> >> Our checksum is only 16 bits, so perhaps one way would be to just >> >> generate 64k of randomly modified pages and hope one of them happens to >> >> hit the right checksum value. Not sure how practical such attack is, but >> >> it does require just filesystem access. >> > >> >Yes, that would work, and opens the question of whether our checksum is >> >big enough for this, and if it is not, we need to find space for it, >> >probably with a custom encrypted page format. :-( And that makes >> >adding encryption offline almost impossible because you potentially have >> >to move tuples around. Yuck! >> > >> >> Right. We've been working on allowing to disable checksum online, and it >> would be useful to allow something like that for encryption too I guess. >> And without some sort of page-level flag that won't be possible, which >> would be rather annoying. >> >> Not sure it needs to be in the page itself, though - that's pretty much >> why I proposed to store metadata (IV, key ID, ...) for encryption in a >> new fork. That would be a bit more flexible than storing it in the page >> itself (e.g. different encryption schemes might easily store different >> amounts of metadata). >> >> Maybe a new fork is way too complex solution, not sure. > >One problem of this new fork would be that contents of its buffer (the MAC >values) is not determined until the corresponding buffers of the MAIN fork get >encrypted. However encryption is performed by the storage layer (md.c), which >is not expected to lock other buffers (such as those of the "MAC fork"), read >their pages from disk or insert their WAL records. > >This is different from the FSM or VM forks whose buffers are only updated >above the storage layer. > Yes, that seems like a valid issue :-( -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: