[personal profile] mjg59
Talking about Secure Boot again, I'm afraid. One of the things that's made discussion of this difficult is that, while the specification isn't overly complicated, some of the outcomes aren't obvious at all until you spend a long time thinking about it. So here's some clarification on a few points.

Secure Boot provides no additional security

Untrue. Attacks against the pre-boot environment are real and increasingly common - this is a recent proof of concept, and this has been seen in the wild. Once something has got into the MBR, all bets are off. It can modify your bootloader or kernel, inserting its own code to return valid results whenever any kind of malware checker scans for it. The only way to reliably identify it is to either move the disk to another system or to cold boot off verified media. By restricting pre-OS code to something that's been signed, Secure Boot does provide enhanced security.

Secure Boot is just another name for Trusted Boot

Untrue. Trusted Boot requires the ability to measure the entire boot process, which gives the OS the ability to figure out everything that's been run before OS startup. The root of trust is in the hardware and a TPM is required. Secure Boot is simply a way to limit the applications that are run before the OS. Once booted, there is no way for the OS to identify what was previously booted, or even if the system was booted securely.

Microsoft are just requiring that vendors implement the specification

Untrue. Quoting from the Windows 8 Hardware Certification Requirements:

MANDATORY: No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway Signature verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not pass signature verification, they must explicitly disable Secure Boot on the target system.

Section 27.7.3.3 of version 2.3.1A of the UEFI spec explicitly permits implementations to provide a physically present user override. Whether this is a good thing or not is obviously open to argument, but the fact remains that Microsoft forbid behaviour that the specification permits.

Secure Boot can be used to implement DRM

Untrue. The argument here is that Secure Boot can be used to restrict the software that a machine can run, and so can limit a system to running code that implements effective copy protection mechanisms. This isn't the case. For that to be true, there would need to be a mechanism for the OS to identify which code had been run in the pre-OS environment. There isn't. The only communication channel between the firmware and the OS is via a single UEFI variable called "SecureBoot", which may be either "1" or "0". Additionally, the firmware may provide a table to the OS containing a list of UEFI executables that failed to authenticate. It is not required to provide any information about the executables that authenticated correctly.

In both these cases, the OS is required to trust the firmware. If the firmware has been compromised in any way (such as the user turning off Secure Boot), the data provided by the firmware can be trivially modified and the OS told that everything is fine. As long as machines exist where users are permitted to disable Secure Boot, Secure Boot is not any kind of DRM scheme.

Secure Boot provides physical security

Untrue. Secure Boot does not in any way claim to improve security against attackers who have physical access, for the same reasons as the DRM case. The OS has no way to determine that the firmware's behaviour has been modified. A physically-present attacker can simply disable Secure Boot and install a piece of malware that lies to the OS about platform security. The "Evil Maid" attack still exists.

Secure Boot only defines the interaction between the firmware and the bootloader. It doesn't specify any higher policy

Misleading. It's true that Secure Boot only specifies the authentication of pre-OS code. However, if you implement Secure Boot it's because you want to ensure that only authenticated code has run before your OS. If there is any way for unauthenticated code to touch the hardware before your OS starts, you can't ensure that. If an authenticated Linux kernel is booted and then loads an unsigned driver, that unsigned driver can fabricate a fake UEFI environment and then launch Windows from it. Windows would falsely believe that it has booted securely. If that authenticated Linux kernel were widely distributed, attackers could use it as an attack vector for Windows. The logical response from Microsoft would be to blacklist that kernel.

The inevitable outcome of implementing Secure Boot is that every component that can touch hardware must be signed. Anyone who implements Secure Boot without requiring that is adding no additional security whatsoever.

Only machines that want to boot Windows need to carry Microsoft's keys

Again, misleading. Microsoft only require one signing key to be installed, and the Windows bootloader will be signed with a key that chains back to this one. However, the bootloader is not the only component that must be signed. Any drivers that are carried on ROMs on plug-in cards must also be signed. One approach here would have been for all hardware vendors to have their own keys. This would have been unscalable - any shipped machine would have to carry keys for every vendor who produces PCI cards. If a machine carried an nvidia key but not an AMD one, swapping a geforce for a radeon would have resulted in the firmware graphics driver failing to load. Instead, Microsoft are providing a signing service. Vendors will be able to sign up for WHQL membership and have their UEFI drivers signed by Microsoft.

This leads to the problem. The Authenticode format used for signing UEFI objects only allows for a single signature. If a driver is signed by Microsoft, it can't be signed by anybody else. Therefore, if a system vendor wants to support off-the-shelf PCI devices with Microsoft-signed drivers, the system must carry Microsoft's key. If the same key is used as the root of trust for the driver signing and for the bootloader signing, that also means that the system will boot Windows.

This is only a problem for clients, not servers

Not strictly true. While Microsoft's current requirements don't mandate the presence of Secure Boot on server hardware, if present it must be enabled and locked down as it is for clients. It's not valid for servers to ship with disabled Secure Boot support, or for it to be shipped in a mode allowing users to make automated policy modifications at OS install time.

Secure Boot is required by NIST

This is one that I've heard from multiple people working on Secure Boot. It's amazingly untrue. The document they're referring to is NIST SP800-147, which is a document that describes guidelines for firmware security - that is, what has to be done to ensure that the firmware itself is secure. This includes making sure that the OS can't overwrite the firmware and that firmware updates must be signed. It says absolutely nothing about the firmware only running signed software. Secure Boot depends upon the firmware being trusted, so these guidelines are effectively a required part of Secure Boot. But Secure Boot is not within the scope of SP800-147 at all.

It's easy for Linux to implement Secure Boot

Misleading. From a technical perspective, sure. From a practical perspective, not at all. I wrote about the details here.

It's only a problem for hobbyist Linux, not the real Linux market

Untrue. It's unclear whether even the significant Linux vendors can implement Secure Boot in a way that meets the needs of their customers and still allows them to boot on commodity hardware. A naive implementation removes many of the benefits of Linux for enterprise customers, such as the ability to use local modifications to micro-optimise systems for specific workloads. One of the key selling points of Linux is the ability to make use of local expertise when adapting the product for your needs. Secure Boot makes that more difficult.

Conclusion

Much reporting on the issues surrounding Secure Boot so far has been inaccurate, leading to misunderstandings about the (genuine) benefits and the (genuine) drawbacks. Any useful discussion must be based around an accurate understanding of the specification rather than statements from analysts with no real understanding of the Linux market or security.

Effect of Windows security bugs?

Date: 2012-02-12 10:16 pm (UTC)
From: (Anonymous)
What happens when a security bug in a signed Windows or driver version allows accessing the hardware? Once such a version is found could it not be used for all the same things as a Linux kernel that intentionally allows loading any module? Is there some efficient blacklisting or other mechanism to recover from this?

ROM firmware?

Date: 2012-02-13 07:34 am (UTC)
From: (Anonymous)
I don't think that many people have seen the attack vector of firmware that also needs to be signed. I guess the solution, is that it is possible to flash the hardware with a self signed firmware?
Do you know of any progress in that area? Hardware vendors making tools and specification available for signing and flashing?
I guess the procedure will be something like this:

1. User download Linux distro.
2. User disables secure boot.
3. User installs Linux distro.
4. Linux distro has a pop up, that ask if it should flash any hardware with a secure key that matches the distro kernel.
5. User enables secure boot with said key.

So step 4...?

Date: 2012-02-14 07:44 am (UTC)
tcpip: (Default)
From: [personal profile] tcpip
I might be beginning to sound like a broken record, but once again these posts are thoroughly appreciated.

You're a credit to the free software world.

Dual boot?

Date: 2012-02-15 11:55 am (UTC)
From: (Anonymous)
Is this the end of dual boot systems? I've always had dual boot systems on my home machines (mostly Windows for gaming, Linux for everything else) but this explanation makes it sound that one and only one signing key can be used by UEFI to authenticate the OS. Given that obviously Linux cannot carry Microsoft's key, this leaves no room for multi-OS options.
Did I misunderstand, or what we really need is an independent, third-party "UEFI Signing Authority" that distributes valid, OS-independent keys to trusted and approved OSes? Sorry but leaving this in Microsoft's hands is giving them way too much power!

Re: Dual boot?

Date: 2012-02-17 03:10 pm (UTC)
From: (Anonymous)
I believe that Windows 8 still supports booting from a machine with Secure Boot turned off. You only need it turned on if you're an OEM who wants to use the Windows 8 sticker. For Windows 8, I think we'll still have dual booting. With a giant amount of luck, maybe gaming on open platforms will have caught up before the release of Windows 9, or whatever garbage they release next. I'm not holding my breath, though.

Date: 2012-02-15 12:31 pm (UTC)
From: (Anonymous)
All reports I've seen so far say that Windows on ARM will require that there is no override for secure boot. This requirement apparently won't be there on x64 hardware.

Date: 2012-02-15 12:43 pm (UTC)
From: (Anonymous)
On x86(64) hardware you can also run older Windows versions which don't work with Secure Boot yet. ARM does not have older Windows versions, that's why Microsoft can be more strict.

Date: 2012-02-15 12:52 pm (UTC)
From: (Anonymous)
So wait, this means that microsoft is pretty much gonna be the only signing authority for UEFI device drivers for most of the computers?
That sounds really uncomfortable to me, I was expecting some sort of modular PKI signing system, not a single signature key system

there can be only one

Date: 2012-02-15 07:30 pm (UTC)
From: (Anonymous)
Just checking: in any system capable of booting Windows 8 with this feature, only Microsoft, a US-based limited liability corporation competing in many market segments, can have an opinion on whether option roms are trustworthy? That sounds like a real strategic marketing winner.

And shouldn't they be having a word with RSA about PR-catastrophic failure modes? Far better to fail in some way you can blame the users.

Legal Attack?

Date: 2012-02-15 08:30 pm (UTC)
From: (Anonymous)
Wouldn't it be possible to attack MS in court with allegations of violation of anti-trust law and anti competitive behaviour?

FSF somebody?

Re: Legal Attack?

Date: 2012-02-22 02:25 pm (UTC)
From: [identity profile] pjc50.livejournal.com
I'm not sure. If I understand this correctly, then ARM Windows 8 devices will only be able to run signed images, ie only Microsoft software; but this appears to be the current state of affairs for all mobile phones and tablet devices, and I don't see any legal intervention there.

Thanks, but IMHO 2 oversights

Date: 2012-02-15 10:28 pm (UTC)
From: (Anonymous)
Kudos for another excellent blog-post on this matter. But as the Windows8 Hardware Certification Requirements also extensively covers TCG-specifications (TPM, TIS, PPI, rtc.) in later chapters, IMHO two statements do not hold true:
1. Secure Boot can be used to implement DRM
2. Secure Boot provides physical security

You marked both of them as "untrue", which is correct when solely focusing on "Secure Boot". But when combined with "Trusted Boot", both statements become fully valid.

Cheers
Olf

But a solution for this?

Date: 2012-02-15 11:50 pm (UTC)
From: (Anonymous)
Ok, maybe some points have been misleading, but actually the problem is that M$ in the name of security is forcing us to buy Windows or not to have a working machine with any other OS soon or later it would happen. So what is your ideal solution for it? and what could be real an avoid to strengthen the M$ monopoly?. Maybe coreboot? another brand that creates not Windows 8 compliant-hardware?. Another CA authority? (maybe but could be paid by M$ and we as Linux users have to pay something that maybe we don't need or don't want.

Date: 2012-02-16 12:55 am (UTC)
From: (Anonymous)
Does Microsoft's take on Secure Boot contemplate anti-modchip provisions? Some enthusiast boards have A/B switches for the BIOS which presumably go away. But current practice for non-socketed Flash BIOS is often to put a SPI header/pogopin target nearby (easier than JTAG).

There are a couple motivations for non-vendor BIOS reflashing; fixing the damn ACPI tables is surprisingly popular, as is removing miniPCIe blacklists. There seems to be a lot demand for inclusion of "I have a windows license" OEM blobs though. Putting a tiny hardware stumbling block in front of a prize (like free Windows or BD access) will industrialize the circumvention hardware. The PS3 hack made it very difficult to acquire Atmel USB microcontroller boards briefly.

Is more secure?

Date: 2012-02-15 11:56 pm (UTC)
From: (Anonymous)
But is not more secure to encrypt my hard drive with something like truecrypt that encrypt the booting process?. At the end the most important is not the hardware but the information that the hardware let me generate and handle. I think is another M$ strategy to increase its power in the market and force us to pay its unfamous M$ tax. And whom will protect us from M$?

UEFI-specific keys?

Date: 2012-02-16 08:42 pm (UTC)
From: (Anonymous)
Very enlightening.

Would it not be reasonable to have two keys -- one for signing the boot loader and other executables up through launch, and another for signing device firmware?

Forced trust? What an idiocy.

Date: 2012-02-18 05:28 pm (UTC)
From: (Anonymous)
Well, as for me, FORCING me to trust to MS is a very BAD idea for my own security. If I'm forced to trust to those who pretends to be my guards, I'm definitely could consider myself JAILED. And mumbling about security does not excuses this fact. So yes, "secure" boot is about securely locking out customers out of their hardvare in favor of MS.

Beware Linux

Date: 2012-06-06 11:53 pm (UTC)
From: (Anonymous)
After all the analysis around UEFI, my humble opinion is that Red Hat along with other Linux Foundations should really discuss how to encounter this evil strategy. I know not of a manufacturer who would dare go against Micro$oft in this matter. And a company like System76 is not enough to remain sat and stood gazing at nature. Urgent actions must be fulfilled.
Does anyone have information about what some leading manufacturers are expecting? Like Dell, Sony, Lenovo, Asus....

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags