Yes, this notion is one I seek too, but deriving only the key chain and confirming the identity of the device is one thing. Saying device integrity is intact because the bootloader is genuine is not quite true, especially with hidden TEE.
Conversation
Replying to
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.
2
2
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
I don't think it makes sense to try to do runtime monitoring of OS integrity from the app. It belongs in TrustZone and I don't think it can accomplish much, since if an attacker is aware of it they can easily avoid tripping it. Injecting code into the kernel is unnecessary, etc.
Some Android devices do have that monitoring in TrustZone and this app works on those devices. As long as they tie it into the keystore and don't allow signing with existing keys (at minimum) it benefits from any additional runtime security monitoring features that are present.
1
1
Replying to
Indeed , as just said, I assumed you did deeper integration with the low-level android-specific implementations. Although this would again require hardware specifics based on SoC TZ Implementation and TEE
1