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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 12 Jan 2007 13:57:18 -0800

Security is risk management, not risk elimination [1].

A TPM might be cracked but we are talking about a much smaller quantity of code than is present in a full O/S. There are a hundred million lines in Windows, Unix that might have security implications. Auditing a TPM with fifty thousand lines or so is a much more realistic proposition.

The second issue is that unlike the O/S there is no turtle underneath the TPM. The only ways to defeat the TPM are through finding an exploitable software error or through a physical attack on the hardware.

These represent a meaningful and useful increase in risk management.

[1] See for example http://www.sandelman.ottawa.on.ca/spki/html/1999/msg00026.html. 

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]] 
> Sent: Friday, January 12, 2007 4:07 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: Re: [Cfrg] how to guard against VM rollbacks
> 
> 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.
> >
> >> -----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
> 

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

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 13 Jan 2007 11:33:09 +0100

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

> A TPM might be cracked but we are talking about a much smaller
> quantity of code than is present in a full O/S. There are a hundred
> million lines in Windows, Unix that might have security
> implications. Auditing a TPM with fifty thousand lines or so is a
> much more realistic proposition.
>
> The second issue is that unlike the O/S there is no turtle
> underneath the TPM. The only ways to defeat the TPM are through
> finding an exploitable software error or through a physical attack
> on the hardware.
>

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.

I believe virtualization and VM rollbacks is a non-issue here,
however, I do believe that the original issue with nonce re-use is
serious.  Having more (detailed!) information in documents on the
consequences of nonce re-use would be very valuable.  Such information
can be used when people consider how they want to design techniques to
guarantee lack of nonce re-use.

If nonce re-use for a cipher mode causes statistically marginal loss
of security, people won't worry much because the complexity in solving
the problem isn't worth the small benefits.  But if nonce re-use
directly gives an attacker the key, people should worry, and sometimes
even chose another cipher mode.

/Simon

---

From: "Hal Finney" <[email-masked]>
Date: Sat, 13 Jan 2007 09:12:23 -0800

> within the powers of a VM?  You can't tell a virtual TPM from a real

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.

Hal Finney

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 13 Jan 2007 12:24:51 -0500

On Sat, 13 Jan 2007 09:12:23 -0800
"Hal Finney" <[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.
> 
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

---

From: Jon Callas <[email-masked]>
Date: Sat, 13 Jan 2007 13:48:11 -0800

Saying that a virtualized TPM is no worry because contains non- 
certified keys is relying on the same sort of security that notes  
that virtualized disks have as their manufacturer name the name of  
the VM maker.

That's only true because the implementation chose to do it that way.  
It is an *implementation* issue, not an *architectural* one.

The minute a financial company pays some certifier enough money, the  
virtualized TPM is going to have certified keys. The minute a  
certifier decides that there is enough price elasticity in TPMs,  
they'll do it themselves.

Remember in the old days when to get an SSL cert you had to sign in  
blood and show incorporation papers? Now you just have to reply to an  
email sent to hostmaster. Yes, yes, I know that CAs are now creating  
a new type of high-value cert, but that doesn't contradict my point,  
it shores it up.

In a perfectly virtualized system, the software cannot tell. In a  
sufficiently virutalized system, the software just doesn't know how  
to tell.

Lastly, to repeat myself, not all VMs are your enemy. Some are your  
friend. Yup, it's hard to tell the difference, but it's true.

	Jon