Overcoming the potential downside of TCPA

Thu Aug 15 16:41:58 EDT 2002

hum, i guess i somewhat view the situation somewhat in flux ... maybe
analogous to the period when there was a claim that only auto mechanics
should be allowed to drive automobiles .... and only automobiles that
required mechanics to drive them should allowed to be built. The situation
today is that while anybody could build their own automobile from scratch,
few actually do.

as to putting together reliable configurations ... i've had a little
experience ... possible you've heard of some of it.

there was this little client/server startup in the valley that was
interested in implementing  server transactions ... with this emerging
technology that required some amount of vetting and maturing. during the
year that my wife and i worked with them on the implementation and
deployment they moved from menlo park to mountain view and changed their
name from mosaic to netscape .... the emerging technology is sometimes
referred to as SSL or HTTPS and the transactions they wanted to do are
sometimes now referred to as electronic commerce. Possibly you have heard
of some of this? Does Netscape, SSL, HTTPS, or electronic commerce ring any
bells?

some past integrity and security suggestions:
http://www.garlic.com/~lynn/2001j.html#5  E-commerce security
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean
Anything

no matter how much I wanted the industry to not allow operation of systems
that didn't meet certain criteria, I wasn't succesful.

thread somewhat analogous to this one:
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

slightly related mumblings on security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional to Risc

rant about maybe in a couple thousands years security engineering will
reach the maturity level of civil engineering for bridge building
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several
common SSL implementations?

How many people participate in the creation of the bridges and roads that
you drive on ... so that you could examine the safety of the road bed
before it is paved over?

bear at sonic.net on 8/14/2002 9:54 pm wrote:

... wide ... open ...  <<boggle...>>  Do you even know what Kerchoff's
Principle IS?!  Look, I've been trying to hold back on actual ranting,
but... but...  you really don't get it, do you?

<rant mode ON -- sorry guys....>

On the contrary, 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, which I obtained from sources trusted to
me and which do not and CAN NOT require any further interaction or
authorization whatsoever to run their software.  I have selected software,
on purpose, which denies someone who is not me even the bare possibility of
restricting my ability to run it at some future time.  I have the source
code.

That is what I mean when I talk about trusted computing.  I trust that my
software does what it says it does, is completely open to inspection and
verification by first, second, and third parties, and cannot be denied to
me at any point after I have come to depend upon it, whether or not I have
a net connection at the moment to interact with its creators.  I trust that
I cannot be singled out remotely to have a sniffer installed on my local
machine through a backdoor.  I trust that code I can inspect at the level
of machine instructions is code that cannot keep secrets from me or forever
conceal malign intent.  I trust that I cannot be forced to depend on any
single commercial software provider, whether it be for the OS or for the
"trusted" compiler which can, of course, come from only one source.  I
trust that coercive "upgrades" done for the sake of incompatibility with
existing code,  do not and cannot happen automatically given my system
configuration.

That is trusted computing sir, and TCPA/Palladium is a huge step *backward*
from it.  Anything that runs *ANY* code that cannot be inspected, or which
keeps data that cannot be inspected, is running code that cannot be
trusted.

TCPA/Palladium does not provide trusted computing.  At least not computing
that I can trust in the way I trust what I've got now. In fact, from my
POV, TCPA/Palladium look like ways to enable the running of software which
I *CANNOT* trust. Imagine my excitement at the prospect.

This is a cryptography mailing list.  Do we even want to count the number
of times commercial software providers have come up with some crap and
claimed it was secure, and been just lying to us?  Do I have to recount all
the proprietary, snake-oil encryption systems that relied for its security
on not being inspected?  Do I have to recount the number of ways that
unstudied security designers have given us their best efforts and had them
shot down by professionals in seconds?  Do we have to speculate about what
can happen if the clowns who employ them think they'll never be caught?!
We've all been around the block enough to know this by now:

Kerchoff was absolutely right.  A hundred and twenty years since he
elucidated the Principle has not changed a thing.

NOBODY has the manpower or time to find all their bugs in-house.

If you can't inspect the machine code (and preferably the source) then you
are looking at something that is not and can never be made secure.

Now, you're talking about a system that gives people the opportunity to
HIDE THE CODE, and telling us that's security?!  What the hell are you
smoking?! You are confusing real security mistakes with the ability to
DETECT real security mistakes!

                                                 Bear

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