That is a gap that tokenization is meant to fill. The technology works behind the scenes of a digital transaction: Customers still put in their card number, but software then transforms that information into a one-time token — a randomly generated code — that is sent through the payment-processing chain. Thieves who intercept the code can do little with it without the means to unscramble the token.
Fallacy of Tokenization
This article in The New York Times blog is another example of fallacy of tokenization.
This description is untrue. Tokenization does not work this way. In order to get authorization for the credit card charge, the point of sale system still needs to send the full card data (the content of magnetic track 1 or 2) to the payment processing server. Such data cannot be just "transformed into a one-time randomly generated token" because the server system must be able to recognize and process it. So the card data should be encrypted using another technology called point-to-point encryption (P2PE) which is different from tokenization. Only after the card data is decrypted and processed at the payment processor's data center, it can be tokenized using the method described above, and the resulting token can be returned to the point of sale system. There are P2PE systems that are able to produce the format-preserving encryption so the resulting encrypted data looks similar to the original input so maybe that's created a confusion. But in any case, the data produced by such system is not "randomly generated", and it's not a token, and it's done in hardware rather than software, and the system is called P2PE and not tokenization. Unfortunately, such misunderstanding and overestimation of tokenization is very common perception.
My interview by Cathleen McCarthy at CreditCards.com about recent breaches, payments with credit/debit cards, EMV migration, etc.
Secure payments with HP Mobile POS: Implementing point-to-point encryption using HP retail solutions
Secure payments with HP Mobile POS: Implementing point-to-point encryption using HP retail solutions is the technical whitepaper which I have created for HP. More information about HP mobile POS solutions can be found here.
The PCI SSC meeting (1400 participants) is over. Mostly, minor clarifications in PCI DSS and PA-DSS 3.0, changes in PTS testing requirements 4.0. Unfortunately, no significant changes in PCI standards means no good news for merchants and cardholders. No regulation or tech breakthroughs means the show will go on.
PCI DSS and PA-DSS 3.0 changes
PCI SSC has released a document that "highlights anticipated changes to the PCI Data Security Standard (PCI DSS) and Payment Application-Data Security Standard (PA-DSS) in order to prepare organizations for the introduction of Version 3.0 in November 2013".
I could not find any significant changes that would help to improve the security of card payment transactions. I wasn't surprised though.
Myth: PCI will make us secure
I just found a list of "PCI myths" on some website about PCI compliance. One of the myths sounds familiar and reasonable, although the explanation (they call it "fact") sounds polite but unconvincing and incomplete:
Myth: PCI will make us secure.
Fact: Successful completion of a system scan or assessment for PCI is but a snapshot in time. Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.
Credit card with display and keyboard
There is a new Mastercard which has LCD screen and keyboard. It looks like the plastic becomes smarter and closer to POS terminal in its functionality which I guess will bring new security issues...
I would like to update you on most notable news from the PCI 2012 community meeting which took place in Orlando, Florida.
1. There were no announcements regarding any major changes in either PCI DSS or PA-DSS, but there is a tendency of expanding these standards into the new areas such as Tokenization, Mobile Payments, and P2PE (see below).
2. Tokenization guidelines will become a standard in near future which means the rules around tokenization must be followed and any token implementation must be assessed by auditors. It is still unclear whether it is going to be separate standard or part of the existing one such as PCI DSS. The standard will cover all aspects of tokenization such as token generation, token storage (token vault), usage, etc. Final delivery of the standard: 2013-2014.
3. Mobile Payments
- The Mobile payments solutions are going to be divided into 3 major categories with several sub-categories – based on different technologies and hardware/software configurations. For example, smart phone based solutions fall under 3rd category. The idea is to gradually release guidelines for each and every category/sun-category, and eventually create a mobile payments standard, so most probably, the mobile payments guidelines eventually will become a standard - similar to Tokenization. There were no timelines provided for the future guidelines or standards.
- New PCI Mobile Payment Acceptance Security Guidelines for Developers were released during the meeting.
- Next Steps:
The next step is releasing the Hybrid P2PE Requirements (there is an existing draft), and the next one is going to be software P2PE. No dates were provided.
- SAQ-P2PE-HW: I don’t know if you have noticed but there is new SAQ-P2PE-HW (Self-Assessment Questionnaire for Hardware/Hardware P2PE) available on PCI website since June. It still cannot be used because there are no listed PCI P2PE solutions yet. Once the P2PE solutions listing is published on the PCI website, merchants that implement PCI approved P2PE solution will be eligible to complete special SAQ which is supposed to be “easier” than regular one.
Note: this is still only applicable to merchants that are eligible for SAQ. Others will still go through the regular QSA assessment.
5. New PCIP (PCI Professional) certification program was just launched (in September). The idea is that each organization would have PCIP-certified employees who understand the PCI and help to maintain PCI compliance. The difference between PCI ISA and PCIP is that PCI ISA is linked to specific employer while PCIP is a personal certification.
All candidates - training course and exam;
CISSP holders - only exam;
PCI ISA holders - no training or exam, can be earned automatically (I signed in already).
Visa to launch its "Visa Merchant Data Secure with Point-to-Point Encryption" in 2013:
I think this is confirming the fact that -- despite all the PCI efforts -- P2PE (whether it is PCI approved or not) is the only technology that can provide a real protection for magnetic stripe payment cards.
No more technical details are available at this time...
NFC Phone/RFID credit card hack at DefCon XX: are PCI PTS certified terminals vulnerable?
Eddie Lee demonstrated at DefCon XX how the RFID credit card data can be stolen and used to run payment transaction by replay attack with regular NFC enabled cell phone (and of course loaded with specially crafted software):
"NFCProxy is a new tool (being released at DEF CON 20) that allows you to proxy RFID transactions using Android phones. NFCProxy can record and replay RFID transactions from the perspective of the tag or the PCD (proximity coupling device). NFCProxy is an open source tool/framework that can be used to analyze 13.56?MHz RFID protocols and launch replay (and potentially man in the middle) attacks. You can even use NFCProxy as a virtual wallet by storing previously scanned RFID enabled credit cards and replaying them later at a POS (point of sale) terminal. No fancy equipment needed…just two NFC capable Android phones running ICS (one with a custom rom). Owning RFID enabled credit cards just got easier!"
I watched the presentation and it was very impressive. Personally, I don't care because I still do not have any card with RFID chip. However, according to Forbes, there are "100 million contactless credit cards currently in circulation". Pretty good market if someone decides to exploit this vulnerability.
One detail is still unclear though: what specific types of card readers and protocols versions are vulnerable? Is it some 10 years old refurbished retired device purchased on eBay that was used in the demo, or it was PCI PTS certified one which is eligible for "secure" deployment at merchants' stores? I sent this question to PCI SSC PTS group. I will try to obtain these details from the author and will keep you posted.