Possible CPA or CCA attack when using AES-CBC mode under the following situation? Both client and server know a shared key in advance. Both sides us EVP_BytesToKey() derive a pair of same key and same IV. Then, client and server start transferring data encrypted by AES-CBC mode using this pair of key and iv.

Is there any possible CCA or CPA? Should I use randomized IV every time? Is it safe to transfer IV in plaintext with the encrypted data?

Can CPA be avoided if I use randomized IV every time? How should I mitigate CCA?
TLDR: Don't invent your own protocol, use an existing one.



Reusing an initialization vector with the same key is always a problem, even if the attacker is read-only. For CBC, you can see whether a beginning part of one message is the same as the beginning part of a different message (and you get to know the length of the common prefix, on block-level).

With a CPA (chosen-plaintext attack) and an IV known before chosing the plaintext, the attacker can (with several tries) decrypt about everything. This was used in the BEAST attack.
With a constant (but unknown) IV, a possible attack I can imagine now is guessing prefixes of the unknown plaintext and encrypting it, to see if they match.

All of these are prevented by using a random IV for each message, chosen after the plaintext of that message (or at least the first plaintext block) is given to the "encryption machine". This IV can be sent with the message itself, commonly before the first ciphertext block.

As far as I can see, a CCA (chosen-ciphertext attack) does not gain much from the fixed IV: you can still do a padding oracle attack by modifying the ciphertext block before the last block of a message and see if the message decrypts properly (assuming a padding scheme like PKCS 7), or can be read by the receiving application.

To prevent most CCAs, use a MAC together with your encryption (in the encrypt-then-mac order, i.e. calculate the MAC from the ciphertext including the IV and maybe other message meta data you might want to protect), and check the MAC before starting to decrypt. You can derive the MAC key from the same secret as you derive the encryption key. This has the side effect that it does not just protect the privacy, but also integrity/authentication.

There might be a lot more weaknesses hidden in your example protocol. Don't invent your own, use an existing one. For example, TLS with a preshared-secret ciphersuite should work for your needs (as much they are outlined in the question).