Tag: Android Verified Boot

HowToForge: Building and flashing a secured AOSP build with verified boot and separate lockscreen password for the Nexus 5X

~ hucktech ~ Leave a comment

[…]This tutorial aims to provide detailed instructions on how to solve these caveats, building and flashing AOSP for the Nexus 5X with verified boot and using separate lockscreen/encryption secrets.

https://www.howtoforge.com/tutorial/building-and-flashing-a-secured-aosp-build-with-verified-boot-and-separate-lockscreen-password-for-the-nexus-5x/

CVE-2018-1000205: U-Boot, Verified Boot input validation

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2018/06/26/cve-2018-1000205-u-boot/

and https://firmwaresecurity.com/2018/06/07/teddy-reed-on-u-boots-verified-boot/

There is now a description for the CVE. Ah, this makes sense, the Verified Boot issues that Teddy Reed brought up earlier:

U-Boot contains a CWE-20: Improper Input Validation vulnerability in Verified boot signature validation that can result in Bypass verified boot. This attack appear to be exploitable via Specially crafted FIT image and special device memory functionality.

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

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

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

U-Boot gets Android Verified Boot (AVB) 2.0

~ hucktech ~ Leave a comment

Igor Opaniuk of Linaro posted a patch to the U-Boot list, adding Android Verified Boot 2.0 support:

This series of patches introduces support of Android Verified B oot 2.0,which provides integrity checking of Android partitions on MMC. It integrates libavb/libavb_ab into the U-boot, provides implementation of AvbOps, subset of `avb` commands to run verification chain (and for debugging purposes), and it enables AVB2.0 verification on AM57xx HS SoC by default. Currently, there is still no support for verification of A/B boot slots and no rollback protection (for storing rollback indexes there are plans to use eMMC RPMB). Libavb/libavb_ab will be deviated from AOSP upstream in the future, that’s why minimal amount of changes were introduced into the lib sources, so checkpatch may fail. For additional details check [1] AVB 2.0 README and doc/README.avb2, which is a part of this patchset.[…]

https://lists.denx.de/pipermail/u-boot/2018-April/326562.html

 

CopperheadOS on Android Verified Boot 2.0 docs

~ hucktech ~ Leave a comment

https://android.googlesource.com/platform/external/avb/#device-specific-notes

https://android-review.googlesource.com/c/platform/external/avb/+/582100

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

 

Dorian Cussen’s Android Security Reference

~ hucktech ~ Leave a comment

I just noticed this Android Security Reference. It has a few pages on boot phase:

https://github.com/doridori/Android-Security-Reference

https://github.com/doridori/Android-Security-Reference/blob/master/boot/verified_boot.md

https://github.com/doridori/Android-Security-Reference/blob/master/boot/bootloader.md

https://github.com/doridori/Android-Security-Reference/blob/master/boot/boot_process.md

http://kodroid.com/

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

 

Android Verified Boot enforced with 7.0

~ hucktech ~ Leave a comment

Sami Tolvanen of Google posted a blog about Android Verified Boot and how things have changed with Android 7.0:

Android uses multiple layers of protection to keep users safe. One of these layers is verified boot, which improves security by using cryptographic integrity checking to detect changes to the operating system. Android has alerted about system integrity since Marshmallow, but starting with devices first shipping with Android 7.0, we require verified boot to be strictly enforcing. This means that a device with a corrupt boot image or verified partition will not boot or will boot in a limited capacity with user consent. Such strict checking, though, means that non-malicious data corruption, which previously would be less visible, could now start affecting process functionality more. By default, Android verifies large partitions using the dm-verity kernel driver, which divides the partition into 4 KiB blocks and verifies each block when read, against a signed hash tree. A detected single byte corruption will therefore result in an entire block becoming inaccessible when dm-verity is in enforcing mode, leading to the kernel returning EIO errors to userspace on verified partition data access. This post describes our work in improving dm-verity robustness by introducing forward error correction (FEC), and explains how this allowed us to make the operating system more resistant to data corruption. These improvements are available to any device running Android 7.0 and this post reflects the default implementation in AOSP that we ship on our Nexus devices.[…]

Full post:
http://android-developers.blogspot.com/2016/07/strictly-enforced-verified-boot-with.html

Android 6.0 OEMs: support Verified Boot

~ hucktech ~ Leave a comment

Multiple news sites have a story about Android 6.0 and Google’s new security requirements for OEMs, such as including Android Verified Boot.

http://www.tomshardware.com/news/marshmallow-encryption-fingerprints-verified-boot,30369.html

http://www.zdnet.com/article/google-now-requires-full-device-encryption-on-new-android-6-0-devices/

http://www.androidauthority.com/new-google-oem-marshmallow-requirements-650266/