headers
Marcus Brinkmann | 1 Sep 01:24
Picon
Favicon

Re: Separate trusted computing designs

Hi,

I will make this short because you have indicated that you are not
interested in more discussions on these topics, and I don't want to
impose it, and furthermore I do not have much to add to the issues you
are interested in discussing.  I will find other, more appropriate
venues to raise my concerns to your group and the public in general in
the near future.

However, let me clarify one issue and respond to your direct questions
at least.

At Thu, 31 Aug 2006 20:06:46 +0200,
Christian Stüble <stueble <at> acm.org> wrote:
> You are not consistent here. What is the difference between "possess" 
> and "own"?

I admit I was inconsistent.  The reason is that I was confused about
the ownership and possession of the computer hardware on the one hand,
and the secret key on the TPM on the other hand.  As I do not believe
in ownership of information, the secret key on the TPM can not be
owned in my opinion.  However, if you do believe in ownership, or
proprietarization, the key can be owned, and then it is very clear
that the user does not own it (whoever it is, it is not the user).

Anyway, whatever view one holds on the issue of proprietarization of
information, it doesn't change the facts (information doesn't care
what one believes about it) and the consequences to be expected
(society doesn't care what one believes about how it is working,
either).  Foregoing the ownership discussion actually makes my
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jonathan S. Shapiro | 1 Sep 04:41
Favicon
Gravatar

Re: Separate trusted computing designs

On Fri, 2006-09-01 at 01:24 +0200, Marcus Brinkmann wrote:
> I have a definition, but I do not know if you will find it useful.
> It's the best I can come up with, and it works surprisingly well in
> practice.  Here it comes:
> 
>  A free choice is one that can be made independent of any other
>  choices.

It seems to me that what you are describing is an *independent* choice.
A free choice is one that is made without coercion. A choice between two
discrete options, each having costs and benefits, remains a free choice.

Your concept is fine. It's the label that doesn't seem quite right to
me.

shap
Permalink | Reply | 4 comments |
headers
Christian Stüble | 1 Sep 10:09
Picon
Favicon

Re: Retracting the term ownership (was: Re: Separate trusted computing designs)

Am Freitag, 1. September 2006 00:36 schrieb Marcus Brinkmann:
> At Thu, 31 Aug 2006 14:38:34 -0400,
>
> "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote:
> > I do not believe that the same is true for TPM. The problem with TPM is
> > that the one widely publicized application is DRM. In discussions on
> > this list, we have identified a number of scenarios where TPM protects
> > the interests of the *customer*. TPM per se is merely a mechanism for
> > mechanically embedding certain contract terms. Some of those contracts
> > are socially bad, some are socially neutral, and some are socially
> > positive.
>
> That's the real question, isn't it?  The TPM supporters are
> cherry-picking the use cases and evaluating the scenarios mostly under
> the aspects of protection, and a narrow set of other interests.  So
> are doing some of the critics, I should add.  That's why I am
> targeting at a level of analysis that transcends the individual use
> cases.  A complete evaluation of the expected net effect on society is
> desperately lacking, but the threats are numerous and have been
> expressed by many parties.  To downplay this to the DRM example is an
> understatement of the criticism that exists.
The interesting question for me is whether the negative scenarios coming
with this technologie are caused by a bad design of the technology, or whether 
these bad examples are a logical consequence of a design that
allows the "good" ones (independent of the fact that we have different 
understandings what the "good" and "bad" examples are). 

>
> > There does not appear to be any technical means for differentiating
> > among these.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Christian Stüble | 1 Sep 10:48
Picon
Favicon

Re: Separate trusted computing designs

Am Freitag, 1. September 2006 00:49 schrieben Sie:
> At Thu, 31 Aug 2006 18:37:40 +0200,
>
> Christian Stüble <stueble <at> acm.org> wrote:
> > Am Donnerstag, 31. August 2006 16:31 schrieb Marcus Brinkmann:
> > > I realize that there is a practical difference, but the difference is
> > > only that the party which potentially is in control of the key is a
> > > separate party from the one using it.  This means that you now have
> > > two parties to worry about instead of one.
> >
> > Here we have to exactly define the meaning of "control". In the context
> > of TCG, there are a lot of misunderstandings becuase of this.
> >
> > If "in control of the key" means to control who is allowed to use the
> > keys, then the answer is the TPM owner and thus my at my laptop.
> >
> > If "in control of the key" means (according to your ownership definition)
> > access to every bit, the answer is nobody.
>
> Which poses serious questions about liability.
>
> > According to the basic TPM spec,
> > only the TPM itself has access to the key bits. Not the user, not the
> > owner, and not the TPM vendor. Maintenance and CMK makes this a little
> > bit more complicated, but basically the answer is the same.
>
> But you don't know that the vendor does not keep a copy, you only have
> their word for it.
First, this problem is solved by the assumption that you trust the
TPM vendor (and maybe the evaluators). If you trust the remote party
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Stüble | 1 Sep 11:02
Picon
Favicon

Re: Separate trusted computing designs

Am Freitag, 1. September 2006 01:24 schrieben Sie:
> Hi,
>
> I will make this short because you have indicated that you are not
> interested in more discussions on these topics, and I don't want to
> impose it, and furthermore I do not have much to add to the issues you
> are interested in discussing.  I will find other, more appropriate
> venues to raise my concerns to your group and the public in general in
> the near future.
This is your interpretation, but not what I have written. First, I said that I 
am interested in this discussion, but that I cannot spend too much time on
it. Second, I said that I would like to focus the discussion on this list to
hurd-related discussions and to continue the more general discussions at 
another place. Third, I said that I am interested in criticism, questions, 
and suggestions regarding our projects, but that I do not want to continue 
the discussion here (i) because of lack of time, and (ii) because I neither 
represent the project(s) not our group here officially. I do not want to mix 
up my personal opinion regarding TPM and related topics, and statements
about our group and/or projects. I would expected that you can understand 
this.

Regards,
Chris

>
> However, let me clarify one issue and respond to your direct questions
> at least.
>
> At Thu, 31 Aug 2006 20:06:46 +0200,
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Stüble | 1 Sep 11:28
Picon
Favicon

Re: Separate trusted computing designs

Am Freitag, 1. September 2006 04:41 schrieb Jonathan S. Shapiro:
> On Fri, 2006-09-01 at 01:24 +0200, Marcus Brinkmann wrote:
> > I have a definition, but I do not know if you will find it useful.
> > It's the best I can come up with, and it works surprisingly well in
> > practice.  Here it comes:
> >
> >  A free choice is one that can be made independent of any other
> >  choices.
>
> It seems to me that what you are describing is an *independent* choice.
> A free choice is one that is made without coercion. A choice between two
> discrete options, each having costs and benefits, remains a free choice.
That's the reason I asked. What is the definition of coercion then? The 
decision to use Linux and accept that I cannot use word any more in imo a 
free choice, but many people will say that for them this is not a free 
choice. 

Basically, users have a free choice to disable their TPM. If the OS does not 
work with a disabled TPM, it remains a free choice. But the costs and 
benefits are not as equal as before...

Regards,
Chris 
>
> Your concept is fine. It's the label that doesn't seem quite right to
> me.
>
> shap
Permalink | Reply | 3 comments |
headers
Tom Bachmann | 1 Sep 11:42
Picon
Gravatar

Re: Retracting the term ownership


Christian Stüble wrote:
> The interesting question for me is whether [a)] the negative scenarios coming
> with this technologie are caused by a bad design of the technology, or whether 
> [b)] these bad examples are a logical consequence of a design that
> allows the "good" ones [...]

Can you show me _one_ technology that inherently only allows negative
scenarios? I cannot. I suspect such thing as inherent good or inherent
bad do not exist.
Therefore, *my* answer to your question is b).
But it immediately follows from my argumentation above that I cannot
agree with you about the interestingness of the question. The mere
existance of good scenarios does not justify the use of a technology,
especially not if we can see _very_ bad scenarios and, and this is
special about TC/DRM, this technology will be used by nearly everyone.
--
-ness-
Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 1 Sep 11:54
Picon
Favicon

Re: Separate trusted computing designs

At Fri, 1 Sep 2006 11:02:44 +0200,
Christian Stüble <stueble <at> acm.org> wrote:
> 
> Am Freitag, 1. September 2006 01:24 schrieben Sie:
> > Hi,
> >
> > I will make this short because you have indicated that you are not
> > interested in more discussions on these topics, and I don't want to
> > impose it, and furthermore I do not have much to add to the issues you
> > are interested in discussing.  I will find other, more appropriate
> > venues to raise my concerns to your group and the public in general in
> > the near future.
> This is your interpretation, but not what I have written. First, I said that I 
> am interested in this discussion, but that I cannot spend too much time on
> it. Second, I said that I would like to focus the discussion on this list to
> hurd-related discussions and to continue the more general discussions at 
> another place. Third, I said that I am interested in criticism, questions, 
> and suggestions regarding our projects, but that I do not want to continue 
> the discussion here (i) because of lack of time, and (ii) because I neither 
> represent the project(s) not our group here officially. I do not want to mix 
> up my personal opinion regarding TPM and related topics, and statements
> about our group and/or projects. I would expected that you can understand 
> this.

Yes, thanks for clarifying this.

Marcus
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 1 Sep 11:52
Picon
Favicon

Re: Separate trusted computing designs

At Fri, 1 Sep 2006 10:48:44 +0200,
Christian Stüble <stueble <at> acm.org> wrote:
> >
> > I think I am talking about the privacy agent use case.
> But then the problem is different. Lets say your privacy agent calculates
> a result y := f( p, s ) on your secret input p and the servie provider's 
> secret input s. If both parties do not trust each other, they need a TTP
> to calculate the result. This is expensive and inefficient. Alternatively,
> they can use a TTP within their system, with all the consequences discusses
> above.
> 
> Using a dedicated machine does not solve the problem. It remains the question
> who should control that machine, and whether it has installed an appropriate
> OS. 

I am not sure I understood your scenario correctly.  But it is my
impression that if I only have to remote attest my own operating
system software on a real machine, I can use a secret key on the TPM
that is known by me and certified by me.

To the contrary, if I need an attestation for the service providers
operating system and virtual machine, a vendor-certified TPM secret
key needs to be used that is not known to either party.

I think that is a substantial theoretical and practical difference.
For me the test is always: "Can I have the secret key?"

> > > > Now, let's say your operation is not that critical, and you are
> > > > running your service on a colocated machine together with 10 other
> > > > customers.  Now, a bug or missing feature is detected in the operating
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 1 Sep 12:02
Picon
Favicon

Re: Retracting the term ownership (was: Re: Separate trusted computing designs)

At Fri, 1 Sep 2006 10:09:49 +0200,
Christian Stüble <stueble <at> acm.org> wrote:
> 
> Am Freitag, 1. September 2006 00:36 schrieb Marcus Brinkmann:
> > At Thu, 31 Aug 2006 14:38:34 -0400,
> >
> > "Jonathan S. Shapiro" <shap <at> eros-os.org> wrote:
> > > I do not believe that the same is true for TPM. The problem with TPM is
> > > that the one widely publicized application is DRM. In discussions on
> > > this list, we have identified a number of scenarios where TPM protects
> > > the interests of the *customer*. TPM per se is merely a mechanism for
> > > mechanically embedding certain contract terms. Some of those contracts
> > > are socially bad, some are socially neutral, and some are socially
> > > positive.
> >
> > That's the real question, isn't it?  The TPM supporters are
> > cherry-picking the use cases and evaluating the scenarios mostly under
> > the aspects of protection, and a narrow set of other interests.  So
> > are doing some of the critics, I should add.  That's why I am
> > targeting at a level of analysis that transcends the individual use
> > cases.  A complete evaluation of the expected net effect on society is
> > desperately lacking, but the threats are numerous and have been
> > expressed by many parties.  To downplay this to the DRM example is an
> > understatement of the criticism that exists.
> The interesting question for me is whether the negative scenarios coming
> with this technologie are caused by a bad design of the technology, or whether 
> these bad examples are a logical consequence of a design that
> allows the "good" ones (independent of the fact that we have different 
> understandings what the "good" and "bad" examples are).
(Continue reading)

Permalink | Reply | 3 comments |

Gmane