The authenticity and integrity of firmware and the OS is verified, not only the bootloader stages. The hardware-backed keystore receives information about the software being verified from the earlier boot stages and incorporates it into the key attestation information.
Conversation
Replying to
Verified by the hidden TEE ?
In best case scenario.
I am talking about the specifics of Android here, not about Attestation.
Attestation is key to trust, broadly speaking.
1
Replying to
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.
1
1
1
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".
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.
1
1
Show replies
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.
1
1
1
Show replies