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 imaging 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).

-
imaging $\mapsto$ imagine $\;$ –  Ricky Demer Aug 27 '14 at 20:39
What if only ciphertext is being transferred? No random IV and no IV will be exchanged ever. No prefix added to ciphertext, and assume attacker can only read or change. Is it still safe? –  nnarklrh Aug 28 '14 at 6:12
Also, do you have recommendation of any existing protocol or can you suggest any self-designed protocol which is PSK and shows no specific pattern (like public key exchange). Assume if attacker detects any specific pattern(TLS handshake, public key exchange, etc), attacker can reset the whole connection(by sending TCP RST). This scenario is the reason I tried designing a protocol like I described in the question. –  nnarklrh Aug 28 '14 at 6:18