2
$\begingroup$

I'm reading a protocol specification where the procedure is to generate a CMAC, take the first 4 bytes of it, append this authentication tag to the message and then encrypt the message + CMAC together with another key using CTR mode encryption.

Both CMAC and CTR mode are defined to use the AES-128 block cipher. A separate key is used for CMAC authentication and CTR encryption.

Does encrypting the MAC add any extra security? Shouldn't CMAC be already "secure" by itself?

Is this a typical approach for doing encryption + integrity verification?

Improve this question
$\endgroup$
5
  • $\begingroup$ How is the encryption performed ? Is this a public protocol specification ? $\endgroup$
    – Ruggero
    Commented Feb 6, 2015 at 10:07
  • $\begingroup$ AES-128-CTR and AES-128 CMAC $\endgroup$
    – RubenLaguna
    Commented Feb 6, 2015 at 11:53
  • 1
    $\begingroup$ I'm guessing that this will lead to re-discussing this question about the order of encryption and authentication. Is it common in protocol specs: no. Is it used: yes, quite a lot (TLS). The common understanding is that you do encrypt-then-MAC nowadays, but there will be dissonant opinions. It's less of an issue for CTR mode, but for CBC mode you'll have to worry about plaintext/padding Oracle attacks and you may loose confidentiality. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 7, 2015 at 13:32
  • 1
    $\begingroup$ I'd be particularly concerned about the length of the authentication tag. According to NIST, the output should be at least 64 bits. Encryption of the tag using CTR will only provide limited protection, an attacker can still flip specific bits. I'm currently wondering if the encryption will actually add any protection at all. Usually though, MAC-then-encrypt is used so that the MAC is over the plaintext instead of the ciphertext - usually it is not used to protect the MAC value in particular, to my knowledge. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 7, 2015 at 13:47
  • $\begingroup$ If you have any influence on this scheme, I would strongly suggest replacing it with AES-SIV, which is based on the same primitives (AES, CTR mode and CMAC), but is stronger (128-bit tag), less vulnerable to misuse (can be used even without an nonce), may have less overhead (assuming your scheme transmits an IV/nonce for CTR mode) and has an actual security proof. $\endgroup$
    – Ilmari Karonen
    Commented Feb 9, 2015 at 18:24

2 Answers 2

Reset to default
2
$\begingroup$

If a MAC is encrypted using CTR specifically then specific bits can still be flipped by an attacker. So although the MAC isn't known, specific bits can still be altered in transit. This may allow certain attacks, depending on the error handling of the receiver of the protected messages.

[The question I cannot readily answer is if such a small authentication tag gains nothing from being encrypted. Please alter.]

A CMAC should indeed already be secure by itself. Encryption of a MAC should not be necessary.

In the protocol you are describing the CMAC is however truncated to a very low number of bits. Look at this snippet from RFC 4493, section 2.4:

It is possible to truncate the MAC. According to [NIST-CMAC], at least a 64-bit MAC should be used as protection against guessing attacks. The result of truncation should be taken in most significant bits first order.

No, it's not a "typical approach" in the sense that newer protocols usually calculate an authentication tag over the ciphertext instead of the plaintext.

There are however protocols where MAC-then-encrypt is used, notably Transport Layer Security (TLS). This actually opens up TLS to some attacks such as the Lucky Thirteen attack, although that attack also requires CBC mode encryption instead of CTR mode encryption.

Improve this answer
$\endgroup$
1
$\begingroup$

No, this is not a typical way to go.

Actually Encrypt-then-MAC would be the best way to go, attaching the MAC (in this case a CMAC) as is to the encrypted data.

Before starting the decryption, you would first check the MAC. Even in this setup using two different keys - one for the AES encryption and one for the CMAC - should be used.

Finally I am confused about the AES128-CBC-CTR - normally either CBC or CTR.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Sorry it's AES-128-CTR not CBC. That was a typo. $\endgroup$
    – RubenLaguna
    Commented Feb 6, 2015 at 11:55
  • $\begingroup$ I'm counting 3 related questions, this only answers one of them. The remarks about the two keys and the (justified) confusion about the cipher mode should be comments instead of being included in the answer. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 7, 2015 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.