![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Intel Boot Guard, Coreboot and user freedom
PC 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.
I don't see the benifits I just see trouble.
(Anonymous) 2015-02-17 02:02 am (UTC)(link)This makes 3 questions cross my mind.
1) What happens if I replace the cpu. Am I now magically left unprotected.
2) Am I now stuck that I cannot swap cpu between different model motherboards at all if it been written.
3) With Intel Boot Guard how do I deal with vendor who private key leaks. Do I have to dump all that vendors hardware to be secure again. There appears to be absolutely no way to update the public key.
In my eyes it would have been more sane to add a i2c bus to the cpu to a chip that hold the public key. Of course from the cpu this been a read only i2c bus with a very limit set of instructions. People with direct physical access could remove and replace chip in case of vendor private key leak. CPU's would have remained replaceable. The i2c chip could be a pure rom and the storage ram in cpu for the key could be not writeable by anything else.
Protected Path idea does not like the idea that people will load up their own code.
Intel Boot Guard does not stop you attacker ripping out your cpu and putting in another one. Once a person has physical access all bets that the firmware will not be replaced is off. Really nothing stops attacker replacing complete motherboard in device. Its not the first time that complete laptops have been swapped to attack networks.
Intel Boot Guard makes it more profitable for Intel not really any more secure. In fact worse because a case of 2 computers 1 with borked motherboard and one with borked cpu you will not be able to make 1 out of 2. This could be life and death. Think you are at somewhere like the south pole or on mars no easy access to spares. So the boot guard could kill people.
Yes Intel Boot Guard is environmentally unfriendly and a health hazard.
Re: I don't see the benifits I just see trouble.
(Anonymous) 2015-02-17 02:02 pm (UTC)(link)>Intel Boot Guard does not stop you attacker ripping out your cpu and putting in another one
Right - what's to stop the attacker from switching the CPU for one that trusts their modified firmware? Is it only intended for systems where the CPU is soldered to the motherboard?
It sounds like this scheme is intended for the ultra-paranoid against a targeted attack, but an attacker that resourceful could always swap out as much of the machine's hardware as they like.
Consequently this form of protection seems to have a fairly narrow threat model that it will protect against (an attacker sufficiently dedicated that they are targeting you and get physical access to the machine, but not to the extent that they will actually replace any hardware), which makes me highly doubt that the pros will be worth the cons.
Re: I don't see the benifits I just see trouble.
(Anonymous) 2015-02-17 11:54 pm (UTC)(link)Once you have an adversary willing to swap out hardware, isn't it almost as easy to swap the board? You have to hire and train people with security clearances, write attack tools, divert the hardware to you... I don't imagine a few hundred dollars in extra parts and labour are a major problem at this point.
And out of curiosity, is anyone (maybe corporations?) known to be "paranoid enough that you X-ray your machine after every border crossing".