VeriShield Protect Meets Visa Data Encryption Best Practices

There has been much discussion this year about the benefits of end to end encryption protecting cardholder data. Proper end to end encryption solutions will improve the security of cardholder data, remove some retail systems from PCI DSS scope and will reduce both the costs of compliance as well as the cost of PCI DSS assessments. George Peabody of the Mercator Group projects that retailers will save 20% of their ongoing PCI compliance costs and 25% of their annual assessment costs. (1)

Until recently, merchants were left on their own to evaluate end to end encryption solutions to determine if indeed, the solution did properly protect cardholder data. Visa’s recently published Data Encryption Best Practices has finally provided guidance to retailers who are looking to implement end to end encryption.

While some of the best practices are technical and reference technical specifications, they incorporate generally accepted financial industry standards that are widely understood and used within the payments industry today for the protection of debit PINs and debit PIN encryption keys.

There are 14 Data Field Protection Best Practices which are grouped into 5 Data Field Protection Goals. These goals and the associated best practices are as follows:

Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption.
1. Cardholder and sensitive authentication data must remain encrypted between the endpoints
2. ANSI or ISO approved strong encryption like TDES or AES must be used
3. The first 6 digits and last 4 digits of the PAN may be left in the clear for routing and receipt printing purposes, but the remaining track data must be encrypted
4. Per existing PCI DSS requirements and definitions, sensitive authentication must not be stored after authorization.

Use robust key management solutions consistent with international and/or regional standards.
5. Keys must be managed per ANSI X9.24/ISO 11568 or equivalent within Secure Cryptographic Devices (SCD) such as a PED Payment Terminals and Host Security Modules ( HSM).
6. Keys and key components must be generated using an approved random or pseudo-random process such as NIST SP 800-22.
7. The key management process must be documented
8. Keys may only be transmitted in a secure manner, for example, the key distribution method described in ANSI X9/TR-34.
9. The keys used for encryption must be unique per device and not used for any other purpose like debit PIN encryption or key exchange.

Use key-lengths and cryptographic algorithms consistent with international and/or regional standards.
10. Encryption keys shall have strength of at least 112 equivalent bit strength. (AES is 128 bytes.)
11. Format Preserving Encryption schemes must be evaluated by at least one independent security evaluation organization and subjected to a cryptographic peer review.

Protect devices used to perform cryptographic operations against physical/logical compromises.
12. Devices used to perform cryptographic operations should undergo independent assessment to ensure that the hardware and software they are using is resilient to attack.
13. Keys must be protected against physical and logical compromise as well as protected from substitution and authenticity shall be ensured.

Use an alternate account or transaction identifier for business processes that requires the primary account number to be utilized after authorization, such as processing of recurring payments, customer loyalty programs or fraud management.
14. If any cardholder data (e.g. the PAN) is needed after authorization, a single-use or multi-use transaction ID or token should be used instead.

These best practices should help retailers properly evaluate end to end encryption solutions.

The VeriShield Protect End to End Encryption solution meets or exceeds all of these requirements.

1. Cardholder data is encrypted as soon as the card is swiped and remains encrypted until it reaches the RBS datacenter.
2. VeriShield Protect uses strong AES encryption
3. The first 6 digits and last 4 digits of the PAN are left in the clear for routing and receipt printing purposes, but all other track data must is encrypted
4. No sensitive authentication is stored after authorization.
5. Keys are managed per ANSI X9.24/ISO 11568 within Secure Cryptographic Devices (SCD) such as a PED Payment Terminals and Host Security Modules ( HSM).
6. Keys and key components are generated using NIST SP 800-22 standards.
7. The key management process is documented
8. Keys are only be transmitted in a secure manner.
9. Keys used for encryption are unique per device and not used for any other purpose.
10. AES key strength is 128 bytes
11. VeriShield Protect has been evaluated by an independent security evaluation organization and subjected to a cryptographic peer review.
12. The VeriFone payment terminals used to perform cryptographic operations are PCI PED approved
13. All keys are protected against physical and logical compromise as well as protected from substitution and the authenticity of keys is proven.
14. After authorization, VeriShield Protect can produce a single-use or multi-use transaction ID or token.

Visa’s publication of Data Field Encryption Best Practices is likely to become the next PCI standard. The history of Visa PED, Visa CISP and Visa PABP all being adopted by the PCI Security Standards Council will likely continue to be followed with this set of best practices. Retailers should feel confident that by adopting VeriShield Protect not only will they better protect their consumers data and reduce their PCI compliance costs, but also that they will be ahead of the game for the next payment industry standard.


(1) “End to End Encryption: The Acquiring Side Responds to Data Loss and PCI Compliance”, George Peabody, Mercator Advisory Group, Inc. June 2009.

The Evolution of Payment Terminal Standards

Almost since the inception of payment terminals, there has been concern about criminals tampering with these devices to capture card information for fraudulent purposes. In 1997, Visa issued the first security requirements for PIN Entry Devices. Effective January 1, 2008, all newly deployed PIN entry terminals were required to meet this standard. Manufacturers did not have to submit terminals to independent labs for certification against this standard; rather they simply attested that the standard was met. In 2002, Visa enhanced their PED security program with additional security requirements and the requirement that terminals be submitted to a Visa approved lab for approval. In May of 2003, Visa announced that effective January 1, 2004, all newly deployed terminals must meet this standard and as of July 1, 2010, all installed terminals must have met this standard and independently tested by a lab.

In 2004, MasterCard and Visa agreed to develop one set of PIN Entry Device requirements, which became known as PCI PED. As part of this agreement they announced that all newly deployed terminals after January 1, 2008 must meet this requirement.

In 2005, the card associations (American Express, Discover, JCB, MasterCard and Visa) formed the PCI Security Standards Council to standardize payment standards they required retailers to adhere to (The PCI DSS or Data Security Standard). In September 2006, the PCI SSC announced that they would take over the management and development of the PED Standard, and they released the PCI PED 2.0 Requirements in April of 2007. Next in the evolution of Payment Terminal Standards will be the introduction of the PTS (PIN Transaction Security Program) at the PCI SSC community meeting in September 2009.

The following chart illustrates the timeline of the evolution of payment terminal standards.

Visa - Chip & Pin not coming to US for a long time

The June/July issue of Cards&Payments has an article profiling Ellen Richey,head of global enterprise risk for Visa. Some interesting points from the article.

Q: Is it possible for companies to maintain compliance all the time?
A: Maintaining compliance is basically just disiplined execution. Security needs to be built into the business process so it is part of the everyday work.

Q: You said recently that Visa expects the US to adopt chip technology that is being used elsewhere to make purchases more secure. When do you think that will happen?
A: The fundamental technology will have to be consistent all around the world, and the EMV standard is what needs to be applied to maintain interoperability. But the U.S. is not going to be adopting a chip-and-PIN credit card or debit card any time in the very near future. What we're seeing today in the U.S. is contactless-chip technology rolling out.

Q: What will be the greatest security advance?
A: First, we think the industry ultimately needs to move toward dynamic data. Trying to protect static data within the system is going to be, I hope, less and less of a problem because the data will be less and less vulnerable. Once its stolen, it would be unusable. That would be the ultimate advance. Secondly, what I would like to see is continuously improving collaboration among all stakeholders - better communications and better cooperation to advance security - because we think security is absolutely a shared responsibility, and everybody has a role to play.

Visa's Latest PCI DSS Compliance Numbers

From a session at the MWAA last week.

Level Companies %PCI DSS Compliant
1 362 93%
2 702 88%
3 2,627 57%
4 6m+ low

VISA 7/1/10 Mandate Clarifications

There has been much confusion over the impact to a retailer who does not meet the Visa July 1, 2010 mandates for payment security.

To review, there are three different mandates from Visa that must be met by US merchants by July 1, 2010. These are:

· All non-certified payment terminals on which PIN debit transactions are conducted must be removed from service. This includes any terminal that is not either VISA PED or PCI PED.

· All debit card PINs must be encrypted in TDES from the payment terminal

· All applications that “store, process, or transmit cardholder information” must be PA-DSS or PABP compliant.

So what is the impact of not conforming to one or more of those mandates?

First, in all cases, if the retailer suffers a data breach and cardholder information is compromised, then all liability passes to the retailer if the breach was in part the result of the retailer not being compliant with these mandates. Various studies put the cost of a cardholder breach in the range of $125 to $225 per compromised record. (Not card records actually used fraudulently, but all cardholder records that were exposed by the breach.) The Ponemon Institute publishes an annual study of the cost of a data breach which is available on their web site.

The costs of a breach that a retailer would be subject to include the following:

·Investigation costs by themselves, the card associations and the banks that issued the compromised cards.

·The costs borne by the issuing banks to re-issue the compromised cards

·The actual costs of fraudulent purchases made on any of the compromised cards

·Fines from VISA which would be assessed against the acquiring bank who would pass them to the retailer’s processor who would pass them to the retailer

·In addition, the retailer would have their own legal, PR, IT, forensics and remediation costs, which of course they would also have to bear even if they were compliant at the time of the breach.

What costs would a retailer face if they are non-compliant with the July 1st, 2010 mandates? These may vary by which of the mandates the retailer is not compliant with.

·Use of non-certified payment terminals after July 1, 2010 (Does not apply to Fuel Dispensers, there are different requirements for that.)

- While Visa has not issued a statement about the enforcement of thus mandate, it is reasonable to expect that they will fine acquiring banks who have merchants using non-compliant terminals. This could start on July 1, 2010, or sometime after that date. VISA has not publically published their enforcement plan for this mandate yet. It would be pure speculation to estimate the size of these fines.

Use of Master Session or Single DES (DUKPT) after July 1, 2010
- Visa has already announced, in their April 2009 TDES update that they will begin fining acquires who have merchants using other then TDES on 8/1/12. It is safe to assume that in most cases those fines will be passed onto the merchants in non-conformance with the mandate.

·Use of non PA-DSS (or un-expired PABP) applications after July 1, 2010.
- Visa has confirmed verbally to me that they plan on fining acquirers as of July 1, 2010 if they have merchants that are not in compliance with this mandate. The amount of this fine is likely to be in the same range as the fines for PCI DSS non-conformance ($5,000 t0 $25,000 per month), although I expect a lower tier fine for Level 4 merchants. I would guess that these would be assessed monthly for as long as the merchant remains non-compliant.

In summary, there are two types of costs and fines a merchant could be subject to if they do not meet Visa’s July 1, 2010 mandates: first non-compliance fines for non-compliance with the mandates, some of which be assessed starting on that date; and breach fines and other breach related costs in the event of a breach that was in part based on the merchant’s non0compliance with these payment security mandates.