Android provides a standard hardware attestation system with support for alternate operating systems via allowing their verified boot key fingerprints. It's mainly used with Google's root of trust and remote key provisioning service but the API supports alternative roots of trust.

Volla's Unified Attestation is fully built on Android's hardware attestation API. It solely exists to create a centralized authority and service determining what's allowed under their control.

https://mastodon.social/@volla/116238706890314617

Unified Attestation will permit using products from the companies involved in it while forbidding using arbitrary alternatives. They clearly aren't going to enforce reasonable security standards since their products wouldn't meet those. The whole purpose of the system is to permit their products regardless of merit and convince banking/government apps to adopt it.

There's nothing neutral or fair about a system controlled by companies approving their own products while disallowing other options.

Companies forming an anti-competitive cartel providing a service which permitting their products and while disallowing others isn't legal regardless of how they market it. It's not legal when Google does it with the Play Integrity API and it's not legal when it's Volla, Murena and iodé doing it.

We won't be participating in a system which gives these companies veto power over app compatibility on GrapheneOS. These companies will not be given the power to make arbitrary demands of GrapheneOS.

We've been talking back and forth with multiple regulators over the past several years about the Play Integrity API to have action taken against it. Unified Attestation is a massive disruption to our efforts and will get in the way of having regulators take action against this. We've also been considering filing a lawsuit against Google over the Play Integrity API.

Unlike Google, the companies involved in Unified Attestation don't have massive resources to defend their anti-competitive system.

Android's standard hardware API doesn't require delegating verification to a centralized service. One or more neutral organizations could exist certifying devices and operating systems without providing a centralized API. Those organizations could simply provide signed releases with the roots of trust, revoked keys and operating system key fingerprints. Apps could use multiple different certifying organizations. This is already something Android's hardware attestation API fully supports today.
Volla, Murena and iodé are each a for-profit company selling devices. Each of them has failed to keep up with important security patches and protections. Each has marketed their products as providing a level of security they don't provide. It's very clear why these 3 companies want to be in charge of choosing which devices and operating systems people are allowed to use. They want to make sure their products are permitted and want to have an advantage over others to boost their profits.
Unified Attestation is an anti-competitive cartel turning a decentralized decision into a centralized one. Instead of neutral organizations being formed to certify devices without a massive conflict of interest, these companies will sign off on their products regardless of the level of insecurity. Multiple competing companies forming a cartel which locks out other options is not legal. We're fully willing to file one or more lawsuits over this. It should be discontinued now prior to harming us.

@GrapheneOS

Well on the bright side as long as they sign their own insecure crap there will always be enough vulnerabilities to break their entire vendor-lock-in system...

@GrapheneOS Thank you GOS🙏 for defending everyone’s👨‍⚖️privacy.🕵️‍♀️
@GrapheneOS Thank you for working in the peoples favor instead of a profit driven one and thank you for your work on a secure system that protects privacy.
@GrapheneOS
Them being easy to hack means corporations and main states can easily access GDPR or HIPAA data by purchasing it from the dark web or even "hacking themselves"
@GrapheneOS why do we even need them? Like for every other platform, we have a system of just signing executable files. Why can't we do that here? Like have the developers sign their APKs and then keep that signature through the download process and then have like a way to just easily check if that signature is like who actually made it.
@cutesobri It's not possible to install an Android APK without it being signed. Android's package manager performs signature verification, downgrade protection and key pinning at a lower level than the security provided by app stores. The main security app stores exist to provide is enforcing standards on the apps and bootstrapping trust through having signed metadata with downgrade protection for determining the app comes from the app store, and then the lower level system can secure it alone.
@GrapheneOS so we don't need unified atestation at all.
@cutesobri The primary purpose of systems such as Unified Attestation and Play Integrity is to prevent users from controlling apps. This is done by preventing using modified variants of the app or an operating system where users could control the app. The whole point of Unified Attestation is stopping users from being in control of apps. There are companies which insist on having this and there's already a standard Android hardware attestation API which can be used for it without a new system.
@cutesobri Android hardware attestation supports arbitrary roots of trust and arbitrary operating systems via permitting specific verified boot key fingerprints. Unified Attestation uses Android hardware attestation to centralize control over which roots of trust and operating systems are allowed to be used. Android hardware attestation is a far more open system where apps can use one or more sources on which devices / OSes will be allowed. Unified Attestation is designed as a power grab.
@cutesobri If apps implemented support for verifying based on Android hardware attestation, it would be easy for them to add additional sources providing a signed list of which roots should be trusted and which operating systems should be allowed. Unified Attestation could have been designed as providing signed lists for use with the standard Android attestation API. Instead, it's designed as a centralized service used instead of Android hardware attestation with arbitrary sources of trust.
@GrapheneOS @cutesobri this makes a lot of sense, its a lot like how the SSL certs work on websites with multiple root CA. Central trusts are indeed bad no matter who does it.

@cutesobri system attestation checks if the system is "secure" (well, usually that's the purpose), not if the app is authentic

@GrapheneOS

@risc @cutesobri It does check that the app is genuine but in order to do that it has to check that the hardware, firmware and operating system is genuine and it needs to be an operating system not permitting modifying or changing the behavior of the app in relevant ways without it being possible to detect it. The whole reason that it's verifying the hardware and OS is in order to prevent changing how the app works. Preventing the user changing the app is the focus, not protecting from malware.
@risc @cutesobri It's primarily promoted as protecting from malware but that's not the genuine primary purpose. It doesn't actually provide any significant protection against malware. Nearly none of the companies using it are willing to ban using devices with years of missing security patches, but they're willing to ban using alternatives. Unified Attestation is an attempt by the 3 companies involved to form a new anti-competitive, centralized system where they're the ones benefiting from it.

@GrapheneOS

You should send all of this as a DMA complaint to the @EUCommission

@GrapheneOS Reading GrapheneOS posts is just me going "based! yeeeah thats pretty based!" over and over 😂❤️
@GrapheneOS Off topic: Have you considered raising the character limit on grapheneos.social?
@31113 It was considered, but ultimately decided against, since Mastodon doesn't natively offer an option to change the character limit, so it would require manually patching the code. https://grapheneos.social/@GrapheneOS/115463582032498642
GrapheneOS (@[email protected])

@[email protected] @[email protected] There isn't even build configuration to increase Mastodon's character limit. It requires changing it in multiple places in the code. We're not using a patched fork of Mastodon like infosec.exchange but rather the official upstream releases. We would have to deal with it ourselves as we don't want to use a fork.

GrapheneOS Mastodon

@GrapheneOS does nothing and wins (as always).

Based behaviour, indeed.