Each boot stage verifies the next set of boot stages, chaining from the hardware root of trust all the way to the OS partitions (vbmeta, boot, dtbo, system, vendor), radio firmware, etc.
I don't know what you mean by "hidden" TEE and the TEE isn't a boot stage leading to the OS.
Conversation
Replying to
Secure boot is not system attestation. It only verifies on time of boot. So are we still talking attestation or just the chain of trust on boot?
1
To be blunt, measured boot is not system attestation.
Even if verifying each of the boot images , stage by stage, this process maybe have the name " System Attestation on boot".
But I would be very reserved to call it system attestation ,at all.
1
1
System Attestation is a process and Measured boot is one component of it.
At its beginning indeed, but only measured boot is not by itself system attestation.
Because "only on boot , until next boot" are already two conditions up.
TBH I thought what you did was attestation app
1
1
Replying to
It is an attestation app and it relies entirely on the attestation capabilities provided by the firmware / hardware. I'm not sure what you expect it to have beyond measured boot and whatever runtime mitigations exist for the device, such as kernel monitoring on Samsung devices.
1
1
1
If the TEE / hardware-backed keystore consider the device compromised, they won't provide the signed result. There's a limit to what can actually be done in practice though. I don't think active monitoring has much value in reality but the app inherently benefits if it's present.
1
1
The work I'm doing on the attestation app / server is making the underlying, rarely used hardware/firmware capabilities usable for end users to perform local and remote device integrity and identity verification. I can't do more than working with the existing capabilities though.
2
1
Replying to
True, great use case - Enabling the End User!
I just thought/assumed it was deeper integrated into the low-level side of Android ;-)
1
1
Replying to
It's directly built on the hardware-backed keystore including the key attestation API, so it's essentially a frontend to firmware / hardware capabilities. It doesn't get much from the OS beyond gathering some configuration values to include in the reported data as "OS verified".
2
1
1
The API it uses specifically supporting attestation is developer.android.com/training/artic, and it pins the certificate chain for future verifications, which is not documented as something that can be done but works in practice. It also relies on security properties of the keystore itself.
1
1
1
It keeps around the initial hardware-backed key from the initial pairing and uses that to verify the identity of the device and to provide a chained form of attestation. It has to generate a temporary fresh key each time for a new key attestation result, and enforces pinning.
Improving it requires convincing Google to make some slight changes to the API and then hardware vendors making an increasingly better implementation. There is not really anything I can do to make it better on my side of things now, at least not anything I can think of doing.
1
1