...
After this steps, TDE is ready to use and the cluster can be activated.
When a user makes an operation on secured cache everything goes as usual except 2 moments:
The encryption algorithm is configured in IgniteConfiguration. For a basic implementation, we should support algorithms from Java Cryptography Architecture [5] and acceptable by "Strong Cryptography" in PCI DSS Glossary - AES and 3DES.
When a new server node enters topology, old nodes (previous node in the ring) must send decrypted CEKs to the new node via SSL, so it will be able to work with secured data. And only after that step new node will be ready and topology can be changed.
For data rebalancing, we need to decrypt pages to obtain data for partition exchange, which is made via SSL, and encrypt data again after delivering to a new node.
We should provide a way to replace MEK with a new value. MEK can be stolen or lost.
This can be done only when cluster is up and running.
If MEK is lost when a cluster is stopped - encrypted data will be lost.
Q: How do you make sure that encrypted page fits the page size?
A: We will use block cypher.
Q: 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 the success of known-plain-text attacks. How are you planning to fix it?
A:
Q: 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: https://issues.apache.org/jira/browse/IGNITE-5829
A: We will use block cypher.
Q: Pros in the point of view of security compared with encrypted FS usage?
A: Data encryption/decryption is invisible to the user.
Risks and Assumptions
...