[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Potential use case for opaque space bank: domain factored network st

From: Jonathan S. Shapiro
Subject: Re: Potential use case for opaque space bank: domain factored network stack
Date: Mon, 08 Jan 2007 00:27:37 -0500

On Mon, 2007-01-08 at 06:05 +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 07/01/2007 hora 23:45:
> > I, as a developer am free to say "I do not choose to let you inspect
> > my programs, but you are free not to run them at all."
> I don't understand this part: how can the developer enforce this? Isn't
> the machine owner the only one able to enforce this policy?

Only in the sense that the machine owner can elect not to install EROS.
Once EROS is installed on a TPM-enabled machine, it is possible to
distribute programs in such a way that the user will *never* be able to
inspect the bits in the clear. Difficult, but possible.

The case I was referring to above is more local. I was trying to say
that when the constructor builds a new program, the client normally gets
an *entry* capability to that program, which does not permit debugging.
The usual protocol is to ask for a debugging capability as a very early
request. The service can, of course, refuse.

Opaque installation and prevention of kernel substitution both require
TPM. Without TPM you can substitute the kernel and/or learn the
decryption keys that decrypt the distribution CD/DVD/whatever.

Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100

reply via email to

[Prev in Thread] Current Thread [Next in Thread]