
Secure Boot: Who will control your next computer? - mariuz
https://fsfe.org/campaigns/generalpurposecomputing/secure-boot-analysis.en.html
======
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.

~~~
beagle3
You may disagree with Stallman's philosophy (many do, me too). But his
predicitions WERE spot on, and they were made more than 30 years ago.

He predicted DRM for consumer media, and that DRM violations will carry a
harsh punishment. As the laws are written (and occasionally practiced), he was
more than spot-on.

He predicted being unable to run unapproved software on commodity hardware you
own. This has started happening with iPhone/iPad and somewhat with Win7 and
(boot locked) Android devices. This post is about it coming to a PC near you
in the near future via Win8 UEFI Secure Boot requirements.

In the beginning, you'll have to pay more to get hardware that can run
anything you fancy, and it some point you might not be able to.

I'd say his predictions were right. Philosophy and ethics is never a well
defined right or wrong, so I'm not sure what you are arguing with.

~~~
Create
Those were not predictions. Those things were already happening -- to
paraphrase, the rest of the world got caught up in the future of 30 years ago.

The "F* u nvidia" seems also to catch on slowly in Finland -> "there was a
disturbance that they needed to take care of. The officer then asked what the
disturbance was and the faculty member relented - they were worried that there
would be an incident, but that it hadn't yet happened." --
<http://www.fsf.org/blogs/community/rms-ati-protest.html>

~~~
beagle3
Was anything like DRM (sanctioned in law or not) happening in 1985 when
Stallman wrote "The right to read"?

I'm very interested in the details.

~~~
maratd
DRM is as old as the floppy. Frequently, bad sectors were created on the
original media and the software checked for those bad sectors. If you copied
the software, you couldn't copy the bad sectors, so the software wouldn't
load.

~~~
beagle3
That's a very distant cousin to DRM: if you had two machines, you could just
move the floppy or dongle between them (or lend them to a friend, or resell
them). You cannot do this with your DRMd music or ebooks. Furthermore, your
software and data were usable even if the authorization server went down.
(google play4sure if you are not familiar with a modern counter example ).

Furthermore, quaid software's "Copywrite" and central point's option board
were able to copy just about everything, and we're legally sold and marketed.

French and US 3-strike accusation-based penalty is very much in line with what
stallman was describing. copy protection of the 80's isn't.

The guy deserves credit for quite accurately predicting a non-trivial future.

------
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...](http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-
environment-with-uefi.aspx) ).

The opposite is true of ARM, however.

~~~
flatline3
> _The opposite is true of ARM, however._

There isn't even a non-proprietary standardized ARM platform. You have things
like OMAP, but that's defined by TI:

<http://en.wikipedia.org/wiki/OMAP>

~~~
rbanffy
Fair enough. Microsoft is demanding _no ARM-based platform_ running Win8 can
have their locked-down boot mechanism disabled. In other words, Microsoft is
demanding manufacturers make machines that can only run software Microsoft
allows them to run.

Sounds like a really boneheaded move.

~~~
flatline3
> _Sounds like a really boneheaded move._

Or a market opportunity. Hard to say -- in many respects, the standardized PC
is a fluke, created through clean-room reverse engineering and the resulting
clone market.

~~~
recoiledsnake
Nicely put. Also, another huge factor in the standardized open PC was
Microsoft licensing DOS to Compaq. That triggered the PC clones and the PC
revolution which Linus leveraged with Linux and then Apple a decade and half
later.

------
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?

~~~
zokier
Without Secure Boot systems, even with full disk encryption, would be
vulnerable to repeated evil maid attacks.

>If anything they're easier to detect (just read the boot sectors on the drive
and compare vs. a small list of known bootloaders)

That is what Secure Boot essentially does.

edit: to expand: Boot sector malware is easy to detect from outside the
system, but you need actively to be looking for it. How many users regularly
check their bootsectors with an external OS?

~~~
ajross
So your counterexample is that secure boot can protect against hard drive
encryption breaks. I guess that's fair. But it's not perfect protection (a
compromised kernel will give up the keys too). Honestly, given the frequency
with which we see kernel exploits in the wild I'd say it's at best
incrementally better protection. It's also a hypothetical: are there active
evil maid attacks in the wild?

And, of course, my point was that secure boot comes with very non-trivial
costs (to freedom of use, primarily). I don't think it's worth it, and your
example hasn't convinced me.

And I don't understand the edit. Of course no one checks their bootsectors,
just as no one checks hashes of their system files. There's a whole industry
of (vaguely useful) software to do this for them. How does a potential new
vector change the concept of AV software?

~~~
maxerickson
It's only a hypothetical that secure boot is going to have any impact at all
on the freedom to use x86 hardware.

~~~
pyre
It's also only a hypothetical that implementing an "Internet killswitch" or
government-mandated ISP website blocking ("for the children" of course) will
impact our freedom.

The idea is that with the infrastructure in place, we're ever closer to being
impacted.

~~~
maxerickson
Sure. I was riffing on the other poster calling the malware prevented by a
secure boot scheme a hypothetical.

It's certainly a hairy issue. The ability to run a verified software stack is
a real benefit to users. Central control of that verification is bad for
users, but a shadow of that central control is the obvious way to make it easy
for users that don't know they should care.

~~~
ajross
In context, I called it a hypothetical because I'd asked for specific examples
of boot-time malware that justify the rush to secure boot. This wasn't one.

~~~
maxerickson
My point is that you are anticipating problems with secure boot (there is no
evidence that it will worsen the situation on general purpose hardware; there
are certainly reasons to believe it might) and then dismissing some of the
justification because it merely anticipates an attack.

------
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...](http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-
releases-security-advisory-2718704.aspx)

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.

~~~
rbanffy
With the correct signing keys, you could make every UEFI secure-boot-enabled
machine in the world seamlessly run whatever you want them to. You could
infect them with undetectable malware.

Now, imagine every computer on every office vulnerable to your malware because
you have the signing keys used by Microsoft.

How much computing power would you dedicate to get that keys? How much money
would you spend? A billion? Ten? That's the price of a single fully-loaded
bomber these days. How can you be absolutely sure the keys are kept secure
enough from someone willing to spend a fraction of their military budget to
get what could amount to be the ultimate cyberweapon?

~~~
recoiledsnake
>With the correct signing keys, you could make every UEFI secure-boot-enabled
machine in the world seamlessly run whatever you want them to. You could
infect them with undetectable malware. >Now, imagine every computer on every
office vulnerable to your malware because you have the signing keys used by
Microsoft.

Even if that doomsday scenario comes into play, things would just go back
to... the present.. where there is no locked bootloader.

So I really fail to understand your hype.

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

~~~
ekianjo
Well there will be some incentives for the manufacturers who do NOT support
SecureBoot: they will get a better share on the market than their current one.

~~~
rbanffy
Sadly, that isn't enough. For everyone who understands how UEFI limits their
freedoms, there is a dozen people who will say "look! shiny!".

Idiots will always outnumber smart people. Microsoft relies on that.

~~~
ekianjo
Well the 4% share (or more) of future linux users who need a reliable Linux-PC
is not so small if you consider the potential number of clients.

Surely some will take advantage of this situation, if everyone else rushes to
have SecureBoot.

------
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...](http://msdn.microsoft.com/en-
us/library/windows/hardware/jj128256)

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>

