Being able to trust the security of a client can protect against many attacks and it is up to web sites to evaluate what to do with into information that a client is proven to be secure.
SafetyNet means the app checks to make sure you're not rooted or running a custom ROM because those are considered a security risk. If you are not running a locked-down OEM ROM, you can't run many apps including banking apps.
Microsoft's Pluton on-CPU attestation technology means this is coming to PCs.
- What is the least expensive device that can be certified like that? The least expensive process?
- What is the highest level of openness such a device can offer to the user, and why?
To my mind, it would be best to have an option of a completely locked down and certified hardware token, a device like a Yubikey, that could talk to my laptop, desktop, phone, or any other computing device using a standard protocol. As long as it's unforgeable, the rest of the system can be much. much less secure, without compromising the overall security.
Keep it powered down when not needed for extra security.
Idealy, it could be smaller than a smartphone, and use smartphone's or laptop's hardware for UI and networking.
>means the app checks to make sure you're not rooted or running a custom ROM
The purpose is to be able to tell if the user is running a version of the app is from the play store or to be able to tell if the device's integrity isn't compromised meaning that it can not rely on the security guarantees the OS provides. Banking apps are not against people using custom ROMs. They just want to ensure they are running on a secure operating system.
I don't know. I haven't personally gone through the process.
>What is the highest level of openness such a device can offer to the user, and why?
You have to follow the CDD. https://source.android.com/docs/compatibility/13/android-13-...
and you of course must pass the compatibility tests. So it can be as open as you would like as long as you do not break the android security model.
>it would be best to have an option of a completely locked down and certified hardware token, a device like a Yubikey
That approach is limiting since secrets can't be passed to the host operating system and compute with secrets have to happen on the secure device.
AKA as long as you don't give control to the user.
I don't want to have to agree to Microsoft or Apple's ToS so that I can access my bank.
I do not look forward to trying to find a bank that doesn't require this of me because all of the major banks have jumped on board.
A system being secure doesn't mean that the user doesn't have control. The operating system should allow the user to control it, but only in a secure way that doesn't compromise the rest of the security of the system. The Windows way of having an administrator account or Linux of having a root account given to the user has been proven over time to be worse for security. Windows has been trying to roll back this mistake, but most Linux distributions don't do anything because they don't care that much about security compared to an operating system like Android.
I wanted to extract some data files from an app I was using and Google's Android told me that I was not allowed to do that. That was the apps data not my data.
It doesn't really matter root/fine grained permissions. The fact is that on stock Pixel phones the user can't access whatever data they want. So in practice they don't have control.
Usually banks don't let you disable antifraud protections. They prefer to make their business and the banking system more secure by reducing the rate of fraud. Fraud is expensive for them to deal with so it doesn't really make financial sense to let customers say that they are okay with having more fraud happen using their account.
So the server is wildly insecure and wants to make it my problem.
Take for example a simple spam bot. The bot authenticates and then starts sending spam to people. Detecting spam and spammers server side is an imperfect art. It is a constant game of doing things to reduce the rate of spam. It can help a lot if you can ensure that only your client is able to work with your service. This means that attackers can't just write some python script and deploy it somewhere. They have to actually be running your app and actually liking the content in the app. This increases the costs for attackers and reduces the amount of spam.
Both client and server security is important.
And the alternative is taking a picture of the QR code.
> Additionally just because someone is using a device that doesn't mean that the current user is the owner of the device.
Yeah that's why you make the owner authenticate. It would be ridiculous to use that as a reason to make escalation impossible.
And that effect is against custom ROMs and other kinds of user control.
Furthermore nothing prevents you from just taking pictures of the individual enrollment keys and printing those out either.
If you want TOTP 2FA that actually follows a one key per device policy you need to buy hardware tokens with some kind of out-of-band keying mechanism and enroll those. Then your problem changes from "how to stop people from copying my 2FA tokens" to "how to not get locked out of my account when my 2FA key device breaks."