[coreboot] A proposal against irreversible code signing.

Denis 'GNUtoo' Carikli GNUtoo at no-log.org
Tue Mar 15 22:36:41 CET 2016


Hi,

Coreboot, Replicant, and other communities have some trouble with
signed bootloaders/BIOS/UEFI. So would the following make sense?

Here the goal is to have boot integrity while still protecting the
user's freedom to modify all the software running on their hardware.

The implementation should be practical enough to permit most users, to
actually exercise that freedom.

Note that I didn't check every fact's accuracy.

Some approaches to the issue:

Chromebooks:
------------
  Part of the flash is made read-only to implement the root of trust.
  There is then a chain of trust with signatures.
  The user is also permitted to run the OS of their choice, and, in
  some case, to replace part of the boot firmware.
  In either cases the user is warned if the software is replaced by
  something not signed by the vendor.
  However to fully replace the boot fimrware, the users have to be
  knowledgeable enough to dissemble their computer to remove the write
  protection.
  An adversary capable of disassembling and reflashing the laptop can
  circumvent the boot integrity without the user's knowledge.

External TPMs[1] (v1.2?[1]):
----------------------------
  - TPM can be used to hash data (and optionally sign the hash).
    The hash of the next data also depends on the value of the previous
    hash.
  - TPM can also conditionally release secrets once a certain hash is
    attained.
    When using an encrypted data partition, it can be used to prevent
    simple[2] evil maid attacks, by verifying the integrity of the
    software used before opening that partition.
    That can be done by making each pieces of the boot chain send, to
    the TPM, the next piece of code that is executed (and optionally
    some configuration data).
    Once a given hash is attained, the TPM would release the secret.
    The secret could then be used in different ways:
    * As part of the key to open the partition.
      If the boot fimrware changes[4], then the partition cannot be
      opened anymore.
    * To display some secret picture to the user when prompting for the
      passphrase. This way, when the boot fimrware is changed, the
      secret isn't released. The users then wound (hopefully) not open
      the partition because they would suspect tempering. At first this
      sounds a good compromise, but, on older hardware[8], replacing
      the boot firmware carries not obligation for it to send its
      pieces to the TPM.

      It could instead send the pieces of the old boot fimrware, if it
      can be retrieved somehow. This way the TPM would release its
      secret. This is probably one of the reason[9] why the bootblock
      is often made read only on proprietary boot fimrwares.

      However we want users to be able to easily replace their boot
      firmware. And the boot fimrware and the TPM have to interact,
      because the TPM cannot interact directly with the user.

External CPU:
-------------
  Another approach would be to make an external CPU that can interact
  with the user check the boot fimrware.
  It could for instance warn the user in some ways, if the boot
  fimrware hash changed, or if the public key used to verify it changed.
  However that only shift the problem inside that external CPU, since
  the user might also want to change its firmware.

Internal TPM(ME)[1] and Boot Guard[1]:
--------------------------------------
  Here the TPM is an application inside the ME, and Boot Guard can be
  used to force the first piece of the boot fimrware to be sent to the
  TPM.
  Then to release the TPM secret, one would have to either prevent
  that, or break the TPM checksum(SHA1).
  The downside is that the code running inside the ME is non-free.
  Having the user being able to replace its fimrware would only result
  in shift the problem.

Bootroms[5] implementing signatures verification:
--------------------------------------------------
  Many ARM SOCs have the ability to check the signature of the first
  code executing after the bootrom[5].
  An example is documented on the USB armory wiki[6], for the Freescale
  I.MX53.
  The SOC vendor (or here the final user) typically fuses the hash of a
  public key inside the SOC. This is irreversible.
  It would not be realistic to expect each computer user, many
  non-technical, to handle their own PKI.
  This also includes not loosing the private key, while keeping it
  secure from attackers.

The proposal:
-------------
  The idea is to have a system that ties together the public key and a
  secret.
  On such system, any user would be able to replace the boot fimrware.
  But to still be able to boot the user would also have to replace the
  public key.
  When that happens, the previous secret would then be automatically
  erased and would have to be re-added.
  Having storage that big inside CPU/SOCs is probbaly unpractical, and
  dangerous[7].
  An external chip would then have to be used. Let's call that chip HBM
  (Hardware boot module).

                              +------------------+
  +-------------------------->|External connector|
  |                           +------------------+
  |                                ^         ^
  |                                |         |
  |                                |         |
  |                                |         v
  |   +---------------------+      |     +-------+       +-----+
  |   |         HBM         |<-----(---->|       |       |     |
  |   +------------+--------+      |     | Flash |<----->| CPU |
  +-->| Public Key | Secret |<-----+     |       |       |     |
      +------------+--------+            +-------+       +-----+
            ^          ^                               ^ ^
            |          |                               | |
            |          +----------------[Write/clear]--+ |
            +------------[read, Write(clears Secret)]----+

Usage: User chosen boot fimrware:
----------------------------------
  The user powers the computer. The HBM then verifies the boot flash.
  If the signatures matches, the HBM then flips a switch that would give
  exclusive access of the flash to the CPU. It would also release the
  secret to the CPU.

  The secret would be an image displayed at the same time than the
  password prompt (used to unlock the encrypted partition).
  An attacker trying to attack the user might still be able to capture
  that image if the users uses that computer in a public space. 
  Hopefully the reconstructed image would differ in some subtle ways
  that a careful user might be able to notify. 
  
  If the signature doesn't match, it might notify the user trough some
  GPIOs connected to a red led, and/or that powers off the computer.
  
  Once the user is notified, they would have to replace the public key
  and the secret to get the computer boot again.
  
  The machine could be recovered by connecting an external flasher to
  the HBM, ideally trough an easily available external connector.
  The external flasher could be some common ARM Single board computer.
  
  The boot fimrware could also be replaced from the CPU running it.

  With this system, the user could also be able to easily delegate the
  firmware updates to Their favorite GNU/Linux or boot firmware
  distribution.
  To change update provider the user would then replace the public key
  and could add back the same secret into the HBM. 

Usage: Android device vendor:
-----------------------------
  Most Android phones have a signed bootloader[10][11].
  This means that the bootrom[5] will check the bootloader's signature
  and refuses to boot the phone if it doesn't match.

  On many phones, the bootloader can be unlocked. This means that the
  bootloader will stop checking signatures of what runs after it.
  However, this doesn't mean that the phone's CPU will run the
  (modified) bootloader the user chose.

  Unlocking the bootloader will also, typically, trigger the erase of
  the Android data partition, and potentially other actions.

  With the previous proposal, implementing such requirement would still
  be possible:
  The secret would be the key(or a part of it) to open the data
  partition.
  After changing the bootloader, to boot, the user would need to add
  inside the HBM the respective public key, erasing the secret at the
  same time.
  Vendors could then keep the same features, but while letting users
  replace their bootloader.

References:
-----------
 [1]I'm not very confident with my knowledge on TPMs (and Boot guard).
 [2]https://github.com/GDSSecurity/EvilAbigail/
 [3]https://mjg59.dreamwidth.org/35742.html
 [4]And optionally its configuration.
 [5]A bootrom is just a fancy name for in-silicon assembly instructions
    that are executed first at boot.
    Typically this is used to implement signature verification,
    booting from a variety of external storage(MMC/SD, eMMC, NAND, SPI
    flash, etc), or loading its code from external buses(Serial,
    USB) and the order in which they are tried.
 [6]https://github.com/inversepath/usbarmory/wiki/Secure-boot
 [7]http://blog.invisiblethings.org/2009/06/01/more-thoughts-on-cpu-backdoors.html
 [8]Currently, newer Intel hardware don't match the freedom and
    privacy requirements.
 [9]Prevent hardware bricking is probably also one of
    the potential reasons.
[10]In contrast, many tablets have unsigned bootloaders.
[11]On embedded devices, the bootloader often does the equivalent of
    coreboot and grub.
    The functionality of each component of the boot chain might differ
    between devices and SOCs(System on a chip).

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160315/bc862270/attachment-0001.sig>


More information about the coreboot mailing list