AES CBC: When to use new IV

I am trying to figure out when to use a new IV for an AES-CBC communication and whether my approach is safe.

Here is a quote from Thomas Pornin from a similar question:

So, to sum up: you must choose a new, random IV (with a cryptographically strong generator) whenever you are about to encrypt plaintext data which was obtained after having sent over the wire the previous encrypted block.

I need clarification on this. My current setup are two devices which communicate with each other using a command/answer scheme (master and slave). The slave has a true random number generator.

My idea is, that the master requests an IV from the slave which it then uses to encrypt a command. The slave decrypts the command and then uses the last ciphertext of the command as an IV for its encryption, basically seeing command and answer as a continuous stream. After transmitting the answer, the slave creates a new IV which can then again be requested by the master.

Is this safe? Thanks!

It's probably unwise to let the other participant to choose your IV. If nothing else the attacker could force IV reuse.

More commonly, challenge and response schemes put the challenge inside the plain text and leave key/IV used as prescribed. The fact the other participant can encrypt a randomly chosen challenge is generally proof of ownership of a key.

You seem to have some concern that the response from the slave should in some way to be tied to the master's response. A common protocol I can think of here would be the double-ratchet protocol. Where (roughly) plain texts inform a key derivation step that both sides keep track of independently.

If you don't have a secure channel, then you can't trust the IV that the other side is sending you, because an attacker could well tamper with it. Even if you do have a secure channel, the other side might not be considered especially trustworthy.

If your master device has some sort of CSPRNG, whether fed by a true random number generator or not, you can use that. Otherwise, if you can have some sort of persistent counter, one easy way to handle this is to use a key derivation function like HKDF. Simply use your shared key as the entropy input in the key derivation function, use the counter as the salt, and then generate both a new key and IV for each message. Send the counter instead of the IV with the message, and the other side can derive your key.

This can work even if you don't have a persistent counter if the master device has a trusted clock. You can use a timestamp plus a more ephemeral counter, or any other sort of data that is guaranteed not to repeat, and use that in HKDF. Then, you just send that along with the message and both sides can agree on the secret key and IV.

As foreverska mention, you can also use a double-ratchet protocol, although this is more complex. It also requires that both sides, at least originally, have a CSPRNG, since you'd need one for the Diffie-Hellman keys.