5 ms·

Only because it's there. I don't think the would demand it if it wasn't offered, but once it's there imagine being in a bank and saying to management "it recomm

Only because it's there. I don't think the would demand it if it wasn't offered, but once it's there imagine being in a bank and saying to management "it recommend we don't enable this security feature that works on 99.99999% of phones".

mhast 1y ago
As someone who used to work for a bank building applications I would say no. This is definitely a feature companies and organizations like banks would request if it wasn't available. There are a lot of scams targeting vulnerable people and these days attacking the phone is a very "easy" way of doing this. Now perhaps there is a more forgiving way of implementing it though. So your phone can switch between trusted and "open" mode. But realistically I don't think the demand is big enough for that to actually matter.
- const_cast 1y ago
  Play integrity does almost nothing to prevent malicious actors. In fact, id say overall it's probably more harmful because it gives actors like Banks false confidence. Even with play integrity, you should not trust the client. Devices can still be compromised, there are still phony bank apps, there are still keyloggers, etc. With the Web, things like banks are sort of forced to design apps that do not rely on client trust. With something like play integrity, they might not be. That's a big problem.
  - brookst 1y ago
    That’s a “seatbelts so no good because people still die in car crashes” argument with a topping of “actually they’re bad because they give you a false sense of security” Play integrity hugely reduces brute force and compromised device attacks. Yes, it does not eliminate either, but security is a game of statistics because there is rarely a verifiably perfect solution in complex systems. For most large public apps, the vast majority of signin attempts are malicious. And the vast majority of successful attacks come from non-attested platforms like desktop web. Attestation is a valuable tool here.
    - pona-a 1y ago
      How does device attestation reduce bruteforce? Does the backend not enforce the attempt limits per account? If so, that's would be considered a critical vulnerability. If not, then attestation doesn't serve that purpose. As for compromised devices, assuming you mean an evil maid, Android already implements secure boot, forcing a complete data wipe when breaking the chain of trust. I think the number of scary warnings is already more than enough to deter a clueless "average user" and there are easier ways to fish the user.
      - Sayrus 1y ago
        And those apps use MEETS_DEVICE_INTEGRITY rather than MEETS_STRONG_INTEGRITY so a compromised device can absolutely be used to access critical services. (Usually because strong integrity is unsupported on old devices) This reminds me of providers like Xiaomi making it harder to unlock the bootloader due to phones being sold as new but flashed with a compromised image.
        pona-a 1y ago
        Maybe a good compromise is to change the boot screen to have a label that the phone is running an unofficial ROM, just like it shows one for unlocked bootloaders? If the system can update that dynamically based on unlock state, why can't it do it based on public keys? Might also discourage vendors/ROM devs from using test keys like Fairphone once did.
        drewbug 1y ago
        Pixels with, for example, GrapheneOS already do exactly that: "Your device is loading a different operating system."
      - mike_hearn 1y ago
        I developed this stuff at Google (JS puzzles that "attest" web browsers), back in 2010 when nobody was working on it at all and the whole idea was viewed as obviously non-workable. But it did work. Brute force attacks on passwords generally cannot be stopped by any kind of server-side logic anymore, and that became the case more than 15 years ago. Sophisticated server-side rate limiting is necessary in a modern login system but it's not sufficient. The reason is that there are attackers who come pre-armed with lists of hacked or phished passwords and botnets of >1M nodes. So from the server side an attack looks like this: an IP that doesn't appear anywhere in your logs suddenly submits two or three login attempts, against unique accounts that log in from the same region as that IP is in, and the password is correct maybe 25%-75% of the time. Then the IP goes dormant and you never hear from it again. You can't block such behavior without unworkable numbers of false positives, yet in aggregate the botnet can work through maybe a million accounts per day, every day, without end. What does work is investigating the app doing the logging in. Attackers are often CPU and RAM constrained because the botnet is just a set of tiny HTTP proxies running on hacked IoT devices. The actual compute is happening elsewhere. The ideal situation from an attacker's perspective is a site that is only using server side rate limiting. They write a nice async bot that can have tens of thousands of HTTP requests in flight simultaneously on the developer's desktop which just POSTs some strings to the server to get what they want (money, sending emails, whatever). Step up the level of device attestation and now it gets much, much harder for them. In the limit they cannot beat the remote attestation scheme, and are forced to buy and rack large numbers of genuine devices and program robotic fingers to poke the screens. As you can see, the step-up from "hacking a script in your apartment in Belarus" to "build a warehouse full of robots" is very large. And because they are using devices controlled by their adversaries at that point, there's lots of new signals available to catch them that they might not be able to fix or know about. The browser sandbox means you can't push it that far on the web, which is why high value targets like banks require the web app to be paired with a mobile app to log in. But you can still do a lot. Google's websites generate millions of random encrypted programs per second that run inside a little virtual machine implemented in Javascript, which force attackers to use a browser and then look for signs of browser automation. I don't know how well it works these days, but they still use it, and back when I introduced it (20% time project) it worked very well because spammers had never seen anything like it. They didn't know how to beat it and mostly just went off to harass competitors instead.
  - mike_hearn 1y ago
    I've worked on such systems. Love it or hate it, remote attestation slaughters abuse. It is just much harder to scale up fraud schemes to profitable levels if you can't easily automate anything. That's why it exists and why banks use it.
    - ulrikrasmussen 1y ago
      Wouldn't device-bound keys for a set of trusted issuing secure elements (e.g. Yubikeys) work just as well but without locking down the whole goddamn software stack?
      - mike_hearn 1y ago
        RA schemes don't lock down the whole software stack, just the parts that are needed to allow the server to reason about the behavior of the client. You can still install whatever apps you want, and those apps can do a lot of customization e.g. replace the homescreen, as indeed Android allows today. You need to attest at least the kernel, firmware, graphics/input drivers, window management system etc because otherwise actions you think are being taken by the user might be issued by malware. You have to know that the app's onPayClicked() event handler is running because the human owner genuinely clicked it (or an app they authorized to automate for them like an a11y app). To get that assurance requires the OS to enforce app communication and isolation via secure boundaries.
        ulrikrasmussen 1y ago
        That's waay too much locking down, and while it gives me some control, it does not give me real control. I cannot remove or modify software in the software stack whose behavior I disagree with (e.g. all of Play Services). I can't replace the OS with a more privacy and security focused OS like GrapheneOS. Imagine if this was done for desktop computers before we had smartphones. That's just crazy. Relying on hardware-bound keys is fine, but then the scope of the hardware and software stack that needs to be locked down should be severely limited to dedicated, external hardware tokens. Having to lock down the whole OS and service stack is just bad design, plain and simple, since it prioritizes control over freedom.
- IshKebab 1y ago
  > This is definitely a feature companies and organizations like banks would request if it wasn't available. Really? Because they've been fine without this feature on desktop for literally decades.
- cyphar 1y ago
  Unfortunately, this kind of thinking leads to insane situations such as the South Korean banking cartel which requires users to install several pieces of "security software"[1] which make your computer more vulnerable to security issues[2] and almost certainly doesn't protect anyone from actual fraud -- classic security theatre. There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. [1]: https://palant.info/2023/01/02/south-koreas-online-security-dead-end/ https://palant.info/2023/01/02/south-koreas-online-security-... [2]: https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-mandatory-financial-security-software-becomes-a-backdoor-and-a-target/ https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-ma...
  - cyphar 1y ago
    > There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. That is to say, banks are not the only entities in existence. If they really need such high security to avoid scams and losing such large sums of money they should just issue bank customers with a locked down device that can only be used for banking (maybe banks can collaborate on a standard for it so you can have one device for multiple banks). To be clear, I would still probably be strongly against such a proposal but at least we would be talking about a somewhat understandable approach.
wkat4242 1y ago
On the other hand, it's not really up to the bank. It's my money, not theirs. I really wish I wouldn't need to have my money managed by some corporate drones in suits but it's really hard these days to do without a bank account. This is why I was really into crypto at the beginning; it envisioned giving us control abck over what's ours. But all the KYC crap and the wishes of the speculators for more oversight basically made crypto the same nasty deal as the public banking sector.
blueg3 1y ago
It is desired enough that plenty of developers license third party libraries that roll their own device attestation, instead of or in addition to Play Integrity.

mhast 1y ago

As someone who used to work for a bank building applications I would say no. This is definitely a feature companies and organizations like banks would request if it wasn't available. There are a lot of scams targeting vulnerable people and these days attacking the phone is a very "easy" way of doing this. Now perhaps there is a more forgiving way of implementing it though. So your phone can switch between trusted and "open" mode. But realistically I don't think the demand is big enough for that to actually matter.

const_cast 1y ago
Play integrity does almost nothing to prevent malicious actors. In fact, id say overall it's probably more harmful because it gives actors like Banks false confidence. Even with play integrity, you should not trust the client. Devices can still be compromised, there are still phony bank apps, there are still keyloggers, etc. With the Web, things like banks are sort of forced to design apps that do not rely on client trust. With something like play integrity, they might not be. That's a big problem.
- brookst 1y ago
  That’s a “seatbelts so no good because people still die in car crashes” argument with a topping of “actually they’re bad because they give you a false sense of security” Play integrity hugely reduces brute force and compromised device attacks. Yes, it does not eliminate either, but security is a game of statistics because there is rarely a verifiably perfect solution in complex systems. For most large public apps, the vast majority of signin attempts are malicious. And the vast majority of successful attacks come from non-attested platforms like desktop web. Attestation is a valuable tool here.
  - pona-a 1y ago
    How does device attestation reduce bruteforce? Does the backend not enforce the attempt limits per account? If so, that's would be considered a critical vulnerability. If not, then attestation doesn't serve that purpose. As for compromised devices, assuming you mean an evil maid, Android already implements secure boot, forcing a complete data wipe when breaking the chain of trust. I think the number of scary warnings is already more than enough to deter a clueless "average user" and there are easier ways to fish the user.
    - Sayrus 1y ago
      And those apps use MEETS_DEVICE_INTEGRITY rather than MEETS_STRONG_INTEGRITY so a compromised device can absolutely be used to access critical services. (Usually because strong integrity is unsupported on old devices) This reminds me of providers like Xiaomi making it harder to unlock the bootloader due to phones being sold as new but flashed with a compromised image.
      - pona-a 1y ago
        Maybe a good compromise is to change the boot screen to have a label that the phone is running an unofficial ROM, just like it shows one for unlocked bootloaders? If the system can update that dynamically based on unlock state, why can't it do it based on public keys? Might also discourage vendors/ROM devs from using test keys like Fairphone once did.
        drewbug 1y ago
        Pixels with, for example, GrapheneOS already do exactly that: "Your device is loading a different operating system."
    - mike_hearn 1y ago
      I developed this stuff at Google (JS puzzles that "attest" web browsers), back in 2010 when nobody was working on it at all and the whole idea was viewed as obviously non-workable. But it did work. Brute force attacks on passwords generally cannot be stopped by any kind of server-side logic anymore, and that became the case more than 15 years ago. Sophisticated server-side rate limiting is necessary in a modern login system but it's not sufficient. The reason is that there are attackers who come pre-armed with lists of hacked or phished passwords and botnets of >1M nodes. So from the server side an attack looks like this: an IP that doesn't appear anywhere in your logs suddenly submits two or three login attempts, against unique accounts that log in from the same region as that IP is in, and the password is correct maybe 25%-75% of the time. Then the IP goes dormant and you never hear from it again. You can't block such behavior without unworkable numbers of false positives, yet in aggregate the botnet can work through maybe a million accounts per day, every day, without end. What does work is investigating the app doing the logging in. Attackers are often CPU and RAM constrained because the botnet is just a set of tiny HTTP proxies running on hacked IoT devices. The actual compute is happening elsewhere. The ideal situation from an attacker's perspective is a site that is only using server side rate limiting. They write a nice async bot that can have tens of thousands of HTTP requests in flight simultaneously on the developer's desktop which just POSTs some strings to the server to get what they want (money, sending emails, whatever). Step up the level of device attestation and now it gets much, much harder for them. In the limit they cannot beat the remote attestation scheme, and are forced to buy and rack large numbers of genuine devices and program robotic fingers to poke the screens. As you can see, the step-up from "hacking a script in your apartment in Belarus" to "build a warehouse full of robots" is very large. And because they are using devices controlled by their adversaries at that point, there's lots of new signals available to catch them that they might not be able to fix or know about. The browser sandbox means you can't push it that far on the web, which is why high value targets like banks require the web app to be paired with a mobile app to log in. But you can still do a lot. Google's websites generate millions of random encrypted programs per second that run inside a little virtual machine implemented in Javascript, which force attackers to use a browser and then look for signs of browser automation. I don't know how well it works these days, but they still use it, and back when I introduced it (20% time project) it worked very well because spammers had never seen anything like it. They didn't know how to beat it and mostly just went off to harass competitors instead.
- mike_hearn 1y ago
  I've worked on such systems. Love it or hate it, remote attestation slaughters abuse. It is just much harder to scale up fraud schemes to profitable levels if you can't easily automate anything. That's why it exists and why banks use it.
  - ulrikrasmussen 1y ago
    Wouldn't device-bound keys for a set of trusted issuing secure elements (e.g. Yubikeys) work just as well but without locking down the whole goddamn software stack?
    - mike_hearn 1y ago
      RA schemes don't lock down the whole software stack, just the parts that are needed to allow the server to reason about the behavior of the client. You can still install whatever apps you want, and those apps can do a lot of customization e.g. replace the homescreen, as indeed Android allows today. You need to attest at least the kernel, firmware, graphics/input drivers, window management system etc because otherwise actions you think are being taken by the user might be issued by malware. You have to know that the app's onPayClicked() event handler is running because the human owner genuinely clicked it (or an app they authorized to automate for them like an a11y app). To get that assurance requires the OS to enforce app communication and isolation via secure boundaries.
      - ulrikrasmussen 1y ago
        That's waay too much locking down, and while it gives me some control, it does not give me real control. I cannot remove or modify software in the software stack whose behavior I disagree with (e.g. all of Play Services). I can't replace the OS with a more privacy and security focused OS like GrapheneOS. Imagine if this was done for desktop computers before we had smartphones. That's just crazy. Relying on hardware-bound keys is fine, but then the scope of the hardware and software stack that needs to be locked down should be severely limited to dedicated, external hardware tokens. Having to lock down the whole OS and service stack is just bad design, plain and simple, since it prioritizes control over freedom.
IshKebab 1y ago
> This is definitely a feature companies and organizations like banks would request if it wasn't available. Really? Because they've been fine without this feature on desktop for literally decades.
cyphar 1y ago
Unfortunately, this kind of thinking leads to insane situations such as the South Korean banking cartel which requires users to install several pieces of "security software"[1] which make your computer more vulnerable to security issues[2] and almost certainly doesn't protect anyone from actual fraud -- classic security theatre. There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. [1]: https://palant.info/2023/01/02/south-koreas-online-security-dead-end/ https://palant.info/2023/01/02/south-koreas-online-security-... [2]: https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-mandatory-financial-security-software-becomes-a-backdoor-and-a-target/ https://ee.kaist.ac.kr/en/research-achieve/in-south-korea-ma...
- cyphar 1y ago
  > There needs to be a point where enough is enough, and locking down devices so that you cannot install programs nor practically use custom operating systems on them anymore is way past that line. That is to say, banks are not the only entities in existence. If they really need such high security to avoid scams and losing such large sums of money they should just issue bank customers with a locked down device that can only be used for banking (maybe banks can collaborate on a standard for it so you can have one device for multiple banks). To be clear, I would still probably be strongly against such a proposal but at least we would be talking about a somewhat understandable approach.

wkat4242 1y ago

On the other hand, it's not really up to the bank. It's my money, not theirs. I really wish I wouldn't need to have my money managed by some corporate drones in suits but it's really hard these days to do without a bank account. This is why I was really into crypto at the beginning; it envisioned giving us control abck over what's ours. But all the KYC crap and the wishes of the speculators for more oversight basically made crypto the same nasty deal as the public banking sector.

blueg3 1y ago

It is desired enough that plenty of developers license third party libraries that roll their own device attestation, instead of or in addition to Play Integrity.