ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Pavlov <dpavlov....@gmail.com>
Subject Re: Transparent Data Encryption (TDE) in Apache Ignite
Date Mon, 14 May 2018 17:16:38 GMT
Hi Nikolay,

I don't mean we should release TDE without WAL, I mean we can consider
phase-1 as minmal mergeable chunk of functionality, which does not fail
tests and contains meaningfull set of changes for TDE.

Sincerely,
Dmitriy Pavlov

пн, 14 мая 2018 г. в 17:45, Nikolay Izhikov <nizhikov@apache.org>:

> Dmitry.
>
> From my point of view, WAL encryption should be done in Phase-1.
> We should provide only production ready features to the users, isn't it?
>
> Ticket for a phase-1 created -
> https://issues.apache.org/jira/browse/IGNITE-8485
>
> I'm starting working on it and expecting to implement it in a couple
> months.
>
> В Пн, 14/05/2018 в 17:33 +0300, Dmitry Pavlov пишет:
> > Hi Nickolay,
> >
> > Thank you for sharing results.
> >
> > I would suggest to make phase 1 as small as possible, for example,
> skipping
> > WAL encryption or something like that.
> >
> > It would not be full TDE implementation, but will allow us to move by
> small
> > steps, it also allows us to merge smaller changes to master.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 14 мая 2018 г. в 16:53, Nikolay Izhikov <nizhikov@apache.org>:
> >
> > > Hello, guys.
> > >
> > > We had private discussion about TDE with Dmitriy Pavlov, Vladimir
> Ozerov
> > > and Anton Vinogradov.
> > >
> > > Some decisions was made I want to approve with communtiy:
> > >
> > >   1. Current design of TDE is OK. We can start work on implementation.
> > >
> > >   2. We should split implementation to phases.
> > >      So we can focus on basic features and deliver it to users.
> > >      And after it, extend it for a full compliance with enterprise
> > > standarts such as PCI DSS and others.
> > >
> > > I propose following plan:
> > >
> > >   Phase-1. Basic TDE:
> > >     1. Usage of standard JKS, Java Security.
> > >
> > >     2. Persistent Data Encryption/Decryption.
> > >
> > >   Phase-2. Keys rotation:
> > >     1. Key regeneration.
> > >
> > >     2. CEK and MEK rotation.
> > >
> > > Other phases to be added.
> > >
> > > Thoughts or objections?
> > >
> > > В Пн, 07/05/2018 в 10:19 +0000, Dmitry Pavlov пишет:
> > > > Hi, just 2 remarks,
> > > >
> > > > 1) We should somehow separate issue with disc corruption and
> incorrect
> > >
> > > key.
> > > > For incorrect key I suggest to adopt Key Check Value (KCV) techique.
> It
> > >
> > > is
> > > > some heading bytes (e.g. 3 bytes) of encrypted 00...00 block using
> this
> > > > key. KCV allow us to check key decrypted correctly and check key
> before
> > > > processing storage.
> > > >
> > > > 2) I'm not sure about AES CBC, would it be applied only to one page,
> or
> > >
> > > to
> > > > whole store? We need random access to pages for example for page
> > > > replacement process, so we need to reset CBC init vector (IV) to some
> > >
> > > well
> > > > known value. If we set IV to 0 for each page dectyption, it means
> CBC is
> > > > applied only in scope of page. Continious IV accumulating CBC mode
> for
> > > > whole store seems to be not working. Same question about IV is
> applicable
> > > > to WAL records.
> > > >
> > > > Could we consider ECB? or limit CBC with zero or well known IV?
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > сб, 5 мая 2018 г. в 17:49, Nikolay Izhikov <nizhikov@apache.org>:
> > > >
> > > > > Hello, Guys.
> > > > >
> > > > > Here are answers to the TDE design questions.
> > > > > I will create FAQ in IEP-18 with this answers, also.
> > > > >
> > > > > > 1. MEK, CEK rotation. Should we provide the way to
> change(regenerate)
> > > > >
> > > > > MEK, CEK from time to time?
> > > > >
> > > > > Yes. PCI DSS are require it. See 3.6.4, 3.6.5 sections.
> > > > >
> > > > > > 2. Does CEK(table keys) relate to user access permission?
> > > > >
> > > > > No. It is prohibited by PCI DSS. 3.4.1: "Decryption keys must not
> be
> > > > > associated with user accounts"
> > > > >
> > > > > > 3. WAL encryption. How will it be implemented?
> > > > >
> > > > > LogicalRecord – key+value for encrypted cache entries are
> encrypted.
> > > > > PhysicalRecord.FullPageSnaphot - regular page encryption algorithm
> > >
> > > used.
> > > > > PhysicalRecord.DeltaRecord - delta is encrypted.
> > > > >
> > > > > > 4. We should keep CEKs in MetaStore.
> > > > >
> > > > > Yes, we should.
> > > > > We can't store CEKs in KeyStore because of PCI DSS 3.5.3.c:
> > > > > "Key-encrypting keys are stored separately from data-encrypting
> keys."
> > > > >
> > > > > > 5. How should we handle following case
> > > > >
> > > > > I propose to not include the node to cluster with the appropriate
> > > > > exception message.
> > > > >
> > > > > > 6. Public API to deal with CEK should be provided.
> > > > >
> > > > > The first draft of public API for TDE -
> > > > > https://github.com/nizhikov/ignite/pull/12
> > > > >
> > > > > > 7. Can each node use own CEK? What are pros and cons for that?
> > > > >
> > > > > I propose to use one CEK per cache.
> > > > > CEK would be the same on every cluster node.
> > > > > It simplifies Ignite cluster management, backup procedure(like
> saving
> > >
> > > key
> > > > > copies on some external device), etc.
> > > > >
> > > > > > 8. How we can ensure that decryption succeed? In case CEK is
> broken.
> > >
> > > It
> > > > >
> > > > > can be broken because of memory corruption, network errors, etc.
> > > > >
> > > > > Currently, page integrity is checked by CRC.
> > > > > I propose to reuse this procedure to ensure decryption integrity.
> > > > >
> > > > > > 9. Specific encryption algorithm has to be chosen prior an
> > > > >
> > > > > implementation.
> > > > >
> > > > > AES CBC – 256, 192, 128 bits.
> > > > >
> > > > > > 10. Page integrity are checked by CRC. How this process would
be
> > >
> > > changed
> > > > >
> > > > > for encrypted pages?
> > > > >
> > > > > The process doesn't change:
> > > > > 1. Decrypt page.
> > > > > 2. Check CRC.
> > > > >
> > > > > > 11. Page header has well-known content. This can be used for
> > > > >
> > > > > known-plain-text attacks. We should measure the treatment and find
> the
> > >
> > > way
> > > > > to deal with it.
> > > > >
> > > > > This question requires additional research.
> > > > > We have to understand: Is there any issue here?
> > > > > But at first glance, We can encrypt blocks in reverse order – from
> > >
> > > last to
> > > > > first.
> > > > > Last blocks don't have well know so there is no issue here.
> > > > >
> > > > > В Пт, 27/04/2018 в 19:41 +0300, Nikolay Izhikov пишет:
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > We've discussed TDE design privately with some respected
> community
> > > > >
> > > > > members including Vladimir Ozerov and Alexey Goncharyuk.
> > > > > > Here the list of questions we have to address before starting
TDE
> > > > >
> > > > > implementation:
> > > > > >
> > > > > > 1. MEK, CEK rotation.
> > > > > > Should we provide the way to change(regenerate) MEK, CEK from
> time to
> > > > >
> > > > > time?
> > > > > > Is it required by PCI DSS standard?
> > > > > >
> > > > > > 2. Does CEK(table keys) relate to user access permission?
> > > > > > Need to study other vendors implementation.
> > > > > >
> > > > > > 3. WAL encryption. How will it be implemented? What issues we
> have to
> > > > >
> > > > > solve?
> > > > > >
> > > > > > 4. We should keep CEKs in MetaStore.
> > > > > > Not a question, just to write down decision.
> > > > > >
> > > > > > 5. How should we handle following case:
> > > > > >     a. Node X left cluster.
> > > > > >     b. Node X joins cluster.
> > > > > >     c. Between steps a and b encryption keys has been changed
> > > > > >
> > > > > > 6. Public API to deal with CEK should be provided.
> > > > > > Looks like we need to support following methods:
> > > > > >     a. Generate new CEK when encrypted cache are created
> > > > > >     b. Decrypt CEK whenever needed.
> > > > > >
> > > > > > 7. Can each node use own CEK? What are pros and cons for that?
> > > > > >
> > > > > > 8. How we can ensure that decryption succeed?
> > > > > > In case CEK is broken. It can be broken because of memory
> corruption,
> > > > >
> > > > > network errors, etc.
> > > > > >
> > > > > > 9. Specific encryption algorithm has to be chosen prior an
> > > > >
> > > > > implementation.
> > > > > > We have to support usage of other algorithms.
> > > > > >
> > > > > > 10. Page integrity are checked by CRC. How this process would
be
> > >
> > > changed
> > > > >
> > > > > for encrypted pages?
> > > > > >
> > > > > > 11. Page header has well-known content. This can be used for
> > > > >
> > > > > known-plain-text attacks.
> > > > > > We should measure the treatment and find the way to deal with
it.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message