Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29192-6: Lightweight Cryptography — Part 6: Message Authentication Codes
Lightweight MAC constructions for data integrity and origin authentication in constrained networks
Message Authentication Codes (MACs) are essential for guaranteeing both the integrity and the authenticity of data transmitted over untrusted networks. In the IoT ecosystem, where devices broadcast sensor readings, receive firmware updates, and exchange control commands, the absence of a MAC leaves the system vulnerable to forgery, replay, and data corruption attacks. ISO/IEC 29192-6 standardises lightweight MAC algorithms that provide strong security guarantees with minimal computational and storage overhead, complementing the encryption and hashing primitives defined in Parts 2, 3, and 5.
A MAC is fundamentally different from a hash function: a MAC incorporates a secret key, so only parties who possess the key can verify the authenticity of a message. Hash functions, by contrast, are public and provide integrity only — anyone can compute a hash of a given message.
Block Cipher-Based MAC Constructions
Lightweight CBC-MAC and Cipher-Based MAC (CMAC)
The standard specifies several MAC constructions built on the lightweight block ciphers from Part 2. The most notable is a lightweight variant of CMAC (Cipher-based MAC), which uses a block cipher in CBC mode with a final encryption of the last block to prevent length-extension attacks. When instantiated with PRESENT-80 or CLEFIA-128, the resulting MAC provides 64-bit or 128-bit security respectively, matching the block size of the underlying cipher. The hardware overhead is minimal — the same cipher core is reused for both encryption and MAC computation.
When using CBC-MAC with lightweight block ciphers, it is critical to use the CMAC variant (XOR with a constant before the final encryption) rather than plain CBC-MAC. Plain CBC-MAC is only secure for fixed-length messages, while CMAC handles variable-length messages securely. Several IoT protocols have been broken due to this oversight.
Dedicated Lightweight MAC Algorithms
TBC-MAC and LP-MAC
Beyond block-cipher-based constructions, ISO/IEC 29192-6 includes dedicated MAC algorithms designed from scratch for lightweight operation. TBC-MAC (Tweakable Block Cipher MAC) uses a tweakable block cipher as its core primitive, providing built-in domain separation without additional state. LP-MAC (Lightweight Parallel MAC) is optimised for hardware parallelism, processing multiple message blocks simultaneously to achieve higher throughput than serial CBC-MAC designs. LP-MAC is particularly well-suited for high-speed sensor interfaces such as SPI or parallel buses.
| MAC Algorithm | Core Primitive | Tag Size (bits) | Security Level | HW Gate Count | Parallelisable |
|---|---|---|---|---|---|
| CMAC-PRESENT-80 | PRESENT-80 block cipher | 64 | 64-bit | ~2 000 | No |
| CMAC-CLEFIA-128 | CLEFIA-128 block cipher | 128 | 128-bit | ~3 500 | No |
| TBC-MAC-64 | Tweakable block cipher | 64 | 64-bit | ~1 800 | No |
| TBC-MAC-128 | Tweakable block cipher | 128 | 128-bit | ~3 200 | No |
| LP-MAC-64 | Dedicated permutation | 64 | 64-bit | ~2 500 | Yes |
| LP-MAC-128 | Dedicated permutation | 128 | 128-bit | ~4 000 | Yes |
Engineering Design Insights
Tag Truncation and Security Trade-Offs
The standard allows MAC tags to be truncated to as few as 32 bits to reduce transmission overhead in bandwidth-constrained channels. However, truncation directly reduces the security level: an attacker attempting forgery needs only 2^(t/2) attempts for a t-bit tag on average due to birthday-bound effects. For a 32-bit tag, this is merely 2¹⁶ attempts — feasible for a determined attacker. The standard recommends a minimum tag length of 64 bits for most applications and 128 bits for high-security environments.
Nonce Requirements and Replay Protection
All MAC constructions in 29192-6 are deterministic: the same message and key always produce the same tag. To prevent replay attacks, the message must include a nonce (number-used-once) such as a monotonically increasing sequence number or a timestamp. The standard explicitly recommends that implementations enforce nonce uniqueness at the protocol level, and that the nonce be included in the MAC input. Failure to do so is one of the most common vulnerabilities in deployed IoT systems.
For a typical smart-home sensor network, CMAC-PRESENT-80 with 64-bit tags provides an excellent balance: the MAC computation completes in under 50 µs on a 16-bit MSP430 microcontroller, and the 64-bit tag adds only 8 bytes of overhead per message — negligible on most low-power radio links.
Never use a MAC without replay protection. An attacker who records a valid (message, tag) pair can retransmit it verbatim unless the receiving device checks a nonce or timestamp. This is the most common real-world IoT authentication failure, and the standard explicitly warns against it.
Frequently Asked Questions
Q1: Should I use a dedicated lightweight MAC or build one from a block cipher using CMAC?
If your device already implements a lightweight block cipher from Part 2 (e.g., PRESENT for encryption), reusing the same cipher core for CMAC saves area and simplifies the design. If you need higher throughput or parallel processing, LP-MAC is the better choice.
If your device already implements a lightweight block cipher from Part 2 (e.g., PRESENT for encryption), reusing the same cipher core for CMAC saves area and simplifies the design. If you need higher throughput or parallel processing, LP-MAC is the better choice.
Q2: How do I choose between 64-bit and 128-bit tags?
For most consumer IoT applications where the message lifetime is short (seconds to minutes) and the value of a successful forgery is low, 64-bit tags are adequate. For industrial control systems, medical devices, or financial transactions, 128-bit tags should be used.
For most consumer IoT applications where the message lifetime is short (seconds to minutes) and the value of a successful forgery is low, 64-bit tags are adequate. For industrial control systems, medical devices, or financial transactions, 128-bit tags should be used.
Q3: Can I use the same key for encryption (Part 2/3) and MAC computation?
Using the same key for encryption and MAC is dangerous — it can lead to cross-protocol attacks and invalidates security proofs. Use independent keys derived from a master secret via a key-derivation function. ISO/IEC 29192-5 hash functions can serve as the KDF.
Using the same key for encryption and MAC is dangerous — it can lead to cross-protocol attacks and invalidates security proofs. Use independent keys derived from a master secret via a key-derivation function. ISO/IEC 29192-5 hash functions can serve as the KDF.
Q4: What is the performance of LP-MAC compared to CMAC?
LP-MAC processes multiple blocks in parallel, achieving approximately 2–4× higher throughput than CMAC in hardware, at the cost of roughly 30 % larger area. In software on a serial processor, the advantage is smaller — typically 1.5–2×.
LP-MAC processes multiple blocks in parallel, achieving approximately 2–4× higher throughput than CMAC in hardware, at the cost of roughly 30 % larger area. In software on a serial processor, the advantage is smaller — typically 1.5–2×.
