Subject: Re: [CFRG] how to guard against VM rollbacks

From: Phillip Rogaway <[email-masked]>
Date: Thu, 11 Jan 2007 11:17:15 -0800 (Pacific Standard Time)

Hi Wei,

WD> ... the security of a nonce-based
WD> cryptographic scheme may be compromised due to unintentional nonce reuse ...
WD> Apparently ... no one has proposed a solution (that I could find)....
WD> Where possible, it may be best to go back to deterministic cryptography....

Let me point you in this connection to

   P. Rogaway and T. Shrimpton, Deterministic Authenticated Encryption:
   A Provable-Security Treatment of the Key-Wrap Problem,
   http://www.cs.ucdavis.edu/~rogaway/papers/keywrap.html, full version
   of Eurocrypt 2006 paper.

Section 7 is about making encryption schemes maximally robust against 
nonce-reuse.  Besides formalizing the goal, the suggestion is to use a 
deterministic authenticated-encryption (DAE) scheme that supports 
vector-valued associated data. Hijack one component of it to use as the 
(anticipated) nonce.  A concrete instantiation, SIV, is proposed and proven 
secure.  If a proper nonce is supplied you get the usual notion of nonce-based 
semantic security; but if a nonce should get reused, all that is leaked 
is repetitions in (message, nonce, further-associated-data-components)-tuples,
with no damage to future privacy or integrity.

phil

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

---

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

> From: Jon Callas [mailto:[email-masked]] 

> 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.

There were reasons that led to that situation, not least the lack of CA accountability. If you look at the EV certs you will see that this is not a one way trend any more. 

The most important feature of EV is making the user aware of who provided the credential. That is there to ensure CA accountability.

> 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.

A Virtual TPM cannot by definition be a trustworthy hardware TPM.

Whether the scheme is 'secure' depends on what your application is. If you are trying to enforce strong DRM for copyright enforcement your problem is break once run anywhere. In order to succeed you have to depend on none of the billion plus TPMs created is ever compromised - fat chance!

If on the other hand you want to prevent the corporate strategy appearing for sale on EBay then you have a much smaller locus of trust, maybe 100 or so machines. That is entirely practical.

The biggest vulnerability in the system is not going to be the CA, it's the manufacturing process. Unless every TPM is manufactured in the type of production environment used for FIPS-140-3 devices (unlikely) the simplest way to abstract a key would be to introduce a modified TPM onto the production line.

The other reason that protecting corporate secrets is a more practical proposition is that the profit opportunities are nowhere near as reliable as making pirate copies of Lord of the Rings on release. Sure you might get timely inside information that allows you to make a lot of money but more likely is that the information you get is not actionable.