We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it.
-
@GrapheneOS what the fuck. that is absolutely horrifying
remote attestation is a technology that has no good uses. it's just drm
everyone 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 away
someone 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@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.
-
@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.
@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.
-
@GrapheneOS apps should not even have the privilege to check these things. it's a complete violation of a security boundary
@lumi Apps should be able to use pinning-based attestation but root-based attestation as it exists today is inherently anti-competitive and anti-security. It locks people into using less secure hardware and software. The approaches should be differentiated. Any device can provide pinning-based attestation support including software emulation of it if they don't support the security features. Apps can use it with no loss of choice or privacy. Attestation roots are the abusive part.
-
@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.
@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 that
edit: woops. replied to the wrong post. was meaning to reply to the latest one. sorry -
@lumi Apps should be able to use pinning-based attestation but root-based attestation as it exists today is inherently anti-competitive and anti-security. It locks people into using less secure hardware and software. The approaches should be differentiated. Any device can provide pinning-based attestation support including software emulation of it if they don't support the security features. Apps can use it with no loss of choice or privacy. Attestation roots are the abusive part.
@lumi Root-based attestation is can be used to bootstrap pinning-based approach to bootstrap initial trust in a weak way that's vulnerable to leaked keys and trusts a bunch of different parties which is what we do in our Auditor app. The real security model it uses is a Trust On First Use model to provide secure attestation going forward. The problem is Google or this new group declaring themselves as arbiters of what's allowed and using a root CA to allow only business partners.
-
@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 that
edit: woops. replied to the wrong post. was meaning to reply to the latest one. sorry@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 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.
