Salon Topic 3. Boot, Firmware & Supply Chain

[shannona]

Tell us more about your thoughts on the issues of Boot, Firmware & Supply Chain.

Here's some notes from the Salon:

Secure silicon doesn’t exist on its own. There are also bootloaders and firmware and a whole supply-chain. The supply-chain needs authentication and the code needs auditability and verifiability. Black-box code can make all of this problematic. Do attestations or lists of trusted manufacturers help to solve these problems?

This core issue also led to discussions of the problem of authentication, in large part due to Google moving away from passwords and toward device sign-ins. Uploading keys into HSMs and using OCAPs may both offer solutions to some of these problems.

[simonratner]

Just on the bootloader and firmware parts alone, there are several sub-topics to unpack:

1. On-chip secure bootloader and verification of internal flash firmware. Common implementation of this involves embedding a public key into the bootloader, and having the bootloader verify the signature of the application firmware image on boot.

   • It is important that chip vendors allow this secure bootloader to be replaced entirely by the device manufacturer, or to support multi-stage boot where the vendor bootloader boots into the manufacturer bootloader which in turn boots into the application image. This way the device manufacturer does not have to trust the chip vendor, and retains control of their own signing keys.
   • What about user-controlled firmware keys? If the above requirement is met, device manufacturers have the flexibility of allowing users to use their own signing keys and to build their own firmware images (with some added complexity - and added risk - of providing a mechanism by which the manufacturer bootloader can be updated or replaced).
   • Actual security often lies in the resilience of internal memory protection offered by the chip vendor; there have been multiple instances of chip memory protection being broken or bypassed.

2. Multi-chip verification. It gets harder when the integrity of multiple chips must be mutually assured. See Breaking Ledger Security Model (cache) for a discussion of the problem and possible attacks.

   • Related to this is mutual authentication of components to ensure they had not been replaced by untrusted ones (think iPhone secure enclave blocking fingerprint ID after a screen repair, since the integrity of the fingerprint reader could not be confirmed).

3. External flash verification (and related, encryption).

   • Factory reset / recovery images are often stored in external flash; modifying this external flash and triggering a factory reset or firmware rollback may allow a device to be compromised.
   • Execute-in-place (XIP); due to code size limitations or other reasons, some code may be executed from external flash directly.

[kanzure]

Soft request for more and better definitions. For example, what is the secure bootloader versus any of the other bootloaders that might be installed. There is a chip maker, device manufacturer, and user; are there any other parties to specify?

Factory reset / recovery images are often stored in external flash; modifying this external flash and triggering a factory reset or firmware rollback may allow a device to be compromised.

The owner of the chip or device should be able to configure the factory reset behavior: do all the secrets get erased upon factory reset? Is there a legitimate use case for secrets to not be wiped upon factory reset? If secrets are encrypted on the device with a sufficiently strong key, then does it matter if factory reset + new firmware gets access to it? or is the assumption that on-board encryption is with a short human-memorable key?

[simonratner]

What is the secure bootloader versus any of the other bootloaders that might be installed

This is used very loosely. I have seen the term describe anything from "non-replaceable bootloader in ROM using chip secrets", to "any code capable of verifying a firmware image before booting it", with a spectrum of capabilities in-between.

Here's an example boot sequence:

@0x0000 chip vendor bootloader
  - non-replaceable
  - fixed feature set defined by chip vendor
  - uses internally stored keys and vendor specified image signing/encryption algo
  - jumps to 0x8000
  @0x8000 device manufacturer bootloader (for example, https://github.com/mcu-tools/mcuboot)
    - this is application code from the chip perspective, fully programmable, but generally 
      not part of the firmware update or reset images, not in-field upgradeable
    - supports device-specific boot and verification semantics
    - performs own image verification using own keys
    - jumps to @0xc000
    @0xc000 device manufacturer app code
      - in-field upgradeable via firmware update or factory reset

Mostly, when you see "secure bootloader" you can substitute "bootloader".

There is a chip maker, device manufacturer, and user; are there any other parties to specify?

Occasionally there may also be an original device manufacturer. As far as the user is concerned, the device is made and sold by "X", but really "X" is purchasing it from ODM "Y" and customising the software / configuration / branding. In this context, both "X" and "Y" may have influence over firmware images and signing keys. Sometimes "X" has full control and the ODM is irrelevant, but sometimes they have to supply their changes back to "Y" who will then build the final image for distribution (and may control the distribution of future updates).

re: factory reset

You bring up an important point about erasing keys on reset. Legitimate exception: firmware verification keys in the bootloader.

That's not what I was hinting at though. I am talking about an attacker running modified, untrusted code on the device. One possible vector for this is modifying the "pristine factory image" which may be stored somewhere in external Flash and may not covered by MCU memory protection:

• depending on bootloader implementation, this factory image may be unsigned (e.g. a bare-bones image provided by chip vendor), and sometimes the factory reset procedure bypasses image verification because it assumes the factory image to be "trusted", leaving the possibility for the factory image to be replaced with completely custom code.
• if factory image is signed, and subject to verification before being applied, this is still be a vector for downgrade attacks since the factory reset procedure generally ignores the downgrade check by design.

[ChristopherA]

We are currently planning another Silicon Salon for August 16th or 17th, 23rd or 24th (PDT), on the topic of boot, firmware, supply chain security, and updates. Crossbar has plans to share some of their thoughts on a new silicon architecture for this, and I'm lining up now other presenters on these topics.

A key challenge is what time zone is best for the presenters. Our last call was friendly for EU, but less so for Asia. If you are interested in presenting, let us know soon so we can pick a day and time zone that works for most!

-- Christopher Allen

[shannona]

We talked about this topic extensively at Silicon Salon 2:
https://www.siliconsalon.info/salon2/

But we're also happy to keep discussing it here!