get a grip on what TCPA is for

[John S. Denker]

bear wrote:
> 
> ... I have one box with all the protection I want:
> it's never connected to the net at all.  I have another box
> with all the protection that I consider practical for email
> and web use.  Both run only and exactly the software I have
> put on them,
.... 
> That is trusted computing sir, and TCPA/Palladium is a huge
> step *backward* from it.  

Brother Bear belabors one obvious point while missing a
more-important obvious point.  What some people want
is not what other people want.

The TCPA/Pd designers don't much care whether the
person who has custody of the machine trusts it.  They've
been shipping untrustworthy software for years.  The
thing they care about, probably the only thing they deeply 
care about, is whether _they_ can trust the machine while 
it is in _somebody else's_ custody.

To a first approximation, TCPA/Pd is for !!their!! direct
benefit, not for yours.  But to a second approximation, 
they are not entirely wrong when they say consumers will 
benefit, because there are indirect benefits of having 
some sort of system whereby authors, performers, and
inventors get paid for their work.  Things that are
simply not available now would become available if there
were a way people could get paid for creating them.

You can wish for some Land of Cockaigne where you get 
paid but nobody has to do any paying, but that's a 
long way from reality.

==================

Most of us know how to secure a machine that is disconnected
from the net.  We can probably even combine some limited 
networked functionality with some degree of security -- 
!!provided!! we retain physical custody of the machine.

But how to trust a machine when you don't have physical
custody?  Even the most-skilled members of this list 
would find that a challenge (depending, as I have emphasized 
before, on what your threat model is).

I guarantee you will not understand TCPA/Pd unless you
walk a while in the proponents' moccasins.  If you can't 
stand the smell of those moccasins, OK, but prepare 
yourself for perpetual ignorance and irrelevance.

For example: Imagine you are the owner of a valuable copyright
and you want to protect it.  You want consumers to be able 
to use your work in some ways, but you want to prevent rampant
infringement.  What will you do???  It's not an easy problem.

If your powers of imagination are not up to the task in the
previous paragraph, here's an alternative:  Suppose you want
to spend a few weeks visiting Outer Zambonia, but you want to 
communicate securely with your colleagues back home during this
time.  Alas, the Zambonian Ministry of Friendship has been
looking forward to this as an opportunity to trojanize your
laptop.  You simply don't have the resources to guard your
laptop 24 hours a day.  You can't travel with a GSA-approved
safe in your carry-on.  You can't take your laptop with you
when you go swimming.  The idea of hardware with !!some!!
degree of tamper-resistance might eventually start to appeal
to you.

Of course, our task of understanding what TCPA/Pd is trying
to do is made more difficult when proponents lie about what
they are trying to do.

===================

The most interesting technical point AFAICT is figuring out
how to _vet_ a piece of tamper-resistant hardware.  Presumably
you want it to detect the early stages of tampering and
react by expunging all its private keys.  Alas essentially
identical behavior could be used to cover the tracks of
built-in trojan beasties.

Here are some partially-baked thoughts:
  1) You have to allow it to expunge things.  That's the
only way it can really protect your secrets.
  2) So allow that.  It should be possible to verify that
the box is in a tabula-rasa state -- if the trojan is gone,
it's gone, and if it's not gone, it should be detectable
if you probe hard enough.  We require the hardware to allow
certain types of probing.  
  3) After you're satisfied that the hardware is not infested, 
load the software, and the keys, from a trusted source.  Replace
the tamper-evident seals and latches.

This isn't a complete design, but you can where it's going:
It should be possible to design hardware with some degree 
of tamper-resistance !!without!! creating a monopoly as to
who decides who trusts whom.

Alas it is also possible to design the hardware so that it
becomes a monopoly-enhancer of Orwellian proportions.  We
need to be vigilant to prevent this.  This will require
nuanced, non-extremist thinking.  Those who exhibit the
knee-jerk response that "all tamper-resistant hardware is
bad" will be ignored.  Such hardware, like most things,
can be used for good or ill, depending on details.

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