Re: dangers of TCPA/palladium
Mike Rosing wrote:
The difference is fundamental: I can change every bit of flash in my BIOS. I can not change *anything* in the TPM. *I* control my BIOS. IF, and only IF, I can control the TPM will I trust it to extend my trust to others. The purpose of TCPA as spec'ed is to remove my control and make the platform "trusted" to one entity. That entity has the master key to the TPM.
Now, if the spec says I can install my own key into the TPM, then yes, it is a very useful tool. It would be fantastic in all the portables that have been stolen from the FBI for example. Assuming they use a password at turn on, and the TPM is used to send data over the net, then they'd know where all their units are and know they weren't compromised (or how badly compromised anyway).
But as spec'ed, it is very seriously flawed.
Ben Laurie replied:
Although the outcome _may_ be like this, your understanding of the TPM is seriously flawed - it doesn't prevent your from running whatever you want, but what it does do is allow a remote machine to confirm what you have chosen to run.
David Wagner commented:
I don't understand your objection. It doesn't look to me like Rosing said anything incorrect. Did I miss something?
It doesn't look like he ever claimed that TCPA directly prevents one from running what you want to; rather, he claimed that its purpose (or effect) is to reduce his control, to the benefit of others. His claims appear to be accurate, according to the best information I've seen.
I don't believe that is an accurate paraphrase of what Mike Rosing said. He said the purpose (not effect) was to remove (not reduce) his control, and make the platform trusted to one entity (not "for the benefit of others"). Unless you want to defend the notion that the purpose of TCPA is to *remove* user control of his machine, and make it trusted to only *one other entity* (rather than a general capability for remote trust), then I think you should accept that what he said was wrong. And Mike said more than this. He said that if he could install his own key into the TPM that would make it a very useful tool. This is wrong; it would completely undermine the trust guarantees of TCPA, make it impossible for remote observers to draw any useful conclusions about the state of the system, and render the whole thing useless. He also talked about how this could be used to make systems "phone home" at boot time. But TCPA has nothing to do with any such functionality as this. In contrast, Ben Laurie's characterization of TCPA is 100% factual and accurate. Do you at least agree with that much, even if you disagree with my criticism of Mike Rosing's comments?
On Mon, 12 Aug 2002, AARG! Anonymous wrote:
I don't believe that is an accurate paraphrase of what Mike Rosing said. He said the purpose (not effect) was to remove (not reduce) his control, and make the platform trusted to one entity (not "for the benefit of others"). Unless you want to defend the notion that the purpose of TCPA is to *remove* user control of his machine, and make it trusted to only *one other entity* (rather than a general capability for remote trust), then I think you should accept that what he said was wrong.
That does seem to be the purpose - but may not be what was planned - it could simply be a "fortuitous accident". There are way too many unknowns really, so conjecture is all we've got to go on. So far we know that the guys writing Palldium are not happy with TCPA - it doesn't solve their problems the way they like. We know less about the TPM. What's "right" or "wrong" about vaporware is kind of hard to pin down. There are some basic conceptual things we do know, and we know there are already commercial solutions to problems that TCPA claims to attempt to solve. I'm working from what I know about those existing devices and project that onto TCPA. I may well be wrong, and hopefully somebody who's actually building TCPA and TPM can give us concrete answers.
And Mike said more than this. He said that if he could install his own key into the TPM that would make it a very useful tool. This is wrong; it would completely undermine the trust guarantees of TCPA, make it impossible for remote observers to draw any useful conclusions about the state of the system, and render the whole thing useless. He also talked about how this could be used to make systems "phone home" at boot time. But TCPA has nothing to do with any such functionality as this.
I have to disagree. If I control the content of the TPM, *I* can trust it, and anybody who trusts *me* can trust it too. What other remote observers of my system are there than the ones *I* trust? Or to put in another way - I only want remote observers that I trust to have the ability to check my TPM. This is what it all boils down to - "who is in charge of what?" If I create a fixed key, I can authenticate myself via multiple channels and build trust to multiple and independent parties. That is how TPM becomes useful. If somebody else controls the TPM, they may well *not* trust me, and they may put my computer to work doing something I don't like. In that case, I can not trust my computer, because my computer does not trust me. (I said may, just because it's possible doesn't mean it will happen.) What started this very long and interesting discussion was the fear that TCPA is going to be mandated by law. That is a very bad idea, and as long as the fear is real, we need some very good arguments to prevent it from happening. The main one is economic, the secondary one is that we don't need it - you can buy hardware that does the same thing off the shelf and plug it in to any generic PC. If the authors of Palladium want their software to work, they should look at the commercial hardware security computing platforms already available and get their stuff to work with it. Ditch TCPA and get your stuff on the market now, and see how people really deal with it. It will be an interesting experiment. Patience, persistence, truth, Dr. mike
participants (2)
-
AARG! Anonymous -
Mike Rosing