Motivation

Cache encryption key rotation required in case of it compromising or at the end of crypto period (key validity period). in addition, such feature is required to provide support for encrypt and descrypt existing caches in the future.

...

In place re-encryption design.

The overall process consists of the following steps

• Rotate cache group key - add new encryption key on each node and set it for writing.
• Schedule background re-encryption for archived data and cleanup the old key when it completes.

Process description

To support multiple keys for reading encrypted data it is required to store key identifier on each encrypted page and on each encrypted WAL record.

1. Check that all baseline nodes online.
2. Start distributed process GROUP_KEY_CHANGE_PREPARE, each node
   1. verifies that reencryption not in progress
   2. ensures that new key identifier does not exists
   3. adds new key
3. After successful completion of PREPARE, start distributed process GROUP_KEY_CHANGE_FINISH, each node
   1. sets new key for writing
   2. adds the mapping "WAL segment -> *old* key identifier" (to safely cleanup this key in the future)
   3. stores current pages count as total pages for background re-encryption (?)
   4. starts background re-encryption

Background re-encryption

Scan all pages from specified range (metapageid + [offset -> total])

1. acquire/lock page
2. log into wal (PageSnapshot?)
3. unlock page (dirty=true)

Re-encryption progress is stored into metapage (int offset, int total), updates during checkpoint.

Cleanup old key

Old group key will be removed when

1. re-encryption is complete for cache group
2. last WAL segment in which the key was used was removed

Fault tolerance

// TBD

Risks and assumptions

// TBD

Copy with re-encryption design.

...