CMAC: Cipher-Based Message Authentication

Introduction

HMAC builds a message authentication code from a hash function. CMAC (Cipher-based Message Authentication Code), standardized by NIST in SP 800-38B, builds one from a block cipher instead — almost always AES. For systems that already have fast, hardware-accelerated AES on hand (which describes the overwhelming majority of modern CPUs, thanks to AES-NI) but don’t want the overhead of a separate hash function implementation just for authentication, CMAC offers an efficient, well-analyzed alternative built entirely from cipher primitives already in place.

Table of Contents

• Why Build a MAC from a Block Cipher?
• The Naive Approach’s Weakness
• How CMAC Works
• Subkey Generation
• A Verified Example
• Real-World Applications
• FAQ
• References

Why Build a MAC from a Block Cipher?

A block cipher like AES already provides a strong, well-studied pseudorandom permutation. CMAC’s insight is that this same primitive — with a clever chaining construction — can produce a secure MAC without needing to also implement or verify a separate hash function. In embedded systems, hardware security modules, or any environment where code size and the number of distinct cryptographic primitives matter, this consolidation is genuinely valuable.

The Naive Approach’s Weakness

Simply running a block cipher in CBC mode and taking the last ciphertext block as a MAC — traditionally called “CBC-MAC” — has a real, well-known weakness: it’s only secure for fixed-length messages. Two messages of different lengths, chosen carefully, can be combined to forge a valid MAC for a third message the attacker never had a legitimate tag for, exploiting how CBC-MAC handles (or fails to properly handle) variable message lengths. CMAC’s specific subkey mechanism, covered next, exists precisely to close this gap.

How CMAC Works

1. Derive two subkeys, K1 and K2, from the main key (see below).
2. Split the message into 16-byte (AES block-size) chunks.
3. Run standard CBC-style chaining: XOR each block into the running state, then encrypt with AES, feeding the result into the next block.
4. For the final block: if the message length is an exact multiple of the block size, XOR the last block with K1 before the final encryption. If it’s not a full block (including the empty-message case), pad it with a single 1 bit followed by zeros, then XOR with K2 instead.
5. The final AES-encrypted block is the CMAC tag.

This subkey-based handling of the final block — using a different derived key depending on whether padding was needed — is exactly what prevents the length-manipulation forgery that plain CBC-MAC is vulnerable to.

Interactive Visualizer

The visualizer above runs genuine AES-CMAC — real AES-128 encryption (the same verified core from the AES guide), real subkey derivation, real block chaining — and was independently cross-checked against a standard library’s raw AES-CBC encryption before being published here.

Subkey Generation

1. Encrypt an all-zero block with AES under the main key: L = AES(key, 0).
2. K1 is L shifted left by one bit; if L’s most significant bit was 1, XOR the result with a fixed constant Rb (0x87 in the last byte, zero elsewhere) to keep the result within the correct algebraic structure.
3. K2 is derived from K1 using the exact same shift-and-conditionally-XOR process.

This construction (based on doubling in a finite field) guarantees K1 and K2 are always well-defined, non-trivial values, deterministically derived from the main key alone — no extra secret material needed.

A Verified Example

Using the widely-cited NIST SP 800-38B test key:

• Key: 2b7e151628aed2a6abf7158809cf4f3c
• Message: 6bc1bee22e409f96e93d7e117393172a (exactly one 16-byte block)
• CMAC: 070a16b46b4d4144f79bdd9dd04a287c

Every correct AES-128-CMAC implementation, including the one running in the visualizer above, reproduces this exact tag from these inputs.

Real-World Applications

• NIST-approved protocols: CMAC is a NIST-standardized MAC option (SP 800-38B) used in various government and financial-sector protocols that already standardize on AES.
• Hardware security modules: environments where minimizing the number of distinct cryptographic primitives (and their associated implementation and certification burden) is a priority.
• Bluetooth Low Energy: uses AES-CMAC as part of its key generation and authentication procedures.
• 802.1AE (MACsec): Ethernet-layer security using AES-based authentication.

FAQ

Is CMAC as secure as HMAC?

Both are considered secure, well-analyzed MAC constructions when used correctly. The choice between them is typically driven by what primitives are already available and fast in a given system (a hash function vs. a block cipher) rather than a meaningful security gap between the two.

Why not just use CBC-MAC directly?

Plain CBC-MAC (without CMAC’s subkey mechanism) is only secure for messages of a single, fixed, pre-agreed length — using it for variable-length messages opens the door to a real forgery attack. CMAC’s K1/K2 subkey construction specifically closes this gap, making it safe for arbitrary-length messages.

Can CMAC use a block cipher other than AES?

Yes — NIST SP 800-38B defines CMAC generically over any approved block cipher; AES-CMAC is by far the most common instantiation given AES’s ubiquity, but the construction itself isn’t AES-specific.

What happens if the message is empty?

CMAC still produces a valid, well-defined tag: an empty message is treated as an “incomplete final block” (padded with a single 1 bit and zeros), so it uses the K2 subkey path — exactly the same as any other message that doesn’t end on an exact block boundary.

Is CMAC used in AES-GCM?

No — AES-GCM uses a completely different authentication mechanism (GHASH, based on Galois field multiplication) rather than CMAC. CMAC is typically used as a standalone MAC, not as part of GCM’s construction.

References

1. NIST SP 800-38B. “Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication.” Available at: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38b.pdf — includes the official test vectors referenced in this guide.

2. RFC 4493. “The AES-CMAC Algorithm.” IETF, 2006.

3. Iwata, T. and Kurosawa, K. “OMAC: One-Key CBC MAC.” FSE 2003 — the academic predecessor to CMAC’s design.

4. Wikipedia. “One-key MAC.” Available at: https://en.wikipedia.org/wiki/One-key_MAC