Versions Compared

Old Version 2

changes.mady.by.user Pavel Pereslegin

Saved on

compared with

New Version 3

changes.mady.by.user Pavel Pereslegin

Saved on

Key

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

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. 

...

  1. Cache key rotation.

  2. Removal of the cache key.  

New administrator commands: 

...

Cache group keys rotation: 

Process start: 

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

Process description: 

  1. New A newkey generated using configured EncryptionSPI. 

  2. Message A messagewith 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. New The newkey  is saved in to the metastore (WAL record about this event is written to the disk added). 

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

  7. Further page are isencrypted with the new key. 

  8. Pages reencryption The pagesre-encryptionprocess is initiated. 

Pages

 reencryption 

re-encryptionprocess description: 

Process uses it's own ThreadThis procedure usesitsownthread pool. 

Thread pool configured in IgniteConfiguration. 

  1. For each partition file. File readed

  2.  page by The file is read page by page. 

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

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

    2. Page is readedread (from file) into memory. Note, this process doesn“tdoesn't use regular Offheap off-heapIgnite 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 reencrypted the re-encryptedpages set(Bloom filter as it has constant size). 

    7. Page is unblockedunlocked. 

  4. Progress of reencryption re-encryptionis saved to WAL for failover after each X pages processed. X is configured in IgniteConfiguration. End of each partition process is saved to WAL. 

  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. Doesn“t It doesn'tdisplace hot pages from RAM during file scan process. 

Page decryption during

 reencryption 

the re-encryptionprocess: 

During reencryption the re-encryptionprocess page may be encrypted with the previous key OR with  the new key one. 

To decrypt page we have to do the following steps: 

  1. Block page from reencryptionre-encryption. 

  2. Check in reencrypted re-encryptedpages set is this page processed(see «Pages reencryption re-encryptionprocess 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 reencryption the re-encryptionprocess we should resume reencryption the re-encryptionprocess on node startstartup. 

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.