Is TLS secure against VM reset attacks?

Question

Is the TLS protocol secure against VM reset attacks?

Background: Imagine running cryptographic software inside a virtual machine (VM). A VM reset attack is one where the the state of the software is checkpointed (snapshot) at one point in time, allowed to run forward, and then reset (rolled back) to the previous snapshot and run forward some more. In some cases, this allows powerful attacks. There exist protocols that are secure in the standard model, but not secure against VM reset attacks.

So, is TLS (as a protocol) secure against this kind of attack? Are there are any attacks? Are any of the TLS ciphersuites vulnerable to VM reset attacks?

---

Prior work: Ristenpart et al. showed that some TLS implementations are vulnerable to VM reset attacks, in the following paper:

Thomas Ristenpart and Scott Yilek. When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography. NDSS 2010.

However, their attacks are all against particular implementations of TLS, and exploit failure to reseed the RNG. In other words, they seem to represent a failure of the implementation rather than of the protocol itself. It appears that a sufficiently careful implementation can shield against those attacks by adding additional entropy to the PRNG at appropriate points.

My question is: are there any protocol-level VM reset vulnerabilities in TLS?

---

Threat model: Here is a more detailed threat model. The software runs inside a VM. The attacker can freely interact with the software over the network, as usual. Also, the attacker gains two additional powers: at any point, the attacker can save a snapshot of the current state of the VM; and at any point, the attacker can roll the VM back to some prior snapshot and then cause it to continue execution from there.

It is easy invent protocols that would be secure in the standard model but insecure in this model. For instance, imagine a protocol that generates an ephemeral keypair $K_A,K_A^{-1}$ for a one-time signature scheme, signs the ephemeral public key $K_A$ with a long-term RSA signing key, receives some message from the attacker, and then signs some message using the ephemeral signing key. In the standard model, this would be as secure as using a RSA signature. But in the VM reset model, this is insecure: an attacker could snapshot the system right after it generates the ephemeral keypair, let it run forward to emit one message signed by the ephemeral private key; then roll it back to the snapshot and run it forward from there, observing a second message signed by the same ephemeral private key. Once the attacker observes two messages signed by the same one-time private key, the attacker can forge other messages. So that's a proof that protocol-level VM reset vulnerabilities can exist. But is the TLS protocol vulnerable?

Answer 1

No, TLS is not secure against VM reset attacks. There are at least two attacks that are made possible by VM reset attacks, off the top of my head:

1. AES-GCM nonces are typically generated deterministically from the message counter value. If you set the snap shot prior to the local peer sending a plain text message that will change after resetting to the snap shot, you will have a severe nonce reuse vulnerability. As specified in RFC 5288, the 64 bit explicit nonce that is sent per packet MAY equal the message counter. The current TLS 1.3 draft removes the explicit nonce and replaces it with the implicit message counter xor:ed with the static IV values that were derived from the master secret. The same nonce generation is specified in the chacha20-poly1305 draft, which consequently has the same vulnerability. The traditional CBC cipher suites would be less vulnerable, in particular if used in encrypt-then-mac mode. Edit: In practice, the VM engine might be implemented to automatically close all TCP connections when suspended, and not necessarily reconnect when resumed after a reset. This might help to make the attack less practical against normal TLS connections directly over TCP. TLS over other types of channels and DTLS over UDP might be a different story.

2. Session master secrets are supposed to be discarded after any fatal alert corresponding to the session, such as failures to verify the finished messages. An attacker that is able to reset the local peer would obviously be able to circumvent this. This means e.g. that an attacker might attempt to perform session resumptions using the session id belonging to another peer, even after an initial failure. Such attacks against the session state do not depend on in which state the VM engine leaves the network stack when resetting to a snapshot.

Answer 2

If you break this down in terms of a client/server relationship I think it may offer some insight. TLS is neither explicitly or implicitly vulnerable and, like you said, it depends on the implementation.

For example: if the server utilizing TLS is virtualized, then rolling back to that point may introduce a replay. But if you’re talking about client authenticating with a server, then you don't have that issue unless there is some other factor like a bug or something or a bad implementation – which is why when you log out of a site and restore a VM to the past you are still logged out, but if you were to restore the server to that point (let's say in a backup or something) you may have that problem especially if the cookie hasn't expired yet. Although, with proper security “best practices” that may be mitigated.

If you could spoof the time on the server though there may be an issue there as well. There is nothing inherent though in TLS as there are many protocols that could have an issue with that which is why it's called what it's called. Does that help? My point, in a nutshell, is that there are other factors, as you well know, and the security of the protocol itself may have very little to do with your server getting pwnd.