|
Top-level
By and large I don't think Google uses SafetyNet for its own apps, because it isn't seen as so necessary... except for stuff like contactless payments. And there is no way you would have contactless payments without device integrity verification. I also find it frustrating how much app developers feel the need to protect themselves from the platform with this stuff, but I don't see how to generally convince them otherwise. (And Apple's Android security FUD doesn't help.) 8 comments
 @hackbod Actually, with some tender love and care, my custom rom, with root, does Google Pay. And you won't believe it, nobody was defrauded because, shock, it's me, the owner who rooted the device. Not some malware. If I wanted to defraud anybody, I could read up on all the beautiful design faults in the EMV protocol that the payment industry managed to design into it. Google is not very anal about verification. But by not taking a stand, and not doing the right thing, they are spreading it. @hackbod So what exactly is Google fearing if Google Pay is running on a Custom ROM? The EMV protocol is meant to be cryptographically secure, and I'd hope that you store the card credentials on the secure hardware enclave that all Androids must have due to Google requirements. So what threats exactly is Google protecting against by doing a verification? @hackbod I mean I do online banking all the time on a Fedora Linux laptop, with, *gasp*, Secure Boot disabled. (Btw, SMS is still legal as a 2FA authentication under the current EU payment directive. While banks tend to force (“guide”) users into “smart apps”, the initial handshake still happens via SMS.) @hackbod So tell me because you said, “And there is no way you would have contactless payments without device integrity verification”. Against what threats does that device integrity verification protect the user/system? The secrets are in the secure hardware enclave in mobile. The EMV protocol is designed to be cryptographically secure. You should be able to publish the traffic on the Internet, and nothing bad happens. You should be able to modify the traffic and the payment fails. Okay given the false equivalence between Android and PlayStation; blanket dismissal of modern best practices of hardware security modules for software validation, at rest encryption and authentication and biometrics protection; and ignoring my points about the expectations and requirements of app developers... it seems clear there isn't really much opportunity for a discussion, so I am going to bow out. @hackbod You still have not explained which threat Google Pay protects against by verifying that the mobile is untampered, but not checking that the security patch levels are up to say in the past 12 months. And yes, Googlified Android gives App developers the tools into their hands to validate the whole system chain starting with the boot loader to the app. You call it “best practices in hardware security”. I call it Playstation style lock down. @hackbod You seem to forget that the newer "free software licenses" explicitely deal with the issue of the "freedom" of the user being able to modify the software and apply it to his device. What's the point of that freedom, if you make sure that "best practices" include making sure that the open source Custom ROM cannot run most of the software for the platform? So explain what's the threat for the Google Pay running on a Custom ROM? |
Gregory's Server
@hackbod Ah, but the point is:
Google requires manufacturers to provide the hardware functionality for a PlayStation level verification. Or they do not get the Google apps.
OTOH, Google does not educate developers on correct security practices (as in check how fresh the security patches are, or even use a library that actively checks for exploits, instead of “verifying” that your user is running an unsecure 3 years old Android).
Because that would cause havoc for their business.