From 9d154c532ce8b7d81e6852cf82bdf2df3815bc0e Mon Sep 17 00:00:00 2001 From: River Date: Thu, 10 Apr 2025 10:50:47 -0400 Subject: [PATCH] Add Full Verified Boot --- Full-Verified-Boot.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Full-Verified-Boot.md diff --git a/Full-Verified-Boot.md b/Full-Verified-Boot.md new file mode 100644 index 0000000..a01e9c5 --- /dev/null +++ b/Full-Verified-Boot.md @@ -0,0 +1,20 @@ +# What is Full Verified Boot? + +Full verified boot is a means by which all the resources involved in system bring-up are known to be valid, working, and secure. This works by performing cryptographic signatures at each step of the boot process to verify the next step's resources. A typical chain of trust will look like this: + +- Security processor verifies system firmware +- System firmware verifies bootloader and kernel images +- Kernel verifies system partition hash + +In HalogenOS, the root partition containing volatile data is encrypted, and the encryption key is released automatically by the TPM (Trusted Platform Module) when it verifies that the system firmware, bootloader, and kernel are all correct. Additionally, user data is encrypted separately per-user, so it is impossible to modify any data on the root partition without knowing the user's password or sniffing the TPM for the encryption key. + +So what does the chain look like for HalogenOS? + +- Security processor verifies system firmware +- System firmware verifies bootloader and kernel images +- System firmware releases root partition encryption key to the kernel +- Kernel verifies system partition hash +- System partition verifies user-installable software and updates +- User password decrypts home directory + +With this setup, modifying any data without proper clearance will render the partition un-bootable or corrupted. However, the system can recover from such a scenario, due to how it performs provisioning automatically. \ No newline at end of file