AES - CCM, why not use CMAC inside instead of CBC-MAC? I was reading up on AES-CMAC when I learned that this basically is an improved and more robust version of CBC-MAC, with the ability to safely have variable-length messages. 

Difference between CBC-MAC and CMAC

The AES-CCM uses AES in counter-mode, and thus turns AES it into a stream cipher. It therefore needs message authentication at the end to ensure message integrity as far as I have understood. Here it uses CBC-MAC. But if CMAC is more robust, why not just use this one?

I am working with Bluetooth Low Energy, and this algorithm is the backbone in the encryption of LE Secure Connections.

Grateful for any clarification.
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...