Understanding Encryption Requirements of PCIDSS

By balaji

June 13, 2009

At information security conferences, there are heated discussions on the difficulties faced by the merchants/service providers in complying with the encryption requirement of PCIDSS. Inability to comply with the requirements often lead the vendor to seek refuge under the section called "Compensatory Control". As compensatory controls are subject to the interpretation of the assessors and the vendor, adversaries are making the most of this situation by exploiting the loopholes left behind while implementing these workarounds.

At information security conferences, there are heated discussions on the difficulties faced by the merchants/service providers in complying with the encryption requirement of PCIDSS. Inability to comply with the requirements often lead the vendor to seek refuge under the section called "Compensatory Control". As compensatory controls are subject to the interpretation of the assessors and the vendor, adversaries are making the most of this situation by exploiting the loopholes left behind while implementing these workarounds.

We hear several conflicting advice when it comes to the encryption requirements of PCIDSS.

  • Advice 1: "Mask CVV2 and use SSL for transmission"
  • Advice 2: "Mask CVV2, use one-way Hash and use SSL for transmission"
  • Advice 3: "Our application is not compatible with AES, so we are encrypting and storing the PAN using 3DES in the database. We store the decryption key in the database for faster processing"
  • Advice 4: "WPA2! We are facing too many constraints. Let's stick with WEP and improve the key management process"

This article helps you understand the specific encryption requirements and the ways to comply with these requirements. This is a two part article. In the first, we focus on Requirement 3 of PCIDSS. In the next part, we look at Requirement 4. We also touch on some scenarios that are often overlooked while trying to secure the cardholder data.

Requirement 3: Let's protect what is getting stored

First, let's review what exactly constitutes cardholder data. We can split cardholder data into two parts: (1) PAN data (2) Authentication data. (1) PAN data further constitutes of 16 digit PAN, Cardholder Name, Expiry date, and Service code. (2) Authentication data constitutes of the full magnetic stripe data, CVV2 and the PIN/PIN Block

3.1 "Limit storage of cardholder data, develop retention and disposal policy"

Areas of concern:

  • We are ISO27001/CMM Level 5 etc., compliant and our security policy is sufficient enough.
  • Our existent security policy has clauses which if interpreted along a particular line of thinking addresses the 3.1 requirement

What to do:

  • What gets written gets implemented. Ensure that your policy aligns with the intent of PCIDSS by having clauses on not storing sensitive authentication data & identifying legal/regulatory/contractual requirements for data retention. Also the policy should address the process for removal of cardholder data post the retention period
  • PCIDSS being a technical standard wants the management to appreciate the finer nuances being highlighted in the standard and as such complying with PCIDSS would require the organization to amend the policy level details as mandated by the requirements

3.2 "Don't store sensitive authentication data after authorization"

Areas of concern:

  • There are scenarios where CVV2 (the 3 or 4 digit card validation code) gets stored even after sufficient precautions are taken by the vendor company. For e.g. CVV2 getting stored in web browsers auto complete feature set or getting stored in clear text in the user machines RAM.
  • During the transmission stage and before the authorization actually takes place there can be multiple locations where the sensitive authentication data could get stored for e.g. transaction logs, history files, trace files, debugging logs

What to do:

  • Ensure that the auto complete feature of browsers is disabled when the user gets the payment gateway web page. Also consider using a one-way hash while transmitting the CVV2.
  • Authentication data should not be stored in any logs. Implement mechanisms to periodically counter check the existence of authentication data in the logs. One of our clients wrote a stored procedure that searches for 16 digit PAN numbers. Corrective actions could then be put in place for deleting these files.

3.3 "Mask the PAN when being displayed"

Areas of concern:

  • PAN being displayed in full in transaction receipts (POS receipts), invoices, web pages (purchase receipts from e-commerce websites or online transfer of fund receipt)
  • PAN being displayed to the relevant business users

What to do:

  • The first 6 or the last 4 digits of PAN can be printed in full on receipts. The other digits should be masked
  • Considering valid business justification, PCIDSS does not mandate masking of PAN when being made visible to employees or other parties

3.4 "Render PAN, at minimum unreadable anywhere it is stored"

Areas of concern:

  • Should I truncate, hash or encrypt the PAN?
  • Should I implement File/Disk level encryption when I am using database [column-level] encryption for securing the PAN?
  • We have integrated LDAP with the disk level encryption for easier implementation.
  • Current system architecture requires the PAN to be stored in readable format, truncation to be implemented in 3 months time. Is there any compensatory control I can go for the 3 months time?
  • Our service provider uses voice based process and there is no data entry being done. Should I worry about encryption then?
  • Would data loss prevention tool be of any help?

What to do:

  • Choosing between truncation, hashing or encryption could be related to how well it is integrating with other system components.
    • Truncation is easier to implement while displaying the PAN on receipts, monthly bills or storing PAN in locations apart from the main database
    • Encryption or Hashing is recommended while storing PAN in the database
  • Typically, column-level encryption will not address the risks pertaining to storage of PAN in log files/trace files/debug files etc. PCIDSS mandates secure storage of PAN not just in the database columns but also in any other location where the PAN gets stored.
  • PCIDSS mandates separation of native OS access control and authentication process for disk level encryption.
  • Encryption software used for disk level encryption might not be usable in removable media or backup tapes. As a result separate mechanisms should be built in for encryption of data stored in backup tapes and removable media devices.
  • Compensatory controls that can be implemented:
    • Ensure the logical access to the database storing the PAN is independent of Active Directory or LDAP authentication
    • Ensure that applications used to access the database is being scanned periodically by an ASV
    • Internal network segmentation to isolate placement of database
    • Restrict access to the database by considering following options:
      • IP / MAC based restrictions
      • Two factor authentication
  • Voice based process too has files which are used for recording the conversation between customer and the agent. These voice files could potentially contain the PAN details, cardholder name etc., File/Disk level encryption should be considered to protect these files.
  • Analysis of recent frauds has revealed insider threat to be the prime factor behind such events. DLP tools will ensure that users are not able to leak sensitive cardholder data through email, removable media devices etc.,

3.5 & 3.6 "Document and implement a fool-proof key management system"

Areas of concern:

  • Storage of decryption keys in the database?
  • I am encrypting my data key (DEK) using Key encryption key (KEK), should I put in same level of access control on both the keys?
  • Should I invest in a Hardware Security Module (HSM)?
  • How do I trust the people entrusted with storing of different parts of encryption keys? Can I prevent a possible collusion attempt for compromising the key?
  • As a service provider who is required to share encryption keys with my customer, how should I ensure that the customer follows safe practices while handling the keys?

What to do:

  • Before proceeding further let us look at the intent of Requirement 3: It is to ensure that the cardholder data is stored securely. So if you encrypt the data and store the decryption key along with the encrypted data then purpose of encryption itself is defeated.
  • There are several schools of thought. One says that if DEK is encrypted then it need not be securely stored as how the KEK would be stored. The same level of access control should be used to protect DEK and KEK. Consider using Split knowledge and Dual control: i.e. having two persons for reconstructing the keys (split knowledge) and having them use password/token for access the keys (dual control).
  • Hardware Security Module (HSM) is the most fool-proof system for secure encryption and decryption of keys. Typical credit card transaction flows through multiple components. So all components using HSM boxes would be the safest option. The cost deters many from taking that route. It's best to decide based on a risk assessment. Please note that it is not mandatory to have HSM
  • Split knowledge & dual control is targeted to prevent collusion, but then human behavior is unpredictable. On account of collusion, both the customer and the organization suffer. Build trust among employees and at the same time have a procedure to make them sign an agreement for safeguarding of the keys at all times.
  • Security awareness is as important as encrypting the data. Sharing of keys for business reasons with customers would also require you to make them aware of the key management practices being followed by you. They can then take equivalent if not higher precautions while handling the key.


Choosing the right encryption algorithms and associated key management practices in line simplifies the implementation of controls for PCIDSS. Making things complex will surely deter the adversary but at the same time would increase the probability of having a security loophole. In this article we have touched on the storage requirements for the cardholder data. In the next part, we will focus on the finer nuances of ensuring secure transmission of the cardholder data.


Tags: Features






Buyer’s Guide to Managed Detection and Response


Get AI Powered

Managed Detection and Response





AI-Driven Managed Detection and Response

Download Report



Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset