Re: DRM vs. Privacy

[Bas Wijnen]

On Tue, Nov 08, 2005 at 12:39:16PM -0500, Jonathan S. Shapiro wrote:
> > True.  But does such a chip solve this problem?  If we know we're running
> > on a true Hurd system, we're not anywhere near authenticating that it's a
> > real version of the game.
> 
> True, but if we know that we are *not* running an authenticating, secure OS,
> then we are already done, because we cannot *determine* whether we are
> running an authentic game.

That makes sense.

> > Sure.  What I was saying is that it's fine with me if the Hurd doesn't
> > support answering, or more specifically, if it doesn't support any
> > protocols on top which certify authentic programs.  If it's trivial to do
> > and doesn't cost anything, I don't have a problem with it.
> 
> It's pretty trivial to do from a software perspective.

But it does cost something.  If it needs to be useful, then for a start it
costs:

> The burden on the OS distributor isn't trivial, however.

Furthermore, it costs control.  That is, it creates a system where the user
may loose control to a content provider.  The user can refuse to give the
control away, but he can't get it back once he lost it.

> I'm not really advocating TPM/TCPA here.  We're going to support it at the
> Coyotos layer, mainly for experimental purposes. There is no requirement for
> Hurd to expose that functionality.

At the moment I think we shouldn't expose it.  It'll be pretty useless anyway
since we will actually encourage people to make changes to the system if they
feel they need it.

> > > > IMO this should only work as far as the user in control wishes it to
> > > > work.  The user in control is the one who created the constructor.
> > > 
> > > Then the user in control is me, personally.
> > 
> > Hehe, no you're not the one I meant. :-)  I meant the one who called the
> > meta-constructor and thereby instantiated the creation of the constructor.
> 
> I don't think you understand all of this yet. If I ask your machine "are you
> running an authentic Coyotos", then I know whether you are running the
> Coyotos TCB. If you are, then I know that you are running my (i.e.  me
> personally) implementation of the metaconstructor. If that is true, then I
> know the properties of the constructors executing on your system.
> 
> You can swap the metaconstructor if you like, and the new system may be
> perfectly good, but it will not be able to certify itself as an unmodified
> Coyotos system.

Oh, but it is.  The TCB isn't modified, I just created an object which happens
to behave like a meta-constructor (but it isn't *the* meta-constructor).

Perhaps I don't quite understand how TPM/TCPA is supposed to work, but I'd
assume that the OS gets a question from the network, it forwards that to the
chip, gets an answer, and forwards that over the network.

In that case, I can indeed run an unmodified Coyotos system and prove it.  But
I can still be using a meta-constructor which isn't what you expect, since the
trusted info ("who is the real meta-constructor?") comes from a source which
should not be trusted by the program (assuming the program is the agent of the
content provider), namely the user.

> > > This sounds like dogma. *Why* should any program be debuggable?
> > 
> > Because the user who creates the constructor for it (which once again
> > isn't always you ;-) ) _should_ be in control.  If I'm creating a
> > constructor around some downloaded binary, then I should be the one who
> > controls what happens with it.  I don't want untrusted code to be in
> > control.
> 
> But you are not the user who created the constructor.
> 
> Let's take GCC. The user who creates the GCC constructor is the author of
> GCC.

No, he isn't.  The author of gcc compiles it and creates a (on this system
non-executable) data file.  The system administrator installs this data file
on the computer.  He does that by calling the meta-constructor and passing it
the non-executable binary and possibly some capabilities.  That makes the
binary executable and in that form it's called a constructor.  The
administrator can do anything he likes at install time, including adding a
spying wrapper.

Or am I misunderstanding how the meta-constructor works?

> Are you really saying that this person should be in control?

No.

> Alternatively, are you saying that the administrator should be able to alter
> the behavior of my compiler simply by virtue of being the administrator?

Yes.  He needs this control because he is the one who installs updates to the
compiler.

> Yes, you could alter the installer to do what you say. I don't think that
> you are thinking through the consequences of such a change.

The consequences aren't as deep as you think, because you seem to
misunderstand what I'm proposing. :-)

> > > Remember that there is no notion of UID, and the program has no way to
> > > know who is debugging it.
> > 
> > It can create a capability at constructor creation time.  Whoever holds it
> > is allowed to debug it.  Obviously this will break the confinement unless
> > the process calling the constructor authorizes the capability.  But if I
> > create the constructor this way, then I know that noone else has the
> > capability, so I do authorize it.
> 
> But you are not the party who needs to authorize it. The party who needs to
> authorize it is the party *calling* the constructor (i.e. requesting the
> process instantiation).

I know, that's what I said.  The situation is that I get some code which a
content provider wants me to execute to protect his content.  I'm saying that
I can spy on that code, because I'm the one who creates the constructor for
it, *and* I'm the one calling that constructor.

> A consequence of your proposed design is that an administrator can snoop
> every password change on the system. Why should the administrator be able to
> do that?

No, that doesn't follow.  As I said, adding the debugging capability will
break confinement unless the user (the one calling the constructor) authorizes
it.  If a program which asks for a password is not confined, the user will not
use it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature