Oracle E-Business Suite PCI DSS Credit Card Encryption
PCI requirement 3.4 mandates that the Primary Account Number (PAN) is unreadable anywhere it is stored using one-way hashes or strong encryption. The Oracle E-Business Suite Release 12 meets this requirement first by centralizing cardholder data (into the Secure Payments Repository) and then applying strong encryption.
Oracle Payments offers two modes of encryption, full or partial, as well as immediate or scheduled. Which encryption options are selected should be the result of discussions with legal counsel, compliance and risk management.
Partial encryption refers only to the encryption of the PAN. Full encryption refers to the encryption of the Primary Account Number (PAN) along with the cardholder name and card expiration date. The cardholder name and expiration date are also referred to in the documentation as supplemental data.
Immediate encryption encrypts cardholder data as it is being written to the database. Scheduled encryption leaves cardholder data unencrypted until a concurrent request is run manually or scheduled at a later point in time to encrypt cardholder data. Integrigy Corporation strongly recommends only using immediate encryption.
Specifically, to meet requirement 3.4, Oracle Payments uses a chained encryption key approach and a Triple Data Encryption Algorithm (TDEA, Triple DEA, TDES or 3DES) symmetric-key block cipher. A master encryption system key is used to encrypt sub-keys. This master key is stored in the Oracle Payment Wallet (cwallet.sso).
The sub-keys are 156-bit-length system generated and are encrypted using 3DES and the master key as the key. The encrypted sub-keys are then stored in the table IBY.IBY_SYS_SECURITY_SUBKEYS.
Cardholder data collected by the Secure Payments Repository is stored in the table IBY.IBY_CREDITCARD. When encryption is enabled, the records in IBY.IBY_CREDITCARD are flagged as being encrypted and the specific PCI cardholder data is moved to the table IBY.IBY_SECURITY_SEGMENTS.
Cardholder data in IBY.IBY_SECURITY_SEGMENTS is encrypted using the 156-bit sub-keys and a 3DES algorithm. The standard Oracle package DBMS_OBFUSCATION_TOOLKIT performs the encryption. The 156-bit key exceeds the PCI DSS required minimum of double-length keys for 3DES. It is also interesting to note that the Oracle E-Business Suite is using the depreciated DBMS_OBFUSCATION_TOOLKIT package rather than the newer DBMS_CRTYPO package.
Remember to Rotate Wallet Keys Annually
PCI requirement 3.6 requires that encryption keys be rotated on a regular basis – at a minimum of annually. This means that the Oracle Payment Wallet keys needs to be rotated. Changing the password for the wallet does not change the key. The process of rotating the wallet key for Oracle Payments requires that an entire new wallet be created, and the old wallet destroyed (both the *.p12 and the *.sso files) through a secure wipe – not just deleted from the file system.
Further Information
For further information on PCI compliance, Corporate Cards and the E-Business Suite please refer to our whitepaper in the link below.
If you have questions, please contact us at info@integrigy.com
- Michael Miller, CISSP-ISSMP
