Subject: Re: [e-lang] capability myths demolished!

From: "Jonathan S. Shapiro" <shap@eros-os.org> · Date: 04 Dec 2002 11:01:08 -0500

On Tue, 2002-12-03 at 17:35, marcs wrote:
> > Your point is sound and worth making, but it has nothing to do with
> > Palladium and it will become discredited as people figure that out.
> 
> If Palladium uses code-signing as the mechanism for establishing trust and 
> allowing execution, but still lets the operating system grant gross excesses 
> of authority once this primitive test has been passed, simple programming 
> bugs in a Palladium universe will continue to present rich targets for 
> cracker exploitation. Is this true, or is my understanding of Palladium even 
> more wildly wrong than I had thought? I.e., its security stance is based on 
> code signing, right?

Yes and no, but mostly no.  You have the facts right, but your assembly
of them is potentially misleading and could lead to misunderstandings
that might damage credibility.

When people talk about "code signing", they generally mean signing of
applications.  The palladium strategy takes no position on application
signing. The objective of the Palladium hardware is to reliably load an
operating system (whether or not signed) -- what the operating system
does after that is not something that Palladium attempts (or needs, or
should want) to control. The signing function in Palladium is not
presecriptive. It does not restrict what is loaded. It allows us to
reliably (relatively reliably, anyway) ask *what* was loaded. Subsequent
decisions about trust in what was loaded are left to the parties in the
transaction. All such decisions are contingent on trust in the Palladium
key hierarchy.

With respect to OS signing, I must confess that I haven't looked at the
palladium details hard enough to give a detailed explanation.  My
impression from prior discussions here is that every Palladium chip has
a signing key unique to that chip. The signing key is in turn certified
by a certificate authority, indicating that the signing key is a valid
palladium key. The Palladium chip may generate further keys for local
use -- this part I'm uncertain about, and I'm therefore not clear on the
details of the chain of signatures. At the end of it all, however, the
net effect is that a challenge-response protocol is enabled by which a
third party can request cryptographic assurance that you are running an
acceptable operating system (i.e. acceptable to the third party), and
(subject to the limitations of the security of the Palladium keying
chain) can obtain such assurance **with your machine's consent**.
Nothing in this sequence requires (technically) that the third party
demand any particular OS, though the usual social and market forces will
tend to turn this into a market lock-in for Windows.

In your description, it appears that the primary concern is that
Palladium should somehow control the actions of the OS.  This isn't a
goal, and its absence isn't a flaw. The objective of Palladium is solely
to load an arbitrary OS reliably and tell us what OS it is. Flaws in
that OS are outside the scope of Palladium. The decision to limit the
scope of Palladium in this way was a good call -- such things are
complex enough without overburdening them.

I am, by the way, deliberately ignoring some hardware aspects of
Palladium. A few are worthwhile.  Most of them are unnecessary and
unhelpful. In practice they are unlikely to be important. This is a
primary area where the Palladium and TCPA specifications differ.

It is true that a variety of bugs (simple or complex) in the loaded
operating systems will lead to gross security problems.  Palladium does
not per se improve the security of the system and does not attempt to do
so. Rather, it allows us to detect with high confidence when we are
running a crap operating system. [Or, at the other extreme, when we are
running E on EROS :-)]

There is a reason that Microsoft isn't trying to run Windows as their
nub... 

shap 

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang