We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it.
-
@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.
-
@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.
@danieldk @ftm It's inherently security theatre because neither companies and governments are willing to ban using the majority of Android phones which is what would happen if even basic security standards such as keeping up with High and Critical severity patches from AOSP and the SoC / radio vendors was enforced. Instead, they're disallowing people having the freedom to use their hardware or OS of choice while not enforcing even basic security standards. They're disallowing better security.
-
Murena and iodé are extremely hostile towards GrapheneOS. They've spent years misleading people about it with inaccurate claims to promote their insecure products. We'll never work with them. Volla, Murena and iodé should have no say in which OS people can use on their devices.
There's no legitimate purpose for either Play Integrity or Unified Attestation to exist. Both will inherently fail to uphold even basic security standards since otherwise their own products wouldn't be allowed. Root-based attestation is also inherently not a secure approach.
-
We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it. Companies selling phones should not be deciding which operating systems people are allowed to use for apps.
The Nostr based app store called "Zapstore" has already solved this problem. Zapstore empowers developers to sign and release apps over the Nostr protocol without needing to get permission from any app store or from any governnent or any other entity.
The Zapstore already has most of the useful F-Droid apps, and anyone can release more apps.
Zapstore.dev
-
There's no legitimate purpose for either Play Integrity or Unified Attestation to exist. Both will inherently fail to uphold even basic security standards since otherwise their own products wouldn't be allowed. Root-based attestation is also inherently not a secure approach.
Having a European version of the Play Integrity which permits people to use insecure products from specific European companies participating in it while disallowing using arbitrary hardware or software is the opposite of a solution. It's more of the same anti-competitive garbage.
-
@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.
@ftm @GrapheneOS Another thing I don't really like about Volla is that they seem to do Eurowashing.
Maybe (some part of) the Volla Phone Quintus is assembled in Europe, but the phone seems to be a rebranding of the Daria Bond 5G (stated by multiple sources, including the PostmarketOS wiki) with a markup of ~550 Euro (~160 -> 719 Euro): https://www.amazon.ae/Android-Smartphone-Storage-Octa-Core-Monetization/dp/B0DDYDZC4V?th=1
The Daria Bond 5G is sold by an UAE company that also maintains the Volla Phone Quintus source trees (well, 'maintain' is a big word).
-
@zaire wat
-
Murena and iodé are extremely hostile towards GrapheneOS. They've spent years misleading people about it with inaccurate claims to promote their insecure products. We'll never work with them. Volla, Murena and iodé should have no say in which OS people can use on their devices.
@GrapheneOS ich erlebe das genauso umgekehrt von euch gegenüber den anderen Custom ROMs. Ihr seid denen nicht weniger feindlich eingestellt wie ihr das von ihnen behauptet.
torment nexus
european torment nexus
