For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:

* a hardware key (on hardware that supports it), which checks the signature of

* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.

* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).

* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.

* base packages are then launched upon demand.

This establishes a direct line of trust from the hardware key to the base packages.

For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.

[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...

[2]: https://theupdateframework.io/

[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...