Android Developer Verification: Threat masquerading as protection

> giving the option to completely block attestation and DRM API would be a good start.

Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.

GrapheneOS does provide a toggle to block apps using the Play Integrity API because we found a small subset of apps using it are not yet enforcing providing a result due to being in the process of phasing it in. This doesn't apply to DRM or direct use of hardware attestation. We have a planned feature for blocking access to DRM as an attack surface reduction feature since it can eliminate a little bit of OS attack surface and a significant part of the TrustZone attack surface. Hardware key attestation has almost no attack surface and doesn't provide any info not available other ways.

> this is false, the attestation middleman Google server can fingerprint your unique device serial (in-silicon key) whenever it wants.

That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue. That's why they made a point of how they separated the systems for it, but you don't have to trust that on GrapheneOS. If you use a VPN it's irrelevant.

> the DRM situation is even worse as ANY app can fingerprint your device serial and I don't mean just the DRM ID. anyone who has a license server certificate can fingerprint the DRM key in-silicon.

That's not an accurate description. It's also implemented via our server by default too. If you use a VPN that's not relevant.

The MediaDRM ID is also widely misunderstood since it is scoped per-app rather than being global. The best way to address it is our planned DRM toggle.

> if you were serious about privacy you would provide the option to completely disable that functionality in grapheneos

We disabled DRM provisioning and usage by default in Vanadium years ago and have a publicly visible feature planned for providing a toggle for native apps being able to use it. We don't have unlimited resources to get everything we want quickly implemented.

> how many of your users are even aware that google can track them across factory resets (or anyone who has a license server certificate)?

You're making attestation and DRM key provisioning sound far worse than it is. It's not fingerprinting and it doesn't give them another way to track users in practice. If services want to share data with Google then they don't need any of this to do it and it doesn't inherently result in anything being shared with them that's in any way useful. We have a planned feature for providing a DRM toggle but it's nearly entirely wanted for security, not privacy, and there are bigger security features to implement. There are many planned privacy features which would make a major impact rather than near zero as this would.

Preventing fingerprinting by websites is a very hard problem especially considering things like using timing and performance measurements for it. That's going to be a priority for us. Doing it for native apps would require a massive amount of changes to get anywhere close to websites. We could add 100 features reducing fingerprinting for native apps without accomplishing anything significant. We're focused on privacy features with a larger impact.

Their goal is to hold a standard of security and privacy that can be trusted. They want the brand to be associated with that level of security and privacy. Sticking to Pixel allows them to leave their brand undiluted in this respect.

    > Blocking access to attestation or DRM will prevent using the functionality of the app depending on it or the whole app unless it's implemented incorrectly.

which is what the user would want or be fine with in this case... present the option.

    > That's not how the hardware key attestation system works. Only key provisioning uses their service and if you don't trust their separation of the provisioning with the frontend, that's fine since we run it through our own frontend by default so they can't connect an IP with the provisioned key which would be the only real privacy issue.

you appear to not know how it works, which doesn't inspire confidence.

both remote attestation packets and DRM license request responses contain a unique hardware identifier that can be extracted with knowledge of the right secret information.

in the case of attestation, privacy CA and the verifier must collude to do this (technically, you need the ephemeral key provisioning packet + attestation packet + secrets). blind signatures were proposed to make this impossible and REJECTED. using a proxy/VPN does not prevent having your unique hardware identifier be attributed to the attestation in this scenario. also note how when you attest to google both the CA and verifier are one and the same...

with DRM I'm not even aware of any effort to not directly expose the KeyBox public key to a license server, and ANY app can make use of DRM API. you do need the license server's private key to extract the identifier however.

Some day the right evil person will gain access to these things and use these fascinating capabilities. I hope it will take a long time.

In the meantime we might try think of a solution.

Thats are improving peoples security overall by only using pixels at this time. Nothing else currently meets the hardware security requirements except pixel devices. To use subpar hardware would set the security back substantially. They are not going to compromise on security for the sake of broad device support.

Also note that Motorola Mobility has stepped up to provide the needed hardware security features. So it will expand to a subset of Motorola devices next year.