Cross Industry Cross Compliance - Governance, Risk, and Compliance Topic for Oracle Applications - page 338

The following bullets explain the entities and give examples of the data that would
be held in them:
• Credit Card Issuers : For example, VISA, Mastercard
• Credit Card : For example, John Doe's VISA Card
• Bank Account : For example, John Doe's bank account
• Security Segments : This holds the encrypted credit card or bank
account numbers
• Security Subkey : A random number that is used as a key to encrypt
a subset of the bank accounts and credit cards
• Master Key : The master key encrypts the subkeys
In R12 Payments, encryption is optional and the customer can choose to enable it.
As per Payment Card Industry Data Security Standard (PCI DSS), it's required to
encrypt payment instruments such as Credit Card Number and Bank
Account numbers.
Key management
Oracle Payments uses a chained key approach wherein the master key encrypts
the subkeys and the subkeys in turn encrypt the credit card numbers. Subkeys are
system-generated random numbers, which are rotated periodically. If the current
subkey has exceeded its usual count, then a new one is generated automatically
using a random number function. This means that in the event of a single key being
compromised, the exposure is limited to a smaller number of credit card numbers.
In order to rotate the keys, you can go to the setup UI and change the master key.
That only re-encrypts the subkeys but does not touch the payment instrument data.
If you want to re-encrypt the payment instruments then you will have to decrypt
both the encryption keys and the payment instruments and re-encrypt with a new
master key and subkeys.