To better understand how SAKA rotates keys, it is important to understand how they are used and how the key duration policy of the symmetric keys affect the process. Additionally, it is important to understand how applications are affected when symmetric keys are rotated.

All unencrypted data (plaintext) are encrypted using DEKs. The default key duration policy for DEKs is Monthly, which implies that a new key is used every month to encrypt new transactions. However, applications never receive this encrypted data (ciphertext) or the DEK. As a result, they have no control over these objects directly (and are thus not within scope for audits with respect to encryption and key management controls).

Plaintext sent to SAKA also have their HMACs calculated before encryption—also after every decryption to verify their integrity. The HMACs of plaintext are calculated with DHKs, which have an Annual key duration. The HMACs are stored in the internal database along with the ciphertext and the key identifiers of the DEK and DHK.

If a site chooses not to use Tokenization—the substitution of a data-value resembling the plaintext characteristically but which is completely useless outside the scope of SAKA—the HMAC is returned to the calling application as a “token” to store and use within their applications. However, if the site chooses to use tokenization, instead of returning the HMAC, SAKA generates a unique Pseudo-Number (PSN) based on rules configured in the encryption domain, and returns the PSN as the token. This token becomes the unique identifier that authorized applications must use to retrieve the original plaintext.

A consideration for applications is whether to use the HMAC or PSN as the token. This consideration is important as it has implications on data stored by the application and the business processes it must implement.