> One question, with the two-stage approach, isn’t that a security risk? App 1 gets measured and can’t change, but it needs to identify app 2 in a way that still allows it to be updatable, invalidating the whole security chain.
It doesn't invalidate it if it works as the application developer intended. The essential idea is that the first mutable boot stage contains a trust policy which somehow verifies the second stage. Let's say that's a valid signature over the hash value of the second mutable stage. The trusted public key in contained in the first stage.
What we've done there is first used measured boot, and then verified boot.
Measured boot is basically load-hash-measure-execute, where "measure" means "store the hash value of whatever I'm about to execute somewhere safe where the soon executed thing won't be able to undo my storing of its hash".
Verified boot on the other hand is about verifying the next stage and only execute it if it verifies as valid by the trust policy.
> I’m probably not understanding something, so I’d love an explanation (preferably one that non-cryptographers understand)
Honestly I'm beginning to realize it's not all that simple to explain.
