Subject: [Cfrg] RE: how to guard against VM rollbacks

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 14 Jan 2007 05:30:13 -0800

> From: Simon Josefsson [mailto:[email-masked]] 

> Aren't you forgetting that a virtual TPM, that can be rolled 
> back, is within the powers of a VM?  You can't tell a virtual 
> TPM from a real one, if the VM is good.

Not at all, a virtual TPM under the control that allows it to be rolled back or otherwise behave in ways that violate the trust claims could not be certified as such by a Trusted Third Party.

Such a machine would be consistent internally but could not make a trustworthy external claim - to another network party or to a user.

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Jan 2007 20:41:34 +0100

"Hallam-Baker, Phillip" <[email-masked]> writes:

> Not at all, a virtual TPM under the control that allows it to be
> rolled back or otherwise behave in ways that violate the trust
> claims could not be certified as such by a Trusted Third Party.
>
> Such a machine would be consistent internally but could not make a
> trustworthy external claim - to another network party or to a user.

How does a certified TPM protect against the VM (or anyone) replaying
earlier answers (i.e., counter value) from the TPM to the application?

How can an application tell whether the answer they get from the TPM
is from a certified trusted TPM, or replayed answers from the same, or
simply just faked answers?

I'm not familiar with all TPM implementations, but it seems that
unless a TPM sign the internal state and sign the data that goes out
from the TPM, and require that implementations verify the answers
against an online service (through a protected channel) to make sure
the answers are not replayed, a TPM doesn't seem to offer any major
advantage.  Still, extracting the private key inside the TPM
effectively destroys the security of the scheme, too.

/Simon

---

From: "Hal Finney" <[email-masked]>
Date: Sun, 14 Jan 2007 15:05:34 -0800

Getting back to the point raised earlier about the threat model, I
think some of this discussion is getting sidetracked into a scenario
where the VMM and the client OS are enemies each trying to defeat the
other. While this might describe certain situations, perhaps breaking
DRM or copy protection via virtualization, I don't think it should be
our primary focus here.

Rather, we should consider scenarios where the VMM and client OSs are
"on the same team" and are cooperating to achieve the user's goals.
The threat we might consider is a third party who can induce VM state
rollbacks, perhaps by crashing some other process in the VM. For
analysis, we could let the third party choose the starting and ending
points of the rollback arbitrarily: the process runs to point B, and
then is reset back to the point A, and runs again.

Ideally we would want to get notification to the crypto protocol layer
that the rollback had occured. It might not be practical to clearly
identify point B, but at least when the software resumes from point A
it could be notified that a rollback had happened and it might be
re-using state which had been used before. This would require
cooperation between the VMM and the client OS, and support for
application software to be notified from the client OS when these
events occur. I don't see any reason why we should not expect such
support to be available in a mature VM system. Given that the VMM and
client OSs are cooperating, there should be support for exactly this
kind of communication.

In general, any software which anticipates engaging in communication
in an environment where rollbacks can occur must design some kind of
resynchronization mechanism into its protocol. The crypto layer can
perhaps capitalize on this feature and perform its own state refresh
at the same time, communicating whatever data is needed to the
receiving end.

Hal Finney