Good news for anyone considering using Google Wallet. Google Wallet encrypts the PAN and only stores the last four digits of the PAN in clear-text according to a forensic assessment conducted by ViaForensics. The other piece of good news from ViaForensic’s examination was that drive by attacks against Wi-Fi or near field communications (NFC) to intercept Google Wallet communications appear to fail.
Based on ViaForensic’s analysis, it appears that Google Wallet would likely comply with the PA-DSS. The full PAN is encrypted and communication of the PAN via Wi-Fi or NFC is secured. Granted there are a lot of other PA-DSS requirements that we do not have a window into that may or may not be PA-DSS compliant. But on the whole, I would have to believe that Google Wallet would be PA-DSS certified. So, why is Google Wallet not PA-DSS certified?
First and foremost, in the eyes of the PCI SCC and the card brands, Google Wallet and similar applications are storing pre-authorization data and are just an electronic representation of someone’s traditional wallet. The PCI SSC does not certify traditional wallets, so why would they certify electronic wallets? As a result, the PA-DSS does not apply. Should Google and other vendors of electronic wallets ensure the security of cardholder data? No doubt about it.
But a more important reason that the PCI SSC is backing away from certification is related to the other findings in ViaForensic’s report. Their analysis also uncovered some not so good news in that Google Wallet stores a lot of personally identifiable information (PII) unencrypted. This PII includes such information as cardholder name, expiration date, credit limit and account balance. I think most people would now start to understand why the PCI SSC backed away from certifying such applications.
The PCI SSC does not want to be on the hook for the unsecured PII. If the PCI SSC were to certify Google Wallet as PA-DSS compliant, I am sure their lawyers informed them that such a certification would drag them into lawsuits involving the exposure of the unsecured PII even though the PA-DSS does not cover PII outside of the PAN. Their lawyers probably advised them that a PA-DSS certification would likely imply to users of these electronic wallet applications that their PII was included in the PA-DSS certification. As a result, the PCI SSC and card brands would likely have to launch a massive and costly educational campaign to explain to the public that the PA-DSS certification was only related to protection of a cardholder’s PAN and nothing else. And even with such a campaign, the PCI SSC would likely still get dragged into lawsuits over peoples’ PII being exposed.
And the likelihood of such lawsuits is very high. Smartphones are regularly lost and the security protecting them is almost non-existent, if security is even enabled. A hacker can easily take a lost smartphone and obtain enough information to perform identity theft. Hackers could even decrypt the PAN given the high likelihood that the PIN to decrypt the PAN could be derived from other information on the smartphone. The nightmare scenario would be development of malware delivered through the smartphone’s application store that harvests the PII.
At the end of the day, there is just too much risk involved in certifying such applications because there is just no way to manage the risk. So those of you thinking the PCI SSC should certify these applications need to rethink your position.
FYI This is my 200th post. I never guessed that this blog would last this long and I want to take this time to thank all of you for keeping this going.
Thank you for keeping us updated and taking time to answer your reader’s questions.
Happy holidays!
Congratulations on 200 posts. You have some great things to say keep it up!
A few things….
a) What does Google Wallet do about the CV2? It’s strictly forbidden to store the CV2 post-auth, but what about if this is just, as you say, an electronic representation of a person’s actual card?
b) And if the CV2 is not stored, how does Google Wallet (and Google’s ultimate merchant) handle the possible different acquiring charges based on whether the CV2 is present or not?
c) Is there any evidence that the PCI SSC has been involved with Google Wallet _at all_? Surely it’s Google’s choice whether they opt to apply for PA DSS certification or not, given the vagueries around the definitions you’ve mentioned above. When you say “…PCI SSC is backing away from certification…”, maybe they have never been asked to certify in the first place?
Emma.
PS Happy anniversary
From the screen shots in ViaForensics’ posting on their Web site it does appear that CVV/CVC/CID is stored. Since this is considered pre-authorization data, there is no restriction on its storage other than the card brands have advised it should be protected with the same voracity as with the PAN. This is no different than someone carrying a credit card in their traditional wallet that would also have CVV/CVC/CID printed or embossed on the card. Since there is no mention of CVV/CVC/CID in ViaForensics’ data store analysis, one has to assume that it is stored encrypted like the PAN.
I am not aware of any input from the PCI SSC or the card brands regarding the design and functionality for Google Wallet or any other eWallet program. I do know that at this year’s Community Meeting in Phoenix that the topic of eWallet applications was brought up and there was a definitive statement made that these applications would not be certified.
Thanks PCI Guru
Hi again PCI Guru,
Google Wallet has now incorporated the (ex) Google Checkout functionality. This now allows you to register card details online (i.e. not storing them in your phone). That means they have a store of many PAN and CV2 details in one place, online. For each individual, the data may constitute pre-auth data, but what’s your view on mass storage of PANs and CV2s? (This is, I think you’ll agree, subtly but importantly different to an individual storing their own card details in their own phone.)
Emma.
According to the PCI SSC and the card brands, “wallet” programs are not covered under the PCI standards just as company credit card information stored in a corporate database are not covered under the PCI standards.
That said, the card brands have always been very clear that this data should be protected the same as post authorization data, but it is not in-scope for PCI assessment purposes. I would point any “wallet” program developers to the PA-DSS and encourage them to follow that standard when developing their solutions even though they cannot certify their program to that standard.
Thanks