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.
