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 <nizhi...@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 <nizhi...@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.
signature.asc
Description: This is a digitally signed message part
