Managing Encryption Keys

TimesTen creates two types of keys for encryption at rest: a master key and a data encryption key (DEK) specific to each checkpoint or transaction log file.

During the creation of an encrypted database, TimesTen creates a randomly-generated master key and stores it in a wallet. Every time TimesTen creates a new checkpoint or transaction log file for the database, it also creates a randomly-generated DEK. The DEK is exclusively for the encryption and decryption of that specific checkpoint or transaction log file. TimesTen uses the master key to encrypt and decrypt DEKs.

Checkpoint Files

During a checkpoint operation, TimesTen encrypts all blocks of a checkpoint file using its corresponding DEK. Then, TimesTen encrypts the DEK with the master key and stores the encrypted DEK and the index to identify the master key in an unencrypted section of the checkpoint file.

A checkpoint file is basically an image of the data stored in memory. To ensure checkpoint files remain as such, for encrypted databases, a new encryption data file (edata file) is created for each checkpoint file. The edata file contains the encryption metadata for each block in the checkpoint file (TimesTen uses 12 byte initialization vectors to encrypt each block in a checkpoint file).

The edata files are named dsname.edata0 or dsname.edata1, where dsname is the database path name and file name prefix specified in the DataStore attribute, and the 0 or 1 suffix corresponds to the checkpoint file the edata file complements.

Edata files have the same permissions as checkpoint files—read and write privileges for owner and group (660)—and are approximately 50 bytes per block in size.

Transaction Log Files

For encrypted databases, TimesTen encrypts all blocks of a transaction log file using its corresponding DEK. Then, TimesTen encrypts the DEK with the master key and stores the encrypted DEK and the index to identify the master key in an unencrypted section of the log file.

TimesTen uses 12 byte initialization vectors to encrypt each block in a log file. TimesTen stores the integrity data for each block at the end of the block.

Re-Keying an Encrypted Database

Re-keying an encrypted database consists of rotating the master key and DEKs used to encrypt the checkpoint and transaction log files. The database files are then re-encrypted using the new keys. Master keys are associated with an index number—the index consists of a monotonically increasing sequence of numbers. The wallet generally only stores one master key. It may store up to two master keys during an ongoing rekey operation: the new and previous master keys. Therefore, if we assume—prior to a re-keying request—that the last master key is associated with an index value of 3 (meaning that the encryption keys have already been rotated twice), then during a new rekey operation, TimesTen does the following:

  1. Creates a new randomly-generated master key and assigns the next number in the sequence, 4 in this case, as its index. Then, it stores the new master key in the wallet.

  2. Creates two new checkpoint files and their corresponding randomly-generated DEKs.

  3. Encrypts the checkpoint files using their corresponding DEKs.

  4. Encrypts the DEKs using the new master key and stores the encrypted DEKs and master key index, 4, in the header of the checkpoint files.

  5. Searches for any transaction log files using the previous master key, which in this case is the master key with index 3, and creates a new randomly-generated DEK for each of these log files.

  6. Re-encrytps the log files using their corresponding new DEKs.

  7. Encrypts the DEKs using the new master key and stores the encrypted DEKs and master key index, 4, in the header of the corresponding log files.

  8. Removes the previous master key from the wallet. In this case, this leaves the wallet with only the master key with index 4, since the master key with index 3 is removed.

You can also use a rekey operation to change the encryption details, such as changing the encryption algorithm or encrypting a non-encrypted database.

Tip:

  • It is highly recommended that you implement a time-based key rotation strategy as best practice based on your own risk assessment, contractual requirements, and security policies of your organization.

    Use the ttRekeyStatus built-in utility to determine when the database was last rekeyed. 

    Command> CALL ttRekeyStatus();
< Rekey done, 2025-09-04 18:51:13.072758, 2025-09-04 18:51:14.786877, 3 >
1 row found.
  • Since there is a performance cost to a rekey operation, it is recommended that any rekey operation is performed during low-demand periods and that a checkpoint is performed first.

Note:

You cannot rekey an encrypted database while any of these operations is in progress:

  • Rekey operation

  • Database backup

  • Database duplicate (for replication)

You can perform a rekey operation using the -rekey option of the ttAdmin utility. 

ttAdmin -rekey dsname

If you want to change the encryption algorithm or want to encrypt an unencrypted database, you must include the -encrAlg option and specify encryption algorithm TimesTen should use. 

ttAdmin -rekey -encrAlg AES256 dsname

Note:

A rekey operation can only be performed by the instance administrator and the database must be loaded into memory.

You can use the ttRekeyStatus built-in procedure to determine the status of the rekey operation. 

Command> CALL ttRekeyStatus();
< Rekey done, 2025-09-11 22:19:39.044642, 2025-09-11 22:19:39.997542, 4 >
1 row found.

For more information on the -rekey option of the ttAdmin utility or the ttRekeyStatus built-in procedure, see Encryption at Rest or ttRekeyStatus, respectively, in Oracle TimesTen In-Memory Database Reference.