Challenge to David Wagner on TCPA

Wall, Kevin Kevin.Wall at qwest.com
Fri Aug 2 01:10:15 EDT 2002


First off, let me say that in general, I am against almost everything that
the DCMA stands for and am no fan of DRM either. But I do think that
we will lose credibility if we can't substantiate our claims, and part
of that means recognizing and acknowledging what appears to be legitimate
claims from the TCPA side.

Having said that, let me plunge right in and proceed to mark a complete
fool of myself. Besides, so what if another hundred spambots harvest
my e-mail address for breast enlargement ads (stupid spambots--think
they could at least use my name to determine my sex and send me the
herbal Viagra ads instead. ;-)

Note that I'm interpreting Jay's reiterated question of
"Claimed advantage to me here?" in the more general sense of
advantage to anyone rather than to Jay personally. Not knowing
him, the latter would be a rather difficult assessment to make.

So, on with it already. Open mouth, insert foot... (yumm..
filet of sole)...

Jay Sulzberger writes...

> On Thu, 1 Aug 2002, AARG!Anonymous wrote:
> 
> > Eric Murray writes:
> > > TCPA (when it isn't turned off) WILL restrict the software that you
> > > can run.  Software that has an invalid or missing signature won't be
> > > able to access "sensitive data"[1].   Meaning that unapproved software
> > > won't work.
> > >
> > > [1] TCPAmain_20v1_1a.pdf, section 2.2
> >
> > We need to look at the text of this in more detail.  This is from
> > version 1.1b of the spec:
> >
> > : This section introduces the architectural aspects of a Trusted
> > : Platform that enable the collection and reporting of integrity
> > : metrics.
> > :
> > : Among other things, a Trusted Platform enables an entity to
> > : determine the state of the software environment in that platform
> > : and to SEAL data to a particular software environment in that
> > : platform.
> 
> 
>     Claimed advantage to me here?

If you produce copyrighted materials that you don't want others to
illegal copy, it can protect your assets. Might also be useful in
protecting state secrets, but general crypto is sufficient for
that. (Don't need it at the hardware level unless you are worried
that some TLA gov't agency is out to get you.)

The advantage depends on one whether is a producer of goods, or merely
a consumer. I shall not make a judgement call as to which is more
important. Suffice it to say that both need each other.

[more from TCPA spec]
> > :
> > : The entity deduces whether the state of the computing environment in
> > : that platform is acceptable and performs some transaction with that
> > : platform. If that transaction involves sensitive data that must be
> > : stored on the platform, the entity can ensure that that data is held
> > : in a confidential format unless the state of the computing environment
> > : in that platform is acceptable to the entity.
> 
>     Claimed advantage to me here?

One could use this to detect virus infected systems, systems infected
with root kits, etc., could they not? Also, ones alluded to above
come to mind.

> > :
> > : To enable this, a Trusted Platform provides information to enable
> > : the entity to deduce the software environment in a Trusted Platform.
> > : That information is reliably measured and reported to the entity.
> > : At the same time, a Trusted Platform provides a means to encrypt
> > : cryptographic keys and to state the software environment that must
> > : be in place before the keys can be decrypted.
> >
> > What this means is that a remote system can query the local TPM and
> > find out what software has been loaded, in order to decide whether to
> > send it some data.  It's not that unapproved software "won't work",
> > it's that the remote guy can decide whether to trust it.
> 
>     Claimed advantage to me here?

Well, here's one place that I can see a potential value to consumers.
I've thought a lot about how one can secure peer-to-peer (P2P) systems.

Sure, if I want to allow my box be a P2P host, I can use a sandboxing
technique to control and restrict (at least in theory) what rights I
give other programs to run. [I'm think of a sense similar to the Java
sandbox used for running applets.]

However, the more interesting, and I believe more challenging piece is
what guarentees can you give *ME* as a user of P2P services if I design
some important code that I wish to utilize some generic P2P service.
Unless I want to pay specific services for a P2P or grid computing from
some company that I might happen to trust, be it IBM, HP, or whomever,
I'll probably use some (future?) P2P services that are open sourced freeware
that typical home users might host out of the generosity of their hearts
(whereby they allow others to use some of their spare cycles). While this
is all well and good, my level of trust would likely not be at the same
level it would be if I paid a company to use their services. The feeling
being if I buy a service from a reputable company and they intentionally
do something malicious such as steal private data, etc. I can haul their
butts to court. No such luck when dealing with the faceless masses.
Bottom line seems to be that you get what you pay for.  In particular,
I'd be afraid that a few rogues might intentionally try to screw up
my calculations giving me bad results or run a debugger and examine my
data while it is unencrypted for some short part of the calculation,
etc.  How do I prevent that? Well, I don't think that it can necessarilly
be PREVENTED, but all I really need to do is detect it...preferably
before hand.

Thus it would seem that giving the ability of a remote system to
query a particular system's local TPM to see whether it is "trustworthy"
(by whatever criteria that *I* decide) is just what the doctor ordered
in this case.

Or am I missing something here? Without this, I don't see how I would
ever trust all the faceless masses P2P network for anything remotely
critical or sensitive to me.

> > Also, as stated earlier, data can be sealed such that it can only be
> > unsealed when the same environment is booted.  This is the part above
> > about encrypting cryptographic keys and making sure the right software
> > environment is in place when they are decrypted.
> 
>     Claimed advantage to me here?
> 

Your turn. My little fingers are getting weary. Someone else take it from
here.

> > > Ok, technically it will run but can't access the data,
> > > but that it a very fine hair to split, and depending on the nature
> > > of the data that it can't access, it may not be able to run in truth.
> > >
> > > If TCPA allows all software to run, it defeats its purpose.
> > > Therefore Wagner's statement is logically correct.
> >
> > But no, the TCPA does allow all software to run.  Just because a
> remote
> > system can decide whether to send it some data doesn't mean that
> software
> > can't run.  And just because some data may be inaccessible because it
> > was sealed when another OS was booted, also doesnt mean that software
> > can't run.
> 
>     Claimed advantage to me here?
> 

I think that we had better define our terms here. What does it mean
for a program to "run". I think most of us would hold that we mean
that it executes in a way that provides the normal and generally
expected functionality. Which would mean that if I put in my own
copy of a audio CD that I burned for a backout copy, it should play
the audio CD without any loss of quality rather than telling me that
I have a pirated copy and that it's going to report me to MPAA or RIAA.

However, I'm not going into any advantages or disadvantages.
For the most part, I agree with Ross and David not because what
they state necessarily is the intent of the TCPA or Palladium
today, but because I believe that in general both humans and
therefore human corporations are in essence greedy and seedy
(not necessarily in that order).

Of course, I have to add that I speak for myself (most of the time;
sometimes my lips just move but some other voices come out ;) rather
than for my company. Etc.

-kevin wall

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list