In a AES-CBC + HMAC architecture, Is it secure to send a second IV in a message to a device incapable of producing satisfactory random numbers?

Question

There are many threads here explaining the need of a random and unpredictable IV for the AES-CBC.

I am building a home automation system with security for a school project where a Raspberry Pi creates a separated WPA2 network to communicate with many ESP8266 Wi-fi modules via HTTP requests. Each new message from the central node is encrypted with a key and a newly generated(using "/dev/urandom") IV.

The message payload structure is:

plain-text IV || cipher-text || HMAC-SHA256

However, the answer of a GET request needs to be encrypted too. From what I read, encrypting the answer with the same IV from the received request may not be the ideal.

So is it okay for the central node to send another IV, which the esp8266 is going to use for encrypting the answer?

And what is the best way to send this IV?

1. Inside the encrypted message(cipher), or

2. As plaintext, making the payload:

   IV2 || IV1 || cipher || HMAC(hash of IV2 || IV1 || cipher)
   

Answer 1

And what is the best way to send this IV?

CBC IVs need to be unpredictable to attackers. If you just send them along your other IV they are no longer unpredictable, hence encrypting them as well would be the way to go and should provide reasonable security.

plain-text IV || cipher-text || HMAC-SHA256

What you are doing here is the infamous Mac-Then-Encrypt with CBC. This is a really bad idea. A really, really, really bad idea. This is the source of many attacks on TLS. Please, learn from the past mistakes done with TLS and use a pre-made authenticated encryption mode, such as EAX or CCM, or at least Encrypt-Then-Mac with CTR.