"John S. Denker" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] www.ihtfp.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]