Tag: verified boot

U-Boot Verified Boot vulnerability: CVE-2020-10648

~ hucktech ~ Leave a comment

Excerpt from comments in part1 of patch:

When booting a FIT, if ‘bootm’ is used without a specified configuration, U-Boot will use the default one provided in the FIT. But it does not actually check that the signature is for that configuration. This means that it is possible to duplicate a configuration conf-1 to produce conf-2 (with all the signatures intact), set the default configuration to conf-2 and then boot the image. U-Boot will verify conf-2 (in fact since hashed-nodes specifies the conf-1 nodes it will effectively verify conf-1). Then it will happily boot conf-2 even though it might have a different kernel. This series corrects this problem and adds a test to verify it. It also updates fit_check_sign to allow the configuration to be specified. This vulnerability was found by Dmitry Janushkevich and Andrea Barisani of F-Secure, who also wrote the vboot_forge script included here. This is CVE-2020-10648. […]

https://lists.denx.de/pipermail/u-boot/2020-March/403409.html

No useful info yet:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-10648
https://bugs.launchpad.net/bugs/cve/2020-10648

coreboot 4.11 released

~ hucktech ~ Leave a comment

“[…]Since 4.10 there were 1630 new commits by over 130 developers. Of these, about 30 contributed to coreboot for the first time.[…]
Verified Boot: The vboot feature that Chromebooks brought into coreboot was extended to work on devices that weren’t specially adapted for it: In addition to its original device family it’s now supported on various Lenovo laptops, Open Compute Project systems and Siemens industrial machines. Eltan’s support for measured boot continues to be integrated with vboot, sharing data structures and generally working together where possible.[…]”

Detailed blog post:
https://blogs.coreboot.org/blog/2019/11/19/announcing-coreboot-4-11/

CVE-2018-3266: Oracle Solaris Verified Boot vuln

~ hucktech ~ Leave a comment

Vulnerability in the Solaris component of Oracle Sun Systems Products Suite (subcomponent: Verified Boot). The supported version that is affected is 11.3. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Solaris executes to compromise Solaris. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Solaris accessible data as well as unauthorized read access to a subset of Solaris accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Solaris.

https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html

https://nvd.nist.gov/vuln/detail/CVE-2018-3266

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3266

Current Exploit Price (≈) 3.9 $5k-$25k

https://vuldb.com/?id.125643

 

Teddy Reed on U-Boot’s Verified Boot

~ hucktech ~ 1 Comment

Teddy Reed, author of UEFI Firmware Parser, among other things, has some U-Boot Verified Boot issues:

Verified boot production uses question

Hi all, question, is anyone using the U-Boot verified-boot in production? I am using configuration verification for several OpenCompute/OpenBMC boards. After a deep-dive review I found some edge cases that in rare circumstances could lead to a signature check bypass. I think this is low-risk at best since the scenario requires special hardware behavior to exist. Our board were susceptible in the general sense, but we had implemented some additional sanity checks on the FIT structures that
prevented this. There are some proposed changes that attempt to mitigate this [1], [2], [3]. Any one of these changes mitigates the bypass scenario. If you don’t mind reaching out to me I can share the exact situation/details.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
[2] https://lists.denx.de/pipermail/u-boot/2018-June/330487.html
[3] https://lists.denx.de/pipermail/u-boot/2018-June/330599.html

https://lists.denx.de/pipermail/u-boot/2018-June/330898.html

Chrome OS firmware change may support Verified Boot of Windows?

~ hucktech ~ Leave a comment

[…]A recent branch title “firmware-eve-campfire” was discovered in the Chromium gerrit, accompanied by changes referencing “AltOS” and “go/vboot-windows.” That, combined that with the addition of placeholder strings for “Chrome OS” and “AltOS” being added to all languages, suggests that a future Chrome OS device, codenamed “Eve” will have the capability to boot more than one operating system. The commit was found by -nbsp- on Reddit. Obviously, with a name like “vboot-windows,” it is easy to jump to the conclusion that the feature is intended for Microsoft Windows, though little information about this is available. Most of the relevant code is hidden behind the private gerrit for Google employees, making it difficult to ascertain how this works and what it is intended for. According to a post at XDA-developers, it seems possible that this could be used for non-Windows OSes, such as Linux, or whatever Google Fuschia actually is.[…]

https://www.techrepublic.com/article/a-mysterious-chrome-os-commit-could-hint-at-a-chromebook-that-dual-boots-windows/

Payment card Industry: Secure Boot == Verified Boot == “Trusted Boot”

~ hucktech ~ Leave a comment

I just noticed that the PCI compliance group lumps all of the Trusted/Measured/Verified/Secure boot technologies into one, and calls it Trusted Boot, which, AFAIK, is the name for Intel TXT-based Trusted Boot. I wish they were more precise. Then again, I guess I should be glad there is *SOME* firmware security in the PCI compliance docs, I wish there was more, system should check firmware-based code for malware, not just OS-based code.

Payment Card Industry (PCI)
Software-based PIN Entry on COTS Security Requirements
Version 1.0, January 2018
[…]
The PIN CVM Application must only support platforms that, at a minimum, provide the following features:
* An enforcing mandatory access control framework
* A “trusted boot” mechanism that validates the operating system’s authenticity

Trusted Boot: A cryptographic process where the bootloader verifies the integrity of all components (e.g., kernel objects) loaded during operating system start-up process, before loading. Also known as Verified Boot and Secure Boot (e.g., Google or Apple).
[…]

Click to access RP450RP456RP457_PCI_Security_Policy-1461704231.78085.pdf

 

dump_avb_signature: dump/verify Android Verified Boot signature hash

~ hucktech ~ Leave a comment

Dump/Verify Android Verified Boot Signature Hash
For researching Android Verified Boot issues
To exploit TZ image verification 🙂

python verify_signature.py boot.img

Issues: Might not work with AVB Version 2.0 or higher

https://github.com/bkerler/dump_avb_signature

 

AMI on Intel’s BIOS end-of-life announcement

~ hucktech ~ Leave a comment

 

https://ami.com/en/tech-blog/intel-says-bye-to-bios-by-2020/

Click to access Brian_Richardson_Intel_Final.pdf

 

The UEFI Forum likes to frame UEFI -vs- BIOS, and has a 3-5 Class heirarchy of those systems, including having to deal with UEFI systems that also provide BIOS via Compatibility Support Module (CSM), referring to BIOS as Legacy Mode. If you look at BIOS outside of the framing of the UEFI Forum, it is usually based security, and UEFI has some security where BIOS has none. But there’s another ‘class’: non-UEFI coreboot, optionally secured with Verified Boot, with a BIOS payload. UEFI Forum doesn’t include this in their Class heirarchy… AFAICT, the mainstream IBVs have given up on BIOS and migrated to UEFI. The only places where BIOS will probably remain are in Purism boxes, where they will use TPM+Heads to secure BIOS, or on Chrome boxes, where they will use coreboot Verified Boot to secure BIOS, or in SeaBIOS-based VMs. When Intel stops offering Intel’s implementation of BIOS, maybe this means that the remaining BIOS users will switch to the open source SeaBIOS project, which is great news. Getting rid of the complex class of dual UEFI/BIOS systems will be a joy. 🙂

Android Oreo Verified Boot’s Rollback Protection

~ hucktech ~ Leave a comment

This flew under our radar back at I/O, but it’s big news. On compatible devices, the new Verified Boot changes in Android 8.0 Oreo will prevent a device from booting should it be rolled back to an earlier firmware. The new feature is called Rollback Protection. So if your phone is flashed with older software, you (and your data) are protected from whatever potential security vulnerabilities may have been present in earlier versions. For 99% of users, the new Rollback Protection is great news. If a phone is lost or stolen, it further decreases the number of potential attacks which could be used to gain access, providing better safety for your data.[…]

http://www.androidpolice.com/2017/09/05/android-oreo-feature-spotlight-changes-verified-boot-wont-allow-start-downgraded-os/

https://android.googlesource.com/platform/external/avb/#Rollback-Protection

 

CMC-Vboot: investigates Chrome’s Verified Boot

~ hucktech ~ Leave a comment

This project takes Chrome’s Verified Boot (Vboot) process and examines its various security properties using formal logic. This verification is done with a focus on the firmware/hardware boundary. The Vboot process depends on the correct functionality of a Trusted Platform Module (TPM) and a SHA accelerator. Because these hardware accelerators are interacted with through Memory Mapped I/O (MMIO), it is difficult for normal formal methods to capture the interface between the MMIO registers and the workings of the Hardware modules. To explore this boundary I am using a Software TPM Library and passing it through to the QEMU Hardware Emulator. This allows me to use the normal MMIO registers of a TPM with the original Vboot Library.[…]

https://github.com/gilhooleyd/CBMC-Vboot

Signing boot images for Android Verified Boot

~ hucktech ~ Leave a comment

Signing boot images for Android Verified Boot (AVB)
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme. Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images. Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM’s keys). This depends on the device, bootloader version, and bootloader unlock state. For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM’s. Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.[…]

https://forum.xda-developers.com/android/software-hacking/signing-boot-images-android-verified-t3600606

More Info:
https://source.android.com/security/verifiedboot/
https://source.android.com/security/verifiedboot/verified-boot
http://blog.andrsec.com/android/2016/03/26/android-verified-boot.html

 

coreboot 4.4 released!

~ hucktech ~ Leave a comment

coreboot version 4.4 has been released, which includes 850 commits by 90 authors added 59000 lines to the codebase since their last quarterly release. This release includes OpenPOWER support and experimental U-Boot payload support. It also has an Intel ME tool which is new (at least to me). There are many other changes, excerpting their announcement:

Significant changes:
* Build system (30 commits) – Add postcar stage, ‘timeless’ builds, extend site-local, test toolchain by version string, update dependencies, catch ACPI errors, l add additional macros.
* Toolchain updates (40+ patches) – Update IASL to v20160318 , LLVM to v3.7.1, add GNU make, add nds32le GCC compiler
* Lint tools (30 patches) – Update existing lint utilities, add lint tests for executable bit, make sure site-local isn’t committed, add test to break all lint tests.
* Payloads (60 commits) – Fixes for libpayload, coreinfo and nvramcui, add new payloads, see below.
* Maintainers file – (8 patches) – continue adding maintainers for various areas.
* Documentation for adding Intel FSP-based platforms (20 commits)

New architectures:
* power8
* qemu-power8

New payloads:
* depthcharge: For ChromeOS verified boot
* iPXE: For network booting
* Memtest86+: Updated with fixes for correctly testing coreboot with payloads
* U-Boot (Experimental): Alternate payload for booting an OS

New/updated mainboards:
* asus/kcma-d8
* emulation/qemu-power8
* google/auron_paine
* google/gru
* intel/amenia
* intel/apollolake_rvp
* intel/camelbackmountain_fsp
* intel/galileo
* lenovo/t420
* asus/kgpe-d16
* google/oak
* google/chell
* intel/kunimitsu

New/updated socs:
* intel/apollolake
* intel/fsp_broadwell_de
* intel/quark
* marvell/armada38x
* rockchip/rk3399
* cpuamd/mct_ddr3
* drivers/intel/fsp2_0
* northbridge/intel/sandybridge/raminit
* soc/intel/apollolake
* soc/intel/fsp_baytrail
* soc/intel/skylake
* soc/mediatek/mt8173

New vendorcode directories:
* siemens

New/updated submodules:
* chromeec
* 3rdparty/arm-trusted-firmware (329 commits)
* 3rdparty/vboot (28 commits)
* util/nvidia/cbootimage (13 commits)

New/updated Utilities:
* archive – Concatenates files into a single blob with an indexed header
* chromeos – Download and extract blobs from a ChromeOS image
* futility – vboot Firmware utility
* intelmetool – Shows information about the Intel ME on a platform.
* marvell/doimage_mv – No usage notes
* post – Simple utility to test post cards

Full announcement:
http://blogs.coreboot.org/blog/2016/05/02/announcing-coreboot-4-4/
https://www.coreboot.org/releases/

U-Boot Verified Boot to get security improvements

~ hucktech ~ Leave a comment

Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.

I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.

Full post/thread:
http://lists.denx.de/mailman/listinfo/u-boot

Survey of Boot security technologies

~ hucktech ~ Leave a comment

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

Android M Verified Boot UI changes

~ hucktech ~ Leave a comment

As reported by multiple online news sources, Android is getting some UI changes related to Verified Boot. Quoting Android Police article:

“Google has just added an interesting page to the Nexus support site that lists new operating system safety warnings. According to the page, this is a boot verification system that checks the integrity of your device software during each startup. You probably haven’t seen this on any devices yet, but Android M is right around the corner.”

More Information:
http://www.ibtimes.co.uk/android-m-introduce-googles-new-boot-verification-system-1512937
http://www.androidpolice.com/2015/07/27/google-posts-details-of-user-facing-verified-boot-system-probably-coming-in-android-m/
https://source.android.com/devices/tech/security/verifiedboot/index.html
https://support.google.com/nexus/answer/6185381

What is the safest firmware solution?

~ hucktech ~ Leave a comment

Stephan of the coreboot project is currently having a Twitter conversation with some others. It includes this post:

This makes me wonder, has anyone compared Chrome’s Verified Boot with UEFI’s Secure Boot. With and w/o TPM chip on Intel or TrustZone on ARM. It would be nice if some cyypto-savvy researchers could analyze the crypto used in both implementations and give a comparison, including how these solutions meet the NIST and NSA/CC criteria for securing BIOS.

In terms of code size, coreboot has a much smaller codebase than tianocore, even with the all the additional size that Chrome brings to it’s coreboot dialect. But both Secure Boot and Verified Boot are nearly the same in terms of PKI.

On a related not, I’ll do a future blog post looking into the various boot flavors: Trusted Boot, Secure Boot, Measured Boot, Verified Boot, etc.