SafetyNet attestation is snake oil and will remain that way until they have a hard dependency on hardware-based attestation. Once they do, it will be a weak security feature providing low assurance due to the trust model for keys, but at least it won't be the theatre it is now.
Conversation
SafetyNet attestation was never intended to be provide high assurance. They provide direct access to hardware-based attestation for those that need it. They're working on providing better support for a strong pairing-based model which will hopefully be available in Android 11.
1
Auditor currently doesn't get exactly what it needs from the API and has to pin the batch key instead of what it really wants which is an app key used internally by the TEE/SE to sign attestations which can be pinned and cannot be obtained by exploiting the TEE/SE elsewhere.
1
Auditor uses the SE-based keystore (StrongBox) for devices like the Pixel 3 and newer Samsung devices and with direct support for pairing it will become very high assurance. Weak point will definitely be verified boot rather than the design of hardware-based attestation for it.
1
So according to your own arguments if we grant a specific process/app extended privileges it shouldn't be a problem due to no persistence (access can be revoked after reboot) :)
1
Having root exposed only via adb shell with physical access is much less of a problem but isn't a non-issue. A production user build of AOSP doesn't have root access but a developer-oriented userdebug build has `adb root` and `su` only usable via `adb shell` which isn't terrible.
1
It's a security issue and doesn't belong on devices where the user doesn't explicitly want it. Trusting attached computers by whitelisting their ADB client key is already problematic and having root makes it substantially more dangerous. What if that computer is compromised?
1
It weakens the security model used by Auditor but doesn't totally destroy it. Also worth noting that simply having full read/write access as root to the entire file system won't actually provide access to all app data. Need to have further access like ptrace to use keystore keys.
1
I don't think there's much issue with a developer using a userdebug build in production if ro.adb.secure=1 is set, particularly if they only trust the same machine they already trust to build the OS, since that's not extending trust further. Only weakens security a bit.
1
It's different to have that on an end user device where they aren't a developer with the appropriate knowledge and awareness of how the platform works. I don't see much issue with publishing userdebug factory images with separate signing keys and over-the-air updates though.
1
If someone is going to go through the effort of unlocking the device, flashing factory images and locking it they might as well have official userdebug images available. Better for them to use those than something else. I'd do it for GrapheneOS if there weren't limited resources.
I don't have time/resources to make separate userdebug builds for every device. Google could easily do that for Pixels. Just sign with different keys so it doesn't pose any risk to verified boot / update verification with stock OS and requires flashing the AVB pubkey to lock it.
1
It won't have the green boot state and won't pass CTS due to exposing root access via adb and the ability to bypass whether an app can be debugged, separately from root access, so it's not going to be SafetyNet attestation approved and apps checking for that aren't going to work.
1
Show replies