[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: Pierre THIERRY
Subject: Re: Potential use case for opaque space bank: domain factored network stack
Date: Sun, 7 Jan 2007 17:27:25 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Scribit Marcus Brinkmann dies 07/01/2007 hora 05:10:
> You mean hypothetically?  That is easier answered when looking at a
> specific proposal.  The canonical example for opaque storage used to
> be the construction of (possibly confined) isolated program instances.
> In that case the harm is that I am using software which I can not
> inspect or modify, thus I am making myself dependend on proprietary
> technology.

But you don't need opaque memory to implement proprietary software on
the new Hurd: just implement a classical server as it is done nowadays,
in it's own address space and without use of shared memory for parts of
the work that reveal the secret you want to keep.

The clients will use the server as a service they have no authority to
debug or monitor. The people using it would be as dependent as if the
service was provided as a program they spawn in memory opaque for

This kind of service will just be unable to take full advantage of the
architecture of the Hurd, but that's no big deal for them.

And the fact that program instances be spawned in opaque memory for the
spawner is only the result of the good (or bad) will of the machine
owner. Nothing prevents the machine owner to let users spawn program
instances designed to use opaque memory in totally transparent memory,
making them debuggable and modifiable...

That's why I cannot see how opaque memory, as a mechanism, can achieve a
policy that would harm the community at large. But I see how opaque
memory could, as a mechanism, make some very strong security policies b
enforcable on Hurd systems, and that would be a huge benefit for the

> I wish I had known about this one earlier: Ross Anderson seems to have
> done studies of the economics of "trusted computing".

Well, I don't know very well the internal of TC, but I ain't mistaken,
TC in itself will provide the so-called curtained memory without much
specific support of the underlying OS.

Could someone with better understanding of TC could tell if support of
opaque memory in Hurd would really change anything for implementors of a
DRM system using TC in Hurd?

> http://www.cl.cam.ac.uk/~rja14/Papers/tcpa.pdf

I'm rolling on the floor:

  ``There is also a significant risk – that if TC machines become
  pervasive, they can be used by the other side just as easily. Users
  can create ‘blacknets’ for swapping prohibited material of various
  kinds, and it will become easier to create peer-to-peer systems like
  gnutella or mojonation but which are very much more resistant to
  attack by the music industry – as only genuine clients will be able to

BTW, this is a very interesting paper indeed.

> Pierre, I have the impression you are exclusively focusing on
> mechanisms and technology.  If that is true, we will keep talking
> beside each other, because I am focusing on policies and people.

Well, that's partially the case. I misunderstood some of your claims
about policies as claims about mechanisms. But I really want to get a
clear picture of both issues.

OpenPGP 0xD9D50D8A

Attachment: signature.asc
Description: Digital signature

reply via email to

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