[Nexus 5 Q&A, Help & Troubleshooting] Entropy512:
One potential compromise here - while "card present transactions" are considered more secure, the reality is that these transactions are typically MUCH smaller (and as a result far less likely to have liability issues) than "card not present". Most common use case for Android Pay/Apple Pay is stuff like groceries and fast food. These are typically much smaller transactions with far less liability - to the point where many retailers don't even require signatures for transactions less than a certain amount (For example, $50 at Wegmans).

I'd happily accept a per-transaction limit in the $30-50 range for Android Pay.

Actually, HCE was the best thing to happen to Wallet. If I recall from a Google patent application, Wallet generated time-limited and geographically-limited credentials. This occurred when you unlocked Wallet with your PIN (which is why you started needing network connectivity when unlocking Wallet). The end result was that the impact of a device compromise was pretty small. Now it seems like semi-permanent credentials are generated when adding a card, and the system now relies entirely on lockscreen security.

During the era of HCE Wallet, we lived in a golden age with no known compromises and no one directly attacking the Wallet APK to bypass artificial limitations. That golden age is now over.

This would be interesting - I am fairly certain unfortunately that Google's SafetyNet database is not populated by CTS passes, but actually by GMS approvals (which requires CTS to pass along with a whole lot more).

Passing CTS is actually very time consuming so not feasible for most custom firmware projects and definitely not any one that does nightlies, however it might be possible as a compromise to do periodic "CTS-verified" releases - CM could do it for example with M releases, I know occasionally in Omni we've talked about doing "verified nightlies" where a particular nightly is marked as "known to work well by more than N users" and such a nightly could also have CTS run against it.

One thing I saw Jason mention was the issue of keys - CM community builds are signed using testkeys to avoid some of the issues Omni has had with switching between nightly and homebuilt releases, although with some frameworks modifications to reduce the security impact this has - https://github.com/CyanogenMod/andr...mmit/89c10fbc4aa2058c63e6a59f59cc89d9e284aa30 . (Omni signs our releases with a private key - it's more secure but has the negative consequence of making switching between homebuilt and official much more difficult.)

PayPass IS EMV... It is not being phased out. It has been renamed to MasterCard Contactless, but it's still ISO 14443 EMV.

Yeah. This is the thing - I've occasionally seen Google security engineers talk about removing the need for root by "baking in" common uses for root into Android itself. But it's all talk, actions speak louder than words.

Backup - ADB backup is still horrifically unreliable to the point where it's almost useless. It routinely fails to back up or restore some apps/data, and which ones fail is COMPLETELY random. TiBu blows it out of the water. This is one of the only cases I've seen Google even ATTEMPT to provide a workable alternative to a root application.

Power management/wakelocks - This information used to be readily available to the user. It was removed from the UI ages ago but available to apps, prompting the creation of BetterBatteryStats. A few Android releases later and Google locked down the info needed by BBS so that it now requires root privileges to work. Actually IIRC with Lollipop it now MUST be installed as a system app. For all of Google's talk about improving power management, the fact that BBS is the ONLY way I can determine that the reason my device is in deep sleep less than 50% of the time is due to bluesleep/BTLowPower kernel wakelocks is BBS. I've had one case where my phone was awake for more than 75% of the time due to bluesleep wakelocks, but the built-in battery stats app showed a grand total of two users of battery each only consuming 1% - neither of those had ANY actual connection to what was draining my battery. It's a case where even after 3+ years of claiming they want to reduce the need for root by building such functionality in the platform, they've actually CREATED new needs for root privileges by removing it.

Yes. One of my points was that SafetyNet's root checks are utterly pointless. They're supposedly intended to prevent against malware, but the reality is that they only find "legitimate" root control applications with robust access controls like SuperSU. It's incredibly naive of Google to think that malware is going to obtain root privileges by putting a binary at /system/xbin/su... That would only be done by the dumbest of malware authors, any one of them with half a brain is going to use a location that is NOT blatantly obvious.

The current Xposed module out there doesn't fix Pay since it is only patching the server response to the device check. It turns out SafetyNet validations can be done server-side and I believe Pay is doing this. But it's just a matter of time (I expect less than a month) before that module starts faking the data from which the attestation is built, resulting in all servers receiving bogus attestation data. As a side effect, the author of that module is considering adding lockscreen security status fakeouts to the module as an "enhancement".

If Pay simply had the annoying lockscreen security but not SafetyNet, probably few would have bothered to write an Xposed module to fake this status. However, thanks to SafetyNet going beyond "annoying" to "makes the app completely nonfunctional", Pay and SafetyNet are coming under direct attack. Once you've already got an Xposed module targeting some of Pay's security features, it's far less effort to say "eh, what the hell, may as well kill the lockscreen security requirement while I'm at it". I've suggested to the guy that he NOT do this to avoid an arms race/cat-and-mouse game with Google, but it's a perfect example of how SafetyNet actually is going to result in a massive REDUCTION in security for Pay, by causing far more people to actively target Pay's security measures to defeat them. It's a perfect opportunity for malware authors to ride the coattails of these efforts.

As an example - see the PlayStation 3. For a long time, users could officially install Linux in a sandbox on the PS3. As a result of this, there was far less effort put into running unsigned code on the PS3. Eventually, geohot started working on breaking out of the sandbox in order to do more. Sony's response to this was to completely remove OtherOS functionality - BAD MOVE. Suddenly, there was a HUGE amount of interest in defeating the PS3's code-signing enforcement. PS3 security was pretty much totally dismantled within 2-3 months. fail0verflow had a good slide on this - the PS3 lasted longer than any other console thanks to OtherOS, and nearly every console compromise was initially done by people wanting to run Linux or homebrew software. However, every time a console was compromised for Linux/homebrew, blackhats rode the coattails of those efforts to enable piracy within another month or two. Same thing is now going to happen to Pay due to Google focusing solely on the technical aspects of security and ignoring the psychological aspects of security, such as "if security becomes too intrusive, legitimate users become interested in bypassing/defeating it". I can't find a link to it at the moment, but I recall a study that showed that past a certain point, strong password security policies became counterproductive. If password requirements became too complex, many users couldn't remember their passwords, with the results being that users who would normally never write their passwords down began doing so. Also, password reset requests became far more frequent, leaving a great hole for social engineering attacks.