Versions Compared

Old Version 4

changes.mady.by.user Anton Vinogradov

Saved on

compared with

New Version Current

changes.mady.by.user Pavel Pereslegin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


IDIEP-18
AuthorDmitrii Ryabov
Sponsor

Nikolay Izhikov

Anton Vinogradov

Created26 March 2018
Status

Status
colour

Grey

Green
title

DRAFT

ACTIVE


Table of Contents

Motivation

...

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

Configuration 

IgniteConfiguration: . EncryptionSpi instnce should be configured to setup 

EncryptionSpi – Spi that provide possibilities:

  1. Obtain master key hash. 

  2. Create new cache key.

  3. Encrypt/decrypt blocks of data

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

    5. Encryptor – interface for cypher   algorithm. Basic implementations should comply with "Strong Cryptography" in PCI DSS Glossary [2].

CacheConfiguration:

  1. isEncrypted – shows that flag. If true then cache data must be encrypted or not. 

Storing and using MEK and CEKs 

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]). 

  1. MEK and CEKs are stored in encrypted form. 

  2. MEK must be decryptedaccessible by an administrator during node cluster activationstart. 

  3. CEKs are decrypted immediately after MEK decryption.  on MetaStore initialization(node start) 

  4. Every encrypted cache must have separateits own CEK. 

  5. 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].

Image Removed

Preparation

  1. First of all, an administrator should configure SSL to enable secure data transferring.
  2. An administrator must ensure MEK storage available for all server nodes.
  3. Administrator sends the password via SSL for MEK decryption to any server node.
  4. Node received password decrypts MEK.
  5. Every server node (including node from 4 just after decrypting MEK) received MEK decrypts CEKs on itself and send MEK over the ring.

After this steps, TDE is ready to use and the cluster can be activated.

Encryption

When a user makes an operation on secured cache everything goes as usual except 2 moments:

  1. Ignite send data between nodes by SSL.Ignite encrypt pages when saving to Persistence Data Storage.

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.

Image Removed

Rebalancing

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.

MEK regeneration

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.

FAQ 

  • Q: Will SQL queries be supported against the encrypted data? 
A: Yes.
  • Q: How big would be a performance impact in this case? 
  • A: We need additional research and benchmarking. TDE mostly will increase CPU usage: SSL + pages encryption/decryption. But CPU is not a bottleneck in most of Ignite use-cases, especially when it used as an in-memory database. 

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

    1. Cluster must have secure communication between nodes, e.g. SSL.
    2. Cluster must be activated only after decrypting MEK by an administrator.

    We should remember that:

    • Rebalance will suffer performance in the case when we should transfer some data, which stored only in the PDS. We need to decrypt page to receive data needed to be transferred and encrypt new data into another page.
    • New secure caches can be created only by an administrator.
    • Data size in a single page is restricted by the block size of an encryption algorithm, if block cipher used.
    1. Ignite encrypt each WAL record that belongs to encrypted cache.

    The encryption algorithm implementation is provided by  EncryptionSpi implementation. 

    For default implementation(KeystoreEncryptionSpi) it's AES.

     http://apache-ignite-developers.2346864.n4.nabble.com/Transparent-Data-Encryption-TDE-in-Apache-Ignite-td18957.html 

    ...

    1. PKCS#11 - http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html

    2. PCI DSS Glossary - https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf

    3. PKCS#12 - https://tools.ietf.org/html/rfc7292

    4. PCI DSS - https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf

    5. Java Cryptography Architecture - https://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html  

    Tickets

    Jira
    serverASF JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryproject = Ignite AND labels IN (IEP-18) and key != 'IGNITE-8260' ORDER BY status
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    // Links or report with relevant JIRA tickets.