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
Replying to
Good approach. I am not fan of the java and haven't looked at the app source, but I was always curious since you announced it. I may sacrifice few hours, because I am really curious. And working on Attestation in similar 'for the end user' way, but not related to android devices.
1
Replying to
The best way to think of the app is that it's a frontend for the underlying attestation support. It coerces it into working as a form of strong paired attestation despite not being a perfect API by doing certificate chain pinning and generating signatures from an initial key.
The app then has to implement the workflows for local verification via QR codes and scheduled remote verification with attestation.app. It layers on some useful OS verified information gathering to detect compromise via persistent state (i.e. configuration, normal apps).
1
1
It's not very low-level code. It has to deal with the cryptography APIs and extracting the data from the key attestation certificate extension.
I could provide the option of using it as a more elaborate monitoring app via developer.android.com/reference/andr but for now it's out of scope.
1
1