Assume that all those input values are not difficult to identify/guess as they are required to establish correct transmission and synchronization between the two communicating parties.
If we assume that the key is secure then the mode of operation will also be secure for the security that it was designed to deliver. That the IV may be public is a common assumption: it does not in itself make the resulting cipher insecure.
Is this a weak AES-CTR implementation, assuming one can obtain pairs of keystreams/input-values?
It is hard to read what you mean here, but lets assume that:
- keystreams means ciphertext;
- input values means the components that make up the IV.
instead of the normal definition:
- keystreams means the output of the block cipher that get XOR'ed with the plaintext
- input values means the plaintext.
In that case the scheme would still offer confidentiality - presuming that there aren't any protocol or implementation mistakes.
Obviously if you do get access to part of the keystream generated by AES CTR - the part that gets XOR'ed with the plaintext - then you can decrypt that part of the plaintext, but not any other part of the plaintext.
You should only be able to get to parts of the keystream by either:
knowing that part of the plaintext - this doesn't help the adversary because that part of the keystream is not linked to any other part of the keystream;
knowing the key - this obviously breaks the cipher completely: once the key gets known all security assumptions are broken.
Note that the block cipher will protect the key. Furthermore the IV may be get known to an adversary. So knowing part of the key stream does not break security of CTR.
Knowing all of the keystream implies knowing all of the plaintext of a message or to know the AES key. In the first case no mode of operation can protect that particular message as the plaintext is already known. Other messages would still be secure. If the key gets known then the adversary can simply decrypt anything and all security is lost.
I guess we can say this implementation is malleable as any AES-CTR without authentication steps.
Of course it is malleable. There is nothing to authenticate the plaintext or ciphertext after all.
There aren't any other obvious attacks on CTR mode as long as the IV doesn't repeat or if the key gets known.
There is a copious amount of bits reserved for the counter, so it is clear that the message size is not an issue.
The IV seems to be build up well.
There is 32 bits space for a message counter. This allows for over four billion messages to be send before the counter starts to repeat. Do note that if the adversary can trigger messages to be send that this could become a problem: a computer can easily perform more than 4 billion calculations after all.
The transmission is identified by the next 5 bits and the direction in the one after. You could argue that those 6 bits should be before the message counter semantically, but in that case the 32 bit counter would not be 8 bit aligned, making the counter encoding non-trivial. There are obviously only 32 "transmission" connections possible. In general it is nicer to calculate a different key for each transmission and direction - but cryptographically speaking this is not required.
incr is the space reserved for the block counter used for CTR. It allows $2^{64}$ 16 byte blocks to be encrypted for each message. That should be plenty.
26 bits are left over. This is a bit weird: it would at least be easier to have IV1 and IV2 occupy their own byte. Now the least significant bits of the IV1 & IV2 byte must be set to zero and you have to shift the bits into place.
It is up to the protocol and protocol implementation to make sure that the IV doesn't repeat. The build up of the IV does seem to allow this.
Beware that counters are particularly dangerous to implement: a reset of the device should for instance not reset the counter value. If the implementation can be fooled to increase the counter if the transmission fails then the counter could easily cycle back to the starting value after $2^{32}$ tries.
TL;DR: this seems like a well thought out build up for the IV. If that IV is made sure not to repeat this scheme should deliver the security promised by CTR and AES.