Hacker News new | ask | show | jobs
by jsiepkes 26 days ago
> You also have the EUs Payment Services Directive (so a law) which require strong customer authentication, rooted devices can also fail up here.

Plain wrong. PSD3 does not apply to "digital wallets" [1] ("This Directive also does *not* cover, in its scope, the provision of technical services including processing or the operation of digital wallets.").

> If your phone is rooted or has an unlocked bootloader then it's possible that trusted store is no longer secure or can be snooped on by a third party.

That's also wrong. Even with a rooted phone you can't mess or snoop on data in the trusted execution environment. The isolation is enforced in hardware.

> If a device fails compliance (a rooted phone certainly does), as far as banks are concerned it's not safe.

If this were about security, then why allow phones which have known security vulnerabilities (and no longer receive updates) to pass the Google Play Integrity API tests?

> But people just find it easier to say "Google is Evil".

Apparently you also find it easy to forgo about the history of Android. Like how Google introduced the Google Play API about a decade ago and did a "Embrace, extend, extinguish" thing. You also conveniently stay silent on things like the fact that Google now only releases the Android sources only twice a year.

[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52...

1 comments

> Even with a rooted phone you can't mess or snoop on data in the trusted execution environment

A rooted phone can have a modified runtime/kernel that can inject code into whatever processes it sees fit, including Google Pay.

Which can expose information being sent to and read from the TEE by the app.

> Plain wrong. PSD3 does not apply to "digital wallets" [1] ("This Directive also does not cover, in its scope, the provision of technical services including processing or the operation of digital wallets.").

The legislation still applies to the bank behind Google Pay.

> A rooted phone can have a modified runtime/kernel that can inject code into whatever processes it sees fit, including Google Pay. Which can expose information being sent to and read from the TEE by the app.

You seem to have now realized (?) you can't modify or see data in the trusted execution environment from the host OS (rooted or not). Meaning the point you made earlier: "means the EMV token store on your Android phone must be in an isolated uncompromised location (usually the TEE)." is not affected by your phone being rooted.

So you have shifted your argument from "the store is unsafe" (false) to "the data in transit to the app might be observable". PCI-DSS doesn't require you to have something like Google Play Integrity API for that.

> The legislation still applies to the bank behind Google Pay.

You started out with that the Google Play integrity API was a hard requirement to comply with legislation (false). Sure, banks are still responsible for fraud under that legislation. But that is a very broad statement which doesn't require Google Play integrity API. GrapheneOS proved you can do attestation in an open way. Google just chose to do it in a way which ties you to Google and further locks down the Android ecosystem.