Android Pay and Custom ROM

[niteh@wk]

Google is giving root/custom AOSP ROM users the finger on AP. How is AP ever gonna take off with these restrictions. They initially did similar with Wallet, that didn't go so well. So they introduced HCE (host card emulation), it was working perfectly. Now they messed up again.

Sent from my Nexus 5 using Tapatalk

 

[Joshmccullough]

Google is giving root/custom AOSP ROM users the finger on AP. How is AP ever gonna take off with these restrictions. They initially did similar with Wallet, that didn't go so well. So they introduced HCE (host card emulation), it was working perfectly. Now they messed up again.

Sent from my Nexus 5 using Tapatalk

Agreed. If they want adoption to take off, maybe making it accessible to the earliest of adopters would be a good idea. For a company that's made its fortune off advertising, they did a horrible job of advertising Google Wallet to begin with. I'm constantly explaining what the Google Wallet card is to restaurant staff, people at stores, etc.

 

[WhosAsking]

Google is giving root/custom AOSP ROM users the finger on AP. How is AP ever gonna take off with these restrictions. They initially did similar with Wallet, that didn't go so well. So they introduced HCE (host card emulation), it was working perfectly. Now they messed up again.

Sent from my Nexus 5 using Tapatalk

Just my two cents, but perhaps Google didn't have a choice in the matter. Remember that new PCI-DSS rules go into effect in October, which among other things requires the enabling of CHIP cards (which are intended to block replay attacks in a similar manner to how NFC transactions work). Given the fact that the banks now have a say in whether or not a card is accepted into Android Pay, perhaps Google is required by these new PCI-DSS standards to include higher degrees of security or face fines and possible legal penalties should they be sued. This may also be why Android Pay was split off of Google Wallet: Android Pay includes all the mandated stuff.

 

[iamxaq]

My experiments

So this is what I have discovered on my Nexus 5 (using Cataclysm) regarding Android Pay.

-will not work at all if xposed is installed
-yes, unrooting via SuperSU allows the entrance of a card, however...
------if the phone has been rooted at any point following the entrance of the card, it will no longer work to pay at a terminal
-----------this holds even if you unroot before you pay; you have to unroot, add card, and pay without having ever rooted while the card was registered to your phone

No workarounds, apps, or xposed modules have had any success in my experience. Basically, they broke Android Pay for power users in much the same way Google Wallet was initially broken. Hopefully they'll fix it. Maybe not. I enjoy paying with my phone, particularly at vending machines, but I am at a place where I can no longer do so.

 

[WillJitsu]

So this is what I have discovered on my Nexus 5 (using Cataclysm) regarding Android Pay.

-will not work at all if xposed is installed
-yes, unrooting via SuperSU allows the entrance of a card, however...
------if the phone has been rooted at any point following the entrance of the card, it will no longer work to pay at a terminal
-----------this holds even if you unroot before you pay; you have to unroot, add card, and pay without having ever rooted while the card was registered to your phone

No workarounds, apps, or xposed modules have had any success in my experience. Basically, they broke Android Pay for power users in much the same way Google Wallet was initially broken. Hopefully they'll fix it. Maybe not. I enjoy paying with my phone, particularly at vending machines, but I am at a place where I can no longer do so.

Good info. Thanks!

I am also running Cataclysm on my Nexus 5. I was able to add my cards by un-rooting via SuperSU. However, I was not able to make a payment because I had re-rooted (re-checked the box in SuperSU). I also found that un-rooting just before making the payment did not work. It's good to see that it would have worked if I had never re-rooted after adding the card. Hopefully Google makes some changes regarding rooted devices, or the community figures out a workaround.

 

[iamxaq]

Good info. Thanks!

I am also running Cataclysm on my Nexus 5. I was able to add my cards by un-rooting via SuperSU. However, I was not able to make a payment because I had re-rooted (re-checked the box in SuperSU). I also found that un-rooting just before making the payment did not work. It's good to see that it would have worked if I had never re-rooted after adding the card. Hopefully Google makes some changes regarding rooted devices, or the community figures out a workaround.

I'm lucky in that we have a vending machine at my internship that sells bottles of soda for $1.10, so if I randomly buy a bottle of soda, no big deal, and if my experiments didn't work, no big deal. But yeah. I can't use AP now because there are too many things with Tasker, AutoApps, and GMD Gestures that I use that need root. I honestly don't understand how someone could use a phone without root, I am so used to those things.

 

[Joshmccullough]

Just my two cents, but perhaps Google didn't have a choice in the matter. Remember that new PCI-DSS rules go into effect in October, which among other things requires the enabling of CHIP cards (which are intended to block replay attacks in a similar manner to how NFC transactions work). Given the fact that the banks now have a say in whether or not a card is accepted into Android Pay, perhaps Google is required by these new PCI-DSS standards to include higher degrees of security or face fines and possible legal penalties should they be sued. This may also be why Android Pay was split off of Google Wallet: Android Pay includes all the mandated stuff.

Good point, never considered all of that.....

I'm lucky in that we have a vending machine at my internship that sells bottles of soda for $1.10, so if I randomly buy a bottle of soda, no big deal, and if my experiments didn't work, no big deal. But yeah. I can't use AP now because there are too many things with Tasker, AutoApps, and GMD Gestures that I use that need root. I honestly don't understand how someone could use a phone without root, I am so used to those things.

You're definitely lucky, I couldn't tell you the last place I saw a bottle of soda for $1.10!

 

[dcwiker05]

Good point, never considered all of that.....



You're definitely lucky, I couldn't tell you the last place I saw a bottle of soda for $1.10!

My work has them for a buck! I was shocked lol.

Sent from my LG-H811 using Tapatalk

 

[gakio12]

I'm not using a nexus 5, but this came up in Google, so why not. I have the nexus 6 and I unrooted through superSU before adding the card and never rooted again. Payments worked fine, but today (week later) I decided to reenable root through the app and try paying. It actually went through at a vending machine WITH root enabled, I only had adblock plus running as root, but it worked none-the-less. I'm running the stock rom image with corresponding bootloader and radio IMG, but custom recovery and kernel, unlocked bootloader.

 

[adeptustech]

Sounds pretty darn tough to bypass.

Sent from my Nexus 5 using Tapatalk

But not impossible. If anyone wants to take the challenge I'll be happy to do any testing from any ROM you wish.

 

[DAVe3283]

So this is what I have discovered on my Nexus 5 (using Cataclysm) regarding Android Pay. ...(snip useful info)

... I have the nexus 6 and I unrooted through superSU before adding the card and never rooted again. Payments worked fine, but today (week later) I decided to reenable root through the app and try paying. It actually went through at a vending machine WITH root enabled, I only had adblock plus running as root, but it worked none-the-less. I'm running the stock rom image with corresponding bootloader and radio IMG, but custom recovery and kernel, unlocked bootloader.

What is the SELINUX state on your guys phone? Permissive or enforcing?

I'm on a Nexus 5 with CM12.1, and the kernel I'm running has SELINUX set to permissive. Even unrooting with SuperSU, I can't get a card added. I'm wondering if SELINUX state is another factor it looks at?

 

[ariesgodofwar]

So this is what I have discovered on my Nexus 5 (using Cataclysm) regarding Android Pay.

-will not work at all if xposed is installed
-yes, unrooting via SuperSU allows the entrance of a card, however...
------if the phone has been rooted at any point following the entrance of the card, it will no longer work to pay at a terminal
-----------this holds even if you unroot before you pay; you have to unroot, add card, and pay without having ever rooted while the card was registered to your phone

No workarounds, apps, or xposed modules have had any success in my experience. Basically, they broke Android Pay for power users in much the same way Google Wallet was initially broken. Hopefully they'll fix it. Maybe not. I enjoy paying with my phone, particularly at vending machines, but I am at a place where I can no longer do so.

Just wanted to say that this was exactly my experience as well.

 

[gakio12]

What is the SELINUX state on your guys phone? Permissive or enforcing?

I'm on a Nexus 5 with CM12.1, and the kernel I'm running has SELINUX set to permissive. Even unrooting with SuperSU, I can't get a card added. I'm wondering if SELINUX state is another factor it looks at?

You won't be able to add a card if you are running a custom rom from aosp, at least, I haven't been able to. Also SELinux must be enforcing.

 

[Evo_Shift]

I know changing the dpi in your build.prop makes it so I couldn't add a card on my nexus 5. I am sure that's been stated before but just throwing it out there. I can't stand Google's kindergarten size icons so I am not willing to use the stock dpi (nor am I willing to give up root) which means I don't use Android Pay even though I used Google Wallet tap to pay just fine.

 

[jasondclinton_google]

Agreed. If they want adoption to take off, maybe making it accessible to the earliest of adopters would be a good idea.

Hey Josh,

Android users who root their devices are among our most ardent fans and when this group speaks, we listen. A few of us around Google have been listening to threads like this one and we know that you're disappointed in us. I'm a security engineer who works on Android Pay and so this thread struck me particularly hard. I wanted to reach out to you all and tell you that we hear you.

Google is absolutely committed to keeping Android open and that means encouraging developer builds. While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact.

That "ensuring" is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and--by proxy--real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite--which includes checks for the security model.

The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases. I know that many of you are experts and power users but it is important to note that we don’t really have a good way to articulate the security nuances of a particular developer device to the entire payments ecosystem or to determine whether you personally might have taken particular countermeasures against attacks--indeed many would not have.

Let's keep the dialogue open: I'll be monitoring this and other threads for constructive ideas. I won't be able to reply to all messages but we will keep listening. We love our community and we want you to keep challenging us.

 

[trickinit]

Hey Josh,

Android users who root their devices are among our most ardent fans and when this group speaks, we listen. A few of us around Google have been listening to threads like this one and we know that you're disappointed in us. I'm a security engineer who works on Android Pay and so this thread struck me particularly hard. I wanted to reach out to you all and tell you that we hear you.

Google is absolutely committed to keeping Android open and that means encouraging developer builds. While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact.

That "ensuring" is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and--by proxy--real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite--which includes checks for the security model.

The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases. I know that many of you are experts and power users but it is important to note that we don’t really have a good way to articulate the security nuances of a particular developer device to the entire payments ecosystem or to determine whether you personally might have taken particular countermeasures against attacks--indeed many would not have.

Let's keep the dialogue open: I'll be monitoring this and other threads for constructive ideas. I won't be able to reply to all messages but we will keep listening. We love our community and we want you to keep challenging us.

So what does that mean though? You're still open the possibility of allowing Android Pay to work on a rooted device?

I understand that rooting my device makes me more vulnerable, though I feel the the benefits outweigh the risks. I also know that when I choose to root my device I'm taking the responsibility upon myself to ensure that my phone remains secure. If there were some sort of breech, I would have no one to blame but myself. Could a disclaimer of some sort be added into the user agreement? Something that makes it clear that users with rooted devices are taking all the liability upon themselves?

Frankly, I just don't understand the reason for changing the model. I have been an avid user of Google Wallet for several years. I love the tech. Why make the change to tokenization? I understand that it's more of a standard and more secure. But the virtual cards seemed to work just fine. I've never had an issue with them. Better yet, why not let the user choose whether or not they use the tokens.

Simply put, rooting is more important to me. So if that means forfeiting the ability to use Android Pay, so be it. I just don't see why it has to be that way.

 

[Joshmccullough]

Hey Josh,

Android users who root their devices are among our most ardent fans and when this group speaks, we listen. A few of us around Google have been listening to threads like this one and we know that you're disappointed in us. I'm a security engineer who works on Android Pay and so this thread struck me particularly hard. I wanted to reach out to you all and tell you that we hear you.

Google is absolutely committed to keeping Android open and that means encouraging developer builds. While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact.

That "ensuring" is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and--by proxy--real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite--which includes checks for the security model.

The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases. I know that many of you are experts and power users but it is important to note that we don’t really have a good way to articulate the security nuances of a particular developer device to the entire payments ecosystem or to determine whether you personally might have taken particular countermeasures against attacks--indeed many would not have.

Let's keep the dialogue open: I'll be monitoring this and other threads for constructive ideas. I won't be able to reply to all messages but we will keep listening. We love our community and we want you to keep challenging us.

Wow, never expected this

I greatly appreciate the response, like the commenter above, if I had to make a choice between having a rooted phone that I can make my own and being able to use Android Pay, the rooted phone would win out. However, I'm hopeful that the security concerns of moving money using phones and customers' ability to use their phones as they see fit can co-exist.

I'm glad to see that Google's taking active steps to see what the power user/dev community is doing and thinks about advances in Android and its various related applications. Thanks for reaching out to us, it's a cool thing, and make sure to say hi to Eric/Sergei/Larry/et. al. for me

 

[baknblack]

I for one would agree to terms where I take the responsibility. I've been rooting my devices for years.
I think most of us understand what we're doing and understand the risk. I hope google can come up with a compromise.
Choosing root or Android pay. Root wins.

Sent from my Nexus 5 using Tapatalk

 

[jasondclinton_google]

So what does that mean though? You're still open the possibility of allowing Android Pay to work on a rooted device?

I don't want to falsely get your hopes up, so to be completely honest: I don't know of any way to currently or in the near future make an assertion that a particular app's datastore is secure on a non-CTS compatible device. As such, for now, the answer is "no". I could speculate about the future but I'm just one engineer.

I understand that rooting my device makes me more vulnerable, though I feel the the benefits outweigh the risks. I also know that when I choose to root my device I'm taking the responsibility upon myself to ensure that my phone remains secure. If there were some sort of breech, I would have no one to blame but myself. Could a disclaimer of some sort be added into the user agreement? Something that makes it clear that users with rooted devices are taking all the liability upon themselves?

I think what you are asking for is a "power user" bit that we would pass along when you set up Android Pay with a card. Something like, "I'm an Android Pay user who understands the risks but I want to root anyway." I think that this would be too hard to build a risk model for: every financial institution in the world would need to build a risk model that incorporates this signal and weigh it against all of the other signals that go in to approving or declining a transaction.

Frankly, I just don't understand the reason for changing the model. I have been an avid user of Google Wallet for several years. I love the tech. Why make the change to tokenization? I understand that it's more of a standard and more secure. But the virtual cards seemed to work just fine. I've never had an issue with them. Better yet, why not let the user choose whether or not they use the tokens.

I can't speak for Google but I think that the virtual card didn't work particularly well for my use-case: I didn't get the full name of the merchant on my credit card statements and I didn't get all of the reward points that I was supposed to be getting. I also found chargebacks to challenging. With tokenization--which I've been using for months--my relationship with my credit card company is much better.

Simply put, rooting is more important to me. So if that means forfeiting the ability to use Android Pay, so be it. I just don't see why it has to be that way.

Yea, I don't blame you: I completely understand that you are disappointed. I wish that you could get the benefits of rooting without the root.

---------- Post added at 09:45 PM ---------- Previous post was at 09:41 PM ----------

Wow, never expected this

I greatly appreciate the response, like the commenter above, if I had to make a choice between having a rooted phone that I can make my own and being able to use Android Pay, the rooted phone would win out. However, I'm hopeful that the security concerns of moving money using phones and customers' ability to use their phones as they see fit can co-exist.

I'm glad to see that Google's taking active steps to see what the power user/dev community is doing and thinks about advances in Android and its various related applications. Thanks for reaching out to us, it's a cool thing, and make sure to say hi to Eric/Sergei/Larry/et. al. for me

Glad to reach out and completely understand why you find root valuable.

Actually, I'm just a lowly engineer so I think you're about as likely as I am to ever casually say hello to the founders.

 

[trickinit]

I don't want to falsely get your hopes up, so to be completely honest: I don't know of any way to currently or in the near future make an assertion that a particular app's datastore is secure on a non-CTS compatible device. As such, for now, the answer is "no". I could speculate about the future but I'm just one engineer.



I think what you are asking for is a "power user" bit that we would pass along when you set up Android Pay with a card. Something like, "I'm an Android Pay user who understands the risks but I want to root anyway." I think that this would be too hard to build a risk model for: every financial institution in the world would need to build a risk model that incorporates this signal and weigh it against all of the other signals that go in to approving or declining a transaction.



I can't speak for Google but I think that the virtual card didn't work particularly well for my use-case: I didn't get the full name of the merchant on my credit card statements and I didn't get all of the reward points that I was supposed to be getting. I also found chargebacks to challenging. With tokenization--which I've been using for months--my relationship with my credit card company is much better.



Yea, I don't blame you: I completely understand that you are disappointed. I wish that you could get the benefits of rooting without the root.

I appreciate you taking the time to respond to this. It's nice to finally have some clarity as to why I can't get the app to work. It really is a bummer, but I understand why. Hopefully there can be some kind of compromise to get it working eventually.

One recommendation I have would be to add some kind of disclaimer either in the Play Store or in the app itself that makes it clear that Android Pay won't work on rooted devices. The message I've been getting that says "Google is unable to verify that your device or the software running on it is Android compatible" doesn't really make sense. It seems like there has a been a lot of confusion and frustration, with no clear explanation as to what the real problem is.