Key Management and Strong Encryption For PCI DSS Compliance With Powertech Encryption for IBM i

What Is PCI DSS?

The Payment Card Industry (PCI) is a coalition of credit card companies including American Express®, Discover®, MasterCard® and Visa®. PCI has created a Data Security Standard (PCI DSS) which details the security requirements for credit card merchants, service providers and processors. Any organization that stores, processes or transmits cardholder data is required to comply with the PCI DSS requirements.

Fines Associated with Non-Compliance with PCI DSS

If cardholder data is accessed by unauthorized individuals, an organization may be subject to the following liabilities:

• Punitive fines for non-compliance with PCI DSS.
• All fraud losses incurred from the use of the compromised account numbers from the date of the compromise forward.
• Cost of re-issuing cards associated with the compromise.
• Cost of any additional fraud prevention/detection activities required.
• Potentially the revocation of an organization’s merchant account, resulting in their inability to process future credit card transactions.

In response to the increasing cases of stolen and lost cardholder data, PCI DSS has been enhanced with stringent security requirements. PCI DSS is multifaceted with requirements for security management, policies, procedures, network architecture, cryptology, key management and other protective measures. Fortra offers a comprehensive portfolio of cybersecurity solutions aimed to help you comply with PCI DSS requirements.

PCI DSS Encryption and Key Management Requirements

This article focuses on sections of PCI Data Security Standard (PCI DSS), which address cryptology (encryption) and key management requirements for protecting cardholder data. 

PCI DSS 3.3 Mask PAN when Displayed

Requirement

3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). 

Response

Using Powertech Encryption for IBM i’s granular authority controls, you can indicate which users (or groups) have access to the full PAN and which users have access only to the masked PAN. When defining the PAN’s field settings in Powertech Encryption for IBM i, you can specify the formatting of its masked value. For example, a mask can be specified to show only the last four digits (e.g. ************1234) or first six digits (e.g.  485620**********) of the PAN. All other digits can be substituted with a special character such as an asterisk.

PCI DSS 3.4 Render Primary Account Number (PAN) Unreadable

Requirement 

3.4 Render Primary Account Number (PAN), at minimum, unreadable anywhere it is stored (including data on portable digital media, backup media, in logs) by using any of the following approaches:  

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key management processes and procedures.

The MINIMUM account information that must be rendered unreadable is the PAN. 

Response 

Powertech Encryption for IBM i provides strong cryptology (encryption) for protecting data on IBM i.  The popular cryptology standards of Advanced Encryption Standard (AES) and Triple Data Encryption Standard (TDES) are provided in Powertech Encryption for IBM i.    

The AES and TDES standards are widely used throughout the corporate and government sectors for encrypting sensitive data.  The National Institute of Standards and Technology (NIST) also approves the AES and TDES standards for protecting top secret information within the federal government.  

Although PCI DSS does not specifically state the cryptology standards which must be utilized, most organizations are using AES cryptology to protect credit card information. AES is the latest encryption standard (approved by NIST in 2001) and offers strong protection (using keys up to 256 bits in length) with good performance.   

Powertech Encryption for IBM i also includes a comprehensive key management solution for IBM i.  This key management solution allows organizations to perform the following:

• Establish policy settings on how Symmetric Keys can be created and utilized
• Indicate which users can create and manage Symmetric Keys
• Randomly generate strong Symmetric Keys  
• Protect Symmetric Keys using Master Encryption Keys
• Protect the recreation of a Master Encryption Key by requiring passphrases from up to 8 users
• Organize Symmetric Keys into one or more Key Stores
• Restrict access to Key Stores using i5/OS object authority
• Restrict the retrieval of the actual Symmetric Key values
• Provide separation of duties (i.e. the creator of a Symmetric Key can be restricted from using the Key to encrypt and/or decrypt data)
• Control which users can utilize Symmetric Keys to encrypt and decrypt data

PCI DSS 3.5 Cryptographic Keys

Requirement 

3.5  Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse.  

3.5.1  Restrict access to cryptographic keys to the fewest number of custodians necessary

3.5.2  Store cryptographic keys securely in the fewest possible locations and forms  

Response

Powertech Encryption for IBM i includes a comprehensive key management solution for IBM i. This solution allows an organization to indicate the Key Officers (Custodians) which are authorized to create and manage Master Encryption Keys (MEKs) and Data Encryption Keys (DEKs).  
A Master Encryption Key (MEK) is a special Symmetric Key used to protect (encrypt) the Data Encryption Keys (DEKs).  

An organization can create up to eight MEKs per environment on the IBM i. A MEK is generated by the product using passphrases entered by designated users. Depending on the organization’s key policy, up to eight different passphrases can be required to be entered (by different users) in order to generate a MEK. 

The encrypted Data Encryption Keys (DEKs) are contained within Key Stores. Each Key Store is created as a *VLDL (Validation List) object on the IBM i.   

An organization can control access to the Key Store *VLDL object using i5/OS object security. Object *Change authorities can be granted only to those users that are allowed to manage the keys within the Key Store. Object *Use authority can be granted only to those users that are allowed to use the keys (for encrypting/decrypting data) within the Key Store.

PCI DSS 3.6 Document All Key Management Processes

3.6  Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:  

PCI DSS 3.6.1 Generation of Strong Cryptographic Keys

Requirement

3.6.1 Generation of strong cryptographic keys 

Response 

Powertech Encryption for IBM i allows the creation of strong symmetric keys using the AES and TDES encryption standards.  For AES, the key length can be specified up to 256 bits to offer the highest protection.    

By default, keys are randomly generated by Powertech Encryption for IBM i to offer the best security. Depending on the Key Policy settings specified in Powertech Encryption for IBM i, the actual value of the Key will never be known to the user or applications. The Keys will simply be referred to by a user-defined label.    

Depending on the Key Policy, a Key can additionally be generated based on a user-entered passphrase, salt and iteration count using the PBKDF2 standard (pseudorandom key function as detailed in RFC2898).

PCI DSS 3.6.2 Secure Cryptographic Key Distribution

Requirement 

3.6.2  Secure cryptographic key distribution  

Response 

Powertech Encryption for IBM i stores Data Encryption Keys (DEKs) within Key Stores, which are created as *VLDL (Validation List) objects on the IBM i. The DEKs within the Key Stores are encrypted with Master Encryption Keys (MEKs).    

The Key Store *VLDL objects can be distributed to other systems over non-secure connections. The targeted systems will only be able to utilize the Data Encryption Keys (DEKs) within the Key Stores if they implement the same Master Encryption Keys (MEKs). MEKs can only be regenerated by entering the exact passphrase values as were entered on the original system. 

PCI DSS 3.6.3 Secure Cryptographic Key Storage

Requirement 

3.6.3  Secure cryptographic key storage  

Response 

Powertech Encryption for IBM i stores Data Encryption Keys (DEKs) within Key Stores, which are created as *VLDL (Validation List) objects on the IBM i. The DEKs within the Key Stores are encrypted with Master Encryption Keys (MEKs).    

The Key Store *VLDL objects can be saved to backup media and other systems. The restoring system will only be able to utilize the Data Encryption Keys (DEKs) within the Key Stores if that system implements the same Master Encryption Keys (MEKs). MEKs can only be regenerated by entering the exact passphrase values as were entered on the original system. 

>> Download the guide "IBM i Encryption: How to Protect Your Database" and learn about your options for encrypting IBM i data

PCI DSS 3.6.4 Periodic Cryptographic Key Changes

Requirement 

3.6.4  Periodic cryptographic key changes:

• As deemed necessary and recommended by the associated application (for example, rekeying); preferably automatically  
• At least annually  

Response 

Powertech Encryption for IBM i allows periodic changing of Keys (rotating Keys) as required by the organization. Only authorized Key Officers (custodians) are allowed to rotate Keys in Powertech Encryption for IBM i. Keys can be rotated at any time without having to change customer’s applications. Existing encrypted data can be translated (re-encrypted) to any new Keys by using commands provided, without any programming requirements.  

Powertech Encryption for IBM i can store the Key identifier on a per-record basis, which allows a mixture of Keys for a single PAN column (field).

PCI DSS 3.6.5 Retirement or Replacement of Old or Suspected Compromised Cryptographic Keys

Requirement

3.6.5  Retirement or replacement of old or suspected compromised cryptographic keys  

Response

Powertech Encryption for IBM i allows authorized Key Officers (custodians) to remove Keys when they are no longer needed. The Key Officer must have *change authority to the Key Store *VLDL object in order to remove a Key from it.  

As an alternative option, an old Key can be restricted from encrypting new data while still allowing the Key’s use for decrypting existing data. This option allows for the destruction of the Key only after existing data has been re-encrypted under a new Key.

PCI DSS 3.6.6 Split Knowledge and Establishment of Dual Control of Cryptographic Keys   

Requirement 

3.6.6  Split knowledge and establishment of dual control of cryptographic keys   

Response (Split Knowledge) 

In Powertech Encryption for IBM i, the policy can be configured to restrict Key Owners (the creators of the Keys) from using those Keys to encrypt and/or decrypt data. This creates a separation of duties in which Key Owners will only be able to create and manage Keys, whereas a different set of authorized users will be able to utilize those Keys.  
Response (Dual Control) 

Master Encryption Keys (MEKs) are used to protect (encrypt) Data Encryption Keys in Powertech Encryption for IBM i.  A MEK can be generated (reconstructed) only if all passphrase parts are entered exactly as they were entered on the original system.  Each MEK can have up to 8 passphrase parts.  To provide dual control, the Powertech Encryption for IBM i policy can be configured to require that each passphrase part is entered by a different Key Officer (custodian). 

PCI DSS 3.6.7 Prevention of Unauthorized Substitution of Cryptographic Keys

Requirement 

3.6.7  Prevention of unauthorized substitution of cryptographic keys  

Response 

Within Powertech Encryption for IBM i, only an authorized Key Officer (custodian) is allowed to change Keys for an entry in the Field Encryption Registry. Data can only be decrypted if the proper Key Label name is specified and if the user is authorized to the Key Store in which the Key resides. 

PCI DSS 10.0 Track and Monitor All Access to Network Resources and Cardholder Data

Requirement 

10.0 Track and monitor all access to network resources and cardholder data  

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.  

Response

Powertech Encryption for IBM i Includes Comprehensive Auditing

For meeting the most stringent security requirements, audit log entries are automatically generated for the following events:

• When any Key Policy settings are changed
• When Key Officers are added, changed or removed  
• When Master Encryption Keys (MEKs) are loaded or set  
• When Key Stores are created or translated  
• When Data Encryption Keys (DEKs) are created, changed, exported or deleted  
• When Field Encryption Registry entries are added, changed, removed, activated or deactivated
• When any functions are denied due to improper authority  
• When data is encrypted or decrypted with a Key that requires logging of those events

The audit log entries are sent to an IBM journal file. Entries in the journal file cannot be altered. Each entry in the journal is assigned an “Entry Type”, which indicates the event which generated the audit log entry. For each entry, Powertech Encryption for IBM i will store an audit description, user, date, time, job name, job number and any application-supplied comments.

A command is provided to allow authorized users to print the Powertech Encryption for IBM i audit log entries. This command provides selection criteria of date and time ranges, audit types and user ids. For each audit entry printed, it will include the audit date, time, user, job name, job number, audit type and message. Security Alerts can also be configured to send notifications when any Key Management activities are performed. These notifications can be sent to email addresses, message queues and journals.  Alerts can also be sent when authority errors occur in Powertech Encryption for IBM i, such as when an unauthorized user attempts to access a Key Store.

Summary

Data encryption has traditionally been very difficult and time-consuming to implement. In the past, major application changes were required to expand database field sizes and implement complicated API calls to encrypt/decrypt data. In some cases, these complexities were preventing organizations from meeting stringent PCI DSS Key Management requirements by not properly securing and controlling their encryption Keys. 

Powertech Encryption for IBM i is a comprehensive solution for protecting sensitive data through strong encryption technology, integrated key management and audit trails.  

The design of Powertech Encryption for IBM i allows organizations to implement encryption quickly using intuitive screens and commands, while providing a high degree of protection. Every effort has been made in Powertech Encryption for IBM i to minimize the application changes needed, allowing an organization to implement encryption successfully for less time and money.