ID | IEP-18 |
Author | Dmitrii Ryabov |
Sponsor | Nikolay Izhikov |
Created | 26 March 2018 |
Status | DRAFT |
Transparent data encryption automatically and silently protects data in rest (persistence). It will allow users to minimize the effort for data protection. TDE should comply with standards like PKCS and PCI DSS, so users will spend less for data protection.
CEK – Cache Encryption Key. Encrypts data, encrypted by MEK.
MEK – Master Encryption Key. Encrypts CEK. MEK is stored in some key storage.
TDE – Transparent Data Encryption.
IgniteConfiguration:
TdeKeyStore – interface for key store. Contains encrypted MEK. When administrator starting the cluster, he should open key store bypassing password before activating cluster. An interface should comply with the PKCS#11 [1] to be used for user's key store implementations. Our basic implementation will be just a proxy with java.util.KeyStore
Encryptor – interface for cypher algorithm. Basic implementations should comply with "Strong Cryptography" in PCI DSS Glossary [2].
CacheConfiguration:
Encrypted CEKs are stored in the special system cache.
Encrypted MEK is stored in a key storage, which has to be accessible from every server node (java.security.KeyStore is good for basic implementation because it complies with PKCS#11 and PKCS#12 [3]).
MEK and CEKs are stored in encrypted form.
MEK must be decrypted by an administrator during cluster activation.
CEKs are decrypted immediately after MEK decryption.
Every encrypted cache must have separate CEK.
Opened keys must be destroyed when they aren't needed anymore (MEK – when CEKs are encrypted, CEKs - when a node is going down). This requirement came from PCI DSS 3.6.5 [4].
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.
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
To enable TDE we should have some guarantees:
We should remember that:
PKCS#11 - http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html
PCI DSS Glossary - https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf
PKCS#12 - https://tools.ietf.org/html/rfc7292
PCI DSS - https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf
Java Cryptography Architecture - https://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html
// Links or report with relevant JIRA tickets.