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.

I read the recent article "Tokenization Vs. End-to-End Encryption: Experts Weigh in" published in Bank Information Security yesterday and felt compelled to send the following letter to the editor to correct the mis-information it contained.

_____________________________________________________________

Linda McGlasson
Managing Editor, Bank Information Security

I read the recent article you published on Tokenization versus End-to-End Encryption and I think there are several errors or misconceptions that should be corrected. Perhaps some of this comes from the bias of the experts you interviewed.

First the entire discussion of tokenization versus end-to-end encryption does not even make sense. This is not an either or solution, nor is it a large versus small company decision. Both tokenization and end-to-end encryption can improve the security of cardholder data and can work well together in many environments.

By definition, tokenization cannot take place at the point of card swipe. Cardholder data must be sent throughput the authorization process to a secure token server before a token could be generated and sent back in the response message. This is the main reason why tokenization cannot stand alone in protecting cardholder data. It will remain unprotected in payment terminals, POS systems and retailer host systems where it may be captured by malware planted by criminals.

However, for long term data storage, tokenization may be the ideal solution for many retailers. We are partnering with several processors and merchants to deploy solutions which protect cardholder data in transit with end-to-end encryption and data at rest with tokenization.

The first important point about end-to-end encryption is that it should take place as soon as the card is swiped and remain protected as it traverses the payment infrastructure until it is decrypted. If that decryption takes place at the merchant’s acquiring processor, then there is no unencrypted cardholder data in the retailer’s environment.

And I will have to disagree with Anton Chuvakin that no one can roll out and end to end encryption solution and have it secure and useable. If the acquirer is involved and the payment terminal manufacturer provides a robust end to end encryption solution then smaller Level 4 merchants can remove cardholder data in the clear from their environment. By following industry encryption and key management standards, such as defined by Visa in their recent Data Field Encryption Best Practices, larger merchants can also implement a secure and useable end-to-end encryption solution.

Kevin Nixon, your independent security consultant needs to learn more about the end-to-end encryption solutions on the market. I suspect he is a QSA and fears that if security technology removes systems from PCI DSS scope he will be out of a job. It has nothing to do with doing security on the cheap, it has all to do with doing the best security. In fact, end-to-end encryption for many retailers will cost more than their annual PCI DSS assessment. Further, he argues such encryption could encrypt a worm and send it along. First, end –to-end encryption, done per Visa Data Field Encryption standards is done in the Tamper Resistant Security Module (TRMS) of the payment device which is protected by many of those layers Kevin talks about. And how could someone write a worm or malware and make it fit in the limited bytes of track data.

Perhaps next time you write an article about end-to-end encryption or tokenization you should consider talking to some of the vendors who are currently helping retailers protect sensitive cardholder data.

Jeff Wakefield
VP & General Manager, Global Security Solutions, VeriFone