Nikolay, Does it mean that administrator must enter the MEK password upon Ignite start?
2018-03-06 13:24 GMT+03:00 Nikolay Izhikov <[email protected]>: > Hello, Alexey. > > Thank you for very helpfull feedback. > We certainly consider all the issues you written. > > > How encryption keys will be stored and accessed? > > *MEK(Master encryption key)* will be stored in regular java key store JKS > [1]. > To access it admin must enter key store password. > > *CEK(Cache encryption key)* will be stored inside regular Ignite cache. > It will be encrypted by MEK. > So access to CEK may be done only after one got the MEK. > > Please, see IEP draft for futher information [2]. > > > Will pages be encrypted on disk or also in memory? > > Current understanding that only on disk pages will be encrypted. > PCI DSS standart requires only on disk encryption. > > > How do you make sure that encrypted page fits the page size > > AFAIK encryption doesn't affect data size. > > > This significantly increases success of known-plain-text attacks. > > How will you write WAL delta records for encrypted pages? > > I don't have an answer to this questions for now. > So, prior to starting an implementation we returns with answers. > > [1] https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html > [2] https://1drv.ms/w/s!AqZdfua4UpmuhneoVhOCiXSUBGIf > > > В Вт, 06/03/2018 в 13:04 +0300, Alexey Goncharuk пишет: > > Guys, > > > > I think this TDE proposal is not thought through enough yet. Please > > consider the following points when writing the IEP: > > > > * How encryption keys will be stored and accessed? If the encryption key > > is stored with the same permissions as the main data storage, the whole > > exercise with encryption is self-deception > > * Will pages be encrypted on disk or also in memory? > > * How do you make sure that encrypted page fits the page size (I am not > an > > expert in encryption, so I am not sure if it adds an overhead) > > * As Dmitriy Pavlov mentioned, currently data and index pages are highly > > redundant and some of the fields in certain pages are known in advance. > > This significantly increases success of known-plain-text attacks. How are > > you planning to fix it? > > * How will you write WAL delta records for encrypted pages? If a change > in > > a single byte will potentially change the whole page, this will induce a > > huge write amplification on WAL. How do you encrypt WAL data records? How > > will this work with this optimization: [1] > > > > [1] https://ggsystems.atlassian.net/browse/IGN-7789 > > > > --AG > > > > 2018-03-06 8:55 GMT+03:00 Nikolay Izhikov <[email protected]>: > > > > > Thank you, it's - nizhikov > > > > > > В Пн, 05/03/2018 в 15:09 -0800, Denis Magda пишет: > > > > Nikolay, what's your Wiki ID? I'll grant you required permissions. > > > > > > > > -- > > > > Denis > > > > > > > > On Sun, Mar 4, 2018 at 11:00 PM, Nikolay Izhikov < > [email protected]> > > > > > > wrote: > > > > > Hello, Denis. > > > > > > > > > > > I would encourage you creating an IEP > > > > > > > > > > That is exactly what we want to do :) > > > > > > > > > > But seems I have not sufficient privileges to do it on Ignite wiki. > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/ > Active+Proposals > > > > > > > > > > Can you or someone give me such rights? > > > > > > > > > > В Чт, 01/03/2018 в 22:23 -0800, Denis Magda пишет: > > > > > > Dmitriy R., Nilokay, > > > > > > > > > > > > Thanks for the analysis and handout of the architectural design. > No > > > > > > doubts, > > > > > > it would be a valuable addition to Ignite. > > > > > > > > > > > > I would encourage you creating an IEP on the wiki and break the > work > > > > > > into > > > > > > pieces discussing specific part with the community. > > > > > > > > > > > > -- > > > > > > Denis > > > > > > > > > > > > > > > > > > On Thu, Mar 1, 2018 at 9:29 PM, Nikolay Izhikov < > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hello, Dmitriy. > > > > > > > > > > > > > > Thank you for feedback! > > > > > > > > > > > > > > > Will it be supported? > > > > > > > > > > > > > > Yes. > > > > > > > > > > > > > > TDE shouldn't broke any of existing Ignite features. > > > > > > > It adds some encrypt/decrypt level when we writing and reading > > > > > > pages > > > > > > > in/from PDS. > > > > > > > > > > > > > > В Пт, 02/03/2018 в 07:29 +0300, Dmitriy Setrakyan пишет: > > > > > > > > I have looked at the design, but could not find anything > about > > > > > > running > > > > > > > > > > > > > > SQL > > > > > > > > queries against the encrypted data. Will it be supported? > > > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > On Thu, Mar 1, 2018 at 8:05 PM, Nikolay Izhikov < > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hell, Dima! > > > > > > > > > > > > > > > > > > Thank you for document! > > > > > > > > > > > > > > > > > > I'm ready to implement this feature with you. > > > > > > > > > > > > > > > > > > Igniters, please, share you thoughts about proposed design > > > > > > > > > > > > > > > > > > [1] https://1drv.ms/w/s!AqZdfua4UpmuhneoVhOCiXSUBGIf > > > > > > > > > > > > > > > > > > В Чт, 01/03/2018 в 15:46 +0300, Дмитрий Рябов пишет: > > > > > > > > > > Hello, Igniters! > > > > > > > > > > > > > > > > > > > > I investigated the issue and wrote some details in a > draft > > > > > > document > > > > > > > > > > [1]. I think we should made IEP for TDE because it is a > big > > > > > > change > > > > > > > > > > > > > > and > > > > > > > > > > should be described in a single place, but not in a > message > > > > > > > > > > conversation. > > > > > > > > > > Please, look it and write your thoughts. What is not > > > > > > understandable, > > > > > > > > > > what should be detailed or described? > > > > > > > > > > > > > > > > > > > > > Where are we going to store keys (MEK) physically? > Would > > > > > > it be > > > > > > > > > > > > > > PKCS#11 > > > > > > > > > > > storage? Where we will store passwords to unlock > storage > > > > > > or it > > > > > > > > > > > > > > will be > > > > > > > > > > > responibilty of user? > > > > > > > > > > > > > > > > > > > > I think we should provide interface for MEK storage to > let > > > > > > users use > > > > > > > > > > storages they want. I suppose at the first step we should > > > > > > provide > > > > > > > > > > > > > > very > > > > > > > > > > simple implementation, which will store MEK on every node > > > > > > and MEK > > > > > > > > > > > > > > will > > > > > > > > > > be extracted by administrator during cluster activation > > > > > > process. Once > > > > > > > > > > MEK is extracted from key store, we decrypt CEKs and > destroy > > > > > > open > > > > > > > > > > > > > > MEK, > > > > > > > > > > leaving open only cache keys. > > > > > > > > > > > > > > > > > > > > I think external storage is user's worry and we shouldn't > > > > > > give users > > > > > > > > > > built-in external storage like Oracle Wallet or Microsoft > > > > > > Azure Key > > > > > > > > > > Vault because it will increase Ignite's complexity too > much. > > > > > > > > > > > > > > > > > > > > And yes, we should to comply with the standards like > PKCS#11. > > > > > > > > > > > > > > > > > > > > > One more thing is how "node gets MEK from > coordinator", if > > > > > > we send > > > > > > > > > > > cleartext MEK, such security becomes useless also. > > > > > > > > > > > > > > > > > > > > Yeah, that's why we should use secured connection. As I > > > > > > know, we have > > > > > > > > > > SSL implementation over JDK implementation, am I right? > But > > > > > > we must > > > > > > > > > > ensure to use latest SSL/TLS version. > > > > > > > > > > > > > > > > > > > > [1] https://1drv.ms/w/s!AqZdfua4UpmuhneoVhOCiXSUBGIf > > > > > > > > >
