Alexey,

Yes, administrator has to enter password before cluster *activation*(not start).

В Вт, 06/03/2018 в 13:27 +0300, Alexey Goncharuk пишет:
> 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
> > > > > 
> > > > > 

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to