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
Uncategorized

Signing boot images for Android Verified Boot

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

 

Standard
Uncategorized

Verified Boot

Marc Kleine-Budde of Pengutronix gives a talk at the Embedded Linux Conference Europe (ELCE), on using Verified Boot.

http://linuxgizmos.com/protecting-linux-devices-with-verified-boot-from-rom-to-userspace/
http://elinux.org/images/f/f8/Verified_Boot.pdf

https://www.linux.com/news/event/elcna/2017/2/verified-boot-rom-userspace

Standard
Uncategorized

coreboot 4.4 released!

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/

Standard