Encrypted counter as IV in CBC mode encryption using same key I'm currently working with a secure transport protocol that defines the IV to be a counter (incremental nonce) to be encrypted with the same key. This is a followup to a protocol that did not provide any kind of IV.

Could you please describe the possible attack vectors on CBC encryption using this encrypted nonce?

Furthermore, the protocol has the following characteristics:


a MAC is calculated over each encrypted message and verified before decryption (including any parameters send)
session keys are used that are recalculated each time the protocol is initiated
the session is lost when any error is detected in the protocol
the protocol is half duplex, with the attacker having full capabilities on the communication layer, but limited (if any) influence on the sender and receiver
the cipher used is AES with sufficiently random session keys


Would these characteristics alleviate any of the concerns of using an encrypted counter using the same key?

Related question: What are the constraints for an IV using AES in CBC mode?

[EDIT]

Note that for this case the counter and IV are not send or included in the MAC calculation - which seems to be the main issue with the protocol.
Just to be sure we're on the same page, I interpret your question as defining encryption of a string $P_1 P_2 \cdots P_\ell$ with a counter $\mathsf{ctr}$, key $K$, and an $n$-bit blockcipher $E$ as follows:
$$ \mathcal{E}_K(\mathsf{ctr}, P_1P_2\cdots P_\ell) = C_0 C_1 C_2 \cdots C_\ell$$
where $C_0 = E_K(\mathsf{ctr})$, $C_{i+1} = E_K(C_i \oplus P_{i+1})$, and each $P_i$ is an $n$-bit string. (So I'm assuming plaintexts have already been padded as necessary.) I'm assuming the values that will be used for $\mathsf{ctr}$ are determined ahead of time. If this is incorrect, attacks become possible.

The scheme above is secure in the sense of real-or-random security under chosen-plaintext attacks (this is a somewhat stronger condition than semantic security). That is, an adversary cannot distinguish between $\mathcal{E}_K$ and an oracle that given an nonce and an $nm$-bit plaintext returns $(m+1)n$ random bits. This is true as long as $E$ is secure (in the sense of being a pseudo-random permutation), $K$ is random, and the total length of all the ciphertexts encrypted under a given key is much less than $2^{n/2}$ bits (the birthday bound).

Proof sketech. A standard game-hopping security proof might proceed like this:


Change the scheme to use a random permutation $\pi$ in place of $E_K$ (this is reasonable if $E$ is secure and $K$ is random).
Change $\pi$ to a random function $\rho$ (this is reasonable as long as long as the number of queries to $\pi$ is much less than $2^{n/2}$; see the PRP-PRF switching lemma).


As long as no input to $\rho$ is ever repeated, all its outputs are uniformly random and independent. Therefore using the encryption scheme over $\rho$ is indistinguishable from an oracle that outputs random strings, as long as this condition holds. So we need to bound the probability that an input to $\rho$ is repeated.

From here the proof proceeds like the standard CBC security proof, with the caveat that instead of looking for collisions just among the $\rho$ inputs we've already seen, we also need to worry about one of the inputs being equal to a counter value we'll need in the future. (This is where the assumption that counter values are pre-determined comes into play.) Since barring a repeated input, each $C_i$ and therefore each $C_i \oplus P_{i+1}$ is a uniform random value independent of previous queries, the probability that a given $C_i \oplus P_{i+1}$ is equal to a counter value is at most $q / 2^n$, where $q$ is the number of queries the adversary will make (and hence the number of counter values we require).

Using a union bound, the probability that such a collision will ever occur is at most $q^2 M /2^n$, where $Mn$ is the length of the longest plaintext. This probability is negligible as long as $(qM) \ll 2^{n/2}$. And note that $qMn$ is an upper bound for the total number of bits encrypted.

So. The encryption scheme $\mathcal{E}$ is not significantly less secure than CBC with a random IV. The larger question of whether the protocol as a whole is secure as a much more difficult question, and one that I can't answer without knowing more about it (and probably couldn't answer even if I did). But you are authenticating the counter, right? :)