We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it.
-
@lumi GrapheneOS supports the Android hardware-based attestation API. The API itself is a neutral approach which can support arbitrary roots of trust, non-stock operating systems verified based on verified boot key fingerprint and also has pinning-based attestation based on a proposal we made to Google before they stopped collaborating with us. Pinning-based attestation can be used with or without chaining up to a root for bootstrapping trust. It could exist without root-based attestation.
@lumi The problem with the Android attestation API is that the documentation and libraries treat Google as the only root of trust and it's also inherently biased towards stock operating systems since it can verify those by simply checking for the green state instead of needing to allowlist keys for the yellow state. Even if apps used hardware-based attestation instead of the Play Integrity API, many wouldn't permit GrapheneOS and they'd still be limiting what people can use if they did allow it.
-
@lumi GrapheneOS supports the Android hardware-based attestation API. The API itself is a neutral approach which can support arbitrary roots of trust, non-stock operating systems verified based on verified boot key fingerprint and also has pinning-based attestation based on a proposal we made to Google before they stopped collaborating with us. Pinning-based attestation can be used with or without chaining up to a root for bootstrapping trust. It could exist without root-based attestation.
@GrapheneOS so, if i built my own aosp rom, or decide to use an emulator run an aosp rom (for compat reasons, not security), could i pin my own certificates, to make (unmodified) apps work on my device without complaining?
-
@GrapheneOS so, if i built my own aosp rom, or decide to use an emulator run an aosp rom (for compat reasons, not security), could i pin my own certificates, to make (unmodified) apps work on my device without complaining?
@lumi Apps don't use the hardware-based attestation API directly in practice by rather using a service like the Play Integrity API choosing what's allowed. Unified Attestation is a group which wants to use hardware-based attestation to choose what's allowed themselves. We don't think hardware-based attestation should be used to choose which operating systems are allowed and also don't agree with this specific group of companies selling insecure products adding vendor lock-in for themselves.
-
@lumi The problem with the Android attestation API is that the documentation and libraries treat Google as the only root of trust and it's also inherently biased towards stock operating systems since it can verify those by simply checking for the green state instead of needing to allowlist keys for the yellow state. Even if apps used hardware-based attestation instead of the Play Integrity API, many wouldn't permit GrapheneOS and they'd still be limiting what people can use if they did allow it.
@GrapheneOS i think it is fundamentally wrong that the app gets to decide what it runs on. it should not have this authority as it is completely backwards
if i wanted to run the most insecure system, i should still be able to run whatever apps i want, as long as all the apis are implemented
of course i don't want to run an insecure system. but it's my device so i should be able to do whatever i want -
@GrapheneOS i think it is fundamentally wrong that the app gets to decide what it runs on. it should not have this authority as it is completely backwards
if i wanted to run the most insecure system, i should still be able to run whatever apps i want, as long as all the apis are implemented
of course i don't want to run an insecure system. but it's my device so i should be able to do whatever i want@lumi Apps wouldn't be able to disallow using operating systems via the hardware attestation API if it only supported pinning-based security and didn't have support for chaining up to a root. It's chaining up to a root which enables trusting only Google's root or specific roots permitted for specific alternate hardware. Similarly, there's the fact that they differentiate green and yellow where green trusts every OS approved by the root CA party vs. yellow requiring allowlisting fingerprints.
-
@lumi Apps don't use the hardware-based attestation API directly in practice by rather using a service like the Play Integrity API choosing what's allowed. Unified Attestation is a group which wants to use hardware-based attestation to choose what's allowed themselves. We don't think hardware-based attestation should be used to choose which operating systems are allowed and also don't agree with this specific group of companies selling insecure products adding vendor lock-in for themselves.
@GrapheneOS yeah, i agree. if it's my device, i should be able to do whatever the heck i please
-
@lumi Apps wouldn't be able to disallow using operating systems via the hardware attestation API if it only supported pinning-based security and didn't have support for chaining up to a root. It's chaining up to a root which enables trusting only Google's root or specific roots permitted for specific alternate hardware. Similarly, there's the fact that they differentiate green and yellow where green trusts every OS approved by the root CA party vs. yellow requiring allowlisting fingerprints.
@GrapheneOS i think i might be confused as to what the difference between root-based and pinning-based attestation is
is the one allowlisting the app or the system? -
@lumi Apps wouldn't be able to disallow using operating systems via the hardware attestation API if it only supported pinning-based security and didn't have support for chaining up to a root. It's chaining up to a root which enables trusting only Google's root or specific roots permitted for specific alternate hardware. Similarly, there's the fact that they differentiate green and yellow where green trusts every OS approved by the root CA party vs. yellow requiring allowlisting fingerprints.
@lumi We don't support using attestation to disallow using hardware or operating systems. We do support having hardware attestation for providing protection against device compromise. The issue is that the features provided can be used to disallow using devices instead of only protecting against compromise and notifying users if something is wrong. Apps notifying users their OS is missing security patches or lacks security features would be fine but we don't agree with banning using it..
-
@GrapheneOS i think i might be confused as to what the difference between root-based and pinning-based attestation is
is the one allowlisting the app or the system?@lumi Root-based attestation is done by verifying certificates up to a root of trust which is a Google certificate authority for Google Mobile Services devices. The Android hardware attestation API is in fact not inherently biased towards Google itself but rather their documentation and open source sample libraries hard-wire their roots as the only ones which should be checked.
Android supports apps generating attest keys in the hardware keystore to use for signing attestations instead.
-
@lumi Root-based attestation is done by verifying certificates up to a root of trust which is a Google certificate authority for Google Mobile Services devices. The Android hardware attestation API is in fact not inherently biased towards Google itself but rather their documentation and open source sample libraries hard-wire their roots as the only ones which should be checked.
Android supports apps generating attest keys in the hardware keystore to use for signing attestations instead.
@lumi These attest keys are meant to be pinned after the initial use and then used to enforce that subsequent attestations have trust chained from the initial verification. As long as the initial key was securely generated in the TEE or secure element and those have not been compromised with exploits then compromised apps or a compromised OS cannot fake the data. It chains trust from an initial starting point and does not limit which hardware or software can be used, the root approach does.
-
@lumi These attest keys are meant to be pinned after the initial use and then used to enforce that subsequent attestations have trust chained from the initial verification. As long as the initial key was securely generated in the TEE or secure element and those have not been compromised with exploits then compromised apps or a compromised OS cannot fake the data. It chains trust from an initial starting point and does not limit which hardware or software can be used, the root approach does.
@lumi The pinning-based approach was implemented so that you can verify the initial chain based on the root by enabling attestation for the attest key itself but it doesn't have to be used that way. It can be used to solely provide pinning-based attestation. Our Auditor app uses both but we don't consider root-based attestation to have much value. Any exploit of any TEE or secure element on any Android device that's certified can be used to get keys chaining to a root. It's not a secure system.
-
@lumi These attest keys are meant to be pinned after the initial use and then used to enforce that subsequent attestations have trust chained from the initial verification. As long as the initial key was securely generated in the TEE or secure element and those have not been compromised with exploits then compromised apps or a compromised OS cannot fake the data. It chains trust from an initial starting point and does not limit which hardware or software can be used, the root approach does.
@GrapheneOS oh! that makes sense then. so the app is checking that the system it initially verified on has the same trust as the system it is on right now
i still don't think it's the app's job to do this, but if people really want this, then heh, i don't really care -
@GrapheneOS oh! that makes sense then. so the app is checking that the system it initially verified on has the same trust as the system it is on right now
i still don't think it's the app's job to do this, but if people really want this, then heh, i don't really care@GrapheneOS or, more so, that it is the same system that it initially verified on, and so it will pass initial verification no matter what, even if it's my own build of a rom, or even me using it in an emulator?
-
@GrapheneOS oh! that makes sense then. so the app is checking that the system it initially verified on has the same trust as the system it is on right now
i still don't think it's the app's job to do this, but if people really want this, then heh, i don't really care@lumi Yes, and the attestation metadata includes certain information set by the OS developers such as the patch level for the OS. As an example of how this can be used, consider 2 people talking to each other on Signal who both want it to be a highly secure conversation. There could be a way to opt-in to sending each other attestations as part of the verification. It could then enforce that it's the same devices talking to each other and that the patch level continues to be updated, etc.
-
@ftm Murena and iodé relentlessly spread false claims about GrapheneOS and our team. That includes personall targeting our team with absolutely vile bullying and harassment.
Here's the founder and CEO of /e/ and Murena linking to content from a neo-nazi conspiracy site targeting our founder with blatant fabrications including links to harassment content from Kiwi Farms users:
https://archive.is/SWXPJ
https://archive.is/n4yTOVolla is fully aware of all this but works closely with these groups.
@GrapheneOS @ftm Ah geeze, here we go again
-
@lumi Yes, and the attestation metadata includes certain information set by the OS developers such as the patch level for the OS. As an example of how this can be used, consider 2 people talking to each other on Signal who both want it to be a highly secure conversation. There could be a way to opt-in to sending each other attestations as part of the verification. It could then enforce that it's the same devices talking to each other and that the patch level continues to be updated, etc.
@lumi As an example, pretend that one of the 2 devices is compromised and the attacker stops allowing security patches. This would be visible in the attestation metadata and the attacker wouldn't be able to fake it without an early boot chain or secure element exploit. It could similarly provide more than it does today such as warning if the device hasn't been rebooted for a certain amount of time. This would all work fine without root-based attestation. Our Auditor app provides this stuff.
-
@lumi As an example, pretend that one of the 2 devices is compromised and the attacker stops allowing security patches. This would be visible in the attestation metadata and the attacker wouldn't be able to fake it without an early boot chain or secure element exploit. It could similarly provide more than it does today such as warning if the device hasn't been rebooted for a certain amount of time. This would all work fine without root-based attestation. Our Auditor app provides this stuff.
@lumi Most of the companies using attestation want root-based attestation. They primarily want to use it to control which hardware and software people can use. Useful hardware-based attestation can be provided without enabling apps to do this. It can also be useful without being available to user installed apps but it's not harmful for it to be available to user installed apps if it doesn't provide a root-based system that's inherently anti-competitive. It's even actually very anti-security.
-
@lumi Most of the companies using attestation want root-based attestation. They primarily want to use it to control which hardware and software people can use. Useful hardware-based attestation can be provided without enabling apps to do this. It can also be useful without being available to user installed apps but it's not harmful for it to be available to user installed apps if it doesn't provide a root-based system that's inherently anti-competitive. It's even actually very anti-security.
@lumi Disallowing people using GrapheneOS is anti-security and that's exactly what apps using either the Play Integrity API or Unified Attestation API are going to be doing. Both are going to be allowing extremely insecure options without basic patches and protections but yet not permitting a hardened OS with much better security. As far as we're concerned the whole approach is both fraudulent and violates antitrust law. Fighting Google's influence is hard but fighting this won't be hard.
-
@lumi Disallowing people using GrapheneOS is anti-security and that's exactly what apps using either the Play Integrity API or Unified Attestation API are going to be doing. Both are going to be allowing extremely insecure options without basic patches and protections but yet not permitting a hardened OS with much better security. As far as we're concerned the whole approach is both fraudulent and violates antitrust law. Fighting Google's influence is hard but fighting this won't be hard.
@GrapheneOS yeah. in general, security relies on freedom, security without freedom is very sketchy and on an extremely shaky ground
people should be able to install whatever they like and be able to use the apps they want, be it grapheneos, another android rom, mobile linux, or whatever else
artificial restrictions of what apps you can use are never okay, anything anti-freedom is inherently anti-security -
@GrapheneOS and what exactly is your conflict with volla. I get the iodé and Murena part, but what's wrong with Volla?
@ftm @GrapheneOS it is worth checking Volla's source trees. They use ancient kernels firmware blobs, etc. It's pretty much the same issue as GMS Android, the whole attestation thing becomes security theater if phones with years of known holes get attested.
