Post-PCI: Visa Experiments With More Secure Card Strategies
Written by Evan SchumanVisa has been experimenting—through retail and processor partners—with several alternative security approaches for its cards, including a challenge and response effort at OfficeMax, a digital card fingerprint-like image at processor Fifth Third and a strict data segregation experiment at McDonalds.
Visa’s chief enterprise risk officer, Ellen Richey, said the program is all about looking for the next security approach, to identify ways to develop security measures that are currently not a part of PCI. She said that Visa looks favorably on some form of the chip-and-PIN approach that is used today in the U.K.. “”It’s a matter of when we are going to adopt it and how,” she said, adding that existing contactless payment trials in the U.S. are based on similar technology. “We fully support this technology (chip) as there are different needs in different parts of the world.”
Added Gerry Sweeney, global head, E-Commerce & Authentication at Visa: “We must move from static data to dynamic data, particularly in the area of authenticating consumers and cards.”
The challenge and response pilot was started late last year at 100 OfficeMax stores in Illinois, Indiana and Florida, according to OfficeMax Treasurer William Van Orman. “It originally was to be completed by May of this year. It was initially supposed to be a six month pilot, but it was extended by four more months at the request of Visa,” Van Orman said.
The trial has cashiers asking consumers a series of rotating questions, including asking them to say their Zip Code, the last four numbers of their home phone number, the last four digits of their cell phone number and their home phone area code, Van Orman said. The trial has had small impacts on store operations, such as requiring disclosure signs near the POS and additional associate training. But Van Orman said his team detected no speed reductions at POS.
Fifth Third Bank, one of the largest card processors, argued that a popular theoretical approach—true end-to-end encryption—is a good idea on paper but it has logistical hurdles that may ultimately make it not viable. “With end to end encryption, there is a tremendous key management issue,” said Fifth Third’s Don Roeber, vice president and manager of merchant PCI compliance. “It’s a significant challenge for (retailers) to manage all those keys. It has some implementation issues.”
Instead, he’s been pushing—and testing—an approach where the processor can take a digital snapshot of the card’s magstripe. “It’s like a digital ID. We read that swipe and take a picture. It’s like a fingerprint, a DNA print of that card,” he said, adding that Fifth Third quietly installed 1,000 specially-designed readers to retailers, saying that it was just part of their normal upgrade process. “It was transparent to the merchant,” Roeber said.
-Marc
March 26th, 2009 at 11:17 am
Roeber is incorrect in his assumption that retailers would have to manage any new keys to implement an end-to-end encryption solution. To be truly secure, the bank needs to own both of the endpoints for account validation. The retailers should be reduced to nothing more than a middleman carrying the already secured data.
This is done with on-chip authentication and using a bank-provided, customer-owned handheld validation terminal, where all the encryption takes place in the customer’s chip and at the customer’s bank. Banks would have to issue a key for each card and embed them in the chips as a part of producing the cards. As a result, account security then lies 100% in the hands of the bank, and out of the retailers.
March 26th, 2009 at 11:17 am
We will try anything except EMV …
March 26th, 2009 at 2:51 pm
ASC X9 is close to approving a new work item to look at a standard for protecting the PAN between the POS device and the acquiring host system. Don is right in saying that the key management end to end to the issuer would be hard. But at the last X9F6 meeting in Salt Lake City in January, we kicked around the idea of just doing the most threatened link, the one between the merchant device and their bank. We already have a key management regimen in place for the PINs, and there is a standard way to use this for data MACing or data encryption too. Using a data encryption working key to protect sensitive data would be easy, and the number of elements on the transaction path that would have to support it is reduced, and many of these vendor belong to ASC X9. It was even suggested that we think about encrypting the track data, including the expiry date, the CVV, and any PIN offset. Then we could leave the PAN in the clear, making routing super easy. With just the PAN, it would be hard to make a fake card. These are just ideas, but with some of the best minds in card security thinking about it, and vendors willing to adopt a standard, we might be able to come up with something.
March 27th, 2009 at 8:32 am
Is PCI Compliance a toothless tiger?
The massive data breach announced in January by Heartland Payment Systems continues to raise significant questions regarding the state of security in the payment industry. Heartland is still in operation. Visa, while taking Heartland off of its “compliant†list, continues to accept transactions processed by the company. And a top analyst at Gartner Research just this week is urging companies that do business with Heartland Payment Systems Inc. and RBS WorldPay Inc. (another breached processor) not to switch to other payment processors.
Heartland has even gone so far as to threaten to sue companies that try to take its business away by raising questions about the effectiveness of its security systems.
What is clear is that millions of people and merchants have been put at risk, and little is being done voluntarily to mitigate the damage. What good is PCI compliance if there are no penalties involved for the major institutions that claim compliance and are not?
Security is only as strong as the weakest link. PCI compliance certification is not a guarantee against breaches. Organizations should prepare accordingly.
March 27th, 2009 at 2:57 pm
“With end to end encryption, there is a tremendous key management issue,†said Fifth Third’s Don Roeber, vice president and manager of merchant PCI compliance. “It’s a significant challenge for (retailers) to manage all those keys. It has some implementation issues.â€
This is not true anymore. Granted , end to end encryption used to be very difficult. Retailers would be stuck with 3DES and AES keys all over the place: ugly key management problems indeed. However, key management at scale is a solved problem as far as I am concerned.
Roeber’s Statement would be correct if we assume a completely static key management model – certainly a problem 5-10 years ago but not today where techniques and standards like Identity Based Encryption (IBE) (RFC 5091 et al), Dynamic Key Management, and AES Format Preserving Encryption (FFSEM Mode AES) solves this problem easily even in complex distributed embedded environments like card payment systems and POS.
Take encryption – in the past we’d have this question and problem:
“If I encrypt the cardholder data, I have to change everything – all those places expecting a credit card #, a date, track 2 etc?”
This is solved by AES FPE – a mode of AES. Interested readers can look up the NIST Modes site for FFSEM mode AES. With FPE, encryption of the card number or internal subfields (first 6, last 4, and middle 9 -whatever sub fields need protecting or left clear) can be performed in place without changing the data structure. With FPE there no need to manage a token database either – encrypted data is created from live data on the fly with no change to data formats – Luhns are still valid etc: the data is directly transformed into encrypted form in situ.
Thus, 256 bit FPE AES encrypted data can look, feel, and behaves like a real card as far as systems are concerned, yet its encrypted to 256-bit AES strength with 256 bit keys. Ditto for dates, Track 2 etc. No format changes, no integrity changes.
Then we have the question: “How do I secure this key and share it with trusted endpoints? What if I power off the device and I have stored data I need to upload the next time I’m online?”
Again, this is a solved problem. By combining IBE and FPE, data that stays in the same format as the original, meaning no changes to other POS processing environments (and taking them out of PCI audit scope), and IBE provides a simple secure key exchange to the trusted back office – warehouse/clearer/acquirer etc where the real data is required or conclude a transaction/reversal. Key rollover is inherently managed and completely behind the scenes – hardly “a significant challenge”. IBE is very efficient and fast.
Therefore, the combination of technologies like IBE and FPE make end to end protection entirely feasible – key management becomes completely transparent and automated, and there’s no need for any third party tokenization system which has its own complications.
Regards,
Mark Bower
Vice President Products
Voltage Security
Full Disclosure: I work for a company providing encryption technologies.
March 28th, 2009 at 10:20 am
Mark,
You state above that end to end encryption would take the POS out of scope. However, the DSS 1.2 and the SSC are quite clear on this, any cardholder data, no matter what format is cardholder data and any items it passes through are in scope. So the SSC needs to get off its backside, get up to speed on new technology and issue a statement acknowlegding that encrypted data in flight is a way forward and that in terms of scoping, the POS would be out of scope.
Regards,
March 29th, 2009 at 10:03 am
I look forward to continued discussions on end to end encryption. I do feel it is feasible and the accountability can shift away from the retailer. My focus is in the International sector and EMV is moving us towards full encryption of authorization data from the device to the central switch, at least reducing our risk in the store environment. When I started a recent dialogue with our Canadian processor as to the possibility of end to end encryption, I was told we were the first to inquire. I asked that they make a note of it as I was certain we won’t be the last.
March 31st, 2009 at 12:31 pm
A Reader says “…any cardholder data, no matter what format is cardholder data and any items it passes through are in scope.” Encrypted data is not considered in-scope when the decryption key is not present. Otherwise, the entire Internet would need to become “PCI Compliant” since all of the card data is being sent through it using SSL.
April 2nd, 2009 at 3:14 am
PCI Guy, understood, however it would be nice if the QSA’s took the same line as you. Numerous QSAs including Stateside ones have refused to rule the POS out of scope and are indeed waiting for the SSC to issue a statement clarifying this. And yes there is no decrpyt key on the POS or terminal.
September 4th, 2009 at 10:35 pm
Mark, did you check if the AES encryption mode that you are planning to use is PCI approved? You should check with the PCI Security Standards Council if they approve the Voltage FPE that you are suggesting. You may start by checking the list of encryption algorithms and modes that are currently approved by NIST ( http://csrc.nist.gov/CryptoToolkit/modes/ ). In Special Publication 800-38A, five confidentiality modes are specified for use with any approved block cipher, such as the AES algorithm. The modes in SP 800-38A are updated versions of the ECB, CBC, CFB, and OFB modes that are specified in FIPS Pub. 81; in addition, SP 800-38A specifies the CTR mode.
September 11th, 2009 at 4:46 pm
Mark, please also review the analysis that came from Adrian Lane, Security Analyst – CTO, at Securosis this week. He said: The business justification for this type of encryption is a little foggy. The commonly cited reasons you would consider FPE/DTP are: a) if changing the database or other storage structures are impossibly complex or cost prohibitive, or b) if changing the applications that process sensitive data would be impossibly complex or cost prohibitive. Therefore you need a way to protect the data without not requiring these changes. The cost you are looking to avoid is changing your database and application code, but on closer inspection this savings may be illusory. Changing the database structure for most is a simple alter table command, along with changes to a few dozen queries and some data cleanup and you are done. For most firms that’s not so dire. And regardless of what form of encryption you choose, you will need to alter application code somewhere. The question becomes whether an FPE solution will allow you to minimize application changes as well. If the database changes are minimal and FPE requires the same application changes as non-FPE encryption, there is no a strong financial incentive to adopt. He also said: The reason this is interesting, and why I was reviewing the proof above, is that this method of encryption is not on the PCI’s list of approved ‘strong’ cryptography ciphers. I understand that NIST is considering the suitability of FFSEM (pdf) and DTP (pdf) encryption, but they are not approved at this time. And Voltage submitted FFSEM, not FPE.
October 18th, 2009 at 9:31 am
I looked at the spec for FCE, FCEM, FPE and FFSEM. I found the specifications of FCEM and FFSEM at http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html . My understanding is that you can define all the data types you need in FCEM. FFSEM is restricted to digits only and the field length must be between nine and nineteen digits.