get a grip on what TCPA is for

[Derek Atkins]

"John S. Denker" <jsd at monmouth.com> writes:

> 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).

Note that this is not the only interesting question
to be solved.  It is one question, certainly the major
question that Da Mouse wants to be answered, but far
from the only one.

> 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.

Ok, I qualify here as "stepping in those moccasins", so let me
continue my analysis.

> 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.

True, however I have yet to believe that this is a credible
threat.  Perhaps I am naive, but I do believe that a majority
of people are honest, and honest people are going to do the
honest thing.  Do I listen to digital music?  Sure, but I
still go out and buy the CD.

> 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.

Um, this is NOT the same problem.  In fact, this is completely
different.  Yes, you still need the TPM to do this, however the
requirements over the TPM are completely different.  To solve this
problem I only need a TPM where *I* can control the keys, and have it
watch over itself.  I could still run Linux or whatever OS I wanted,
because the goal here is for me to certify my own software running on
my own machine.

In fact I don't even need a TPM to detect tampering.  All I need is to
have a boot-CD with md5sum and have it burn the md5sum values of all
files onto another CDROM...  Then I can detect tampering by again
booting off the CDROM and running the tests again.

A TPM that *I* control just makes it more real-time.  You can enforce
restrictions that no changes are made to the OS.  But the manufacturer
needs no control over this.  They don't need the keys.  They don't
need certificates.

Actually, as I think about this, you can do this today with
"non-resetable" BIOS and Bootup passwords and "encrypted" disk drives
(where the disk key is also stored in the BIOS).  Someone with
physical access would need to be able to read out the BIOS settings or
obtain my BIOS passwords to do anything.  You don't need a TPM for
this, you just need resiliant BIOS nvram.  Then the machine is useless
without the passwords.

So, what does the TPM buy _ME_ when running my own machine?

> 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.

Yep!

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek at ihtfp.com             www.ihtfp.com

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