decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Do I have to do this? | 162 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Do I have to do this?
Authored by: reiisi on Tuesday, July 09 2013 @ 09:30 PM EDT
Point by point, not taking the time to do it pretty:

First, about signed, compromised code --

If you enable a key and someone gives you compromised code signed by that key,
UEFI, by definition, can't do anything about it.

Result: Boot.

Hoping otherwise is pipe dreaming.

With that understood, you must re-read the next question.

Sure, if UEFI worked as advertised, it would provide an additional layer of
protection against various exploits digging down into your bios, etc.

It doesn't, and I've just told you one of the reasons why.

So a carefuly maintained OS booted through a UEFI-enabled BIOS does not actually
end up providing any more protection than a carefully administered running
without UEFI.

In particular, "Someone with network access" succeeding in a
man-in-the-middle attack on my machine succeeds whether I've used UEFI
code-signing or not.

If that attack drops a compromised BIOS, and the compromised BIOS is not signed
by a key I have enabled, then and only then does UEFI have a prayer of doing
something about it -- on the next boot.

Plenty of time before then next boot to carefully examine the BIOS, determine
which keys are enabled, and, if there is an enabled key that the attacker has
access to, UEFI is clueless on re-boot, too.

Keys have already been compromised. We have reports of that. We have no reason
to trust that Microsoft can keep their keys uncompromised, and the time lag from
the compromise to the report is a window open to attack, and the time lag from
getting the report to actually re-signing your BIOS with a valid key is yet
another open window.

The only way to close this window is to use only locally generated keys when
using a BIOS that checks keys and signatures. That means you have to sign the
BIOS yourself. Not Microsoft. Not Intel. Not Dell.

Not even Google.

Not even the Debian project team (or Fedora/RedHat/Ubuntu/etc.)

If a manufacturer were to do this half right, they would sign the BIOS and any
provided OS from the factory, with a published read key that would change at
least every month. You would check the signature when you opened the package and
then sign it yourself with your own key.

But you're still trusting the factory.

You can't do that if you want to be sure you know what is going on in you
machine.

(Although we can generally trust the open source project teams a bit more than
any closed corporate team.)

Physical access?

Yeah, resetting the key storage is one potential way on some Motherboards. It
isn't the only way to get around UEFI.

If you don't know how to get around UEFI when you have physical access, you
don't know something you should know about, especially if you are going to run
around promoting UEFI.

The ways exist. They depend on the mother board construction, somewhat. In some
cases (precious few) disabling UEFI non-destructively is a little beyond the
average attacker with a soldering iron. But not beyond one with a scope and
certain other tools that are not hard to get.

UEFI is simply one more speed bump. It will slow some attackers down, so it may
be useful to some people who don't have reason to believe a reasonably skilled
attacker will target them.

But a security blanket is not what people who understand the problem want.

By the way, you mention "rescue OS", I assume you mean a signed live
CD/DVD/USB/SD or whatever. The existence of such a rescue OS inherently weakens
all arguments for UEFI.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )