The initramfs which is used as the root fs even after early boot is verified and loads the security policies. Lockdown is essentially all or nothing even though you can easily enforce a lot of those things through your verified userspace to enable more real world use cases.
Conversation
Even with the whole base OS verified, providing real security properties to users is hard. In the main threat model (remote compromise in previous boot), attacker controls all the persistent state, so you can assume they have all permissions, special access grants, etc.
1
Hmm, wouldn't parts of this be easier to implement with fs-verity? There is also some movement upstream to have signed lists of file checksums so less on-disk files can be modified after package installation.
1
I can describe how it works on Android and what security properties it currently provides. Base SoC firmware is verified from the hardware root of trust. It's usually controlled by phone OEM rather than SoC vendor thanks to the eFuses the OEM uses to flash firmware signing keys.
1
1
eFuses are also used to implement firmware downgrade protection. When a verified boot security bug is fixed, a version bit is set which is flashed to eFuses.
Last firmware stage is usually based on either lk (little kernel) or EDK2. That's responsible for verifying the core OS.
1
It uses a hard-wired key (green boot state) or a user key loaded from secure element (yellow boot state) to verify the tiny vbmeta image. It also verifies that the vbmeta rollback index is equal or greater than the one set for the main vbmeta rollback index in the secure element.
1
AOSP uses the timestamp of the Android security patch level as the default rollback index. For example, it's currently 1656979200 for 2022-07-05.
The vbmeta image has hashes of all the core OS images and hashes of dm-verity roots for the high-level OS images to bootstrap those.
1
It's also possible to have chained vbmeta images, where a public key is included instead of a hash. Each chained vbmeta image has their own rollback index stored in a secure element rollback index slot. For example, Pixel 6 has chained boot and system vbmeta to support GKIs/GSIs.
1
Most of the core OS components are included in the OS as an APK, which means they're a signed package able to be updated out-of-band. A subset of those are APEX modules, which are a signed APK containing chained vbmeta verified filesystem image, used for things beyond just apps.
1
Important to note is Android's verified boot verifies every block read from storage. Core OS images are read once and verified via their hash. dm-verity provides continuous verification each time blocks are read for the high level images and APEX modules.
1
The reason they made fs-verity is so that regular APKs for apps can be continuously verified rather than just APEX modules shipping verified filesystems inside. Apps are signed / verified even without this, but it allows quick continuously verification, not verify once on boot.
You can chain trust to a user installed app using hardware-based attestation. Provides signed response chaining up to attestation root including verified boot state (green, yellow), signing key (useful for yellow), various versions, etc. and also your app id + key fingerprint.
1
Officially supports pinning your own hardware backed attestation signing keys now too, which is a feature we (GrapheneOS) proposed for use in our Auditor app (attestation.app/about). Shipped on Pixel 6 but it has a bug we reported they need to fix for it to be fully usable.
1
1
1
Show replies