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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 14 Jan 2007 06:07:27 -0800

Quite, I think that the big problem with the 'TPM can't possibly work' claim is that TPM is like cryptography, there are so many applications that the claim is essentially meaningless. 

Clearly if everyone in the system conspires to defeat the TPM it is not going to provide any security. But that is not a rational threat model.

The other problem I have with the 'TPM can't work claim' is that it tends to be followed by warnings of dire consequences resulting from it working too well for some people's taste.

> -----Original Message-----
> From: Steven M. Bellovin [mailto:[email-masked]] 
> Sent: Saturday, January 13, 2007 12:25 PM
> To: Hal Finney
> Cc: [email-masked]
> Subject: Re: [Cfrg] Re: how to guard against VM rollbacks
> 
> On Sat, 13 Jan 2007 09:12:23 -0800
> "Hal Finney" <[email-masked]> wrote:
> 
> > On 1/13/07, Simon Josefsson <[email-masked]> wrote:
> > > 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.
> > 
> > TPM chips contain certified keys, which virtualized ones 
> will not, so 
> > software can tell the difference. It knows the CA which 
> certifies TPM 
> > keys and checks that the TPM contains such a key.
> > 
> > In principle the virtualizing engine can reverse engineer the 
> > software, find where it stores the root TPM CA, and change it, or 
> > perhaps crack it in other ways. In practice that can only 
> be done with 
> > considerable human effort customized to the particular software 
> > package you are trying to fool.
> > 
> > Xen is an example of a VMM which virtualizes the TPM, and it (of
> > course) makes no effort to carry the charade so far. Instead, the 
> > proposals I have seen would use a second level key structure for 
> > certifying virtualized TPMs, signed by the real TPM key, 
> similar to CA 
> > certificate chains. Software will have to be VM-aware to 
> recognize and 
> > authenticate virtualized TPMs.
> > 
> > The main issue then is whether the VM software will even give you 
> > access to the real TPM, or only provide a virtual one. It 
> can't fool 
> > you into thinking the virtual TPM is real, but OTOH you lose the 
> > advantages of a real TPM for the purposes described in this 
> thread. At 
> > least you would know you were being virtualized, but you would no 
> > longer have any guarantee that random numbers from the VTPM were 
> > fresh, for example, or that the monotonic counter wasn't going 
> > backwards.
> > 
> What is the threat model here?  Who is rolling back VMs and why?  
> 
> If the enemy can induce VM crashes, necessitating a rollback, 
> that's the real problem.  If the base system operator is 
> trying to subvert the VMs, that's the problem.  I suggest 
> that the latter is unlikely.  A virtual TPM (or virtual 
> crypto hardware of any other type) becomes a distinct 
> advantage in these cases, because it moves the 
> crypto-sensitive items -- the keys, the pseudo-random number 
> state, etc. -- out of the area that's being rolled back.  If 
> the purpose of your VMs is to provide extra protection for 
> some servers, a modest degree of VM-awareness is a fine thing 
> -- let the VM and the hypervisor co-operate.  Xen got that 
> very right.  (The usual reason for malware to do VM detection 
> is to prevent the good guys from using VMs to analyze the 
> malware.  If I run my servers in a VM and the malware 
> refrains from misbehaving because it thinks I'm watching, I 
> win that way, too...)
> 
> 		--Steve Bellovin, http://www.cs.columbia.edu/~smb
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg
> 

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 17 Jan 2007 10:13:25 -0800

On Jan 14, 2007, at 6:07 AM, Hallam-Baker, Phillip wrote:

> Quite, I think that the big problem with the 'TPM can't possibly  
> work' claim is that TPM is like cryptography, there are so many  
> applications that the claim is essentially meaningless.

This is off-topic for the list and even this particular thread, but I  
can't resist commenting that if the TPM is supposed to protect the  
data from the user who controls the computer, then it is very much  
unlike cryptographic security.

Mark
>
> Clearly if everyone in the system conspires to defeat the TPM it is  
> not going to provide any security. But that is not a rational  
> threat model.
>
> The other problem I have with the 'TPM can't work claim' is that it  
> tends to be followed by warnings of dire consequences resulting  
> from it working too well for some people's taste.
>
>
>