Secure Boot: Who will control your next computer?

[beagle3]

Secure Boot is only going to hinder legitimate users in the long term.

iphone boot exploits, wii boot exploits, PS3 boot exploits have all been published freely mostly because they are very hard to capitalize on (these machines all have secure boot implementations, albeit not the UEFI one)

If UEFI secure boot exploits really protect against malware, they will be traded like 0-day exploits and will be worth a lot (I suspect it will be harder to update the firmware against these 0-days than running WindowsUpdate).

It's a landgrab; slow and cunning on the x86/AMD64, quick and merciless on the ARM. But it has a lot more to do with grabbing land than with end user security.

edit: drivebyacct2 claims that none of these 3 had security comparable with UEFI SecureBoot. I don't know enough to argue about that - my assumption is that it will be implementation flaws that will be exploited, rather than theoretical flaws. But I might be wrong.

[seanp2k2]

You've probably heard this a lot lately, but:

"everything Stallman said was true"...and now it's happening on a huge scale.

[cookiecaper]

Let's not get ahead of ourselves. Stallman is cool and everything but he is NOT 100% right. Most of us here, for instance, do not believe it is unethical to create "proprietary software". There is still a lot of basic philosophy on which to contest Stallman.

[mtgx]

People who are ahead of their time always get shot down by the majority.

[Legion]

And it's nice to see the FSF expressing the issues thoughtfully here, rather than pulling insipid stunts like harassing Apple Store employees.

Maybe it's because this is from FSFE - the European counterpart.

[gringomorcego]

well, it's not like anyone has made a real effort to stop it...

[jtsagata]

Today is secure boot. Next say some governments will make it illegal to buy a machine without a secure boot feature and forbids you to run any OS without a backdoor. Now i'am sure that your government will never do that

I personaly will never buy any machine, as soon as i can, as soon as it is still legal, with any "secure" feature. My machine is mine, not to the original manufacture, not to Microsoft or to Redhat or to anyone that believe that it is theirs. Even that i know that i live in a great democracy, i have nothing to hide, and my government is my good friend

[jsmcgd]

Couldn't all hardware that has this secure boot functionality simply include a physical switch that grants full access to the hardware? When the switch is on you can install any OS you like, when the switch is off no root kits could install themselves.

What do you think?

[Spoom]

While not a physical switch, I believe for x86 / AMD64 computers, Microsoft is mandating that the user must have the option to disable secure boot via firmware switch (see http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the... ).

The opposite is true of ARM, however.

[knowaveragejoe]

I agree that a compromise giving the best of both worlds would be the ideal outcome here.

[fpgeek]

I believe this is known as "the ChromeOS solution".

[knowaveragejoe]

Low level vulnerabilities are indeed something that need to be addressed - such vulns are a real (and growing) threat and by their very nature are incredibly hard to deal with. It's a shame countermeasures are taking this manifestation, however.

[ajross]

Is there any actual evidence for this? Why are they any harder to deal with than cleaning existing malware? If anything they're easier to detect (just read the boot sectors on the drive and compare vs. a small list of known bootloaders). "Clean up" just requires installing a new bootloader and rebooting. Obviously the malware could try to take steps (load compromised storage drivers, say) to defeat this, but that's equally an option for traditional malware too (e.g. hack the filesystem to hide itself).

Where's the urgency here? What makes this so important?

[sukuriant]

What other countermeasure would you suggest? If these countermeasures were OSS, would you complain?

[Create]

by trusting MS, surely RH can spare an HPC to sign the kernel every time...

http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft...

Not even to remember, that Mr. Sh. was in the random number selling and certification business in the first place. "I am what I am because of who we all are." -- VeriSign

[jiggy2011]

This would seem to suggest that the days of dual booting are numbered. Either if ARM becomes the key player or if the policy on x86 changes.

I'm not sure that general purpose computers will die though, geeks and developers are a big enough market to support manufacturers creating systems that are more powerful and flexible.

Assuming that Virtual Machine software is not blocked, with good enough visualization software and fast enough hardware (enough RAM especially) running a Linux VM with Windows 8 may be indistinguishable from running it directly on the chip.

If the OS becomes just a way to bootstrap a browser or VM I'm not sure how important it is anyway?

[yk]

How important is the foundation of a house, after all there is also a floor in the second storey of the building.

The entire point of the secured boot process is, that you can only boot a signed kernel. And in the case of iOS today, the kernel will only load signed programs. (And a VM is against the App Store guidelines, as is a python interpreter). So there is no guarantee, that you will be allowed to run a VM on your secure boot machine.

[rbanffy]

If every computer in the world is vulnerable to malware signed by a specific Microsoft key, how long do we think this key would remain secret? What will Microsoft do when (not if) that happens? Will they pay for the replacement of every PC and ARM device built to that point?

The benefit of breaking it and immediately gaining permanent undetectable access to every Windows-capable computer on the planet can offset a lot of cost.

[recoiledsnake]

If you want to make up stuff about Microsoft, at least make up something believable instead of straight up nonsense FUD.

[zokier]

The article nicely ignores the fact that on non-ARM platforms Secure Boot will be disableable.

[ajross]

For some definition of "will", I guess. It's part of the windows logo requirements for x86. For now.

But what happens when someone screws up? I buy a laptop with a windows logo and try to install OpenBSD or whatnot, only to discover that the "disable secure boot" option is missing or broken. What's my recourse? Wait for a firmware update (which we know from experience will never arrive -- it boots fine in windows)? Return the laptop (which works perfectly within its warranted behavior)? Whine and look sad?

The incentives are all wrong for this to be a stable situation. Over time and platform changes, "disable secure boot" is going to rot. We all know it.

[dlitz]

Who cares? There are going to be millions if not billions of Secure Boot ARM devices manufactured. x86 doesn't make this not a problem.

[tzs]

There seems to be a bit of confusion over exactly what Microsoft is requiring, so I did some Googling. The requirements are here: http://msdn.microsoft.com/en-us/library/windows/hardware/jj1...

The relevant parts for this discussion are:

    17. 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:

        1. 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 will put the system into
        setup mode.

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

        3. 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.

PK is the "platform key". It is the key used by the firmware to identify the platform owner, and is used by the platform owner to enroll the "key exchange key" (KEK). The KEK is used for the firmware and the operating system to establish a secure channel. DB is the database of authorized signatures and certificates. DBX is the database of banned signatures and certificates.

UEFI has two modes, "User Mode" and "Setup Mode". It is in User Mode when there is a PK enrolled, and in that mode the secure boot policy is enforced. When in Setup Mode, no secure boot policy is enforced, and PK, KEK, DB, and DBX are writeable without any authentication required.

In other words, in Setup Mode, you can put your own set of signatures and certificates in. You should be able to even put Microsoft's certificates and signatures in DBX and thus prevent people from installing Windows on your box. (Or, more practically, put Microsoft's keys in DB along with yours, so you can dual boot).

Also:

    18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems,
    it is required to implement the ability to disable Secure Boot
    via firmware setup. A physically present user must be allowed to
    disable Secure Boot via firmware setup without possession of
    PKpriv. A Windows Server may also disable Secure Boot remotely
    using a strongly authenticated (preferably public-key based)
    out-of-band management connection, such as to a baseboard
    management controller or service processor. Programmatic
    disabling of Secure Boot either during Boot Services or after
    exiting EFI Boot Services MUST NOT be possible. Disabling Secure
    Boot must not be possible on ARM systems.

[bcl]

Matthew Garrett's posts on Secure Boot do a pretty good job of covering how all this works: http://mjg59.dreamwidth.org/12368.html