Google Wallet and the Edge of PCI’s Regulatory Map

Wednesday, December 14, 2011

Ed Moyle


Google Wallet, cardholder data, and the edge of PCI’s regulatory map?

So today we have some excellent coverage via the always-interesting Mocana DeviceLine blog (have I blog-rolled them enough do you think?) covering a technical deep-dive on Google Wallet from ViaForensics.  An interesting read.

According to their inquiry of how Google Wallet works, they've determined that there's some scary data stored cleartext on the phone, including:

  • Card type and last 4
  • Card holder name
  • Current balance
  • Available to spend
  • Statement balance
  • Payment due date
  • Citi contact number


Well, that's interesting. Folks might object to this kind of data being stored in cleartext within Google Wallet (I sure do), but I'd like to point out that the problem isn't so much Google Wallet (although, guys... really?  Statement Balance?  Really?) but instead the fact that mobile devices are blurring the lines between what's a payment application vs. what's not.

You see, right now, shy of actually storing the whole credit card number, there's not really much guidance on what is or is not acceptable here from a protection standpoint.  

Technically, Google Wallet falls into what the standards council has defined as a "Category 3 Payment Acceptance Application."  What is a Category 3 mobile payment acceptance application, you ask? Per the council:

Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet, or PDA) that is not solely dedicated to payment acceptance for transaction processing.

Sounds like Google Wallet, amirite?  

So how do you validate such an application?  For example say Google wants to do the right thing and have someone review their app to avoid these kinds of shenanigans... to ensure that the security of the application is consistent with the defined requirements of PCI?  Short answer: you can't.

Longer answer --  from the council:

The PCI SSC recommends that mobile payment acceptance applications that fit into Category 3—and are thus not eligible for PA-DSS validation at this time but are intended for use in the cardholder data environment—are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance.

OK, so you can't validate it.  They recommend that you maybe skim through the PA-DSS to check out how to protect cardholder data from an application standpoint, but it's discretionary... So what is the oversight for these apps? Who's responsible?  

From the same document:

Applications used for payment-initiation—for example, those downloaded by consumers onto their mobile phones and used for consumers’ personal shopping—are seen as similar to the payment card in a consumer’s wallet. The Council’s purview does not currently extend to, nor is PA-DSS applicable to, consumer-facing mobile payment initiation applications.

And there you have it.  My reading of this is that -- at least currently -- the expectation that we should have for security of "consumer-facing mobile payment initiation applications" is the goose-egg.  

In other words, Google didn't cross a regulatory boundary.  One might argue that there should be a regulatory boundary here... but if there is, I can't find it.

Anybody disagree?  Would love to hear from a PA-QSA on this.

Cross-posted from: Security Curve Weblog 

Image source:

Possibly Related Articles:
Information Security
Encryption PCI DSS Compliance Regulation QSA PCI SSC Google Wallet
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.