Merchants need to be aware of a new mobile payment solution – Square from Square Inc. A colleague pointed me to the Square site with the question, “Is this PCI compliant?”
Square appears to be a hardware/software solution for iPhones, iPads and Android devices. It has a cute, square magnetic stripe reader for swiping cards, but also appears to provide the capability to manually enter cardholder data through these devices’ virtual keyboards. This all appears to be similar to the iPhone that used to appear in the first Apple iPhone commercials that, for reasons that will become obvious, magically disappeared from their commercials very quickly and quietly. It is also why Apple no longer uses iPhones or iPod Touches in their stores to process payments.
In referencing the PCI SSC’s PTS certification database, I could not find Square’s certification for the PTS standard. Although, given the pictures on Square’s Web site, I really did not expect to find it certified to the PTS standard as there is no way it could meet the PTS standard. Has Square submitted their solution for PTS certification? It may have, but since the PCI SSC PTS certification database only lists those devices that have completed the certification process, there is no way for anyone to know if it has submitted Square until it is certified. However, since the use of PTS certified devices is a requirement of all of the card brands, until Square is PTS certified, use of a Square device for processing of credit cards violates a merchant’s merchant agreement. Game over.
While not complying with the PTS standard is a deal breaker in my opinion that is not the only PCI compliance issue. In referencing the PCI SSC’s PA-DSS certification database, I could also not find the Square software application listed. That situation was also not unexpected as the PCI SSC announced in a press release on June 24, 2011 that it was suspending the PA-DSS certification review of all mobile payment applications indefinitely. As a result, there is no way Square’s software will be PA-DSS certified for the foreseeable future whether they submitted it for PA-DSS certification or not. Not that the PA-DSS certification is a deal breaker for merchants to use the Square software, but it means that merchants using the Square software to process payments will have to have the Square software assessed to ensure it meets all of the PCI DSS requirements regarding payment applications.
And knowing what I know about all of these devices, I can guarantee that the Square software will not be PCI DSS compliant because all of these devices will store the cardholder data unencrypted for an untold amount of time until it is written over. Even if Square’s software encrypts the data, the underlying OS will also collect the data in cleartext. Forensic examinations of these devices have shown time and again that regardless of what the software vendor did, the data still existed in memory unencrypted. And that unencrypted data in memory can exist in these devices for days, weeks to even months depending on transaction volume and other applications loaded on the device. It is this surreptitious OS data collection activity, the security issues with other applications as well as other security concerns that caused the PCI SSC to suspend their PA-DSS certification activities of these applications.
There is only one solution that uses an iPhone or iPod Touch that is PTS and PA-DSS certified at this time and it is from Verifone. The reason that Verifone’s PAYware solution is certified is that: (1) Verifone submitted it for the PCI certifications prior to the June 24 suspension and, the bigger reason in my book; (2) it relies on a digital back separate from the iPhone/iPod that performs the card swipe and all of the card data processing/transmission in a secure manner. The iPhone or iPod Touch are used only as a display and cellular/Wi-Fi conduit for network connectivity.
The only other mobile payment solutions I am aware that are PTS compliant are purpose built credit card terminal using Wi-Fi or cellular communications. These are considered terminals by the PCI SSC, so their underlying software is not required to be PA-DSS certified at this time, but they are required to be PTS certified. In addition, these terminals have been in use in Europe for quite some time, so they are a proven secure solution.
The bottom line is that it is the merchant’s responsibility to ask vendors the right questions and weed out non-PCI compliant solutions. The card brands and the PCI SSC are not in the business of regulating vendors, they leave that to the marketplace.
If you are looking for a PCI compliant mobile payment solution, talk to Verifone, Equinox, Ingenico or other recognized card terminal manufacturers as those are going to be your only PCI certified mobile payment processing options at this time.
UPDATE: I have had a number of people contact me about the certification status of the Square solution based on the fact that Square Inc. is listed on Visa USA’s Web site as a PCI DSS compliant service provider. Remember, this listing only means that the card processing services provided by Square Inc. to their customers (i.e., all of the back office processing they do to process card transactions) are PCI DSS compliant, not that the devices that actually conduct the card swipe are certified PCI compliant. A certified card terminal would be PCI PTS certified and the software running on the terminal would be PA-DSS certified. The Square Inc. device that connects to iPhones and Android devices does not have that PCI PTS or PA-DSS certifications, therefore it should not be used for conducting credit card transactions.
UPDATE: Here is another solution that avoids the iPad altogether, Hubworks Interactive. I spoke with them and their QSA and this product avoids the iPad by conducting the transaction in the digital framework surrounding the iPad. The iPad is strictly used as a display and a Wi-Fi conduit. The digital framework encrypts the cardholder data before it is ever seen by the iPad just as Mark Bower suggested would work.
UPDATE: July 25, 2012 – In the July issue of Transaction Trends, page 6, there is an announcement from Square that they are offering a new loyalty program for merchants using Square Register and Pay. Let us hope it is securely implemented as I am sure Square is using a customer’s PAN for tracking based on how they describe the program.
UPDATE: August 30, 2012 – The Square Web site is now implying that the transmission of card data is secured through “industry-standard encryption,” whatever that means. There have been rumors that Square has implemented point-to-point encryption (P2PE) in their card readers but was not advertising that fact. That is why I went to this page to see what, if anything, had changed. However, based on the statements on this page, it appears that P2PE has not been implemented as you would think they would be touting that fact.
UPDATE: October 15, 2012 – A good friend of mine just started working at Square, so hopefully we can get to the bottom of how Square works and what risk there is to merchants using their solution. Stay tuned.
So now what do we do with this? Starbucks using Square for payments?
https://squareup.com/news/releases/2012/square-starbucks
Good question. I saw this news release as well this morning and wondered the same thing. There was not enough information to discern any security implications, so until we have more information, there is no way to know if their is a risk.
“Starbucks will invest $25 million in Square as part of the company’s Series D financing round”
I guess that this should help to bring anything to compliance over time. In the meantime it still means that Starbucks is not PCI Compliant. I personally don’t believe this tiny magstripe reader could in any way be able to satisfy P2PE requirements (particularly SRED) which is in fact Module 4 of the PCI PTS Standard.
Thus said, under PCI PTS 3.1 a non-PED device may still get certified only for its SRED part, so become P2PE certified. So we’ll see how Square works it out.
Starbuck’s is investing in Square because they see an opportunity to get in on the ground floor of one of the hottest startups around. They also want to leverage Square’s data, customer base, and analytics. They do not, as far as I can tell, intend to use Square’s card reader. Instead, they’ll use the “Pay with Square” mobile app. This is even better (for Starbuck’s) because they will never collect, store, or transmit cardholder data. They could potentially take themselves right out of scope of PCI! However, they’d have to stop take credit card payments altogether for that to happen. As ludicrous as that might seem, I’ll bet it comes to pass sooner than we all think.
You mention ‘the verifone’ approach. I stumbled upon an ad for Sailpay which is I think a new Verifone offering.
If you select Small Business on their site you’re taken to this solution which is a non-merchant account processing service (whatever you call what Square is offering) and it sure looks like just another plug in card reader vs a bolt on which they offer under “Larger Retailer” (so device is just for display like you mentioned).
Seems like Verifone is in the Square game now.
Square quietly introduced a point-to-point encryption (P2PE) version of their Square reader. What I cannot tell you is whether or not they are going back and replacing their original customers’ Square readers with the new one that is encrypted.
Given the heat Square and others got with their unencrypted and insecure solutions, I would find it hard to beli8eve that a company like Verifone would produce an insecure solution. But stranger things have happened.
Recently there have been articles indicating that Square has redesigned their swiper to encrypt the data going from the swiper to the phone. Does this address the issue here? Thanks -
No idea. Square needs to be assessed independently before we will know. It’s better than it was. But if I can still interact manually with the device, it may still be capturing cardholder data.
Hello PCI Guru,
I’d like to draw your attention on this : http://ilovevelvet.com/ which is definitely a working solution for the iPhone & iPad market. I have met their CEO & CTO, they are about to get certified PA-DSS, PTS v3.1 and P2PE (when it comes…) and is also EMV1&2 certified.
I think that once they get these certifications they will definitely lead the mobile market, as their solution is ahead of Verifone already.
Stephane
I seriously doubt this vendor will get a PA-DSS certification on any software that runs on the iOS platform as the moratorium is still in place for those applications. And that is part of the problem as well. One of the issues I have with Square is that they use the fact that their back office processing is certified PCI compliant as a lure to get merchants to use their POS solution which, as near as anyone can tell, is not secure. Merchants have no idea what is PCI certified compliant and what is not compliant because the vendors are tossing around their certifications like chattel.
I am not saying that there are not secure solutions out there for iOS/Android/Windows Phone/etc., it’s that it’s almost impossible for small and mid-sized merchants to know what is marketing hype and what is actual security.
The other thing that drives the marketplace on these solutions is the fantastic interchange rates that these vendors offer. It’s hard for any small to mid-sized merchant to not want to get in on these better rates. But at what cost?
It is these sorts of marketing ploys that are going to get these merchants in trouble to the point that, in the event of a breach, the card brands’ penalties and fines could put them out of business. That will obviously result in a lot of ugly lawsuits about who knew what when and the fact that these vendors traded on greed with no regard to security.
So, PayPal just announced a soon-to-be-released product to compete with Square. Unlike Square’s reader, however, PayPal’s encrypts the track data (according to their FAQ page). This is a step forward for security.
But, their app allows the user to key in a card number too, leaving a big, gaping security hole that is key logging (see early posts by PCI Guru).
Agreed that it is better than Square, but there are a number of questions that still need answers. They say its encrypted but do not specify the algorithm. Using encryption, are they using DUKPT or something else for key management? Then there is that manual PAN input. Yes, manual input should be the exception to the rule, but a release of PANs is still a relase of PANs no matter how small.
The larger issue in my opinion is the remote capture check processing solution. If you think credit card security is bad, check processing security is nonexistent. And this little gem of an application just makes me cringe even thinking about how those images are protected (probably not) and the fact that most merchants have no understanding of their responsiblities under remote capture. If large retailers cannot do remote capture securely, why would anyone think that it would work better for the small merchant?
This is just a lawsuit waiting to happen.
Somewhat tangential to this !excellent! discussion…Apple’s iTunes app on the iPhone and iPad allow users to enter/change their credit card number. Since both are mobile apps they are obviously not PA-DSS validated. So, I guess if Visa invests in your company (Square) or if you are a big enough merchant (Apple) the rules don’t apply.
It should be noted that the PCI PTS program is for devices that accept PINs for debit / EMV transactions. Devices that process signature based transactions are not submitted to or tested in the PTS program. It is true that for P2PE applications PCI recently announced a program to have non-PIN devices approved under the PTS program. This is not a requirement, it is only for those vendors that want to demonstrate the product meets the hardware security requirements for the SRED section of the PCI PTS program.
Are you implying that these iPhone/iPod/iPad/Android devices will not be allowed to process debit cards? Given the tremendous rise in the use of debit cards, I find it hard to believe that this will be the case. So, it is highly likely that PINs could be entered into these devices.
Remember, EMV has a magnetic stripe as well for compatibility with non-EMV terminals. However, when EMV is swiped, it is like any other credit card.
Since Square makes no mention of contactless technology, I am assuming that RFID is not being used, but given these devices capabilities, RFID may not be off the table for long.
You bring up signatures which raises an interesting issue. Are signatures captured on these devices? Is that better than capturing track data or PINs? Probably not.
PINs are not going to be entered on these devices. There are very specific security requirements that must be met for PIN Entry Devices. This is the purpose of the PCI PTS evaluation programs. Vendors supply PED devices into accredited labs for testing and evaluation. However, branded debit cards can be processed as “credit” with signature verification instead of PIN. Those cards could be accepted by these devices.
I also doubt that signatures are being captured on these devices. For those transactions that require a receipt, typically the card holder signs the receipt and the signature is compared to the one on the back of the card.
I think you can extend the “Merchant Beware Tag” to host of IT solutions these days, starting with many Cloud providers, ISPs, and PCI in a box vendors. Regarding Square, I believe they were on the PA-DSS list and were moved off after the council ejected all mobile apps. When this occurred, the card brands took the unusual step of suggesting that Acquirers such as Chase, could “go it alone” and support and promote this technology provided they accept the risk. The concept of simply “accepting risk” is a funny one, as it completely rips the rug out from under PCI-DSS and takes the industry back 8-10 years. I remember auditing a number of large processors under CISP and the standard response for non compliance was “We accept the risk”. It took a few years and a couple of high-profile breaches to understand that PCI was prescriptive. Also, Visa has made a direct investment in Square which suggests that there will not be any card brands(or councils) cracking down on this anytime soon. http://storefrontbacktalk.com/social-networks/new-theory-about-visas-investment-in-square-visa-really-is-after-twitter/
Thanks for the memory refresher. I had almost completely forgotten about Visa allowing merchants and service providers under the CISP to respond to requirements by saying they would “accept the risk.” I too remember a couple of very large merchants that I assessed and stated for a number of requirements that they would “accept the risk.” One was put out of business due to a huge, but largely hushed up, breach with their e-Commerce site a year or two later.
I have talked to some people since my original posting. They have told me that it was their understanding that Square had submitted their PA-DSS ROV but that it was in the PCI SSC review process at the time the Council decided to back off on certifying mobile applications.
Regardless, given how iPhone/iPad/Android devices work, you have to wonder how the forensic examination of the device for PTS certification resulted in no cardholder data being found in the device. All of the vendors that I have spoken with that have iPhone-based POS solutions have told me that the reason they had to create a digital back was because they could not get around the keyboard logging and other applications that collect user information. One forensic examiner told me that rooting Android devices was no guarantee of ridding the device of its “bad habits.” As a result, without a digital back approach, I just do not see a way to make any of these solutions PTS compliant.
Square is the merchant of record, so apparently the risk is on their shoulders. They transfer the money directly into the business owner’s account. The business owner does not set up an account with any processor other than Square. Think “Paypal” but different. Instead of the merchant paying 3% to paypal, they pay 2.75% and have the ability to swipe a card instead of punching numbers into a screen.
According to their website:
Square’s software is developed using industry standard security best practices.
•Card processing applications adhere to PCI Data Security Standard (PCI-DSS) Level 1.
•Square prohibits the storage of card numbers, magnetic stripe data and security codes on client devices.
•Applications developed in-house are subject to strict quality testing and security review.
•Web development follows industry-standard secure coding guidelines, such as those recommended by OWASP.
All of what you quote relates to Square’s in-house applications related to the processing of the card transactions received from the iPhone/iPad/Android devices and not the software on the devices generating the transactions. I thought the same thing as you did until I went back and re-read their statements. You have to read their pronouncements very, very carefully because while they are legally accurate, they do not extend to the software on the devices. Everything is written to relate to the processing of transactions they receive from those devices. Nasty!
The result is that laymen will imply that their statements extend to the iPhone/iPad/Andrid devices displayed on their Web site. What supports this is the fact that the device displayed on Square’s Web site is not PTS certified nor is the software running the device PA-DSS certified.
I’m guessing this is just a sophisticated marketing scheme to drive people to process transactions through them, but not fully informing the merchants that their iPhone/iPad/Android device is technically not a legal way to conduct the transaction. Pretty slick and a bit warped because the unfortunate aspect about this is there are likely a lot of small merchants that are doing something that will bankrupt them if they have a breach because the card brands and Square will be the ones that will hold them accountable and Square will walk away with possibly a hand slap if anything at all.
Don’t you think merchants using Square are not concerned about PCI or a Merchant Agreement at all? In Square’s model – the merchant maintains no direct agreement with the payment card industry and thus cannot be held to ANY card industry usage rules (including PCI) – the only agreement is between the merchant and Square for a flat 2.75%.
I would agree. I am sure these are very small merchants more interested in the relatively inexpensive interchange rate. Not that these merchants are not interested in protecting cardholder data, but I am sure they believe that they will not be a target and it will not cause them a big problem if a breach occurs.
However, there has to be some sort of merchant agreement in place because Square, as a service provider, is required to have a merchant agreement with the merchants they service. That agreement must incorporate a reference to the card brands’ merchant requirements, operating procedures and compliance with the PCI standards. If Square is not following that process, then they are also operating illegally. Given how slick their Web site is written, I would bet that Square follows everything to the letter, but they do not educate or inform their merchants about what the merchants are getting into by accepting credit cards for payment. As a result, Square creates a situation where they can walk away without any consequences but make a fortune.
Simple solution: Square needs to have a P2PE solution in place in its reader per the forthcoming validation requirements. If Square embraces P2PE, the concerns and issues are largely removed. Take the data out of the mobile app altogether with a well implemented P2PE approach. The PCI SSC is already down the path with standards in this area agnostic of its its mobile, desktop, a USB card swipe, a card wedge or an audio jack.
Others have already.
Regards,
Mark Bower
Voltage Security
Disclaimer:my company provides P2PE technology and solutions used by acquirers and payment vendors – some mentioned in the article.
P2PE may not be the solution either. iOS, Android, Windows Phone 7, et.al. all have very un-PC like APIs that cause more problems than they solve. In order for P2PE to work right, it would have to bypass a number of builtin applications such as the keyboard loggers, GPS, etc. that the vendors do not allow to be disabled because applications are not granted that kind of access and authority. According to developers I have spoken with, there are no workarounds for these issues. That is the problem with these devices, they are not as adaptable as their PC brethren where you can program around things or wholly replace a vendor “widget” with your own “widget”. It is my understanding that this is why Verifone developed their PAYware solution on their own internally engineered digital back so that they had control over the operating environment at a level that allowed them to have control of security and what executed, when, where and how.
Even if you solve the software side of the problem, then you still have the PTS compliance issues that are an even bigger set of problems that are not readily solved. The largest of which is the keyboard loggers that record anything typed into the screen or swiped through the magnetic stripe reader.
At the end of the day, you begin to see why the PCI SSC took a giant step backward to think this through and come up with a, hopefully, better solution to certifying these devices and their software. However, until developers can address the internal security and privacy issues of the devices’ OSes, I find it hard to believe that anything other than a Verifone type of approach will be certifiable.
In respect to the above, I was referring to P2PE in a reader device, not on the phone OS or App level – P2PE as defined by the council today implies encryption is taking place in a separate device. So, if the data is encrypted in the reader device before it hits the app, then the app is not dealing with cardholder data. Manual entry may still be an issue unless that is captured directly of course – but for devices like square its about the swipe. Critical of course is the key management – use of a secure device- that’s the point of P2PE – operations take place within an SCD – Secure Cryptographic Device. The boundary where clear data – other than the analog magnetic signal is – is the SCD, not the system it is attached to. We already do this today with our hardware partners in the brick and mortar world to eliminate clear data arriving on the POS, store controlled, upstream systems and so on until the data gets to the acquirer.
There are many more devices out there than Verifones. Some of them pre-date by more than 10-15 years. back then I product managed the Keycorp K78 – the worlds first removable GSM phone based multi-function, multi region E-POS device which was on the market in 2000 and conceived in 1997 – a device which provided a POS in the hand using a GSM phone – well ahead of its time. Since this was designed to work in Australia to AS2805, the cardholder data was encrypted using DES inside a secure processor – so whilst this pre-dated PCI DSS by a long shot, it was already a step ahead of most systems today – the phone would never see the card data ever.
http://www.designawards.com.au/application_detail.jsp?status=2&applicationID=2978
Thank you for the clarification. One can easily forget how intelligent parts of devices can get these days. In going back to Square’s Web site though, I see nothing there that would indicate that this has been implemented. So my concern would be that the iPhone/iPad/Android devices are still coming into contact with the cardholder data stream.
However, P2PE still does not address the keyboard logger issue with these devices. If a customer uses a debit or EMV card, even if the wedge encrypts the track/chip data, the PIN would still have to be entered through the display and the device’s OS would capture the PIN unencrypted and violate the PTS standard. This was the question I had for the Verifone folks about PAYware and I never really got an answer. My guess is that debit/EMV transactions would not be done through PAYware.
Your comment does create a new threat for devices such as the “Square.” How does one secure the “Square” which, in your example, would have all of the security? It’s not like the serialized security tape approach that merchants use on their traditional terminals is going to work. This is obviously a little device that attaches to the audio port of the iPhone/iPad/Android and could be easily swapped out by an attacker for a “Square” that also captured track data and forwarded it on to wherever. Given the merchants that the “Square” is focused, the likelihood of this happening is fairly high and not out of line with the way some criminal gangs have lately operated. The most obvious approach, in my opinion, would be to use MAC addressing or something similar to tie the “Square” to the iPhone/iPad/Android so that a swap of a “Square” would result in the device becoming inoperative and require a call to support to correct.
In response to PCI Guru’s 9 Dec 2011 comment “How does one secure the “Square”?”
The envisaged threat here is that somebody will replace a ‘legitimate’ Square with a ‘hacker’ Square. Let’s assume that P2PE input devices are manufactured correctly, and use a sensible key management approach such as DUKPT. Isn’t it then impossible for a ‘hacker’ Square to be inserted to fool the merchant? In order for this to work, the ‘hacker’ Square would need to contain the same key, serial number, transaction number etc as the original. That is practically impossible to achieve. And therefore, when the merchant attempts the first transaction with the ‘hacker’ Square reader, it would fail. Merchant would then call up Square Inc, get another Square reader sent out, and the problem disappears.
Or is this too simplistic?
Emma.
The problem is the iPhone/iPad/Android/etc. not the Square. iOS/Android/Windows Phone/etc. all have inherent issues of recording all data they come into contact, including cardholder data input through the Square device. So the cardholder data at risk is in the host device, not the Square. And this is not something that can be fixed. According to mobile device application developers I have spoken with, iOS/Android/Windows phone/etc. do not allow developers access to the data recording feature to disable it. So the device is always recording the data.
This is why police and computer forensic examiners love criminals who have smartphones. The criminal’s smartphones record everything about everything including location and time when the something occurred. Think an airplane “black box” for people.
To fix things, I would agree with using some sort of MAC address like identification plus the Square would have to act independently of the host device and ensure that it encrypts its cardholder datastream before it comes into contact with the host device. This is the approach Verifone took with their PAYware solution that is PCI compliant.
Hi PCI Guru,
Whilst I agree with everything you’ve said about the insecurity of the mobile devices themselves, as Mark Bower said above, with proper P2PE the encryption happens onboard the card reader itself. The mobile device, in this case, would not see any plaintext card data.
Emma.
Agreed. But it is my understanding that is not how the Square solution works, nor do any other iPhone/iPad/Windows Phone/etc. solutions other than those that have taken the Verifone approach which only uses the devices as a display and an entirely separate device securely handles the transaction.
This is the larger problem. Merchants see a solution such as Square and gravitate to it because why would anyone develop, let alone be allowed to develop and market, a solution that would put them at risk? The PCI SSC and the card brands have responded and said it is not their job to be solution policemen, only to deem solutions PCI compliant when presented to them.
Better yet, why would Visa USA invest in a non-PCI compliant solution? I see this as the right hand (marketing and management) not knowing what the left hand (PCI compliance) is doing.
And, to add insult to injury, why would Visa USA list Square as a PCI certified service provider if their solution was not PCI compliant? This is purely an operational issue in that Visa USA only lists service providers that process the transactions, not the complete solution. The merchant side is covered by the PCI PTS and PA-DSS and PCI DSS. However, merchants are not educated to see it that way.
All of this causes confusion out in the merchant world and no one does anything to explain it, certainly not the PCI SSC and the card brands.
I’m not entirely sure the “Payware Mobile” sold through the app store, and the associated small business version of card swiper is fully PCI compliant.
I’m wondering if it’s just their enterprise edition because that one has its own separate pin pad, a larger card swiper unit, and comes bundled with a dedicated iPhone.