ID | IEP-18 | |||||
Author | Dmitrii Ryabov | |||||
Sponsor | Nikolay Izhikov | |||||
Created | 26 March 2018 | |||||
Status |
|
|
|
Table of Contents |
---|
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: . EncryptionSpi instnce should be configured to setup
EncryptionSpi – Spi that provide possibilities:
Obtain master key hash.
Create new cache key.
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
CacheConfiguration:
Encrypted CEKs are stored in the special system cacheMeta Store.
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 decryptedaccessible by an administrator during node cluster activationstart.
CEKs are decrypted immediately after MEK decryption. on MetaStore initialization(node start)
Every encrypted cache must have separateits own 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].
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?
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
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:
The encryption algorithm implementation is provided by EncryptionSpi implementation.
For default implementation(KeystoreEncryptionSpi) it's AES.
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
...
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|