Re: Transparent Data Encryption (TDE) in Apache Ignite

[Dmitry Pavlov]

Hi Nikolay,

I don't mean we should release TDE without WAL, I mean we can consider
phase-1 as minmal mergeable chunk of functionality, which does not fail
tests and contains meaningfull set of changes for TDE.

Sincerely,
Dmitriy Pavlov

пн, 14 мая 2018 г. в 17:45, Nikolay Izhikov :

> 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 :
> >
> > > 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 +, 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 :
> > > >
> > > > > 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.
> > 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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 :
> 
> > 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 +, 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 :
> > > 
> > > > 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
> > > > 
> > > > 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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 :

> 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 +, 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 :
> >
> > > 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 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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 :

> 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 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

Hello, Manu

Thanks. I will take a look.

В Пт, 20/04/2018 в 03:17 -0700, Manu пишет:
> Hi,
> 
> Have you think about implementing TDE per DataRegion instead of per Cache?
> 
> And using a transparent encrypted java  file system?  
> This GitHub project is interesting  https://github.com/usrflo/encfs4j
>   .
> 
> Hope it helps!
> 
> Regards!
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Manu]

Hi,

Have you think about implementing TDE per DataRegion instead of per Cache?

And using a transparent encrypted java  file system?  
This GitHub project is interesting  https://github.com/usrflo/encfs4j
  .

Hope it helps!

Regards!



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Дмитрий Рябов]

Hi!

> As far as I remember to be PCI-DSS compliant it is sufficient to use
> encryption at file system level. But it needs to be double-checked. It
> requires encrypt transmission of cardholder data across open, public
> networks. Could you point me where does it require DB data to be
encrypted?

PCI DSS [1] have 12 requirements, but you are asking about "Requirement 3:
Protect stored cardholder data". It's description doesn't say anything
about way of protection.

But there is point 3.4.1 which says that we can use any way to protect data:
"If disk encryption is used (rather than file- or column-level database
encryption), logical access must be managed separately and independently of
native operating system authentication and access control mechanisms (for
example, by not using local user account  databases or general network
login credentials). Decryption keys must not be associated with user
accounts. Note: This requirement applies in addition to all other PCI DSS
encryption and key-management requirements."

> Joined node should be activated (included to baseline) by activation
> request contains node-password.

Agree, this is safer.

> Any reason to keed data crypted in memory?

Only if we want to protect data from something like spectre and meltdown,
but I think they are trouble of hardware, but not software.

> PCI DSS require this?

PCI DSS requires to "protect stored data". That means we *can* encrypt data
to keep it safe in memory, but we don't need it.



[1]
https://www.pcisecuritystandards.org/document_library?category=pcidss=pci_dss

2018-03-26 19:57 GMT+03:00 Anton Vinogradov :

> Folks,
>
> I've checked presentation.
>
> 1) It's a bad idea to allow automatic node join (sending decripted cache's
> keys on join).
>
> Each node join should be allowed by administrator.
> We have to use two-step verification in that case.
> - admitistrator set keystore password for each node
> - another administrator use this password on node join.
>
> My vision is:
> - each node should keep master key in keystore
> - each keystore should have *own* keystore password
> - on cluster activation we have to specify list of pairs node-password.
> This will provide us guarantee that only allowed nodes are in cluster.
> - TDE should be available only in case baseline used.
> Joined node should be activated (included to baseline) by activation
> request contains node-password.
>
> So, on initial activation or BLT join, each node will gain keystore
> password and encrypted cache's passwords.
> This case will guarantee data safe even on SSL issues.
>
> 2) Any reason to keed data crypted in memory? PCI DSS require this?
> Data shoud be crypted on eviction and rebalancing, I think.
> In that case we can implement TDE and data compression in same way.
>
> Thoughts?
>
>
> 2018-03-12 17:58 GMT+03:00 Denis Magda :
>
> > Nikolay, please try on more time.
> >
> > --
> > Denis
> >
> > On Sun, Mar 11, 2018 at 11:20 PM, Nikolay Izhikov 
> > wrote:
> >
> > > Hello, Denis.
> > >
> > > Did you give me the permissions?
> > > Seems, I still can't create IEP on the IGNITE Wiki.
> > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals
> > >
> > > В Вт, 06/03/2018 в 08:55 +0300, Nikolay Izhikov пишет:
> > > > 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 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Anton Vinogradov]

Folks,

I've checked presentation.

1) It's a bad idea to allow automatic node join (sending decripted cache's
keys on join).

Each node join should be allowed by administrator.
We have to use two-step verification in that case.
- admitistrator set keystore password for each node
- another administrator use this password on node join.

My vision is:
- each node should keep master key in keystore
- each keystore should have *own* keystore password
- on cluster activation we have to specify list of pairs node-password.
This will provide us guarantee that only allowed nodes are in cluster.
- TDE should be available only in case baseline used.
Joined node should be activated (included to baseline) by activation
request contains node-password.

So, on initial activation or BLT join, each node will gain keystore
password and encrypted cache's passwords.
This case will guarantee data safe even on SSL issues.

2) Any reason to keed data crypted in memory? PCI DSS require this?
Data shoud be crypted on eviction and rebalancing, I think.
In that case we can implement TDE and data compression in same way.

Thoughts?


2018-03-12 17:58 GMT+03:00 Denis Magda :

> Nikolay, please try on more time.
>
> --
> Denis
>
> On Sun, Mar 11, 2018 at 11:20 PM, Nikolay Izhikov 
> wrote:
>
> > Hello, Denis.
> >
> > Did you give me the permissions?
> > Seems, I still can't create IEP on the IGNITE Wiki.
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals
> >
> > В Вт, 06/03/2018 в 08:55 +0300, Nikolay Izhikov пишет:
> > > 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
> > > > > > > > > > > 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Denis Magda]

Nikolay, please try on more time.

--
Denis

On Sun, Mar 11, 2018 at 11:20 PM, Nikolay Izhikov 
wrote:

> Hello, Denis.
>
> Did you give me the permissions?
> Seems, I still can't create IEP on the IGNITE Wiki.
>
> https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals
>
> В Вт, 06/03/2018 в 08:55 +0300, Nikolay Izhikov пишет:
> > 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 
> 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.
> > > > > > > > >
> > > 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

Hello, Denis.

Did you give me the permissions?
Seems, I still can't create IEP on the IGNITE Wiki.

https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals

В Вт, 06/03/2018 в 08:55 +0300, Nikolay Izhikov пишет:
> 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  
> > 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  
> > > > 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 
> > > > > > 
> > > > > 
> > > > > 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

signature.asc
Description: This 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Dmitry Pavlov]

Hi Nikolay,

Please note there is cluster-auto activation when it reaches baseline
topology.

As far as I remember to be PCI-DSS compliant it is sufficient to use
encryption at file system level. But it needs to be double-checked. It
requires encrypt transmission of cardholder data across open, public
networks. Could you point me where does it require DB data to be encrypted?

Would this solution have pros in the point of view of security compared
with encrypted FS usage?

Please keep me posted, I would like to join this review.

Sincerely,
Dmitriy Pavlov

вт, 6 мар. 2018 г. в 13:29, Nikolay Izhikov :

> 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 :
> >
> > > 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 :
> > > >
> > > > > 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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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 :
> 
> > 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 :
> > > 
> > > > 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, 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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 :

> 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 :
> >
> > > 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 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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 :
> 
> > 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 
> > 
> > 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 
> > 
> > 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 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Alexey Goncharuk]

My bad, the correct link is
https://issues.apache.org/jira/browse/IGNITE-5829

2018-03-06 13:04 GMT+03:00 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 :
>
>> 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 
>> 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
>> > > 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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 :

> 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 
> 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 
> 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 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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  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  
> > > 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 
> > > >
> > > > 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
> 
> 

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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 
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 
> 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  >
> > >
> > > 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
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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  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 
> > 
> > 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

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Vyacheslav Daradur]

Dima, great job!

Looking forward to the feature completion!

On Fri, Mar 2, 2018 at 9:23 AM, Denis Magda  wrote:
> 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  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 
>> 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
>>



-- 
Best Regards, Vyacheslav D.

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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  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 
> 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
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

> Got it, thanks! In this case this sounds very useful. Do we understand the 
> performance impact?

I don't think we fully understand it.
It's a question of additional research and benchmarking.

So preliminary conclusions, based on common sense and my experiense of usage 
Ignite in production,  are following:

1. CPU is not a bottleneck in most of Ignite use-cases. 
Especially when we use it as a in-memory database.

2. TDE mostly will increase CPU usage: SSL + pages encryption/decryption.

В Пт, 02/03/2018 в 08:33 +0300, Dmitriy Setrakyan пишет:
> On Fri, Mar 2, 2018 at 8:29 AM, Nikolay Izhikov  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.
> > 
> 
> Got it, thanks! In this case this sounds very useful. Do we understand the
> performance impact?

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Dmitriy Setrakyan]

On Fri, Mar 2, 2018 at 8:29 AM, Nikolay Izhikov  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.
>

Got it, thanks! In this case this sounds very useful. Do we understand the
performance impact?

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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  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

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[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  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
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Nikolay Izhikov]

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

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Дмитрий Рябов]

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

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Dmitry Pavlov]

Hi Igniters,

Encryption will ensure security only if keys are stored in a secure
storage. Otherwise having access to Ignite node storage, we can extract
encryption master keys values and read data as plain text (page's clear
content).

Where are we going to store keys (MEK) physically? Whould it be PKCS#11
storage? Where we will store passwords to unlock storage or it will be
responibilty of user?

One more thing is how "node gets MEK from coordinator", if we send
cleartext MEK, such security becomes useless also.

Encryption will have negative influence to performance, so I think we
shouldn't do this thing as first priority. And we need to clearly realize
whole security scheme.

Sincerely,
Dmitriy Pavlov

пн, 5 февр. 2018 г. в 11:23, Дмитрий Рябов :

> Hi, Igniters! I think it would be nice to implement encryption in
> Ignite. Even SQLite and H2 have encryption so why Ignite don't have
> it?
>
> I'd like to propose a design for discussion.
>
> Configurations:
> IgniteConfiguration:
> - KeyStore tdeKeyStore - contain encryption keys.
> - Encryptor encryptor - interface for encryption algorythm with
> methods `encrypt()`, `decrypt()`.
> CacheConfiguration:
> - TransparentDataEncryption tde - configures where or how we will
> encrypt. We can encrypt pages (PDS or PDS) or cached objects
> (PDS, PDS and even heap if we encrypt just after key
> validation and security check). And, of course, TDE can be turned off.
>
> Encryption keys:
> Every node has keystore with Cache Encryption Keys (CEKs), one key for
> one cache, they are stored in encrypted form.
> CEKs are encrypted by Master Encryption Key (MEK), which stored on the
> coordinator or somewhere out of cluster (this way is safer). Also, we
> need backups for MEK on other nodes or somewhere out of the cluster.
>
> Encryption:
> To make any operation with encrypting cache node gets MEK from
> coordinator (or somewhere out of the cluster). Then it decrypts needed
> CEK. With decrypted CEK we encrypt/decrypt data. When transaction
> finished we must destroy received MEK.
>
> TransparentDataEncryption enum:
> NONE - no encryption.
> ALL_OBJECTS - data will be encrypted on tx initiator just after key
> validation and security check, so most of time it would be just a
> byte[] object. It is good, but on the other hand we have additional
> encryption for any node with listeners for data changing.
> PDS_ONLY_OBJECTS - data will be encrypted on primary and backups when
> storing to PDS.
> OFFHEAP_PDS_OBJECTS - data will be encrypted when storing to offheap
> storage and PDS.
> PDS_ONLY_PAGES - data pages will be encrypted on primary and backups
> when storing to PDS.
> OFFHEAP_PDS_PAGES - data pages will be encrypted when storing to
> offheap storage and PDS.
>
> But I'm not sure about objects/pages. Do we really need both of them?
>
>
> 2017-06-26 14:39 GMT+03:00 Sergi Vladykin :
> > No, we don't have plans for it.
> >
> > Sergi
> >
> > 2017-06-26 14:20 GMT+03:00 Vyacheslav Daradur :
> >
> >> Sergi, thanks for the answer.
> >>
> >> >> see TDE is just an option for PCI DSS compliancy but not a
> requirement.
> >> Requirement: "Protect stored cardholder data"
> >> Encryption is required.
> >> TDE - is one of ways to implement it at the database level.
> >>
> >> Sure, an implementation at the application level solve it.
> >>
> >> I meant another.
> >> I thought maybe this feature is in the Ignite roadmap?
> >>
> >>
> >> 2017-06-26 13:53 GMT+03:00 Sergi Vladykin :
> >>
> >> > I think no one is interested in this stuff right now.
> >> >
> >> > Also as far as I see TDE is just an option for PCI DSS compliancy but
> >> not a
> >> > requirement.
> >> >
> >> > Your system should pass PCI DSS if you will do the required
> encryption at
> >> > the application level and will properly manage encryption keys.
> >> >
> >> > Sergi
> >> >
> >> > 2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :
> >> >
> >> > > Guys, any thoughts?
> >> > >
> >> > > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur  >:
> >> > >
> >> > > > Hi Igniters.
> >> > > >
> >> > > > I have some user cases where I need fast storage with TDE support.
> >> > > > It is requered for PCI DSS certification.
> >> > > >
> >> > > > As far as I know AI doesn't support it.
> >> > > >
> >> > > > I looked at other storages.
> >> > > > Many storages support it or are engaged in development this
> feature.
> >> > > >
> >> > > > Cassandra community are working on TDE support.[1]
> >> > > >
> >> > > > Oracle support it.[2] Moreover it supports indexing and querying
> on
> >> > > > encrypted data.
> >> > > >
> >> > > > I think it will be very usefull to support TDE by AI.
> >> > > >
> >> > > > What do you think? Maybe development is already under way?
> >> > > >
> >> > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> >> > > > [2] 

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Дмитрий Рябов]

Hi, Igniters! I think it would be nice to implement encryption in
Ignite. Even SQLite and H2 have encryption so why Ignite don't have
it?

I'd like to propose a design for discussion.

Configurations:
IgniteConfiguration:
- KeyStore tdeKeyStore - contain encryption keys.
- Encryptor encryptor - interface for encryption algorythm with
methods `encrypt()`, `decrypt()`.
CacheConfiguration:
- TransparentDataEncryption tde - configures where or how we will
encrypt. We can encrypt pages (PDS or PDS) or cached objects
(PDS, PDS and even heap if we encrypt just after key
validation and security check). And, of course, TDE can be turned off.

Encryption keys:
Every node has keystore with Cache Encryption Keys (CEKs), one key for
one cache, they are stored in encrypted form.
CEKs are encrypted by Master Encryption Key (MEK), which stored on the
coordinator or somewhere out of cluster (this way is safer). Also, we
need backups for MEK on other nodes or somewhere out of the cluster.

Encryption:
To make any operation with encrypting cache node gets MEK from
coordinator (or somewhere out of the cluster). Then it decrypts needed
CEK. With decrypted CEK we encrypt/decrypt data. When transaction
finished we must destroy received MEK.

TransparentDataEncryption enum:
NONE - no encryption.
ALL_OBJECTS - data will be encrypted on tx initiator just after key
validation and security check, so most of time it would be just a
byte[] object. It is good, but on the other hand we have additional
encryption for any node with listeners for data changing.
PDS_ONLY_OBJECTS - data will be encrypted on primary and backups when
storing to PDS.
OFFHEAP_PDS_OBJECTS - data will be encrypted when storing to offheap
storage and PDS.
PDS_ONLY_PAGES - data pages will be encrypted on primary and backups
when storing to PDS.
OFFHEAP_PDS_PAGES - data pages will be encrypted when storing to
offheap storage and PDS.

But I'm not sure about objects/pages. Do we really need both of them?


2017-06-26 14:39 GMT+03:00 Sergi Vladykin :
> No, we don't have plans for it.
>
> Sergi
>
> 2017-06-26 14:20 GMT+03:00 Vyacheslav Daradur :
>
>> Sergi, thanks for the answer.
>>
>> >> see TDE is just an option for PCI DSS compliancy but not a requirement.
>> Requirement: "Protect stored cardholder data"
>> Encryption is required.
>> TDE - is one of ways to implement it at the database level.
>>
>> Sure, an implementation at the application level solve it.
>>
>> I meant another.
>> I thought maybe this feature is in the Ignite roadmap?
>>
>>
>> 2017-06-26 13:53 GMT+03:00 Sergi Vladykin :
>>
>> > I think no one is interested in this stuff right now.
>> >
>> > Also as far as I see TDE is just an option for PCI DSS compliancy but
>> not a
>> > requirement.
>> >
>> > Your system should pass PCI DSS if you will do the required encryption at
>> > the application level and will properly manage encryption keys.
>> >
>> > Sergi
>> >
>> > 2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :
>> >
>> > > Guys, any thoughts?
>> > >
>> > > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
>> > >
>> > > > Hi Igniters.
>> > > >
>> > > > I have some user cases where I need fast storage with TDE support.
>> > > > It is requered for PCI DSS certification.
>> > > >
>> > > > As far as I know AI doesn't support it.
>> > > >
>> > > > I looked at other storages.
>> > > > Many storages support it or are engaged in development this feature.
>> > > >
>> > > > Cassandra community are working on TDE support.[1]
>> > > >
>> > > > Oracle support it.[2] Moreover it supports indexing and querying on
>> > > > encrypted data.
>> > > >
>> > > > I think it will be very usefull to support TDE by AI.
>> > > >
>> > > > What do you think? Maybe development is already under way?
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
>> > > > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
>> > > > asotrans.htm#ASOAG600
>> > > >
>> > > > --
>> > > > Best Regards, Vyacheslav D.
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Best Regards, Vyacheslav D.
>> > >
>> >
>>
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Sergi Vladykin]

No, we don't have plans for it.

Sergi

2017-06-26 14:20 GMT+03:00 Vyacheslav Daradur :

> Sergi, thanks for the answer.
>
> >> see TDE is just an option for PCI DSS compliancy but not a requirement.
> Requirement: "Protect stored cardholder data"
> Encryption is required.
> TDE - is one of ways to implement it at the database level.
>
> Sure, an implementation at the application level solve it.
>
> I meant another.
> I thought maybe this feature is in the Ignite roadmap?
>
>
> 2017-06-26 13:53 GMT+03:00 Sergi Vladykin :
>
> > I think no one is interested in this stuff right now.
> >
> > Also as far as I see TDE is just an option for PCI DSS compliancy but
> not a
> > requirement.
> >
> > Your system should pass PCI DSS if you will do the required encryption at
> > the application level and will properly manage encryption keys.
> >
> > Sergi
> >
> > 2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :
> >
> > > Guys, any thoughts?
> > >
> > > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
> > >
> > > > Hi Igniters.
> > > >
> > > > I have some user cases where I need fast storage with TDE support.
> > > > It is requered for PCI DSS certification.
> > > >
> > > > As far as I know AI doesn't support it.
> > > >
> > > > I looked at other storages.
> > > > Many storages support it or are engaged in development this feature.
> > > >
> > > > Cassandra community are working on TDE support.[1]
> > > >
> > > > Oracle support it.[2] Moreover it supports indexing and querying on
> > > > encrypted data.
> > > >
> > > > I think it will be very usefull to support TDE by AI.
> > > >
> > > > What do you think? Maybe development is already under way?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> > > > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> > > > asotrans.htm#ASOAG600
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Vyacheslav Daradur]

Sergi, thanks for the answer.

>> see TDE is just an option for PCI DSS compliancy but not a requirement.
Requirement: "Protect stored cardholder data"
Encryption is required.
TDE - is one of ways to implement it at the database level.

Sure, an implementation at the application level solve it.

I meant another.
I thought maybe this feature is in the Ignite roadmap?


2017-06-26 13:53 GMT+03:00 Sergi Vladykin :

> I think no one is interested in this stuff right now.
>
> Also as far as I see TDE is just an option for PCI DSS compliancy but not a
> requirement.
>
> Your system should pass PCI DSS if you will do the required encryption at
> the application level and will properly manage encryption keys.
>
> Sergi
>
> 2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :
>
> > Guys, any thoughts?
> >
> > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
> >
> > > Hi Igniters.
> > >
> > > I have some user cases where I need fast storage with TDE support.
> > > It is requered for PCI DSS certification.
> > >
> > > As far as I know AI doesn't support it.
> > >
> > > I looked at other storages.
> > > Many storages support it or are engaged in development this feature.
> > >
> > > Cassandra community are working on TDE support.[1]
> > >
> > > Oracle support it.[2] Moreover it supports indexing and querying on
> > > encrypted data.
> > >
> > > I think it will be very usefull to support TDE by AI.
> > >
> > > What do you think? Maybe development is already under way?
> > >
> > > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> > > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> > > asotrans.htm#ASOAG600
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>



-- 
Best Regards, Vyacheslav D.

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Sergi Vladykin]

I think no one is interested in this stuff right now.

Also as far as I see TDE is just an option for PCI DSS compliancy but not a
requirement.

Your system should pass PCI DSS if you will do the required encryption at
the application level and will properly manage encryption keys.

Sergi

2017-06-26 11:40 GMT+03:00 Vyacheslav Daradur :

> Guys, any thoughts?
>
> 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :
>
> > Hi Igniters.
> >
> > I have some user cases where I need fast storage with TDE support.
> > It is requered for PCI DSS certification.
> >
> > As far as I know AI doesn't support it.
> >
> > I looked at other storages.
> > Many storages support it or are engaged in development this feature.
> >
> > Cassandra community are working on TDE support.[1]
> >
> > Oracle support it.[2] Moreover it supports indexing and querying on
> > encrypted data.
> >
> > I think it will be very usefull to support TDE by AI.
> >
> > What do you think? Maybe development is already under way?
> >
> > [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> > [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> > asotrans.htm#ASOAG600
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Transparent Data Encryption (TDE) in Apache Ignite

[Vyacheslav Daradur]

Guys, any thoughts?

2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur :

> Hi Igniters.
>
> I have some user cases where I need fast storage with TDE support.
> It is requered for PCI DSS certification.
>
> As far as I know AI doesn't support it.
>
> I looked at other storages.
> Many storages support it or are engaged in development this feature.
>
> Cassandra community are working on TDE support.[1]
>
> Oracle support it.[2] Moreover it supports indexing and querying on
> encrypted data.
>
> I think it will be very usefull to support TDE by AI.
>
> What do you think? Maybe development is already under way?
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-9945
> [2] https://docs.oracle.com/cd/B19306_01/network.102/b14268/
> asotrans.htm#ASOAG600
>
> --
> Best Regards, Vyacheslav D.
>



-- 
Best Regards, Vyacheslav D.

Transparent Data Encryption (TDE) in Apache Ignite

[Vyacheslav Daradur]

Hi Igniters.

I have some user cases where I need fast storage with TDE support.
It is requered for PCI DSS certification.

As far as I know AI doesn't support it.

I looked at other storages.
Many storages support it or are engaged in development this feature.

Cassandra community are working on TDE support.[1]

Oracle support it.[2] Moreover it supports indexing and querying on
encrypted data.

I think it will be very usefull to support TDE by AI.

What do you think? Maybe development is already under way?

[1] https://issues.apache.org/jira/browse/CASSANDRA-9945
[2]
https://docs.oracle.com/cd/B19306_01/network.102/b14268/asotrans.htm#ASOAG600

-- 
Best Regards, Vyacheslav D.