I kind of regret not buying one of these instead of a Pixel 7 but, unfortunately, I'm pretty tethered to the Android ecosystem at the moment.
But because the banks that require this are cargo culting some nonsense, they require iOS or Google Android but don't really care how old the phone is. Which means you can transfer your cellular plan to the phone you actually want to use and then just keep your existing phone indefinitely to run the bank app over WiFi or tethering.
The first is that your phone is not compromised. In this case there is no other app trying to steal your bank's authentication token. This is true regardless of which OS you use or whether you have magisk installed or what other code you put on your phone that isn't trying to steal your bank's authentication token.
The second is that your phone is compromised. Then what prevents the device from capturing your bank credentials is the same as if you use a compromised phone running Google Android: Nothing. If you enter your bank credentials into a compromised phone, the attacker gets them. Attestation can't prevent this because the phone is compromised, so the login screen isn't from a bank app that requires attestation, it's from a scam app which is exfiltrating your credentials.
This is far from the truth assuming by compromised you mean that the user has installed a malicous app. Android has proper sandboxing which means that other apps can't read the token owned by the bank app. This is part of the Android security model and attestation is evidence that the Android security model is being enforced. Phishing apps are different from an app that steals existing authentication tokens on the device.
Of course attestation does nothing to improve the "single compromised app" case since (assuming Android) that goes nowhere either way. The only thing attestation does is meddle in end user affairs.
Let's consider this alternative as well:
Scenario 1: Device has no malicious code at all; same as scenario 1 before.
Scenario 2: Device has a malicious app but the malicious app doesn't have root and the OS (regardless of whether it's Android or something else) enforces proper sandboxing. The malicious app can't extract the bank authentication token regardless of attestation.
Scenario 3: Device is fully compromised; malicious code has root. Same as before, if you enter your credentials into this device the attacker gets them.
The problem is that the only useful thing for attestation to do is to distinguish between 1 or 2 vs. 3, but that's the thing it can't do because if the malicious code is privileged it can replace the bank app with one that exfiltrates the credentials without requiring attestation, so the only cases where attestation is happening are the ones where it isn't needed.
The scenario is the phone isn't compromised. Having root means you, or an app you run can bypass the security protecting the authentication token.
IDK about your country, but it's also common for banks to require supplying a token from the phone's banking app in order to login via the browser.
By "not compromised" GP clearly meant a scenario where no malicious apps are present.
I agree that's a serious omission. I responded to your scenario (a nonzero number of malicious apps) in my earlier comment. Any Android device will defend against that regardless of the presence of attestation.
Any non-android device can still use online banking and thus attestation doesn't appear to accomplish anything legitimate. Building out proper support for hardware tokens would provide superior security in approximately all cases.
The specific "root on android" scenario isn't generally a concern. Typical implementations require explicitly granting the capability to a given app. A malicious app can't gain it without fooling the user, at which point it could more easily phish the credentials and possibly even proxy an entire session.
Here the majority continue to use SMS based 2FA rather than supporting TOTP or hardware tokens.
Note that TOTP can be handled by any app of the user's choosing, doesn't facilitate attestation or any other user hostile practices, and in practice means that an attack requires physical theft of the device. While the theory might differ, in practice the effective security level is equivalent to other (objectionable) schemes.
Your suggestion is not plausible as every security feature has 0 security value if there is nothing malicous. It would be like someone saying that antivirus is useless because if someone doesn't have a virus then it doesn't do anything.
>Any Android device will defend against that regardless of the presence of attestation.
Rooted android devices can be set up in a way that malicous apps can gain root and then read it.
>Any non-android device can still use online banking
But this comes with a different risk profile. A bank can reduce risk for a subset of their customers.
>Building out proper support for hardware tokens would provide superior security in approximately all cases.
I think usually the hardware token gains you access to an authentication token. You don't sign every request you are making with a hardware only key.
>Typical implementations require explicitly granting the capability to a given app.
And the majority of users have no clue what an app is able to do. If root is given to it then it can do anything. This is in contrast to when root isn't available and users are protected by the sandbox the app is in.
Modern operating systems will protect the cookies from being stolen from other applications on the system.
The banks are probably using the same standard behind the scenes, but they don't allow alternate TOTP apps. There's no point where they give you a key to set it up in an alternate app.
I suppose part of the point is a lack of trust in users' ability to handle their own security, and the possibility that they may provide such a key to a compromised TOTP app.
> hardware tokens
It'd be excellent if banks moved back to purpose-specific hardware like that. Even better if it were some standard with multiple providers, like FIDO2.
Suppose you have an "antivirus" program that works like this: The system makes a list of every program that runs as root during boot and then at the end of boot the antivirus program checks the list for unexpected programs and if it finds any it displays an error and refuses to display the login prompt to prevent the user from typing their password into a compromised device.
That "antivirus" system is useless, because if a malicious program did run as root during boot then it could just reconfigure the system to display the login prompt unconditionally.
The way attestation is nominally supposed to work is that a remote system cryptographically verifies the state of the local machine before giving it some secret. But that doesn't work in this case because the secret -- the thing that allows the user to sign in -- is coming from the local user rather than a remote machine. The attacker doesn't need to perform attestation or retrieve anything from a remote machine in order to display a local login prompt and collect the user's credentials, and that's the end of the game.
> Rooted android devices can be set up in a way that malicous apps can gain root and then read it.
So can PCs, or various non-rooted android devices that bank apps run on even though they have known unpatched vulnerabilities.
> But this comes with a different risk profile. A bank can reduce risk for a subset of their customers.
How is it reducing risk for anyone? Each person still has the same risk profile as before. The person with a locked Android device still has a locked Android device, the person with an unlocked Android device is now forced to use a PC which is an inconvenience with no security advantage.
From a technical perspective device attestation doesn't add anything here. The typical user doesn't receive any additional protection. All of its supposed "benefits" ultimately stem from the restriction of end user choice but those same end users _already_ have a practically limitless selection of stupid choices available to them. And these are generally very deliberate choices that we're talking about here. Not subtle confusion.
> the majority of users have no clue what an app is able to do. If root is given to it then it can do anything.
If a user is stupid enough to seek out root, ignore all warnings, install a malicious app, and explicitly grant it root, then he was fated to fall for a much simpler scam regardless. Such as granting a malicious app admin on his laptop and then logging into online banking. Or installing a phishing app that proxies the session to the bank.
Typical users don't seek out root, don't install custom ROMs, and don't consent to the warning message about installing APKs from unknown sources. Grandma isn't ricing her mobile phone.
Support for hardware tokens or TOTP would address widespread real world attacks. Shutting down various customer service social engineering account reset tactics would also help, but that would actually cost money. In contrast attestation doesn't accomplish anything other than infringing end user choice. It's a highly unethical waste of resources.
For the user (and in the context of Pinephones), the benefit would lie in getting banks out of their phones. Banks want a device that's not under the control of the user to use as 2FA. A dedicated hardware key would be a compromise for that. They used to give them out, but I pessimistically imagine that today they might prefer to lose a customer.
A bank may not want to put in the extra effort of supporting 3 platforms of secure phones, insecure phones, and insecure web and would prefer to support less and potentially dropping features from the web platform.
If the security of your system depends on the attacker not doing something the attacker can easily do, it's useless.
> A bank may not want to put in the extra effort of supporting 3 platforms of secure phones, insecure phones, and insecure web and would prefer to support less and potentially dropping features from the web platform.
So now we've gone from some kind of hypothetical security benefit to "banks don't support that because they're lazy". Except that adding support for attestation is work they do for no reason, because the people using locked phones are still using locked phones and preventing people with unlocked phones from using them instead of the web page is paying to do work only in order to cause customers trouble.