![[personal profile]](http://s.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.
no subject
Date: 2015-02-16 09:44 pm (UTC)That isn't to say that this security measure is useless (not every adversary is the NSA), just that this dichotomy between security & freedom is false here. As I'm sure you know well, the ability to inspect the code of your firmware is too much of a security benefit to just ignore. Intel is hurting both freedom and -in many ways,-security in this case.
no subject
Date: 2015-02-16 09:47 pm (UTC)There is no Intel signing key. Each vendor uses their own key. There are some vendors who can probably be compelled to give up such a key by the NSA without too much trouble, and there are some vendors who probably can't.
But yeah, that's part of the problem. Being forced to trust that your hardware vendor will maintain good key security isn't necessarily realistic. UEFI Secure Boot allows you to revoke your machine's trust in your vendor, this doesn't.
no subject
Date: 2015-02-17 02:02 am (UTC)That we know about. Just like there's no NSA key in windows NT.
no subject
Date: 2015-02-17 03:34 pm (UTC)This also means that the adversary that can get the keys via legal means (rather than pretty advanced hacking) isn't just the NSA anymore -- am I also supposed to trust e.g. Lenovo for not providing the Chinese goverment agencies with their signing key?
no subject
Date: 2016-02-22 11:14 am (UTC)no subject
Date: 2015-02-16 11:45 pm (UTC)I understand you're being really really REALLY anal about security, but think of how ridiculous it sounds for someone to open up your laptop, solder a jumper on the board, close it without damage(modern shitty laptop designs with clips make it impossible) and then somehow make a patch for the bios.
Not to bloody mention there's really no standard way of flashing bioses nowadays. Not even standard tools are guaranteed to do it and chances are they won't. It's far more common to have to do some soldering to even get Coreboot on.
How about the other way around? Have a special, security hardened laptop for a bit more money which is unflasable. There. All's fine with the world.
There's a ton of options and yet you display a bit of sympathy for the vendor/Intel. Also Secure Boot has yet to be used as it was intended to be used as a security feature. Right now it's just an annoyance.
no subject
Date: 2015-02-16 11:50 pm (UTC)There's nothing ridiculous about this at all. Several of the attacks described in the Snowden documents are exactly this.
There really is - UEFI capsule updates provide a standardised mechanism for handing payloads off to the firmware.
Nonsense. Several attacks against UEFI are entirely mitigated by Secure Boot. Several bootkits in the wild (including the GrayFish attack in the news today) are entirely prevented by Secure Boot.
no subject
Date: 2015-02-17 10:32 pm (UTC)The news mention that the GrayFish attack only corrupts the MBR. This is probably outdated information but what about GPT tables? Also, what about the small non-volatile memory UEFI has which can be used to store a crash dump? Can arbitrary code be ran from there early in the boot process?
no subject
Date: 2015-02-17 10:38 pm (UTC)no subject
Date: 2015-02-18 07:19 am (UTC)If you have nation-state-level adversaries, your system should never leave your sight.
no subject
Date: 2015-02-18 07:21 am (UTC)DOS?
Date: 2015-02-16 11:52 pm (UTC)Re: DOS?
Date: 2015-02-16 11:55 pm (UTC)Re: DOS?
Date: 2015-02-17 01:13 am (UTC)Hopefully Intel made it so you *had* to either fuse in a key or fuse in the lack of a key or the system wouldn't boot, to prevent that kind of vendor foot-shooting. Or some similar solution.
Re: DOS?
Date: 2016-02-29 11:26 pm (UTC)If I cannot do this, I've got two questions which I hope someone can answer:
1) is buying an SPI reader and verifying the BIOS manually enough, or is there extra firmware which BootGuard verifies that an SPI reader would miss?
2) Is there any risk at all of a Linux system being compromised if the BIOS is modified at runtime? In other words, does Linux execute AML, or read anything from the actual BIOS flash chip while it is running?
I don't see the benifits I just see trouble.
Date: 2015-02-17 02:02 am (UTC)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.
Date: 2015-02-17 02:02 pm (UTC)>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.
Date: 2015-02-17 11:54 pm (UTC)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".
boot guard would be even better if
Date: 2015-02-17 03:23 am (UTC)Re: boot guard would be even better if
Date: 2015-02-17 03:25 am (UTC)And please no NDAs.
No upgrading of CPU's anymore?
Date: 2015-02-17 06:48 am (UTC)Re: No upgrading of CPU's anymore?
Date: 2015-02-17 06:11 pm (UTC)1) This only applies to highly integrated systems with soldered down CPUs (like laptops) and anything with a user-replaceable CPU doesn't get this.
or (more likely)
2) It's not literally the CPU. It's in the PCH, but for the more highly integrated systems, the CPU and PCH are in the same package (although not same die) and I assume this is where the confusion comes from.
Intel even provides a proper solution...
Date: 2015-02-17 07:40 am (UTC)If you later want to make sure that your system wasn't tampered with, you can do a (remote) attestation step in which you have the TPM try to use a key sealed ('configured to only be readable if PCR(x)=y') to that hash. If the answer isn't satisfactory, something is wrong.
The TPM is a reasonably safe storage for keys, and using its crypto primitives, while slow, prevents replay attacks.
In this configuration, if you choose not to trust the vendor, you can simply clear the TPM, have it generate your own key pair, and use that for attestation.
So, the issue is that Intel, in their infinite wisdom, decided to also give vendors that other option (verified boot) that enables them to shoot their customers in the foot.
Similar to how Intel TXT uses an Authenticated Code Module (signed code as initialization dependency, this time Intel only), while AMD's SKINIT also just measures the code into an otherwise inaccessible TPM register, allowing the end user to decide which code to trust.
Really bad failure mode.
Date: 2015-02-17 07:49 am (UTC)a) They come clean tell all their users that the cerficates flashed in their cpu no longer provides security and that they should go buy someone else's laptop. A competetor's laptop to be exact since it'll take them a while to get hardware out of the door with fresh keys. Also they can scrap all their inventory.
b) They say nothing because they very likely can't afford a) *maybe* they will replace keys in new hardware but, really, that's incredibly unlikely.
Anyway the point being that there seems to be absolutely no incentive for vendors to respond responsibly to any breach, and no recourse for users. I honestly don't even know what a responsible and reasonable way for a company to handle this would even look like.
Re: Really bad failure mode.
Date: 2015-02-17 03:38 pm (UTC)My concerns
Date: 2015-02-17 08:26 am (UTC)However, when a security vulnerability is discovered in the UEFI implementation on my mainboard, how do I get it fixed? Will the vendors be as good at providing the patches as Android phone vendors are? What if my board is two years old and the vendor doesn't care anymore, do I have to throw it away?
It seems to be that this makes the security worse, not better.
Not to say that virtually all proprietary firmwares I've seen are severely lacking in quality. They are slow as hell, have unpleasant visual presentation (with the possible exception of apple) and often lack essential functionality (a debugger, shell, boot from USB mass storage, boot from SD, ...).
I'm unimpressed.
physical lock & security token
Date: 2015-02-19 05:06 pm (UTC)And make CPUs get the damn key from a dumb (read-only) security token!
Re: My concerns
Date: 2015-02-20 10:17 am (UTC)Some vendors even struggle to get firmware and bioses that work at all outside a very limited set of circumstances. Middle of 2014 I bought a Gigabyte baytrail-d motherboard and it could only boot windows 8 in uefi mode, nothing else,so you had to find a spare hard drive, install Win8 and reflash the BIOS to a slightly newer version which wasn't as buggy.
no subject
Date: 2015-03-03 11:59 am (UTC)no subject
Date: 2015-03-03 12:09 pm (UTC)Intel is innovative
Date: 2015-03-11 11:19 am (UTC)The product got quite some native advertising in the german IT-press.
You can gues, that the development-costs were high. In order to make it affordable to the public, the company includes things like the boot-guard, you mention.
At the local LUG we had two theme-evenings about UEFI and we dealt with that PC. The situation is that it will not boot from Harddisk in UEFI-mode, and when you ask Intel, they really recommend, to use legacy-mode instead. So you have a super-modern, super-innovative PC and you have to run it in legacy-mode, because you are not using Windows. This is clearly the reason for me, why not to buy such products.
Intel wants to discriminate against Linux and probably also other alternative operating-systems.
mistaken
Date: 2015-06-24 06:34 pm (UTC)system vendors dont flash cpu fuses; that is simply ridiculous... intel does that... system vendors do flash firmware.
typical intel consumer lock-in tactics. dont be fooled by "unified".. it was EFI which was and is proprietary (EFI code is in current uefi implementations)... microsoft did the same antitrust code in acpi. i had to disassemble, find evidence and threaten justice to get it fixed. i do believe they contacted insyde and told them to fix the microsoft junk that is hardcoded into every one of our machines... linux users should thank me :-P
whole bunch of born yesterday everywhere. think ya'll invented something new, but you are running on a technology designed the brightest minds over 50 years ago.. Please don't fail to look back and marvel, and never say something old wasn't good or better.
even in its most secure configuration, uefi provides no security guarantee and increases attack surface. ill prove it to you one day.
16 bit bios was fine. getting to 32 bit can literally be done a few lines of code. on modern systems, these classic bootloaders can be extremely small, simple and secure.. i would say military grade.
intel is breaking some core backwards compatibility mantras here and this is definitely lock-in.
avoid uefi, call your intel representative and voice your concerns. If they want to break compatibility, they could at least fix privileged instructions so software could not not break the outer ring.
why do things keep getting worse.
CC
Re: mistaken
Date: 2015-06-24 06:52 pm (UTC)What's ridiculous about it? It's the system vendors who know what their signing key looks like.
Re: mistaken
Date: 2015-06-25 09:22 am (UTC)Re: mistaken
Date: 2015-06-25 09:41 am (UTC)Re: mistaken
Date: 2015-06-25 09:53 am (UTC)Flash however can be programmed and reprogrammed; usually implemented with NAND/NOR memory.
Re: mistaken
Date: 2015-12-13 11:43 pm (UTC)In NOR case, you start with pre-erased 0xFFFF... ("all ones") in whole block. WRITE procedure brings desired bits down, creating number you want as the result. The only way to get bits back to 1 from 0 is perform ERASE. If hardware can't erase it, you can't do it, obviously. This design theoretically allows to have several programming operations: you can create new number if it only needs to transit 1s to 0s but not reverse. Yet, if it desired to have "true" OTP, where you can have only one shot, there could be lock bit in same area, wihch is cleared after write completion and locks down further write attempts alltogether. That's how fuses are often implemented. Though Intel may or may not have such implementations.
Actually, many microcontrollers have eraseable fuses. Though security-sensitive ones (e.g removal of cheap readout protection) usually causing whole IC to perform mass-erase of its NVM memory before unlocking fuses. This ensures you can overtake system if desired, BUT would not get any protected program code or data. Actually, if system designer used microcontroller with builtin memory and locked out reading, one can have quite hard time trying to reverse engineer uC firmware.
At the end you receive "vanilla" IC like if it was coming from factory, without any data left. In principle, similar tech can do secure booting as well. I.e. external software could be unable to access internals, and internal code can do verification and refuse to harm itself, at least until request comes from proper signing key owner. Yet it assumes some rewriteable on-chip memory and seroius separation of interal onchip resources vs externally available ones.
And even then you can't fully trust IC vendors. There was Actel FPGAs. They advertiesed secure code protection: their hardware encrypts configuration bitstream stored in flash array using AES. So even if you dissolve IC package and use electronic beam to read flash array, all you get is a garbage. Sounds interesting, right? But wait, some smartass got idea it is interesting to throw various bytes to JTAG, fuzzing JTAG controller. It turned out, Actel had (undocumented) commands which were able to read firmware back. In already decrypted form. Yay! So everybody can dump "protected" firmware at will. That's what you get if you trust marketing BS from vendors too much.
At the end of day, there is only one good option to make sure IC does what advertised. It have to be open hardware...
Who cares?
Date: 2015-08-04 07:29 am (UTC)Re: Who cares?
Date: 2015-09-03 11:33 pm (UTC)Who cares? Only those who see the benefit in open source operating systems, utilities and support FSF/OSF. Forgetting cost, they want the freedom to be able to study how and what a program/operating system is actually doing - with their personal information and data. And those who aren't in love with the Microsoft/NSA relationship - closed operating source so no audit on what Microsoft could/does plant in the code.
Being able to have an open source BIOS, while important, is only the side issue here. The issue is closed hardware that contains a significant amount of, for lack of a better term, execution time code - code different to that implementing basic hardware instruction set and function. The issue is the Intel ME. Both the dedicated hardware and the encrypted blob (code) that it runs. Perhaps in its early incarnations were acceptable but in later Intel chipsets the ME hardware and software cannot be disabled. From Igor Skochinsky's paper:
. Management Engine (or Manageability Engine) is a dedicated microcontroller on all recent Intel platforms
. Shares flash with the BIOS but is completely independent from the main CPU
. Can be active even when the system is hibernating or turned off (but connected to mains)
. Has a dedicated connection to the network interface; can intercept or send any data without the main CPU's knowledge
So in short if you are happy with a separate "watch dog" processor running alongside your PC's main processor, with nearly unlimited ability to snoop on what the main processor is doing/has access to AND is capable of out-of-band network access,, well then I guess you are right - there's no reason to want something like Coreboot, no big deal.
Re: Who cares?
Date: 2016-02-29 11:48 pm (UTC)If you want a system without the ME firmware or any other binary blobs, I think you can get systems with Libreboot pre-installed from https://minifree.org/ or the Gluglug website (if it still exists).
More information:
http://me.bios.io/Main_Page
https://www.coreboot.org/Intel_Managemen
https://www.coreboot.org/Binary_situatio
https://libreboot.org/docs/hcl/gm45_remo
https://libreboot.org/faq/#intelme
https://libreboot.org/docs/hcl/index.htm
Re: Who cares? I do!
Date: 2015-12-13 05:39 pm (UTC)First, those who would give up their essental liberty to obtain little temporary safety, deserve neither liberty, nor safety. That's how B. Franklin told it, and it seems to be very true.
Second, UEFI shit is not customizable and proprietary, and could expose really nasty bugs. Say, my system firmware would lock up if I hit shift key a moment before GRUB has been started. This makes entering GRUB menu really challenging and annoying and I have to reboot like 3-5 times to just be able to boot with desired version. Because if I hit key half second earlier before GRUB, system locks up. And no, this awful bug is not going to be fixed. Ever. So you can be sure I would seriously consider using some less fucked hardware next time.