Re: [Cfrg] how to guard against VM rollbacks

[pgut001 at cs.auckland.ac.nz (Peter Gutmann)]

"Wei Dai" <weidai at weidai.com> writes:

>I've mentioned in a previous thread that the security of a nonce-based
>cryptographic scheme may be compromised due to unintentional nonce reuse
>caused by rollback of one's virtual machine state to an earlier snapshot.
>Apparently this problem has been noticed by few others and no one has
>proposed a solution (that I could find). The only mention I found of this
>issue is in [1].

My code checks for whether it's running inside the most common VMM, VMware.
However, this issue is rather problematic, because so far the major users of
this technique are malware, which means anything that checks for operation
inside a VMM are likely to be identified as potential malware by heuristics-
based scanners (which in practice means pretty much everything except things
like ClamAV).  The reason why I only check for VMware is because many of the
techniques used to do the checking fall into the voodoo category (even the
VMware one isn't exactly elegant), and it's not certain that they'll continue
to work over time, or that they won't cause system instability.

So yes, it is possible to detect this, but the cost may be substantial.  In
addition it's not certain what you should do if it is detected.  With malware
it's easy, submerge again until you're outside the VM so you won't be
detected, but with legitimate software it's not certain what the response
should be

>I'll throw out some ideas in the hope of bringing more attention to this
>problem. It seems a fairly serious one given the increasing popularity of
>virtualization and the fact that virtually every protocol and application
>software that uses cryptography may be affected.

Is it really a problem?  My thinking about this (in the VM check) was:

/* ...

   There is one variant of this problem that we can't work around, and that's
   where we're running inside a VM with rollback support.  Some VMs can take
   periodic snapshots of the system state to allow rollback to a known-good
   state if an error occurs.  Since the VM's rollback is transparent to the
   OS, there's no way to detect that it's occcurred. In this case we'd roll
   back to a previous state of the RNG and continue from there.  OTOH it's
   hard to identify a situation in which this would pose a serious threat.
   Consider for example SSL or SSH session key setup/generation, if we haven't
   committed the data to the remote system yet it's no problem, and if we have
   then we're now out of sync with the remote system and the handshake will
   fail. Similarly, if we're generating a DSA signature then we'll end up
   generating the same signature again, but since it's over the same data
   there's no threat involved.  Being able to cause a change in the data being
   signed after the random DSA k value is generated would be a problem, but k
   is only generated after the data has already been hashed and the signature
   is about to be generated.

   In general this type of attack would require the ability to generate
   information based on random state, communicate it to an external party, and
   then generate different information from the same state. In other words it
   would require cooperation between the VM and a hostile external party (to,
   for example, ignore the fact that the VM has rolled back to an earlier
   point in the protocol so a repeat of a previous handshake message will be
   seen), or in other words control over the VM by an external party.  Anyone
   faced with this level of attack has bigger things to worry about than RNG
   state rollback */

Peter.

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg