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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 12 Jan 2007 11:53:37 -0800

There is a difference between TPM assurances given to the application running in the VM and assurances given to a third party application or service that is running elsewhere and communicating with the TPM.

Clearly if you are setting up the VM you can start it with a blue pill. You can fudge anything you like inside the VM enviroment.

What you can't do is to provide an assurance to a party that is outside this world that has been created that you did not in fact swallow a blue pill.

The last is important since it is what allows the machine to tell either the user or the enterprise that owns it that the machine has not been compromised.

> -----Original Message-----
> From: Jon Callas [mailto:[email-masked]] 
> Sent: Friday, January 12, 2007 2:37 PM
> To: [email-masked]
> Subject: Re: [Cfrg] how to guard against VM rollbacks
> 
> Peter wrote some things that I was going to write. Long 
> before I did any crypto, I was an OS and virtualization guy. 
> The whole point of virtual system is that it looks like the real one.
> 
> Thus, in the abstract, if you can tell a virtual device from 
> a real one, then that is an imperfection in the virtual 
> system. Now, it may be an intentional imperfection. For 
> example, if I query the ATA drive on my system it may say 
> that its manufacturer is VMware, and this is a really big 
> hint that I'm on a VM.
> 
> However, let's suppose that I replace a rack of servers with 
> two physical machines all doing VMs. If SSL blows up on one 
> of my VMs because it is imperfectly virtualized, I'll go talk 
> to the VM maker and get them to make it sufficiently 
> virtualized that I can do SSL on my VM. Or I redesign my 
> system so that it doesn't need SSL.
> 
> I think we're looking at this the wrong way. This discussion 
> presumes that VM rollbacks are bad things that we must 
> prevent against. They might be, they can be. Some of them 
> will be. But many of them won't be. A cryptosystem that 
> prevents a VM from restarting simply won't be used on a VM. 
> Some other cryptosystem will be used. However, if the way 
> that it dodges the VM is merely that it relies on a TPM, then VMs
> -- both evil and good -- will virtualize the TPM.
> 
> In a truly virtualized world, it's like the notion of the 
> Earth being carried on the back of a turtle. Where does the 
> turtle stand? On another turtle. And it's turtles all the way down.
> 
> 	Jon
> 
> 
> 
> _______________________________________________
> 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: Fri, 12 Jan 2007 13:06:36 -0800

I don't see how a TPM adds anything to the real security of a system  
or to assurances that can be made to the outside world.  A TPM is  
just one more thing that can be cracked, isn't it?

Mark
On Jan 12, 2007, at 11:53 AM, Hallam-Baker, Phillip wrote:

> There is a difference between TPM assurances given to the  
> application running in the VM and assurances given to a third party  
> application or service that is running elsewhere and communicating  
> with the TPM.
>
> Clearly if you are setting up the VM you can start it with a blue  
> pill. You can fudge anything you like inside the VM enviroment.
>
> What you can't do is to provide an assurance to a party that is  
> outside this world that has been created that you did not in fact  
> swallow a blue pill.
>
>
> The last is important since it is what allows the machine to tell  
> either the user or the enterprise that owns it that the machine has  
> not been compromised.
>