Wow, there’s a lot of  “Boot” buzzwords out there: U-Boot verified boot, Solaris Verified Boot,  Chrome Verified Boot,  Android Verified Boot (Class A and Class B),  UEFI Secure Boot (sometimes called Windows Secure Boot),  ARM TrustZone, UEFI Secure Boot, ARM TZ Secure Boot, Measured Boot (sometimes called TCG Measured Boot),  Trusted Boot (Windows and Linux concepts) and most likely half a dozen others I don’t even know about… 🙂

UEFI Secure Boot aside, I’m still learning some of these other boot technologies, and how they overlap. I still have a LOT of questions about many of them.  I think Verified Boot in Chrome and Android share the same Linux linux kernel technology, but have implemented things differently between Chrome and Android. UEFI’s Secure Boot doesn’t use a TPM, yet Microsoft requires OEMs to have a TPM. 😦 There’s the Trusted Boot that Windows has, and there’s also the tboot (Trusted Boot) loader that is Linux-centric. ARM’s TZ Secure Boot appears to be a different Secure Boot than the UEFI one. Solaris had their Verified Boot, but recently added UEFI support, so what is going to happen with UEFI Secure Boot, and will that mix with existing Solaris Verified Boot? Ditto on Android-IA, which only uses UEFI, will UEFI Secure Boot ever mix with Android Verified Boot?

None of these are full security solutions. For example, Intel has Boot Guard to help protect the system before UEFI Secure Boot’s protections kick in.

Below is a bit more information for each one. This is the first blog post on this topic, I’ll be doing further posts with more details about most of these in the future.

=================

U-Boot verified boot

“U-Boot 2013.07 introduces a feature allowing for the verification of a kernel and other images. U-Boot’s new verified boot feature provides a mechanism for verifying images while still allowing them to be field-upgraded. It fits in seamlessly with the existing image loading infrastructure in U-Boot. U-Boot verified boot relies on two familiar technologies: cryptographic hashing (e.g. SHA-1) and public key cryptography (e.g. RSA). Using these technologies it is possible to distribute images and have them verified on a device. Specifically we can create a key, hash an image, sign that hash, and publish the public key. On the device we can obtain an image and verify it was signed by the private key. Images can be chained one after the other and signed in reverse order either using the same keys or sub-keys (keys derived from other keys). For example, U-Boot may load an image containing a new U-Boot, then boot that. That U-Boot in turn may load an image containing a kernel. Doing that would allow U-Boot itself to be updated with the firmware without risking having an unbootable device due to a bad update. In principle this chain can be any length, but there must be an initial trusted image (“root of trust”) that can start the process. This can be stored in read-only media during manufacture or perhaps protected by on-chip crypto using its own signing scheme. The “root of trust” U-Boot must include the initial public key, held in U-Boot’s device tree (often called the flattened device tree or FDT). A more sophisticated scheme would allow the public keys to be provided by the user, perhaps by inserting an SD card containing the key. This could be implemented using a U-Boot script or with a more sophisticated user interface. A TPM can be used to hold rollback counters, to protect against rolling back to an older, compromised firmware. U-Boot also provides TPM support for trusted boot and remote attestation.”

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/verified-boot.txt;
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt;
http://git.denx.de/?p=u-boot.git;a=blob;f=test/vboot/sign-images.its
https://lwn.net/Articles/571031/

=================

Solaris Verified Boot

“Solaris Verified Boot is a solution for Oracle’s version of Solaris. Solaris Verified Boot refers to verification of object modules before execution using digital signatures. If enabled, Solaris Verified Boot checks the factory-signed signature in a kernel module before loading and executing the module. This is to detect accidental or malicious modification of a module. The action taken is configurable and, when enabled, will either print a warning message and continue loading and executing the module or will fail and not load and execute the module. Solaris Verified Boot checks kernel modules before execution and reports if the module is modified. Optionally on failures, the module is not loaded. For Solaris, Solaris Verified Boot will verify kernel modules before execution, beginning with the initial bootstrap SPARC ‘bootblk’ sectors and initial ‘unix’ module. Both of these are verified by SPARC OpenBoot (because Solaris is not running yet). The Solaris kernel loader (krtld) then takes over and verifies the main (generic) “genunix” module and all subsequent modules loaded by the Solaris kernel. The policy to use on failures is configurable with three policy settings: none, warning, and enforce. The default policy is none (that is, Verified Boot is disabled); None is the default behavior — no verification before execution. Re: TPMs, Solaris Verified Boot has no impact on the TPM chip or TPM software (TrouSerS). However, the TPM still serves complementary functions such as providing a secure keystore or taking measurements of firmware executibles. Verified Boot settings are maintained by Oracle ILOM. Anyone with ILOM spsh shell access can modify these settings.  Solaris Verified Boot is available with Solaris 11.2 for Sun SPARC T5/M5/M6 hardware platforms for host domains (with Sun Firmware FW 9.1.0 or better) and Fujitsu M10 systems (with Firmware XCP2250 firmware). Verified Boot is supported for the host domain in the Global Zone. Non-global, non-kernel zones do not have their own copy of the Solaris kernel and do not load kernel modules. Verified Boot is not supported initially for Solaris on X86, T4 or older SPARC platforms, LDoms guest domains, or Kernel Zones. We plan to support more hardware.”

https://blogs.oracle.com/DanX/entry/verified_boot
https://blogs.oracle.com/DanX/entry/solaris_kernel_zones_verified_boot
http://docs.oracle.com/cd/E36784_01/html/E37121/gmwce.html#OSSADgmwce

=================

Chrome Verified Boot

“Chrome Verified Boot is a solution for Google’s Chromium OS. The Chromium OS team is implementing a verified boot solution that strives to ensure that users feel secure when logging into a Chromium OS device. Verified boot starts with a read-only portion of firmware, which only executes the next chunk of boot code after verification. Verified boot strives to ensure that all executed code comes from the Chromium OS source tree, rather than from an attacker or corruption. Verified boot is focused on stopping the opportunistic attacker. While verified boot is not expected to detect every attack, the goal is to be a significant deterrent which will be improved upon iteratively. Verification during boot is performed on-the-fly to avoid delaying system start up.  It uses stored cryptographic hashes and may be compatible with any trusted kernel. This feature is not expected to provide 100% detection of attacks. Instead, it is meant to raise the attack bar significantly and in a way that can be improved upon iteratively.”

https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto
https://sites.google.com/site/chromeoswikisite/home/what-s-new-in-dev-and-beta/shell-acess-with-verified-boot

Click to access chromeos.pdf

http://research.google.com/pubs/pub42038.html
http://chrome.blogspot.com/2011/07/chromebook-security-browsing-more.html

=================

Android Verified Boot

“Android Verified Boot is a solution for Google’s Android OS. Android’s Verified boot guarantees the integrity of the device software starting from a hardware root of trust up to the system partition. During boot, each stage verifies the integrity and authenticity of the next stage before executing it. This capability can be used to warn users of unexpected changes to the software when they acquire a used device, for example. It will also provide an additional signal of device integrity for remote attestation, and together with encryption and Trusted Execution Environment (TEE) root of trust binding, adds another layer of protection for user data against malicious system software. We define two implementation classes for verified boot depending on how fully the device implements this specification. Class A implements verified boot with full chain of trust up to verified partitions. This implementation must support the LOCKED device state, and GREEN and RED boot states. Class B implements Class A and additionally supports the UNLOCKED device state and the ORANGE boot state.”

https://source.android.com/devices/tech/security/verifiedboot/verified-boot.html
https://source.android.com/devices/tech/security/verifiedboot/index.html
https://source.android.com/devices/tech/security/dm-verity.html
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt
http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.html
https://lwn.net/Articles/638627/

=================

UEFI Secure Boot

“UEFI Secure Boot, sometimes called Windows Secure Boot, is an optional security feature of UEFI that can be enabled by a PC OEM to enhance the security by helping to make sure that your PC boots using only software that is trusted by the PC manufacturer. When the PC starts, the firmware checks the signature of each piece of boot software, including firmware drivers (Option ROMs) and the operating system. If the signatures are good, the PC boots, and the firmware gives control to the operating system. Secure Boot does not require a TPM.”

https://technet.microsoft.com/en-us/library/Hh824987.aspx
http://go.microsoft.com/fwlink/?LinkId=278911

Click to access lf_uefi_secure_boot_open_platforms.pdf

https://fedoraproject.org/wiki/Secureboot
https://wiki.ubuntu.com/SecurityTeam/SecureBoot
https://wiki.freebsd.org/SecureBoot
https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot
http://en.community.dell.com/techcenter/os-applications/w/wiki/7568.secure-boot-overview
http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO
https://en.opensuse.org/openSUSE:UEFI

=================

Measured Boot

“I think some refer to Measured Boot as TCG Measured Boot. Windows supports Measured Boot, Trusted Boot, and Secure Boot. Windows 8 introduces a new feature called Measured Boot, which measures each component, from firmware up through the boot start drivers, stores those measurements in the TPM on the machine, and then makes available a log that can be tested remotely to verify the boot state of the client. The Measured Boot feature provides AM software with a trusted (resistant to spoofing and tampering) log of all boot components that started before AM software. AM software can use the log to determine whether components that ran before it are trustworthy or if they are infected with malware. The AM software on the local machine can send the log to a remote sever for evaluation. The remote server may initiate remediation actions either by interacting with software on the client or through out-of-band mechanisms, as appropriate. Working with the TPM and non-Microsoft software, Measured Boot in Windows 8.1 allows a trusted server on the network to verify the integrity of the Windows startup process.”

https://msdn.microsoft.com/en-us/library/windows/desktop/Hh848050%28v=VS.85%29.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/Dn653311%28v=VS.85%29.aspx
https://technet.microsoft.com/en-us/windows/dn168167.aspx
http://www.jwsecure.com/2011/10/18/secure-measured-boot-in-windows-8/
https://mbt.codeplex.com/
http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/Hh848050%28v=VS.85%29.aspx
https://www.ibm.com/developerworks/community/blogs/smartersecurity/entry/uefi_secure_boot_and_the_tpm_implementing_secure_boot_with_a_tpm27?lang=en
https://technet.microsoft.com/en-us/windows/dn168169.aspx
http://mjg59.dreamwidth.org/10971.html

UEFI Secure Boot aside, it appears that ARM TrustZone also uses Secure Boot as a non-UEFI-based concept:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/CACGCHFE.html

=================

Trusted Boot

“Windows supports Measured Boot, Trusted Boot, and Secure Boot. With Trusted Boot, Windows checks the integrity of every component of the startup process before loading it. Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows 8.1 kernel before loading it. The Windows 8.1 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows 8.1 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.”

https://technet.microsoft.com/en-us/windows/dn168167.aspx
http://blogs.msdn.com/b/olivnie/archive/2013/01/09/windows-8-trusted-boot-secure-boot-measured-boot.aspx

“Trusted Boot (boot) is ALSO the name of an open source, pre-kernel/VMM module for Linux, that uses Intel TXT to perform a measured and verified launch of an OS kernel/VMM. Intel TXT provides a hardware- based root of trust to ensure that a platform boots with a known good configuration of firmware, BIOS, virtual machine monitor, and operating system.”

http://hg.code.sf.net/p/tboot/code
http://www.trustedcomputinggroup.org/resources/trusted_boot
https://software.intel.com/en-us/articles/intel-trusted-execution-technology
http://www-01.ibm.com/support/knowledgecenter/SSTQK9_1.1.3/com.ibm.powersc113.se/trusted_boot_concepts.htm

=================

Enterprises which are responsible for user/data security usually like these kinds of technologies. Citizens who like to control their own devices, including installing their preferred operating system, instead of using the pre-installed OEM OS, often find these security technologies a hindrance to their normal usage. OEMs — except Google, with the Developer Mode of their ChromeBook — ignore this latter, smaller consumer demographic, and focus strictly on the security-focused market, creating opportunities for “micro-OEMs” like Purism and Bunnie Studios.

http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
https://en.wikipedia.org/wiki/Hardware_restriction