ImperialViolet

A little while back all the talk was of Palladium and how `trusted hardware' was going to bring forth an end to general purpose computing. (I'm not ridiculing that notion - it may happen, though I think it's less likely now.) I remember being in a hotel in Guildford at the time so I guess that was summer 2002.

People were horrified at this prospect and never have so many people linked to a A Right To Read in such a short span of time. But I was arguing something different at the time:

Just because TCPAv1
*may* be a stepping stone towards something bad doesn't automatically make
TCPAv1 bad. As Hal and I have pointed out, TCPAv1 has a number of interesting
uses and I, for one, will not be asking people to boycot it.

Now, I don't pretend that anyone gave two hoots about what I thought once Hal popped up. But this is a kind of "told you so" link because Hal has now gone and proven that there is a use to this stuff with RPOW.

Normally POW tokens can't be reused because that would allow them to be double-spent. But RPOW allows for a limited form of reuse: sequential reuse. This lets a POW token be used once, then exchanged for a new one, which can again be used once, then once more exchanged, etc. This approach makes POW tokens more practical for many purposes and allows the effective cost of a POW token to be raised while still allowing systems to use them effectively.

I'm not yet convinced that RPOW is actually very useful, but that isn't the point. The point is that I have a strong chain of trust that Hal's server does what he says it does. It's running on an IBM 4758 and IBM publishes the root key for that in lots of places, including every printed manual. That keys signs the onboard key of the 4758 and the 4758 signs that code that it's running. I have a decent amount of trust in IBM because they are certified by NIST and they sell lots of these to the banking sector - so they have a strong financial interest in keeping things above board.

This is a fundamentally different primitive to those which we are used to dealing with. Usually we need either reputation systems, trusted third parties or verifiable proofs of correctness (very rare). In a sense IBM here is a trusted third party but they are one level removed; we aren't trusting them to implement some protocol, but to make devices which can be configured to implement the protocol. There's a saying that every problem in computer science can be solved by implementing another layer of abstraction so we should be pretty excited about what this new layer gives us.

Of course, it's not some magic bullet. Not very many people have 4758's they aren't going to become standard anytime soon. Also, they are pretty slow. But can do a number of things which I couldn't do before:

I could implement a notary public and people would have a strong trust that it functioned correctly without knowing anything about me. I can do stuff like Hal's RPOW (or a number of financial things) and people could verify that I wasn't doing anything untoward etc. I'm sure that more ideas will pop up now that this is in our collective mental toolkit.

How this relates to TCPA:

Now, TCPA also includes remote attestation (the ability to sign the running code) but I feel that this is almost completely useless. For a start there will probably be a number of producers of TCPA chips and this dilutes the trust quite a lot already. Secondly, TCPA chips aren't going to be nearly so hard to subvert as a 4758. The 4758 isn't perfect (no tamper-resistance is), but FIPS level 4 says it's pretty good. Thirdly, it's utterly pointless for the TCPA to sign a Linux or NT kernel image; the trust flowing through either of those to a given running application (assuming that they had been modified so that they could sign the code that they were running) is tiny. At best, the application would have to implemented as a very stripped down kernel - making the box useless for anything else.

But TCPA does have sealing (the ability to encrypt data keyed by the fingerprint of the running kernel). the first two points above still apply, but what I want this for to is to storing the encryption key for the hard drive so that it cannot be removed and inspected on another computer (or booted with another kernel from a floppy etc).

So I still think that TCPA has a place … but not remote attestation.