Slow attestations don't work very well
Ed Felten pointed out something that I had been worrying about in the back of my mind: my "slow attestations" scheme (see my suggestion, discussion on the Cryptography list, Unlimited Freedom's critique, and the EFF comments on the TCG Principles, where slow attestations are discussed in section 6.4) has a serious flaw. The trouble is severe enough that slow attestations probably won't accomplish what I wanted them to.
Felten observes that sealed storage can be used as a sort of proxy for attestation. (I discuss that in section 6.1 of the EFF comments mentioned above.) That is, a given entity can use sealed storage as a way to verify that the state of a machine is the same at some future time as it is at the present. It does this by generating a secret, somehow ascertaining the present state of the machine, and asking the machine to seal the secret. Later, the entity can challenge the machine by asking it to hash the relevant secret with a nonce; if the machine responds correctly, then, assuming sealed storage is secure and works as designed, the machine's state must be the same as it was when the secret was sealed. There are some fine details here, but in theory this should work.
Felten observes that this way of using sealed storage undermines the effectiveness of slow attestations, because slow attestations were meant to make it expensive to ascertain the state of a machine every time anyone tries to do so. However, sealed storage would allow somebody to use attestation (including slow attestation) just once to verify a machine's state, and then issue it a key, token, or even a cryptographic certificate that serves to prove that state as rapidly as desired any time in the future. That makes the expense of verifying a slow attestation an expense that only has to be incurred once per machine (perhaps more precisely, once per machine/OS configuration/application combination, as Felten notes), and only has to be incurred by a single party, since that party can then act as a certifier, if other parties trust it.
I haven't been able to come up with a countermeasure that would restore the benefit of slow attestations. It would, of course, be possible to tinker with sealed storage as well as attestation, but I'm afraid that sort of speculation leads to chaos as well as an arguments that it would significantly increase the cost of implementing the TPM specification.
