Conversation

Mar 14, 2020

Google is really playing a bad game. However, as this is clearly an abuse of dominant position (80% of the mobile market with ##Android) this is clearly the best path for their dismantlement.

Quote Tweet

Christine Hall

@BrideOfLinux

Mar 14, 2020

This sucks: Some apps may stop working on rooted Android phones due to SafetyNet update buff.ly/2TZOeHR

Replying to

and

Those apps are choosing to depend on Play Services and use SafetyNet attestation to verify that it's a certified release without tampering. The issue is ultimately apps choosing to do that not Google improving SafetyNet attestation to make it less trivial for attackers to bypass.

Replying to

and

Users should hav the option to choose what to do with their devices, which apps / processes should have what privileges. Taking this decision from the users is not a solution. #FreeTheSandbox

Replying to

and

Do you want to take away the ability for users to use hardware-based security apps like Auditor? attestation.app/about Users should choose to avoid apps implementing DRM rather than taking away an important hardware-based security feature for protecting users and devices.

attestation.app

Auditor overview

Overview of the Auditor Android app and associated service.

Replying to

and

Letting users have the option to grant special privileges to specific apps or processes doesn't mean that the device is compromised or cannot use together with Auditor

Replying to

and

Auditor can only support OSes leaving the security model for attestation and verified boot intact. If there's a way to grant root access to the application layer, that's not compatible with the security model. Verified boot accomplishes little if persistence as root is supported.

Replying to

Granting the ability to tamper with the core operating system and other applications breaks the security model for verified boot. There has to be a verified core OS not trusting the persistent state (including applications and their permissions) for the security model to work.

Replying to

The hardware-based attestation provides basic information on verified boot state, patch level, etc. The hardware-based attestation feature supports chaining trust through the OS to the app and for that to be meaningful it has to protect Auditor from tampering by other apps, etc.

4:38 AM · Mar 15, 2020Twitter Web App

Replying to

The foundation of Auditor is that an attacker can't fake the hardware-based attestation information without exploiting the bootloader or secure element (or the TEE on lesser devices). OS level checks are given meaning by the hardware-based portion providing the patch level.

Replying to

An attacker can fake OS level checks by temporarily exploiting the OS, but they need to exploit it on each boot and they can't just hold back OS updates without risking detection via patch level from hardware. Auditor is a supplement to verified boot addressing some weaknesses.

Show replies