Should I calculate two CMACs over two different strings that share common bytes?

Question

I am trying to secure my RF communication in which one RF package consists of two separate segments. I need to make sure that one segment of one packet is not replaced with a valid segment of some previous packet, if you know what I mean.

My RF packet is 32 bytes long, and I need to secure it with CMAC (I found an implementation of AES-128 in CBC mode and CMAC - operating on 16 byte blocks). I am planning on doing it like this:

[B1][B2][B3]...[B30][B31][B32] = bytes in my RF packet

[B1] [B2]... [B10] = first segment (10 bytes long)
[B11][B12]...[B20] = second segment (also 10 bytes long)
[B21][B22]...[B32] = remaining bytes of RF packet contain CMAC of first segment, 
                     and CMAC of second segment (both truncated to first 6 bytes
                     in order to fit into 32 bytes that I have for one transmission).

Now for the problem: In order to make sure that nobody captures two of my RF packets, and creates third new packet that contain fist segment of packet 1 and second segment of packet 2 (with corresponding CMACs also copied) I am planning on calculating CMAC of first segment + 6 bytes of second segment, and calculating CMAC of second segment by borrowing last 6 bytes of first segment and remaining 10 bytes of second segment.

Should I do this? If not, how can I make sure someone doesn't transmit third custom packet containing two valid segments of my previous transmissions? It would be best if I could somehow calculate CMAC on the entire 20 bytes, but as I know I can only work with 16 byte blocks maximum.

Answer 1

By using 6-byte MACs you can only authenticate about $2^{24}$ messages on average before seeing a collision, which would allow an attacker to swap one message for another. There's a decent chance you'll see one much earlier, so in practice you can only safely use a key for some thousands of packets.

So the best option would be to find an implementation of CMAC (or another secure MAC, like HMAC) that allows you to create a single 12-byte authenticator for the whole 20-byte message.

If you do need to go with the 16-byte CMAC implementation for some reasons, I think including the first MAC as part of the second message is better than overlap, which may be shared between two messages. I.e. calculate the second as $MAC(B[11]...B[20]||MAC(B[1]...B[10]))$. You would still be limited in the number of messages you can send before collision.