You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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 cache encryption key. 

New processes: 

  1. Cache key rotation.

  2. Removal of the cache key.  

New administrator commands: 

  1. Current state of cache key rotation: node -> group name -> status -> encryption key hash.

Cache group keys rotation: 

Process start: 

Administrator initiates the process via some kind of user interface (CLI, Visor, WebConsole, JMX, etc). 

Process description: 

  1. A new key generated using configured EncryptionSPI. 

  2. A message with the new key (encrypted with the master key) is sent by discovery. 

  3. On message receive following actions are executed: 

  4. Process state: IN PROGRESS. 

  5. The new key is saved to the metastore (WAL record about this event is added). 

  6. Further WAL records are encrypted with the new key. 

  7. Further page is encrypted with the new key. 

  8. The pages re-encryption process is initiated. 


Pages re-encryption process description: 

This procedure uses its own thread pool. 

Thread pool configured in IgniteConfiguration. 

  1. For each partition file. 

  2. The file is read page by page (blocked by IGNITE-11998?).

  3. For each page (following steps executed by many threads using a producer-consumer pattern): 

    1. Page is locked from write operation into regular Ignite Durable Memory. 

    2. Page is read (from file) into memory. Note, this process doesn't use regular off-heap Ignite pages. 

    3. Page decrypted with the previous key. 

    4. Page encrypted with the new key. 

    5. Page is written into a file. 

    6. Page id is added to the re-encrypted pages set(Bloom filter as it has constant size). 

    7. Page is unlocked. 

  4. Progress of re-encryption is saved to WAL for failover after each X pages processed. X is configured in IgniteConfiguration. 

  5. Сompletion of partition re-encryption is accompanied by adding a WAL entry

  6. Process state: FINISHED. 

Motivation:  

  1. Memory footprint [Thread count]*[page size]

  2. Minor affect on regular data operations. 

  3. It doesn't displace hot pages from RAM during the file scan process. 


Page decryption during the re-encryption process: 

During the re-encryption process page may be encrypted with the previous key OR with the new one.

To decrypt page we have to do the following steps: 

  1. Block page from re-encryption. 

  2. Check in re-encrypted pages set is this page processed(see «Pages re-encryption process description» #3.6) 

  3. If page not reencrypted yet we use old key for decryption. 

  4. If page reported as reencrypted(Bloom filter may be false positive) we: 

    1. Try to decrypt page with new key. 

    2. If fail we should try to use old key.  

  5. Unblock page from reencryption. 

Process failover: 

If the node fails in the middle of the re-encryption process we should resume the re-encryption process on node startup. 

We should do the following steps for started but not finished partition file: 

  1. Find the last progress record in WAL. 

  2. Scan partition from the beginning to last progress record point and just add eache page to reencrypted pages set. 

  3. After it we have X pages that MAY BE reencrypted(and may be not). We should find fir not reencrypted page: 

    1. Trying to decrypt page with new key. 

    2. If fails then page is found.  
      We should continue reencryption process starting from it. 

Process completion: 

Administrator initiates process completion via interface by using “cache key removal” command. 
Design assume, administrator will check that all nodes successfully change cache key and reencrypt all pages and all required nodes are alive.

Cache group keys 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 cache key hash. 


When server node processed message following actions are executed: 


  1. Received cache key hash compared with known cache key hash. 

  2. Previous cache key removed from MetaStore. 

Monitoring command:


Reencryption process state. 
  • Input: cache id. 
  • Output: 
    • List of Tuples6 
      • Node ID 
      • Reencryption process state. 
      • Count of partition to process. 
      • Current partition index. 
      • Current partition id. 
      • Count of processed page in current partition. 


  • No labels

Apache Ignite