This is page 3 of:
Post-PCI: Visa Experiments With More Secure Card Strategies
Another impact of the franchisee factor, Weick said, is pure ROI. In the U.S., he said, the typical McDonalds brings in about $2.1 million to $2.2 million in revenue per store. “So any solution that I come up with needs to fit within a P&L that starts with a $2.1 million or $2.2 million revenue line. If I come up with something that is way out of line, I have the franchisees who are there to tell me and to describe for me the economics of their business and whether or not it fits,” Weick said.
He said that he also needs to be especially sensitive to even slight slowdowns in the checkout process, adding that other retailers are likely going to be somewhat more tolerant.
As part of a general discussion of PCI ROI, Fifth Third’s Roeber said that his firm has tried to be more flexible in PCI rulings, with an eye on minimizing material risk as opposed to trying to unrealistically avoid all risk. He cited an example of a retailer who was being assessed about a year ago.
“Say they lost power or lost connectivity at one particular store. Their terminals would go into a store and forward mode, holding onto this data until a connection could be made again. During this period, these transactions were being stored in the clear. That’s a problem. That’s not in compliance with the PCI data security standards,” Roeber said. “The assessor was really taking a hard line, saying that you have got to upgrade every one of your terminals in your entire environment to a terminal that will encrypt this data.” That’s when Roeber said he got involved. “If Store A loses connectivity, no one can connect to that terminal because it’s not connected to the Internet. Once it does connect, it will be immediately be shipped on out for authorization. So I thought, ‘the only risk here is that you might have a store employee that recognizes this particular risk and figures out a way to extract data off that terminal.’ You’re really talking 40 or 50 transactions at the max. I thought, ‘That’s a pretty small risk. That risk was not material.'”
-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.