Re: [Cfrg] how to guard against VM rollbacks

["Wei Dai" <weidai at weidai.com>]

Peter Gutmann wrote:
> 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 think as a writer of cryptographic software, instead of checking whether 
your software is running inside a VM, the safe thing to do would be to 
assume that it is, and take appropriate defensive measures. But I'm curious, 
what does your software do differently if it detects that it's running in a 
VM?

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

Here's the simplest application I can imagine that would be affected by this 
problem: a chat program with messages authenticated by a MAC using a counter 
as the nonce. Say you're the user of such a program, and you roll back your 
VM because your system crashed. As soon as you type the next message (or 
maybe the next few messages depending on the details of the MAC algorithm) 
and send it out, an attacker could start impersonating you to the other 
party.

>   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 some applications k may be pre-generated in order to precompute g^k mod 
p. As I mentioned earlier this practice would have to be abandoned.

Also, Hal Finney mentioned that generating random numbers after fixing the 
message may not be sufficient, if the RNG does not incorporate new entropy 
into its state after being rolled back and before responding to the next 
request.



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