This week PayPal introduced Here, their mobile payment processing application for Apple iOS and Android devices. The good news is that PayPal Here at least appears to encrypt cardholder data, but that appears to be the extent of the good news.
If you pay attention to the latest Suzie’s Lemonade Verizon Wireless advertisement, you will see Intuit’s GoPayment solution on a tablet computer processing a payment. In another bit of good news, the Intuit GoPayment solution is also encrypted.
But what is most disconcerting is that this is just another in a string of mobile payment processing solutions to be introduced with no way of knowing whether or not the security claims are accurate or can even be trusted. This is because the PCI Security Standards Council halted last year the certification of any of these mobile payment processing solutions through the PIN Transaction Security (PTS) and Payment Application Data Security Standard (PA-DSS). Do not get me wrong, the Council was in a tough spot and did not have a plan as to how to deal with these solutions, so the called a halt while they went back and reassessed things.
However the marketplace is not waiting. So while the marketplace continues to deliver solutions, the merchant is left to their own devices to know whether any of these mobile payment processing solutions can be trusted. And what I am fearful of is that small merchants, who are the marketing target of these solutions, will be put out of business should the device somehow be compromised or they lose a device.
So what are the questions surrounding the PayPal Here?
First, what is the encryption algorithm that is used? I am guessing that they are using DUKPT, as that is common with these sorts of devices, but it is something that should be explicitly identified in their FAQ. What PayPal currently says is, “… the PayPal Here card reader is encrypted and is backed by over a dozen years of experience of providing buyers and sellers the highest levels of security.” If they are using DUKPT, can the key be changed? Most of the mobile solutions I have seen do not allow for the key change under DUKPT which could be a problem.
Then there is the fact that you can manually enter a cardholder’s information through the iOS/Android application. Given the fact that these systems are notorious for having keyboard loggers of industrial strength that means that any manual input will be recorded in the device. I am guessing that would include cardholder name, PAN and expiration date. However, if PayPal Here collects the CVV/CVC/CID value in manual entry that would be an extremely bad thing as the device will retain that until it overwrites it months later. Again, there is no documentation to determine what is allowed to be manually entered, so we cannot assess how much risk this might introduce.
But the scariest feature of the PayPal Here is unrelated to credit cards; it is the remote capture of checks. PayPal Here allows the merchant to scan a check and then submit it to their financial institution. Again, given the data retention of these devices, I can only guess that the check images processed through the PayPal Here application will remain on the device until the space is needed which could be months. The problem with all of this is that if people think credit card security was questionable, check processing security is nonexistent. As a result, anyone with a modicum of knowledge could use the check information on one of these devices to drain every bank account stored.
Let us hope that the PCI Security Standards Council and the card brands quickly get back to certifying these applications so that merchants are not using insecure payment solutions.
All of the above refers to a POS scenarios where the cardmember data is captured by the merchant’s mobile device. In cases where the card number is keyed onto the device, certainly it can be captured by a key logger, but this threat also exists on the web. While it is a risk, it cannot be mitigated by any PCI standard short of prohibiting keyed entry of any type on any device. However, that would virtually cease all eCommerce as it would require that each consumer own a swipe machine to encrypt data being entered into a device.
Since the Xpress-pay Mobile solution from Systems East, Inc., is a web-based consumer-facing product, the card or bank account number never reaches the merchant, eliminating the exposure of the information and thus vastly reducing risk. Further, with an Xpress-pay account, the cardmember only types in each card number (or bank account for eChecks) once, and it then it is stored on PCI-compliant servers, not the device. This eliminates future opportunities for malicious capturing of information.
It seems to me that the so-called “mobile” payment solutions being presented by companies are no more than a traditional POS on a smaller screen. That’s why it is up to innovators like us to provide consumers with a true solution within the payment infrastructure available today. Contact me for more information if you’d like to discuss this further.
Thomas
Systems East, Inc.
All of the above refer to POS systems where the cardmember data is captured by the merchant’s mobile device. In cases where the card number is keyed onto the device, certainly it can be captured by a key logger, but this threat also exists on the web. While it is a common risk, it cannot be mitigated by any PCI standard short of prohibiting keyed entry of any type on any device.
Since the Xpress-pay mobile solution from Systems East, Inc., is a web-based consumer product, the card or bank account number never reaches the merchant, eliminating the exposure of the information and thus vastly reducing risk. Further, with an Xpress-pay account, the cardmember only types each card number (or bank account for eChecks) once, and it then it is stored on PCI-compliant servers, not the device. This eliminates future opportunities for malicious capturing of information. Contact me for more information if you like.
Nick V….
Xpress-pay.com
Systems East, Inc.
DUKPT is not an encryption algorithm, its a scheme for managing keys. You should consider revising your comments in this area.
I would suggest that generally, when people reference DUKPT, they are referring to ANSI X9.24 DUKPT (which does not necessarily need to be the case, but is in 99% of the cases when people use this term). This reference is then to a specific method of performing key management that is compliant to the requirements outlined in the rest of ANSI X9.24, that also specifies the use of TDES (the use of single DES was outlined in previous versions).
So, you are correct that DUKPT is not an encryption algorithm, but if you know that they use DUKPT you know both the key management and the algorithm that is used. Some people do use DUKPT to generate keys for algorithms other than (T)DES, but that is no longer ANSI X9.24 DUKPT – as this specifies the use of these algorithms only.
Of course, now we have a specified format for AES encrypted PIN blocks (yay for ISO format 4!), that opens the door for key management schemes that are specified for PIN blocks to be extended to allow AES to be used, but I do not believe that this is yet the case for DUKPT (please correct me if I am wrong in this regard).
When Will The PCI SSC And Card Brands Stop The Mobile Payment Insanity? I’d ask a different question. When Will The PCI SSC amend its mission to STOP FRAUD and not just “proactively protect customer account data”? The data they want to protect is already published for the world to see. It’s static and “in-the-clear” on the front and back of the cards issued to consumers by almost every card issuer in the world. Anyone with a few brain cells and access to Google and eBay can easily acquire the knowledge to build/modify/purchase their own reader to capture a card’s static data and use it for fraudulent purposes, like a Card Not Present Internet transaction or to create a counterfeit card to replicate a Card Present transaction.
PCI’s mandates for encryption cannot stop these threat vectors. So why does anyone think that having certified readers will really solve the problem? How can a consumer tell the difference between a PCI Compliant Device and a Non-compliant device? Are they going to check the PCI web-site prior to swiping, inserting or tapping their card? As long as the “human-factor” plays into the overall transaction process/security, the bad guys will find a way to easily exploit the certification process.
Consider this…Create a counterfeit card with the stolen data gathered by one of these non-PCI compliant devices and then use that card at a merchant who has a fully protected PCI certified system using all of the latest E2EE, SRED, and PTS standards and what will those technologies/standards do for that merchant to STOP the fraud?–NOTHING!
Encryption is but one layer of security and anyone who thinks the PCI SSC getting into the business of certifying everything under the sun at considerable time and cost to the manufacturers and businesses who ultimately pay into the “cottage industry” created by the PCI SSC, is a victim of a massive scam perpetrated by the card brands, the PCI SSC and the issuers who continue to allow static, clear-text card data to be placed on every card issued and then used for authorization purposes. A system using some form of Transaction Authentication is what is required to solve these problems. Where is the PCI SSC on this subject?
Let’s not kid ourselves or any of the readers of this blog to think the “insanity” is coming from those getting into the business of Mobile Payments (hardware or software). The “insanity” is coming from the PCI SSC, its five founders and together, their collusion so they can deflect the responsibility onto the merchants for protecting the static data that is revealed at the moment the cards are issued to consumers and physically accepted by merchants. It is insane to suggest that consumers and merchants benefit from anything the PCI SSC does when the bad guys don’t play by the same rules and they can easily steal the data from the card in spite of PCI certified devices being used by merchants.
Fraud is like a water balloon. You can squeeze it with protective measures like encryption, but it just moves around where there is no pressure to stop it. If the bad guys can’t steal it from the merchants because their terminals encrypt the data, they will find other ways to socially engineer the information away from the consumer because the customer account data is already “in-the-clear” on their card. Once the bad guys have the customer account data, they can then use that data to commit fraud. As an industry, we should aim to STOP the fraud. If we allow ourselves to be misled by insane mandates that do nothing to stop fraud and only provide a false sense of security to those that “foot the bill”, then why would anyone want to follow the PCI SCC down the rabbit hole?
If we want to stop the fraud, we MUST find ways to stop the theft of customer account data. Encryption cannot stop theft of customer account data, but I will agree that it can make it more difficult to steal. However, that is not enough deterrence for the bad guys. The ONLY practical way to stop the theft of customer account data is by eliminating its redemption value and thereby removing the incentive to steal it in the first place. The ONLY practical way to remove the incentive to steal it is to make the data dynamic. Dynamic data is only good for one transaction in time and it cannot be re-used. Moreover, the next transaction will rely on different data that cannot be predicted. Transaction Authentication goes far beyond encryption and delivers real value to those looking to solve the problem of fraud. I find it troubling that the PCI SSC has no apparent interest in soving the fraud problem. After all, if they did that, then why would they need to exist at all?
To clarify, PCI does not prevent a device like this from being evaluated and approved to PCI PTS. It would be certified as an ‘SCR’, or Secure Card Reader, and as long as it encrypts and has all of it’s security in line, then there’s no problem with this. I’d be more than happy to help PayPal out on this
For PA DSS: Yes, a solution like this can’t be certified at the moment. If they didn’t have any manual card data entry modes, it would be an interesting discussion to have that it may be OK if the HERE device was PTS approved and the PA DSS application was listed with that device as a required peripheral to function in a compliant mode.
It’s interesting that PayPal did not certify under the SCR portion of the PTS. Just another question that should be answered.
At our Community meeting last year, GM Bob Russo indicated that mobile payments were not going to be certified under ANY of the PCI standards, not just the PA-DSS. I thought that was kind of odd, but that is how he portrayed their decision.