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 <nizhi...@apache.org>:
> 
> > 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 <nizhi...@apache.org>
> > 
> > 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 <nizhi...@apache.org>
> > 
> > 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 <
> > 
> > nizhi...@apache.org>
> > > > > > 
> > > > > > 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