Boot chain and integrity guarantees. What is Verified Boot, Secure Boot, Trusted Boot, dm-verity? Advantages, restrictions for user freedom, and more.

What is Verified Boot?[edit]

Verified boot is a security feature. In theory, if used right, it improves the security of the user without restricting user freedom. In practice however, for a large part, verified boot is used to enforce user-freedom restrictions.

Let's start with the advantages, and a bit of technical background of verified boot.

Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions including system, vendor, and optionally oem partitions. During device boot up, each stage verifies the integrity and authenticity of the next stage before handing over execution.
[...] Rollback protection helps to prevent a possible exploit from becoming persistent by ensuring devices only update to newer versions of Android.
In addition to verifying the OS, Verified Boot also allows Android devices to communicate their state of integrity to the user.

Android Verified Boot

Articles:

User Freedom[edit]

Freedom Software can be compatible with verified boot. No user freedom restrictions required. While verified boot is often used to restrict user freedom, to prevent the user from modifications and installing another operating system, verified boot is not inherently bad.

It depends on the details, if if the keys used to enforce verified boot are controlled by the vendor or by the user as well as on how the operating system implements verified boot. User-controlled keys are possible.

Nexus and Pixel lines support Verified Boot with user-controlled keys
Mike Perry, The Tor Project Blog

Verified Boot Comparison of Third-Party Controlled versus User-Controlled[edit]

Category	Vendor-Controlled Verified Boot	User-Controlled Verified Boot
Improves security	Yes	Yes
Does not restrict user freedom	No	Yes
Does not hinder the user auditing their system for compromises.	No	Yes
Synonym 1	Tyrant Security	Freedom Security
Synonym 2	Enterprise Security	Cypherpunk Security
Empowers	Corporates	Individuals

Compromised Verified Boot Vendor Key[edit]

https://www.schneier.com/blog/archives/2022/12/leaked-signing-keys-are-being-used-to-sign-malware.html

https://www.schneier.com/blog/archives/2023/03/blacklotus-malware-hijacks-windows-secure-boot-process.html

How does verified boot work?[edit]

It's based on digital software signatures. Only operating systems that come with a valid digital software signature that is signed with a public key that is trusted by the device are booted. Otherwise, the device will refuse to boot.

Lower stage (such as firmware) and hands over control to the next level (such as bootloader). However, every stage will verify the digital software signature of the next stage.

The stage are approximately (simplified):

hardware trust root → firmware → bootloader → kernel → kernel modules → initrd → init

Or specifically on some Linux desktop distributions:

hardware trust root → firmware → shim -> grub bootloader → Linux kernel → kernel modules → initrd → systemd init

Should at any stage the digital software verification fail, then the boot process will be aborted.

There is no technical requirement for each stage to be signed with the same key. Each stage can ship its own keys and/or key management system.

What are the advantages of verified boot?[edit]

Due to this integrity check, unauthorized malware will be gone after reboot (if the device is capable to revert to a clean backup image) or the device will refuse to boot.

Conceptually this improves security because the user runs only applications that have a valid digital signature. This obviously excludes third-party unauthorized malware since this would not be signed with a valid digital signature.

What are the limitations of verified boot?[edit]

Unauthorized malware? Is there such a thing as authorized malware, is this even a thing? Yes. For example the pre-installed Google Play Services on Google Android. See massive espionage data harvesting on Google Android. Verified boot is a security technology but conceptually cannot stop malware that is built-into the operating system by its producer. That does not take away from its useful potential as a security improvement for users.

Who uses verified boot?[edit]

At the time of writing, there was no Freedom Software Linux desktop distribution that implemented full verified boot which means a full chain of digital software verification starting form the hardware trust root up to all pre-installed applications that come with the Linux distribution. Only kernel module digital software verification is supported. The verified boot for initrd and beyond is not yet implemented. (Other Distributions implementing Verified Boot )

By comparison, for example Android and iOS supports full verified boot.

What are the dangers of verified boot?[edit]

The main risks are mistreatment of users, user software freedom restrictions, taking power away from users and handing it over to operating system and application developers.

As verified boot is currently implemented, for the vast supermajority of users the key is controlled by the operating system vendor. Users enrolling their own keys in the hardware key store or at any later stage of the boot process is often literally impossible ^[1], undocumented, not well supported, and even discouraged.

Many user-freedom restrictions are enforced using verified boot, locked bootloaders and non-root enforcement. This includes Android Anti-Features, prevention of replacing the stock operating system on mobile devices and many other mobile devices restrictions.

Verified Boot Compatibility with Rooted Phones[edit]

Yes, verified boot can be compatible with rooted devices.

Verified boot with root support and even with user-locked bootloader would be possible if support for that is built-in into the boot process (bootloader, recovery image). But how to modify the system partition without breaking verified boot? Modern root solutions such as for example Magisk support "systemless" root, via file system overlays.

Verified boot would be compatible with root if an approach similar to such as for example Magisk is using built into the bootloader / recovery image prior signing it.

Furthermore, for compatibility with verified boot, user modifications to the system partition could be reset at device reboot boot time from a known signed good image. This is technically very doable because Android already does something similar with its A/B update mechanism. ^[2] Then how would the user make their system modifications persistent? Via file system overlays and/or automation scripts that run after the boot process. There could even be an boot menu option to boot with versus without user system modifications.

Rooted Security versus Non-Rooted Security[edit]

Quote ^[3]

And what the hell? Root with verified boot? That's like having the most secure castle while leaving the door open for anyone, you can't have both worlds.
Anti user freedom viewpoint.

Root doesn't mean you give root permissions to any dumb app. I implied proper permission management and authorization, of course.
Then it's just like a secure castle where the user can go into all of the rooms, to some with a special key. You don't have to go into those rooms, but you have the option to at any time. And, depending on the implementation, you may change the special room, but if you return after the next reboot, it will be reverted back.
Actually, the castle analogy goes further: Unfortunately, many seem to interpret "verified boot" and "most secure" as "protects the dumbest user from shooting themselves in the foot on purpose by locking them into that castle. That is exactly where the recent apple scandal is coming from: The user is subservient to the OS vendor, and the OS vendor can abuse the user as they please.
Security is very important. Why? In order to not be exploited by strangers (criminals, spys...) against my interests. If security enables exploitation against my interests (by whomever, be it the OS vendor, the movie industry, or the government), it is not the security I want. This one OS is different than all the other evil ones? That's what Apple said before...

Pro user freedom viewpoint.

If you're rooted your security is way lower. Simple as that. Rooting can be used against you, it can lead to exploitation, and likely has been.
Note: you can have secure boot without root and using your own Android build, such as CalyxOS. Not rooting doesn't imply using the stock firmware, never has been.

Anti user freedom viewpoint.

I honestly don't understand why it should be "Simple as that"? If you have the phone rooted, as long as you don't grant root to any application, why should it be less secure than if you hadn't rooted it? (assumed everything else the same, specifically the rom supporting verified boot with root) Then, by granting root permissions to apps, of course the attack surface gets larger, but this is a thing you control yourself.
Your note was always understood. Of course not rooting doesn't imply using the stock firmware. It however implies that you are submitting to a different master. Who may be different, and maybe a bit more lenient than Google/Samsung/whoever, but that other master will still enforce any dumb app's will against you.

Pro user freedom viewpoint.

Ideological Considerations[edit]

Before discussion the technical implementation details and security it might make sense to lay out one's position on who should have more power. Device owners or vendors.

Should the operating system obey the user? Yes | No
Should the user should have ultimate control? Yes | No
Should the operating system make guarantees to app developers in case these guarantees are to the disadvantage of the user? Yes | No
Does one oppose the war on War on General Purpose Computing? Yes | No
Does one support the right to general computing? Yes | No

It is primarily a project goal and policy decision.

Technical excuses are mood. If there's a commitment pro freedom and against anti-features, then there's a way. Security needs to take the backseat if it curtails user freedom. A prison cell is more secure from car accidents but yet we don't want to live in a golden cage. If you want, you will find a way, if you don't want to, you will find reasons.

For example, in case of GrapheneOS non-root enforcement is a project goal and policy decision.

It doesn't sound like you want GrapheneOS since you don't care about the core security goals. I recommend using something else.
GrapheneOS lead developer ^[4]

GrapheneOS is not aimed at power users or hobbyists aiming to tinker with their devices more than they can via the stock OS or AOSP.

(resign-android-image is a script that attempts to provide root access for GrapheneOS.)

Kicksecure Verified Boot Development Ideas[edit]

Verified VM Boot Sequence without Secure Boot[edit]

(Same security level as Secure Boot?)

Talking about VMs only in this concept.

We could boot from a virtual, read-only (write protected) boot medium such as another virtual HDD or ISO. Such a boot medium which only contains a bootloader (shim or grub?) which only task is to verify the bootloader on the main hard drive that contains the bootloader, kernel, debian. That boot medium (such as ISO) could be shipped on Kicksecure Host through a deb package /usr/share/verified-boot/check.iso.

Presuppositions:

the virtual BIOS cannot be flashed/compromised
host not compromised

boot sequence:

VM powered on → virtual BIOS loads boot DVD ISO (or alternatively another hard drive) (contains a bootloader only) → this initial bootloader signature is not verified but secure since boot from read-only medium → verify bootloader on main hard drive → bootloader of main hard drive does signature verification of kernel → continue boot

What we need for that: grub-pc (not grub-efi) with signature verification. ^[5]

By not booting from that initial boot medium (for testing or if that was broken or so), users could do regular boots without verification of the bootloader on the main drive. From the perspective of the main drive, nothing would change. Except we'd enable grub signature verification of the kernel on the main drive.

The boot medium should not load the actual kernel for simplicity of the implementation. Since it is read-only it cannot be easily updated. Kernel packages change and during kernel upgrades /boot and grub.cfg on the main disk changes. If /boot was write protected, that would fail. Therefore the initial boot medium is only a simplified alternative to EFI Secure Boot. By making the initial boot medium as simple as possible, i.e. only chainloading the next bootloader, it does not need frequent updates and does not need to be updated when kernel versions change.

If we could make grub-pc (not grub-efi) use check_signatures=enforce, then maybe we don't need to port to EFI and/or Secure Boot soon and perhaps never?

The disadvantage of this concept is that it is only as secure as Secure Boot. initrd could still be compromised.

Hash Check all Files at Boot[edit]

Higher security level as Secure Boot.

Talking about VMs only in this concept.

We could boot from a virtual, read-only (write protected) boot medium such as another virtual HDD or ISO. Such a boot medium which runs a minimal linux distribution which then compares against checksums from Debian repository on the main boot drive:

The MBR (master boot record)
The VBR (volume boot record)
[A] the booloader
[B] the partition table
[C] the kernel
[D] the initrd
[E] all files shipped by all packages

There are tools that can help with checking all files on the hard drive such as debsums. However, while debsums is more popular, it is unsuitable. ^[6]

A tool such as debcheckroot might be more suitable for this task.

During development of Verifiable Builds experiences were made with verification of MBR, VBR, bootloader, partition table, kernel and initrd. Source code was created to analyze such files. ^[7]

Extraneous files would be reported, with option to delete them, to move them to quarantaine and/or to view them.

Initrd is by Debian default, auto generated on the local system. Hence, there is nothing to compare with from Debian repository. However, after verification of everything (all files from all packages) it would be secure to chroot into the verified system and to re-generate the initrd. Then to compare both versions. This might not be required if initrd can be extracted and compared against files on the root disk.

That boot medium (such as IOS) could be shipped on Kicksecure Host through a deb package /usr/share/verified-boot/check.iso.

Disadvantage of this concept might be that it might be slower than dm-verity. On the other hand the advantage of this concept is that this does not require a OEM image. Also it might be more secure since it does not verify against an OEM image but would verify the individual files. Another advantage is that users are free to install any package and not limited by a readonly root image. Users do not have to wait for the vendor to update the OEM image.

dm-verity[edit]

Once the boot chain is verified, the kernel should verify the rest of the OS with something similar to dm-verity. Verified boot that covers only the boot chain is mostly useless but with some exceptions ^[8].

We can have 2 separate partitions for the base system and user-installed apps. Mount the base system partition as read-only and verify it with dm-verity. Mount the apps partition as /apps and chroot into it. The apps partition will not be verified.

For example:

mount /path/to/unverified_image /apps for dir in bin sbin usr lib lib64 var etc do mkdir "/apps/${dir}" mount -o bind "/${dir}" "/apps/${dir}" done mkdir /apps/{proc,sys,dev} mount proc /apps/proc -t proc mount sysfs /apps/sys -t sysfs mount devtmpfs /apps/dev -t devtmpfs mount devpts /apps/dev/pts -t devpts apt install -o Dir=/apps $program chroot /apps $program

Status[edit]

Help welcome to implement this.
https://forums.whonix.org/t/no-longer-add-virtual-dvd-drive-to-vm-by-default/9337 needs to be undone or considered. Could auto-add a DVD drive as long as needed.

Other Distributions implementing Verified Boot[edit]

Forum Discussion[edit]

https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894 https://forums.whonix.org/t/fs-verity-in-linux-5-4/8911

Footnotes[edit]

↑ Many Android devices come with locked bootloaders. Many Android phones could not have been modded by the modding community because no way to break the verified boot chain and gain full read/write access to their own devices could be found.
↑ https://source.android.com/docs/core/ota/ab
↑ https://news.ycombinator.com/item?id=28096914
↑ https://archive.ph/94YVQ
↑
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188
- https://savannah.gnu.org/bugs/index.php?56887
↑ Quote https://www.elstel.org/debcheckroot/

Usage of debsums instead of Debian-checkroot is strongly discouraged because debsums uses locally stored md5sums which can be modified by an attacker along with the files themselves. It has been meant for integrity checking not for security issues! Debsums furthermore does not provide an output as clean and neatly structured as checkroot and does not spot files additionally added to your system by someone else.
↑ https://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/5100_create-report
↑ For example, Kicksecure loads apparmor.d from the initramfs which it will cover.

Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

FREE · PLUS · PREMIUM Support

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012-2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

[1] Many Android devices come with locked bootloaders. Many Android phones could not have been modded by the modding community because no way to break the verified boot chain and gain full read/write access to their own devices could be found.

[2] ttps://source.android.com/docs/core/ota/ab

[3] ttps://news.ycombinator.com/item?id=28096914

[4] ttps://archive.ph/94YVQ

[5] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188

https://savannah.gnu.org/bugs/index.php?56887

[6] ttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188

[7] ttps://savannah.gnu.org/bugs/index.php?56887

[6] Quote https://www.elstel.org/debcheckroot/

Usage of debsums instead of Debian-checkroot is strongly discouraged because debsums uses locally stored md5sums which can be modified by an attacker along with the files themselves. It has been meant for integrity checking not for security issues! Debsums furthermore does not provide an output as clean and neatly structured as checkroot and does not spot files additionally added to your system by someone else.

[7] ttps://github.com/Kicksecure/derivative-maker/blob/master/build-steps.d/5100_create-report

[8] For example, Kicksecure loads apparmor.d from the initramfs which it will cover.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

Verified Boot

Contents