![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59PC World wrote an article on how the use of Intel Boot Guard by PC manufacturers is making it impossible for end-users to install replacement firmware such as Coreboot on their hardware. It's easy to interpret this as Intel acting to restrict competition in the firmware market, but the reality is actually a little more subtle than that.
UEFI Secure Boot as a specification is still unbroken, which makes attacking the underlying firmware much more attractive. We've seen several presentations at security conferences lately that have demonstrated vulnerabilities that permit modification of the firmware itself. Once you can insert arbitrary code in the firmware, Secure Boot doesn't do a great deal to protect you - the firmware could be modified to boot unsigned code, or even to modify your signed bootloader such that it backdoors the kernel on the fly.
But that's not all. Someone with physical access to your system could reflash your system. Even if you're paranoid enough that you X-ray your machine after every border crossing and verify that no additional components have been inserted, modified firmware could still be grabbing your disk encryption passphrase and stashing it somewhere for later examination.
Intel Boot Guard is intended to protect against this scenario. When your CPU starts up, it reads some code out of flash and executes it. With Intel Boot Guard, the CPU verifies a signature on that code before executing it[1]. The hash of the public half of the signing key is flashed into fuses on the CPU. It is the system vendor that owns this key and chooses to flash it into the CPU, not Intel.
This has genuine security benefits. It's no longer possible for an attacker to simply modify or replace the firmware - they have to find some other way to trick it into executing arbitrary code, and over time these will be closed off. But in the process, the system vendor has prevented the user from being able to make an informed choice to replace their system firmware.
The usual argument here is that in an increasingly hostile environment, opt-in security isn't sufficient - it's the role of the vendor to ensure that users are as protected as possible by default, and in this case all that's sacrificed is the ability for a few hobbyists to replace their system firmware. But this is a false dichotomy - UEFI Secure Boot demonstrated that it was entirely possible to produce a security solution that provided security benefits and still gave the user ultimate control over the code that their machine would execute.
To an extent the market will provide solutions to this. Vendors such as Purism will sell modern hardware without enabling Boot Guard. However, many people will buy hardware without consideration of this feature and only later become aware of what they've given up. It should never be necessary for someone to spend more money to purchase new hardware in order to obtain the freedom to run their choice of software. A future where users are obliged to run proprietary code because they can't afford another laptop is a dystopian one.
Intel should be congratulated for taking steps to make it more difficult for attackers to compromise system firmware, but criticised for doing so in such a way that vendors are forced to choose between security and freedom. The ability to control the software that your system runs is fundamental to Free Software, and we must reject solutions that provide security at the expense of that ability. As an industry we should endeavour to identify solutions that provide both freedom and security and work with vendors to make those solutions available, and as a movement we should be doing a better job of articulating why this freedom is a fundamental part of users being able to place trust in their property.
[1] It's slightly more complicated than that in reality, but the specifics really aren't that interesting.
UEFI Secure Boot as a specification is still unbroken, which makes attacking the underlying firmware much more attractive. We've seen several presentations at security conferences lately that have demonstrated vulnerabilities that permit modification of the firmware itself. Once you can insert arbitrary code in the firmware, Secure Boot doesn't do a great deal to protect you - the firmware could be modified to boot unsigned code, or even to modify your signed bootloader such that it backdoors the kernel on the fly.
But that's not all. Someone with physical access to your system could reflash your system. Even if you're paranoid enough that you X-ray your machine after every border crossing and verify that no additional components have been inserted, modified firmware could still be grabbing your disk encryption passphrase and stashing it somewhere for later examination.
Intel Boot Guard is intended to protect against this scenario. When your CPU starts up, it reads some code out of flash and executes it. With Intel Boot Guard, the CPU verifies a signature on that code before executing it[1]. The hash of the public half of the signing key is flashed into fuses on the CPU. It is the system vendor that owns this key and chooses to flash it into the CPU, not Intel.
This has genuine security benefits. It's no longer possible for an attacker to simply modify or replace the firmware - they have to find some other way to trick it into executing arbitrary code, and over time these will be closed off. But in the process, the system vendor has prevented the user from being able to make an informed choice to replace their system firmware.
The usual argument here is that in an increasingly hostile environment, opt-in security isn't sufficient - it's the role of the vendor to ensure that users are as protected as possible by default, and in this case all that's sacrificed is the ability for a few hobbyists to replace their system firmware. But this is a false dichotomy - UEFI Secure Boot demonstrated that it was entirely possible to produce a security solution that provided security benefits and still gave the user ultimate control over the code that their machine would execute.
To an extent the market will provide solutions to this. Vendors such as Purism will sell modern hardware without enabling Boot Guard. However, many people will buy hardware without consideration of this feature and only later become aware of what they've given up. It should never be necessary for someone to spend more money to purchase new hardware in order to obtain the freedom to run their choice of software. A future where users are obliged to run proprietary code because they can't afford another laptop is a dystopian one.
Intel should be congratulated for taking steps to make it more difficult for attackers to compromise system firmware, but criticised for doing so in such a way that vendors are forced to choose between security and freedom. The ability to control the software that your system runs is fundamental to Free Software, and we must reject solutions that provide security at the expense of that ability. As an industry we should endeavour to identify solutions that provide both freedom and security and work with vendors to make those solutions available, and as a movement we should be doing a better job of articulating why this freedom is a fundamental part of users being able to place trust in their property.
[1] It's slightly more complicated than that in reality, but the specifics really aren't that interesting.
Suggested fix?
Date: 2015-02-16 09:00 pm (UTC)Re: Suggested fix?
Date: 2015-02-16 11:21 pm (UTC)Re: Suggested fix?
Date: 2015-02-16 11:22 pm (UTC)Re: Suggested fix?
Date: 2015-02-17 04:29 pm (UTC)Re: Suggested fix?
Date: 2015-02-17 05:42 pm (UTC)Re: Suggested fix?
Date: 2015-02-18 07:18 am (UTC)There's really no sensible way to allow user interaction at this stage.
On FUSES, READONLY and how to design this feature in REPLACEABLE ways.
Date: 2015-12-13 03:08 pm (UTC)Make fuses eraseable. But only upon asserting some hardware key. So one with physical access can force-erase fuses, BUT only if hardware key toggled.
On hardware level implementation can be like this: fuses are often just some FLASH- or EEPROM-like memory, which just lacks ERASE procedure, so once WRITE occured, you can't write new values again, because to do it flash have to be erased and there is no ERASE. Sometimes OTP memory can be programmed more than once, if bits only change in WRITE direction, but not in reverse ERASE direction. Yet, hardware can be designed in way it prevents further partial WRITEs if desired.
My idea is: ERASE can be here. Flash/EEPROM/etc memory requires "high voltage" to erase or program data (internally generated, but power supply input pin can be separate). This could be put on separate pin. Button press would energize this pin. In this case, witout button press you can't neither program, nor re-program FUSES. At manufacture you have to assert Vpp to write fuse. At re-program you have to do the same. And hardware itself should be unable to do it under program control. Only pysical button press should activate it. If Vpp voltage is physically missing, erase or write just not going to work for purely physical reassons. So even if software executes erase/write sequences, it just not going to work due to lack of programming voltage. Write fails and there is nothing software can do about it.
I can also admit Google's approach: they have read-only SPI ROM with "base" code, and then code here can be configured to allow or disallow unsigned boot, subject to some procedures. Software can't overwrite SPI ROM: its #WP pin is tied to ground, so it happens to be READONLY. And if one really wants to reflash this part, SPI prommer can replace SPI readonly "base". Then you'll have new readonly base running YOUR code. Replacing it in software would not work. And it's actualy most reliable way to have trusted code base: if trusted code base is readonly, nobody can change it. And requirement of physical action ensures this action can't happen in unnoticeable manner most of time. OTOH we do not know if OEM or Intel or whoever has shared their private key and can't check this.
Re: Suggested fix?
Date: 2016-05-15 06:25 pm (UTC)