← Back to context

Comment by grapheneos

5 days ago

GrapheneOS is open source. This has no connection to open or closed source. GrapheneOS has heavily pushed back against apps using remote attestation to restrict which operating systems and hardware can be used. When apps are unwilling or unable to remove it such as due to government regulations, we try to convince them to permit GrapheneOS and other alternatives via a standard Android API instead of only using the Play Integrity API.

Banks are increasingly adding checks for Google certified devices. In the EU, there are regulations requiring banks to start verifying device integrity. It's headed that way worldwide with a growing number of regulations and industry standards requiring it. Apple's App Attest API and Google's Play Integrity API have repeatedly been the only options recommended by the EU which has contributed to the worsening situation in the EU in particular. We convinced the EU to remove those specific examples from several official standards. No one has been able to convince them to stop heading down this path despite a lot of people pushing back against it. We haven't been able to convince them to define actual requirements let alone to require permitting anything which meets those requirements. They give a vague description of what they require doing shaped around the Apple and Google integrity APIs.

We convinced around a dozen banks mostly in the EU to use the standard Android key attestation API included in the Android Open Source Project as an alternative. It allows apps to verify the OS verified boot key hash, patch level, app signing key hash(es) and app version code based on a root of trust. This meets the requirements for the EU standards and enables permitting any alternative with verified boot and a mandatory app sandbox with support for verifying the app's signing key and passing it to the hardware keystores. Other operating systems can publish their signing keys in the signed JSON format we published and ask the same companies to include their keys too.

Once apps implement an alternative to the Play Integrity API to permit a single OS, it's easy for them to add more. The hardest part is getting them to even consider doing it. It's nearly impossible to get in contact with the right people and to convince them to do it. Once we establish that contact and convince them to ship it, it's a lot easier. There has been an ongoing issue of these apps not adding our new verified boot keys which are per-device-model for security reasons similarly to the Pixel OS. We tried to solve that by creating a standard signed JSON format which can be automatically retrieved and used to automatically include the new signing keys. Exactly the same approach can be used to delegate certification and inclusion of arbitrary operating systems to other organizations. It can also be used for handling which roots of trust for non-Google-certified hardware are also permitted.

We would prefer if none of this existed but we don't live in that world and we're doing what we can to convince apps to permit GrapheneOS and other alternatives. We're heavily fighting against it being done in the first place and against more standards and regulations requiring it. We're also fighting against more centralized attestation systems such as the Play Integrity API as opposed to systems with actual standards where anything meeting those standards can be included. It would not be a good thing for there to an EU alternative to the Play Integrity API permitting specific operating systems and devices based on geopolitics and business interests. That would only accelerate adoption of attestation by EU apps which is already happening at a faster pace than elsewhere thanks to both EU regulations and what many of the countries are doing themselves.

If it's impossible build the binary from the source you've been given, then you haven't been given the source. The binary in question is one that passes attestation and secure boot. If I don't have the key, I don't have the source.

MIT allows this (you not giving me the source). GPL2 allows this in some jurisdictions - notably, not in Germany. GPL3 absolutely doesn't, which is the reason Google refuses GPL3 upstreams.

  • Permissively licensed open source code is open source code. Firmware on a secure element can be open source without it being possible to replace it without the signing key on a production device.

    German courts are not bound by precedent in the same way as US courts and you're referring to a specific case in Germany which cannot be broadly applied.

    AOSP ships a lot of GPLv2 code (Linux kernel and OpenJDK libraries among other components) but doesn't use GPLv3 for multiple reasons.

    AOSP used to use a lot of GPLv3 code as part of the toolchain for building AOSP but that was replaced with LLVM, ToyBox and other permissively licensed projects.

  • What part of GPL3 forbids this?

    • "You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License"

      I don't know why some of my comments are being shadowbanned. It might be an AI filter gone awry.

      1 reply →

> GrapheneOS has heavily pushed back against apps using remote attestation to restrict which operating systems and hardware can be used.

This sounds great. Could you give some examples of this pushing back?

  • https://x.com/search?q=from%3A%40grapheneos%20play%20integri...

    Many of our posts about it heavily criticize apps limiting which operating systems and hardware can be used in addition to the Play Integrity API itself. Our focus is mainly on the Play Integrity API because it's the only relevant system resulting in compatibility issues in practice. We don't have to worry about Apple's App Attest API and we aren't aware of any app banning GrapheneOS with the Android key attestation API.

    We've convinced dozens of apps to drop using attestation with user pressure. We've also convinced a much smaller number of apps to at least permit GrapheneOS and other alternatives chosen by them with the Android key attestation API instead of only permitting Google-certified operating systems. We aren't aware of any app using the Android key attestation API in a way which reduces compatibility since apps generally only use the Play Integrity API and have to be convinced to either drop it or at least use an alternative where they can permit non-stock operating systems based on verified boot key hash and non-Google roots of trust.