This is page 2 of:
Post-PCI: Visa Experiments With More Secure Card Strategies
“When they read that card, not only do they pick up the magnetic strip, the typical sensitive data that we authorize with, but they also pick up that DNA picture and send that along with the authorization message,” Roeber said. “Once that card is swiped, the first time that it comes into Visa, we establish a baseline DNA fingerprint for that card at Visa. Once that’s established, all subsequent swipes of that card, and other merchants with that same reader, can analyze that swipe. There’s tolerance thresholds levels built into the technology to figure out, ‘Well, is this really the same card or not?’ One thing that I like about this technology is that there’s no key management to deal with. From a merchant standpoint, all they have to do is install the new readers.”
Still, Roeber said, this approach is based on the assumption that the initial card was legitimate. If it happened to be fraudulent, this approach would unintentionally validate the bogus card. To address that, Roeber said the ideal approach is to create the fingerprint as soon as the card is made. “That DNA could be captured at the point of creating the cards, working with the card that is right off the factory line. The best way is to start (the process) from the issuer. The DNA is captured there.”
Fifth Third’s trial technology factored in the small changes to a card that come from wear and tear and it estimates those changes given the age of the card. “When you swipe a card time after time after time, you’re going to age that strip to a certain extent,” Roeber said. “This technology actually takes that degradation into account so you minimize the number of false positives when you swipe those cards.”
Over at McDonalds, their trial was less technological than organizational and structural: A complete segregation of all payment data from all other data in the restaurant chain’s databases.
“Our point of sale will send a message to a PIN device,” which will send the data through to their processor, said McDonalds CIO David Weick. “None of our internal systems will even have access to cardholder data,” he said.
The CIO of the $24 billion chain said that although McDonalds is huge—with some 33,000 restaurants around the world—the very high percentage of the restaurants that are owned by franchisees makes IT policy enforcement much more difficult. About 85 percent of all McDonalds restaurants in the U.S. are franchised and that figure drops to only 70 percent globally. “That means that I can’t dictate to our franchisees the technology that they are going to put in place. Franchisees may buy into it intellectually, but not necessarily with their pocketbooks.” Weick said he’d go the easy route and start his data segregation trials with company-owned stores.
-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.