4 ms·

GrapheneOS does not support SafetyNet or Play Integrity hardware attestation and there isn't a way to use them on GrapheneOS. The whole point of that article is

by strcat 4y ago

GrapheneOS does not support SafetyNet or Play Integrity hardware attestation and there isn't a way to use them on GrapheneOS. The whole point of that article is encouraging developers to move away from those Google services to the standard Android Open Source Project hardware attestation API which includes support for alternate operating systems. Once developers switch away from the Google attestation API to the Android attestation API, they can freely add support for alternate operating systems by adding their signing keys to an allowlist if they meet the requirements. They can have an application process for operating systems to be approved by their risk/anti-fraud/anti-cheat departments. Starting by adding GrapheneOS would make sense since it's the most widely used alternate mobile OS with properly signed releases supporting attestation. Our article does not recommend only supporting GrapheneOS and if developers change their implementation as we recommend, they can easily add support for many other operating systems. Convincing developers not to unnecessarily lock down which operating systems can use their apps is a separate thing from convincing them to support alternate operating systems meeting their standards. Some apps are required to check for this due to expectations from financial services or even governments, and while most usually do a poor job today they will eventually mostly move to the Play Integrity API and will eventually enforce the strong verification level requiring hardware attestation. It would be much better if they instead used the Android attestation API supported by the Android Open Source Project which is also available in any alternate OS based on AOSP. Basic hardware-based attestation is available on every device launched with Android 8. An alternate OS such as GrapheneOS disabling the feature for user installed apps simply means it won't pass checks based on it. Disabling it would not accomplish anything useful. It doesn't leak any information that can't be otherwise obtained but rather provides a way to cryptographically verify the information that's available including verified boot mode, OS signing key, OS hash, OS patch level, device model and also non-hardware-based things verified by the OS like the app id and signing key. GrapheneOS contributed to upstream hardware attestation improvements by making a proposal for much better pinning support which was accepted and implemented in the Android 12 attestation API. Our proposal makes attestation work much better as a user-oriented feature for securing devices with our Auditor app. Pinning has no use when using this feature for anti-cheat, anti-fraud, DRM, etc. since those simply depend on verifying based on the root certificate which will always be vulnerable to bypass via leaked keys from insecure devices. Supporting verified boot and hardware-based attestation is not anti-FOSS or anti-user. GrapheneOS uses attestation as one of the major included security features via our Auditor app. Other apps can also use it to protect user security. What users see as hostile is not universal. Most users want to play competitive games without having other people using software/hardware to cheat. Hardware-based attestation can be used to build much stronger anti-cheat, and some games are doing exactly that with the feature. It's unfortunate that they're currently doing it with the Play Integrity API (or legacy SafetyNet attestation API) since it locks out users on alternate operating systems. If they used the Android attestation API instead, they could avoid locking out users on operating systems like GrapheneOS and others. It's entirely possible for those games to implement this in a way where people with hardware attestation are placed in games together and people without it are kept separate, which is one of the ways this is being implemented. That means at the moment, GrapheneOS users will have a worse experience due to being grouped with nearly all of the people using cheats. We want to get this fixed. It is not anti-user to want a better experience and broader app compatibility for GrapheneOS users. It is not GrapheneOS choosing to use attestation to lock anything down. GrapheneOS only uses attestation if the user chooses to use our Auditor app and that's entirely based around the user protecting their device. It is other developers who want to use attestation in ways that can be seen as hostile to users, and that will be the case regardless of what GrapheneOS does. GrapheneOS does not have significant influence over Android app developers. If we can get a single major app to switch to the Android attestation API and support GrapheneOS and other alternate operating systems, that will be a major accomplishment. PayPal seems to be gradually adopting using Play Integrity attestation and perhaps we can convince them as a starting point. Our users are certainly not going to be unhappy if PayPal continues working on GrapheneOS instead of breaking. Not clear how you get the idea that this is anti-user. > Tragically GrapheneOS doesn't tend to view any Google decisions through a critical lens, which would allow them to see through some of Google's "security features" for what they really are: user-control features implemented solely to ensure that most people do not switch away from the stock OS and continue to consume Google services, handing over their user data in the process. There have been massive privacy and security improvements in each major release of Android for many years. The hardware attestation API released prior to Android 8 is a single feature. SafetyNet attestation and the Play Integrity API are not part of Android itself but rather Google Play. Those were ported to using the hardware attestation API when available but they mostly aren't based on it and don't take much advantage of it. GrapheneOS itself is one of the only projects using Android's hardware-based attestation directly via our Auditor app. We're likely the ONLY software project using the app-generated attest key feature introduced in Android 12 based on our proposal and first shipped on the Pixel 6 because we found issues making it unusable at first which had to be reported and fixed. App-generated attest keys are a different approach to attestation based around generating hardware backed attestation signing keys and pinning those instead of verifying based on a trusted root certificate. This pinning-based approach is not useful for user hostile features and can be supported even on a device not including a trusted attestation root certificate in the secure element. We helped to make hardware-based attestation into a feature that's much more useful for protecting users and which can exist without the part that allows building user hostile features. The attestation root is still useful for verifying the initial pairing for our Auditor app or other use cases based on Trust On First Use via pinning.

94427 4y ago
You're saying the quiet part out loud: that the AOSP/GrapheneOS security model is designed not only to protect users from attacks, but also to protect apps from users, which I find quite abhorrent. You may disagree, and some others may disagree, but I think your users should at least be aware of your stance on this. It's my hunch that most of your users would agree with me that this is not a good thing, if only they realized that it was happening and actively encouraged by your project. > They can have an application process for operating systems to be approved by their risk/anti-fraud/anti-cheat departments. Or they can just let me run whatever I want on the device that I bought. Anyone should have the ability to spin up their own fork of GrapheneOS or AOSP and make changes that improve their experience. This is one of the basic principles of free and open source software (FOSS). There is a fundamental difference between "open source" and "free and open source". If you want your project to fall into the latter category, it must respect the user's freedom "to study how the program works, and change it so it does your computing as you wish". Users cannot do this if hardware attestation as promoted by GrapheneOS is implemented on a large-scale. See https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html > anti-cheat, anti-fraud There are better, more effective ways of enforcing these things that don't rely on apps policing which OS users are allowed to use, like server-side checks. They're already using these approaches and have been for a long time on platforms without guaranteed access to hardware attestation, which is most platforms besides mobile phones. I don't think it's worth giving up user freedom entirely just so there are less cheaters in Fortnite, or so app developers have excuses to be lazy with regards to anti-fraud, anti-reverse-engineering, etc. > Basic hardware-based attestation is available on every device launched with Android 8. An alternate OS such as GrapheneOS disabling the feature for user installed apps simply means it won't pass checks based on it. Disabling it would not accomplish anything useful. I didn't suggest that you disable it. The problem is that you're using your website and platform to promote usage of the feature in an anti-user way. > GrapheneOS uses attestation as one of the major included security features via our Auditor app. This is a valid use case of hardware attestation. It allows the user to verify that they're running the OS that they think they're running. That's a good thing. When I say "SafetyNet hardware attestation" I'm solely referring to the anti-user practice of enforcing a list of "approved" operating systems via hardware attestation. SafetyNet explicitly provides an API for this. I'm not sure if the AOSP attestation API does, but it's not difficult to implement one as you describe in your article. > Our users are certainly not going to be unhappy if PayPal continues working on GrapheneOS instead of breaking. Not clear how you get the idea that this is anti-user. If PayPal would stop doing pointless hardware attestation verification in the first place, you wouldn't have that problem, and neither would any other Android fork. As you said it's not likely that PayPal will do anything you recommend anyway. So why not use your platform to promote better, non-anti-user solutions to the problems that hardware attestation is unfortunately used to solve? > We helped to make hardware-based attestation into a feature that's much more useful for protecting users and which can exist without the part that allows building user hostile features. I appreciate that you've worked to support ways to use the feature that are the opposite of anti-user and actually enhance user security. That is definitely a positive contribution. But keep in mind that the underlying motives behind implementing such features in the first place are not always "to improve user security". As it stands, most Android applications do not use hardware attestation to check if you're using an approved OS. My point is, that we should encourage developers to keep it that way, rather than encouraging them to use it, but add specific alternate operating systems to their list. I honestly think it's a little more likely that they drop hardware attestation altogether, if presented with good arguments for why it's not only an inferior approach to traditional methods, but also atrocious for user freedom. It's also less burden on them than developing their own system where they have to keep up to date with the latest signing keys as described in your article.

by strcat 4y ago

94427 4y ago

You're saying the quiet part out loud: that the AOSP/GrapheneOS security model is designed not only to protect users from attacks, but also to protect apps from users, which I find quite abhorrent. You may disagree, and some others may disagree, but I think your users should at least be aware of your stance on this. It's my hunch that most of your users would agree with me that this is not a good thing, if only they realized that it was happening and actively encouraged by your project. > They can have an application process for operating systems to be approved by their risk/anti-fraud/anti-cheat departments. Or they can just let me run whatever I want on the device that I bought. Anyone should have the ability to spin up their own fork of GrapheneOS or AOSP and make changes that improve their experience. This is one of the basic principles of free and open source software (FOSS). There is a fundamental difference between "open source" and "free and open source". If you want your project to fall into the latter category, it must respect the user's freedom "to study how the program works, and change it so it does your computing as you wish". Users cannot do this if hardware attestation as promoted by GrapheneOS is implemented on a large-scale. See https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html > anti-cheat, anti-fraud There are better, more effective ways of enforcing these things that don't rely on apps policing which OS users are allowed to use, like server-side checks. They're already using these approaches and have been for a long time on platforms without guaranteed access to hardware attestation, which is most platforms besides mobile phones. I don't think it's worth giving up user freedom entirely just so there are less cheaters in Fortnite, or so app developers have excuses to be lazy with regards to anti-fraud, anti-reverse-engineering, etc. > Basic hardware-based attestation is available on every device launched with Android 8. An alternate OS such as GrapheneOS disabling the feature for user installed apps simply means it won't pass checks based on it. Disabling it would not accomplish anything useful. I didn't suggest that you disable it. The problem is that you're using your website and platform to promote usage of the feature in an anti-user way. > GrapheneOS uses attestation as one of the major included security features via our Auditor app. This is a valid use case of hardware attestation. It allows the user to verify that they're running the OS that they think they're running. That's a good thing. When I say "SafetyNet hardware attestation" I'm solely referring to the anti-user practice of enforcing a list of "approved" operating systems via hardware attestation. SafetyNet explicitly provides an API for this. I'm not sure if the AOSP attestation API does, but it's not difficult to implement one as you describe in your article. > Our users are certainly not going to be unhappy if PayPal continues working on GrapheneOS instead of breaking. Not clear how you get the idea that this is anti-user. If PayPal would stop doing pointless hardware attestation verification in the first place, you wouldn't have that problem, and neither would any other Android fork. As you said it's not likely that PayPal will do anything you recommend anyway. So why not use your platform to promote better, non-anti-user solutions to the problems that hardware attestation is unfortunately used to solve? > We helped to make hardware-based attestation into a feature that's much more useful for protecting users and which can exist without the part that allows building user hostile features. I appreciate that you've worked to support ways to use the feature that are the opposite of anti-user and actually enhance user security. That is definitely a positive contribution. But keep in mind that the underlying motives behind implementing such features in the first place are not always "to improve user security". As it stands, most Android applications do not use hardware attestation to check if you're using an approved OS. My point is, that we should encourage developers to keep it that way, rather than encouraging them to use it, but add specific alternate operating systems to their list. I honestly think it's a little more likely that they drop hardware attestation altogether, if presented with good arguments for why it's not only an inferior approach to traditional methods, but also atrocious for user freedom. It's also less burden on them than developing their own system where they have to keep up to date with the latest signing keys as described in your article.