Hello, Igniters. As you may know, we successfully implement TDE. Phase-1 feature. [1] This improvement allows users to use an encrypted cache.
To make TDE production ready I propose to extend it with two things:
* Master key rotation.
* Cache key rotation.
Such features required by many security standards such as PCI DSS [2] and GDPR
[3]
I think it would be easier to discuss, implement and review both features
separately.
So my plan is the following:
* TDE. Phase-2 - Master key rotation [4]
* TDE. Phase-3 - Cache key rotation. [5]
I prepared designs for both parts.
I want to specifically discuss Phase-2 design.
Phase-3 design state is [EARLY DRAFT].
I propose to use Phase-3 design as a reference to make sure we have a
consistent view of all aspects of TDE
and can be implemented without significant changes in earlier parts.
Below, my design.
Following changes will be made in confluence [4].
Please, share your feedback.
*TDE. PHASE-2. MASTER KEY ROTATION*
Key rotation required in case of it compromising or at the end of
crypto period(key validity period).
Goal:
To implement the ability to rotate master encryption key.
New processes:
1. Master key rotation.
2. Removal of a master key.
New administrator commands:
1. Master keys view: node -> master key hash
2. Cache group keys view: node -> group name -> encryption key hash
MASTER KEY ROTATION:
Process start:
Administrator initiates key rotation via some kind of user
interface(CLI, Visor, Web Console, JMX, etc).
Process description:
Message is sent by discovery.
A Message should contain:
* Master cache key encrypted with the current master
key.
When server node processed message following actions are
executed:
* Blocks creation of encrypted cache key.
* Encrypt cache group keys with new master key.
* Unblock creation of encrypted cache key.
New joining node should also change the current master key with
the new one.
Process completion:
The administrator initiates process completion via the
interface by using “master key removal” command.
Design assumes an administrator will check that all nodes
successfully change master key and all required nodes are alive.
MASTER KEY REMOVAL:
Process start:
Administrator initiates process via some kind of user
interface(CLI, Visor, WebConsole, JMX, etc),
Process description:
Message is sent by discovery.
Message should contain:
* New master key hash.
When a server node processed message following actions are
executed:
Received master key hash compared with known master key hash.
Previous master key removed using configured EncryptionSPI.
NEW COMMANDS:
Master key hashes.
Input: nothing
Output: List of Tuples3
* Node ID
* Current key hash
* Previous key hash or null.
Cache key hashes.
Input: cache id.
Output: List of Tuples3
* Node ID
* Current key hash
* Previous key hash or null.
[1] https://issues.apache.org/jira/browse/IGNITE-8260
[2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
[3] https://gdpr-info.eu/
[4] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381
[5] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384
signature.asc
Description: This is a digitally signed message part
