AES - CCM, why not use CMAC inside instead of CBC-MAC?
So in their original suggestion of the mode for 802.11i (for WPA2) the only reason given by Whiting, Housley and Fergueson is:
A combination of counter mode encryption and CBC-MAC authentication is proposed here. These modes have been used and studied for a long time, with well-understood cryptographic properties, and no known patent encumbrances. They provide for good security and performance, whether implemented in hardware or software.
So they probably were mostly looking for a mode that satisfied their specific needs at the time (no patents, reasonably fast and cheap, with security proof) and so they came up with this relatively simple construction.
Furthermore, "CMAC" is actually OMAC1 (first definition (PDF) from 2003) which is based upon OMAC(2) (from december 2002) which is based upon XCBC (from 2000, PDF) which is based upon CBC-MAC.
So as the CCM specification is from January 2002, it obviously couldn't make use of OMAC / CMAC. Furthermore XCBC was known at the time, but had the problem of requiring 3 keys which would have bumped the key size for CCM from 128 bit for AES-128 to at least 384 bit, probably an undesirable result.
But if CMAC is more robust, why not just use this one?
So I looked through the specification and CMAC actually isn't more robust. CBC-MAC by itself is a prefix-free PRF (and thereby a MAC). So if you don't allow sequences of message blocks to be prefixes of each other you get a secure MAC.
The way this weakness is overcome in CCM is that the length of the message is encoded into the first input block to CBC-MAC so no two messages of different length can be prefixes to each other because the initial block will always differ.
The way CMAC overcomes this is by XORing a constant secret into the last input block, so that an adversary doesn't actually know the complete input to CMAC and thereby can't find any prefixes without guessing the secret key-dependent constant.
So as you can see, security-wise both CCM's CBC-MAC and CMAC are rather equivalent in their properties. The only downside is that with CCM you need to know the message length in advance which sometimes is inconvenient.
Bonus: I actually think the prepending of the message length is unncessary for CCM. This is because CCM already needs a nonce-respecting adversary for security (or else the CTR component breaks horribly), so it's guaranteed that the first block is different for each CBC-MAC invocation and thereby no two inputs can be prefixes of each other.
Also note that the more popular GCM breaks at least as badly as this CCM variant since it leaks the secret authentication key in that case...
