Post B45SYFoqQ62x1FcqO0 by GrapheneOS@grapheneos.social
(DIR) More posts by GrapheneOS@grapheneos.social
(DIR) Post #B45PHeslgMetxxr768 by GrapheneOS@grapheneos.social
4 likes, 6 repeats
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.https://uattest.net/
(DIR) Post #B45RfovYBf2pyho2ls by eskuero@mstdn.io
1 likes, 0 repeats
@GrapheneOS sounds like they are just trying to ride the wave of Europe trying to break free of their reliance on american digital companies, which I completely agree, to grab power for themselves, which is still shitty and nothing to celebrate.Thankfully my bank's app still works fine with gos and they also allow full web access anyway
(DIR) Post #B45SYApixOmNYWzyYy by GrapheneOS@grapheneos.social
1 likes, 0 repeats
Google's Play Integrity API is a horrible system enforcing using devices officially licensing Google Mobile Services. It permits those regardless of how many years behind they are on security patches. The solution to this isn't another anti-competitive system based in Europe.
(DIR) Post #B45SYB7nsBF0SbSPk8 by GrapheneOS@grapheneos.social
1 likes, 1 repeats
Play Integrity API should be regulated out of existence rather than making another system where companies permit their own products while disallowing others. It shouldn't be legal when Google does it and it shouldn't be legal when Volla and Murena do it either. This is wrong.
(DIR) Post #B45SYDu5Xd3L4w40HY by GrapheneOS@grapheneos.social
1 likes, 0 repeats
Hardware-based attestation has valid use cases including the Auditor app on GrapheneOS for protecting users. The way these companies are using it serves no truly useful purpose beyond giving themselves as unfair advantage while pretending it has something to do with security.
(DIR) Post #B45SYEsLvZG65qG8DQ by GrapheneOS@grapheneos.social
1 likes, 1 repeats
If banks and governments insist on checking devices for security they should define actual standards. It should be possible for any tiny project to be certified at no cost and the standards should be fairly enforced so a mainstream device without current patches is disallowed.
(DIR) Post #B45SYFoqQ62x1FcqO0 by GrapheneOS@grapheneos.social
1 likes, 1 repeats
Volla, Murena and iodé sell products with atrocious security. They fail to provide important patches and protections while misleading users with inaccurate claims about privacy and security. That includes setting an inaccurate Android security patch level despite missing patches.
(DIR) Post #B45SYGkcxGGduSezS4 by GrapheneOS@grapheneos.social
1 likes, 0 repeats
These companies should not have any say over which devices can be used for European banking and government apps. It will reduce competition and reduce security exactly as the Play Integrity API is already doing. The EU should ban using attestation to determine OS compatibility.
(DIR) Post #B45SYHh7Rn3Ups1hce by GrapheneOS@grapheneos.social
1 likes, 1 repeats
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.
(DIR) Post #B45SnfrjrSOs94Keci by Phobos1641@mstdn.jp
1 likes, 0 repeats
@GrapheneOS Any sort of regulation by governments would, inevitably, be in favor of things like the Integrity API; not against it.I am convinced we *will* see proposals for regulations favoring exactly this in at most a year or two.
(DIR) Post #B45T31c3HxVvw6JZLM by dristor@masto.es
1 likes, 0 repeats
I know this has probably been asked to death, but how viable would be the develpment of an android-linux compatibility layer (same as wine) in order to have secure linux phones running android apps?
(DIR) Post #B45TIrxcwUG8dNxfJA by agowa338@chaos.social
1 likes, 0 repeats
@GrapheneOS Yea, kill all anti-circumvention laws. It is time. We only implemented them because the US pressured us to do so with "tarrifs", but we now have tarrifs (as well as a quite unpredictable application of them).So middle finger to the US and undo all anti-circumvention laws.
(DIR) Post #B45VqIRBit7uDOr5Pc by lumi@snug.moe
0 likes, 0 repeats
@GrapheneOS what the fuck. that is absolutely horrifyingremote attestation is a technology that has no good uses. it's just drmeveryone should have the freedom to run whatever they want on their own devices. this freedom should never be taken away and it should be enshrined in law that it can never be taken awaysomeone else should not be able to decide whether my device is "secure" enough for their purposes. this is reverse security. the os needs to boot securely and the attestation chain should go upwards, with each stage verifying the ones on top of it. not this opposite world bullshit
(DIR) Post #B45WBOM6umFueQXV5s by lumi@snug.moe
0 likes, 0 repeats
@GrapheneOS apps should not even have the privilege to check these things. it's a complete violation of a security boundary
(DIR) Post #B45XGaDIM4ZIpUSHjs by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@lumi Android's hardware-based attestation API would not cause these issues if it only had the pinning-based attestation we use as the basis for Auditor and omitted root-based attestation. The issue is having attestation roots which determine which hardware and operating systems are valid. Hardware-based attestation can be provided without any centralized authority determining which hardware and software is valid. It would still provide nearly all of what our Auditor app uses without roots.
(DIR) Post #B45XGaeEju7SB33njU by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@lumi We support hardware-based attestation based on pinning for protecting users against attacks. Root-based attestation has extremely weak security due to depending on the entire ecosystem of devices not having vulnerabilities enabling leaking keys chaining up to the root. Pinning-based attestation can be used as a very strong security feature. Check out our Auditor app. It does use the root-based attestation for first verification but it would provide most of what it does without it.
(DIR) Post #B45XGapw2PTclKX8y0 by lumi@snug.moe
0 likes, 0 repeats
@GrapheneOS does this mean, if i build grapheneos myself and flash it on my device, i could still run all these applications?and i mean without contacting any third party or anything like thatedit: woops. replied to the wrong post. was meaning to reply to the latest one. sorry
(DIR) Post #B45Xhk5Nl2qHGbhkCe by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45XhkMkiSjk8TpcHI by lumi@snug.moe
0 likes, 0 repeats
@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?
(DIR) Post #B45XsMb1Qr7hbHZIsC by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45XsMpYYokWKMMuWm by lumi@snug.moe
0 likes, 0 repeats
@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 backwardsif 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 implementedof 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
(DIR) Post #B45Y0eTKqyNtMHvQFk by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45Y0eg65Wanzrtc92 by lumi@snug.moe
0 likes, 0 repeats
@GrapheneOS yeah, i agree. if it's my device, i should be able to do whatever the heck i please
(DIR) Post #B45Y7E2rVTdPQKg2dM by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45Y7ELeNcfCMbT2v2 by lumi@snug.moe
0 likes, 0 repeats
@GrapheneOS i think i might be confused as to what the difference between root-based and pinning-based attestation isis the one allowlisting the app or the system?
(DIR) Post #B45YX00IKp5JP7lYUS by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45YX0CLc0j40VPBHE by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45YX0NgvpneZgiExU by lumi@snug.moe
0 likes, 0 repeats
@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 nowi 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
(DIR) Post #B45YgLIOXcaw2vggaW by lumi@snug.moe
0 likes, 0 repeats
@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?
(DIR) Post #B45ZZECMd8m1xg2Q8u by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45ZZEQBnjpgeYVSgy by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45ZZEa7Cplx9L9OAC by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45ZZEmWShhHloxIVE by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B45ZZEzdfwBmQV5lwm by lumi@snug.moe
0 likes, 1 repeats
@GrapheneOS yeah. in general, security relies on freedom, security without freedom is very sketchy and on an extremely shaky groundpeople 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 elseartificial restrictions of what apps you can use are never okay, anything anti-freedom is inherently anti-security
(DIR) Post #B45c7GrbQZYpyughiy by zaire@fedi.absturztau.be
0 likes, 0 repeats
@eskuero @GrapheneOS :neofox_thumbsdown: torment nexus:neofox_thumbsup: european torment nexus
(DIR) Post #B45c7H68YXBehzUJNY by eskuero@mstdn.io
0 likes, 0 repeats
@zaire wat
(DIR) Post #B45rfaLazawRZFXMUS by lunareclipse@snug.moe
1 likes, 0 repeats
@lumi @GrapheneOS IMO remote attestation really only has a place in organizations that provide managed devices to members, for verifying the integrity of the device as whatever threat model the organization has requires.For personal devices it enables a lot of anti consumer uses.
(DIR) Post #B45rfaYME99MCpVYNk by lumi@snug.moe
0 likes, 0 repeats
@lunareclipse @GrapheneOS in my views it's a pandora's box that should never be opened, the gigantic downsides outweigh the marginal upsides by quite a lot
(DIR) Post #B463lDpioLrMve5BZY by whitequark@social.treehouse.systems
1 likes, 0 repeats
@GrapheneOS are you talking with policymakers about this?
(DIR) Post #B46PIGjf8iHUWWqcOu by wombatpandaa@mastodon.social
0 likes, 0 repeats
@eskuero @GrapheneOS would I be wrong to say that this alternative attestation would still preferable to Play Store Integrity? Perhaps there is some background to the people behind it that I am missing.