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.ht... [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.