Conversation

Auditor and AttestationServer split the user-facing information from device verification into 2 sections: hardware attested and OS / app attested. The information from the hardware cannot be tampered by an attacker that has gained root / kernel access in the OS via exploitation.
Image
1
1
OS / app attested information builds upon verified boot authenticating the firmware, kernel / device tree and base userspace OS. The intention is an attacker can't tamper with this weaker subset of information without exploiting the OS and gaining root/kernel in the current boot.
1
2
Auditor version is directly from hardware attested information, as are the non-user-facing app id and signing key fingerprint fields. The rest of the OS/app attested information depends on trust being chained to the app and useEmbeddedDex eliminates semi-persistent trusted state.
1
2
The TEE/HSM obtains OS patch level(s) in early boot and attests to it directly, so an attacker successfully exploiting the OS each boot cannot hold back upgrades without Auditor / AttestationServer detecting it. This is part of the security model for chaining trust to the app.
Replying to
Auditor has a challenging task with a difficult security model. The core functionality depends entirely on the hardware, firmware and OS security model / features. Other than expanding app attested information, it depends on improvements in hardware and OS releases to get better.
1
1
Replying to
A priv-app can't do anything that would compromise the security model. It depends on core components of the OS including system_server, which haven't been allowed to run code from /data for quite some time. Trust in persistent state has also been dropping with each OS release.
2
Show replies