We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it.
-
@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.
-
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.
@GrapheneOS So if Im understanding this correctly, what GOS wants is for apps to use an API that will interface with a hardware chip like the titan m2 and will report that the bootloader is locked etc and also report the signing key to apps? Then it would be up to the app to trust that key (which necessitates an allowlist of sorts maintained by apps individually). Is my understanding correct?
-
@GrapheneOS So if Im understanding this correctly, what GOS wants is for apps to use an API that will interface with a hardware chip like the titan m2 and will report that the bootloader is locked etc and also report the signing key to apps? Then it would be up to the app to trust that key (which necessitates an allowlist of sorts maintained by apps individually). Is my understanding correct?
@GrapheneOS If that is the case, then IMO uattest is actually better. A CA like uattest, as bad as it sounds, will probably be more amenable to allowing reasonably secure alternative OS like LineageOS. You only need to persuade one entity. While if each app gets to decide then you have to convince each dev, bank, gov to allow your OS. That doesnt sound very practical. And the uattest proposal can be implemented right now on most devices while most devices dont have a security chip at the moment.
-
@dristor Android Open Source Project and GrapheneOS are Linux distributions. GrapheneOS is fully compatible with Android apps and has support for running the vast majority of apps depending on the Play Integrity API. GrapheneOS can run apps for non-Android operating systems via hardware-based virtualization. Hardware-based virtualization support will continue to be fleshed out both for running non-native apps and running Android apps with stronger isolation than the Linux kernel can provide.
Is it me or grapheneos is only supporters on google pixel models ?
If yes why should we give money to google ?
torment nexus
european torment nexus
