|
Top-level
 @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. 3 comments
@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
@yacc143
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.