UEFI secure booting and possible consequences

UEFI secure booting and possible consequences

Ritratto di Igor Levicki
Igor Levicki
Ven, 14/10/2011 - 09:37

Hello Intel,

I would like to draw attention of your UEFI engineers and product managers to possible consequences of adopting unregulated UEFI BIOS signing.

What is this all about?

UEFI secure booting is a means of booting an operating system while making sure that pre-boot environment (BIOS, boot loader) were not compromised by virus or malware.

As such, it is a nice idea for improving PC security. However, if not implemented carefully, it may have severe consequences on the software and hardware industry.

UEFI BIOS secure booting process manages security by refusing to boot an unsigned operating system. What is worse, it may prevent you from installing an unsigned operating system (such as Linux, FreeBSD, etc), or even from installing another brand of video card!

Since there is no central authority for UEFI signing keys, and the user has no control over signing key blacklists and whitelists, the only keys that will be guaranteed to be included will be Microsoft's keys. In practice, that means user will only be able to run Microsoft Windows 8 and its successors on such hardware, and system vendor (OEM) will dictate whether broken or outdated AMD video card can be replaced by new NVIDIA card simply by including or not including NVIDIA keys in the BIOS.

Not only this further extends Microsoft's monopoly on the PC market and allows for underhanded deals between hardware manufacturers, it also removes any control over software and hardware capabilities of the PC from us consumers.

If we analyze this "security" initiative further, it becomes clear that the ultimate goal is not to protect consumers from outside threats, but to prevent them from using "insecure" systems which can allow them potentially unrestricted access to, and manipulation of, copyrighted digital content.

I am posting this here on the ISN because Intel Corporation and its engineers working on UEFI are, knowingly or not, willfully or not, acting as enablers of this potentially damaging change in the software and hardware industry.

I urge all involved parties to carefully reconsider. Major Linux distributions may overcome this obstacle, but compiling your own kernel, and tinkering with software and hardware may become impossible in the near future.

To enable progress, our systems have to be open, not locked down.

For further information on this very important issue please follow the Matthew Garrett's journal:
http://mjg59.livejournal.com/

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
RSS In cima
6 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Brian Richardson (Intel)
Brian Richardson (Intel)
Mer, 27/03/2013 - 15:57

Even though this post is over a year old, I'd like to provide some comments since the UEFI Secure Boot situation has evolved quite a lot.

First of all, the Microsoft Windows 8 requirements are quite clear that secure boot can be disabled by the user. This allows the machine owner to set platform policy, either by disabling secure boot or enrolling an alternate set of keys. A number of tools for Linux have emerged, including a set from the Linux Foundation that handle key/hash enrollment if the platform BIOS doesn't provide proper setup menus.

In regards to the signature process, Microsoft has demonstrated that the UEFI CA will sign Linux loaders. This includes the Linux Foundation toolset, shim loader for Fedora/Ubuntu and SUSE loader for MOK. This allows distributions like openSUSE 12.3 and Ubuntu 12.10 to work "out of the box" on any system with the UEFI CA DB entry.

Intel is concerned about UEFI and OS choice. Intel is the largest contributor to the Linux kernel and promotes the Tizen, Yocto and Android projects (see 01.org for info). Intel is also building the Minnow Board project for UEFI & Yocto development on open hardware (minnowboard.org). Any move that limits the ability to run Linux isn't in Intel's interests.

Articles of interest on this topic:
http://www.zdnet.com/uefi-and-secure-boot-in-depth-7000012138/
http://www.businesswire.com/news/home/20130319006268/en
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-re...
http://mjg59.dreamwidth.org/23817.html

-- Brian Richardson -- @intel_brian
In cima
Ritratto di Igor Levicki
Igor Levicki
Mer, 27/03/2013 - 17:24

Below is what Linus Torvalds said to Matthew Garrett regarding security aspects of "secure boot":

-- snip --
So here's what I would suggest, and it is based on REAL SECURITY and on PUTTING THE USER FIRST instead of your continual "let's please microsoft by doing idiotic crap" approach.

So instead of pleasing microsoft, try to see how we can add real security:

- a distro should sign its own modules AND NOTHING ELSE by default. And it damn well shouldn't allow any other modules to be loaded at all by default, because why the f*ck should it? And what the hell should a microsoft signature have to do with *anything*?

- before loading any third-party module, you'd better make sure you ask the user for permission. On the console. Not using keys. Nothing like that. Keys will be compromised. Try to limit the damage, but more importantly, let the user be in control. - encourage things like per-host random keys - with the stupid UEFI checks disabled entirely if required. They are almost certainly going to be *more* secure than depending on some crazy root of trust based on a big company, with key signing authorities that trust anybody with a credit card. Try to teach people about things like that instead. Encourage people to do their own (random) keys, and adding those to their UEFI setups (or not: the whole UEFI thing is more about control than security), and strive to do things like one-time signing with the private key thrown out entirely. IOW try to encourage *that* kind of "we made sure to ask the user very explicitly with big warnings and create his own key for that particular module" security. Real security, not "we control the user" security.

Sure, users will screw that up too. They'll want to load crazy nvidia binary modules etc crap. But make it *their* decision, and under *their* control, instead of trying to tell the world about how this should be blessed by Microsoft.

Because it really shouldn't be about MS blessings, it should be about the *user* blessing kernel modules.

Quite frankly, *you* are what he key-hating crazies were afraid of. You peddle the "control, not security" crap-ware. The whole "MS owns your machine" is *exactly* the wrong way to use keys.

Linus
-- snip --

I must say I absolutely agree with his opinion, however blunt it might sound. Maybe Intel should ask him for input next time they want to contribute this kind of technology to Linux.

-- Regards, Igor Levicki If you find my post helpfull, please rate it and/or select it as a best answer where applies. Thank you.
In cima
Ritratto di Sergey Kostrov
Sergey Kostrov
Sab, 30/03/2013 - 17:56

>>...First of all, the Microsoft Windows 8 requirements are quite clear that secure boot can be disabled by the user...
>>...
>>... Microsoft has demonstrated that the UEFI CA will sign Linux loaders...

Brian, you clearly out-of-date and take a look at:

Topic: Lawsuit against Microsoft UEFI secure boot
Web-link: www.zdnet.com/microsoft-windows-8-uefi-secure-boot-complaint-the-case-fo...

I could only imaging how many hours, possibly days, it would take for a user to get that magic key which unlocks the system with Windows 8 OS.

In cima
Ritratto di iliyapolak
iliyapolak
Dom, 31/03/2013 - 00:34

Another ugly (M$) attempt to dominate OS market.

In cima
Ritratto di Sergey Kostrov
Sergey Kostrov
Mar, 02/04/2013 - 05:58

Brian,

I just checked BIOS on my Dell Precision Mobile M4700 and it allows to Disable a Secure Boot and I see that my computer is Not affected ( Windows 7 Professional is installed on it and I don't have any plans to upgrade it to Windows 8 ).

In cima

Accedere per lasciare un commento.