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.
Conversation
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.
1
I'd be interested in your point of view regarding security on a PC where a user can access any sensible service using a web browser. Most PC can be hacked easily locally or even remotely. How does this compare to the security in a mobile OS?
1
Mobile OS security is drastically stronger, assuming that you're talking about up-to-date iOS or AOSP without the security model and mitigations screwed up. There's not even much of a comparison to make with traditional desktop operating systems which barely have security at all.
1
I see different things mate. Mobile is full of remote, zero clicks, attacks. PCs usually require interaction. Mobile may be a bit harder but the expanded attack vectors compensate for it. And BTW: Secure boot on iOS will show "yes" even when the boot was tampered with ✌️
1
> Mobile is full of remote, zero clicks, attacks. PCs usually require interaction. Mobile may be a bit harder but the expanded attack vectors compensate for it.
You're making some very extraordinary claims without backing them up with any evidence and it doesn't match reality.
1
1
Attacks and persistence are more than a bit harder and I'd hardly say that there are expanded attack vectors. It's not nearly as useful to perform sophisticated attacks on desktops because there's not much of a security model to bypass.
1
Modern Android and iOS security is quite comparable but iOS has much stronger restrictions on what apps can request from users which makes it much more difficult for attackers to accomplish their goals without exploitation. Desktops essentially don't have this security model.
1
And about verified boot, of course exploiting the implementation is possible as with anything else. It's not the usual security snake oil based entirely on obscurity and annoyances where exploitation is not required to bypass it. Same goes for proper pairing-based attestation.
1
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.
1
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.
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
Show replies