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&offheap) or cached objects
(PDS, PDS&offheap 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 <sergi.vlady...@gmail.com>:
> No, we don't have plans for it.
>
> Sergi
>
> 2017-06-26 14:20 GMT+03:00 Vyacheslav Daradur <daradu...@gmail.com>:
>
>> 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 <sergi.vlady...@gmail.com>:
>>
>> > 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 <daradu...@gmail.com>:
>> >
>> > > Guys, any thoughts?
>> > >
>> > > 2017-06-20 11:02 GMT+03:00 Vyacheslav Daradur <daradu...@gmail.com>:
>> > >
>> > > > 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.
>>

Reply via email to