SUSE Conversations


Our Planned Approach to Secure Boot



By: okir

August 8, 2012 10:13 am

Reads:2977

Comments:9

Rating:5.0

In this follow-on blog to UEFI Secure Boot, I will describe our plans towards UEFI Secure Boot. Note that when we say “SUSE”, we really mean two very distinct distributions -  SUSE Linux Enterprise on one hand, and openSUSE on the other hand. The latter, being a  community project, is rather independent in their decisions on how to address the issue -  so the description below should be considered as the current Plan of Record for SUSE Linux Enterprise, but in the context of openSUSE, it can be a proposal for the community’s consideration only.

As explained in the previous installment of this series, UEFI Secure Boot is a useful technology, making it harder for attackers to hide a rootkit in the boot chain.

And at the same time, already the basics of its operation – establishing a single root of trust – conflict with the principles of Open Source development, which must be independent and distributed to work.

On top of that, there are a number of licensing and legal headaches waiting for anyone who wants to make use of Secure Boot in its default form. The GPL v3 anti-tivoization clause being one, another one being the wording of Microsoft’s SysDev contract that precludes the  signing of GPLv3 binaries with a Microsoft-provided certificate.

Currently, the first desktop systems are shipping with Secure Boot support, and we expect it to become pervasive in all newly sold PCs toward the end of this year. And of course we expect all of them to be shipped with Microsoft’s Key Exchange Key (KEK) installed by default.

Some of these new machines will probably have a way to disable secure boot easily; in others it may be possible but cumbersome; and in still others it may be impossible without loss of other functionality.

Supporting UEFI Secure Boot essentially boils down to having a boot loader with a digital signature that the firmware recognizes as a trusted key, and in order to be useful to Enterprise customers, that key should be trusted by the firmware a priori, without requiring any manual intervention.

There are two ways of getting there. One is to work with hardware vendors to have them endorse a SUSE key which we then sign the boot loader with. The other way is to go through Microsoft’s Windows Logo Certification program to have the boot loader certified and have Microsoft recognize our signing key (i.e. have it signed with their KEK). We are currently evaluating both approaches, and may eventually even pursue both in parallel.

At the implementation layer, we intend to use the shim loader originally developed by Fedora – it’s a smart solution which avoids several nasty legal issues, and simplifies the certification/signing step considerably. This shim loader’s job is to load grub2 and verify it; this version of grub2 in turn will load kernels signed by a SUSE key only. We are
currently considering to provide this functionality with SLE11 SP3 on fresh installations with UEFI Secure Boot present.

Now it is probably clear why this approach offers the level of security that UEFI Secure Boot promises – there is an unbroken chain of verification, making sure only trusted and signed code gets executed prior to handing control to the Operating System kernel.

What isn’t clear is how this allows Open Source developers to run their own kernels, or bootloaders for that matter or how this complies with the GPL v3 license. In the next part of this series of blogs, we will explain how we intend to provide this with our version of the shim.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)
Our Planned Approach to Secure Boot, 5.0 out of 5 based on 1 rating

Tags: ,
Categories: Expert Views, openSUSE, SUSE Linux Enterprise Server

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

9 Comments

  1. Thank you!
    A fine start, and a ‘common sense’ approach for a common senseless situation. Look forward to reading more, specifically when it comes to openSUSE

    • By:Marcos

      I will disagree. The facts are simple: UEFI Secure Boot, as it stands now, is an ever more successful to keep free/open software out of computers.
      “What isn’t clear is how this allows Open Source developers to run their own kernels”? No, it’s very clear: Open Source developers can’t run their own kernels if they want to run some later version of Windows as well. MS didn’t even care to hide that fact: they already require permanent UEFI Secure Boot on ARM. Do you really think they will stop at that? History shows they won’t.
      The half-measures Red Hat, SUSE and others (basically bowing their heads to “the inevitable”) are applying are repeating a policy of appeasement that has been proven ultimately useless time and again.
      Now you can pat the SUSE developers’ back all you want. This decision is wrong and they will find out sooner rather than later, I’m afraid.

      • By:Olaf Kirch

        Well, I don’t think so. Secure Boot is not Trusted Computing, for one.

        On the other hand, there are a number of approaches that are within the UEFI spec that would allow the owner of the machine to run his own boot loader and kernel.

        For instance, one approach would be to have the shim loader validate the signature on grub versus a key installed in the TPM. Only the legitimate owner of a machine can initialize the TPM and store (or generate) a key in it. A valid signature by a TPM-owned key would prove that the boot loader has been installed by the legitimate owner of the PC. This conforms to the goals of Secure Boot but still gives the owner of the hardware full control over what will run on it.

        The problem with this approach is that setting up the TPM tends to be rather cumbersome in several BIOSes; plus you need UEFI drivers to actually talk to the TPM.

        In the end, we came up with some equally effective but more straightforward approaches. Vojtech will provide the details on them shortly.

        So no, Secure Boot is not the end of the free world. It just requires some creative thinking, and a lot of aspirin to figure out a way through the legal maze around it.

  2. By:Roman

    The GPL3 is not a licensing issue for signed keys, you simply need to provide instructions on how someone can generate their own keys, that’s all. See this podcast episode for a concise explanation: http://faif.us/cast/2012/jul/05/0x2D/

    • By:Olaf Kirch

      That is okay as long as the firmware allows the user to install those keys. Currently, we haven’t seen any machines that allow a “return to setup mode”, and frankly, I’d not hold my breath that a lot of them will.

      • The Microsoft certification requirements explicitly require that they do:

        “Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: “Custom” and “Standard”. Custom Mode allows for more flexibility as specified in the following:

        It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

        If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.

        The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.”

  3. By:MichaelM

    Can I just turned off Security Boot on my _OWN_ PC?

  4. Hi
    Translated this article. I will publish in my blog too.
    Always mentioning the an linking original an the author, of course!

    My particular point of view, as a simple user, I would like to be free to install what ever I want in my own PC!! Without the permission of any hardware or software company…
    Maybe it’s necesary as a free software a powerful free and open Hardware…

    Thank’s again for your work!! ;)

Pingbacks

  1. From: SUSE decide usar a solução do Fedora ao Secure Boot | Blog Seja Livre

  2. From: Озвучены планы по поддержке в SUSE режима безопасной загрузки UEFI | AllUNIX.ru — Всероссийский портал о UNIX-системах

  3. From: SUSE podria usar el Secure Boot UEFI de Fedora » MakubeX UchihA

  4. From: SUSE Linux Enterprise/openSUSE i UEFI | linog.info

  5. From: SUSE Linux Outlines Its Plans for Windows 8 Secure Boot | Fix-Singh - Computer Repair Leicester

  6. From: SUSE Linux Outlines Its Plans for Windows 8 Secure Boot | Install Ubuntu

  7. From: SUSE Linux Outlines Its Plans for Windows 8 Secure Boot | TabletPCTrend.com

  8. From: SUSE Linux Outlines Its Plans for Windows 8 Secure Boot | Tux Doc

  9. From: LinuxLife Blog - News: Secure-Boot: Suse erweitert Fedoras Strategie

  10. From: SUSE Linux joins in with Windows 8 secure boot plans | Install Ubuntu

  11. From: La solución de SUSE ante el “arranque seguro” de Microsoft | Ubuntizando.com

Comment

RSS