Uncategorized

Chrome OS firmware change may support Verified Boot of Windows?

[…]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/

Standard
Uncategorized

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

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).
[…]

https://www.pcisecuritystandards.org/ptsdocs/RP450RP456RP457_PCI_Security_Policy-1461704231.78085.pdf

 

Standard
Uncategorized

dump_avb_signature: dump/verify Android Verified Boot signature hash

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

 

Standard
Uncategorized

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

 

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

http://www.uefi.org/sites/default/files/resources/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. 🙂

Standard
Uncategorized

Android Oreo Verified Boot’s Rollback Protection

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

 

Standard
Uncategorized

CMC-Vboot: investigates Chrome’s Verified Boot

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

Standard