ISO/IEC 29167-10 — AES-128 Crypto Suite for RFID Security

Information technology — Automatic identification and data capture techniques — Part 10: Crypto suite AES-128 for security services

1. AES-128 in the RFID Context

ISO/IEC 29167-10 specifies the use of the Advanced Encryption Standard (AES) with 128-bit keys as a cryptographic suite for RFID security services. AES-128, standardized by NIST in FIPS 197, is a symmetric block cipher that operates on 128-bit blocks using a 128-bit key through 10 rounds of SubBytes, ShiftRows, MixColumns, and AddRoundKey transformations. In the RFID context, the standard adapts AES-128 to operate within the severe constraints of passive tag hardware — limited gate count (typically 3,000–8,000 gates for the crypto core), ultra-low power consumption (under 5 µW at 1.2 V), and short transaction time windows (under 50 ms for a full authentication cycle).

The AES-128 core for RFID can be implemented in approximately 3,400 gate equivalents using a 0.18 µm CMOS process, consuming about 3.8 µW at 100 kHz. This makes it one of the most area-efficient block ciphers suitable for tag integration.

The standard defines how AES-128 is used for mutual authentication, encrypted communication, and message integrity checking within the Security Management Protocol (SMP) framework of 29167-1. The crypto suite operates in Cipher Block Chaining (CBC) mode for authentication and Cipher Feedback (CFB) mode for encrypted data transfer. Key diversification is achieved using the AES-based key derivation function specified in the standard, which generates Tag Unique Keys (TUKs) from a Master Key and a tag identifier.

2. Authentication Protocol and Message Formats

The AES-128 authentication protocol follows a three-pass challenge-response scheme. In the first pass, the reader sends an Authenticate command containing a 128-bit random challenge (R1) and the suite identifier. The tag responds with its own 128-bit random challenge (R2) and an encrypted authentication token computed over R1, R2, and a shared secret. The reader verifies the token, computes the response token, and sends it back to complete mutual authentication.

Step Direction Payload Processing Time (typical)
1. Reader Challenge Reader → Tag 128-bit R1 + Suite ID 2 ms (transmission)
2. Tag Response Tag → Reader 128-bit R2 + AES(R1 || R2 || Key) 12–18 ms (encryption)
3. Reader Final Reader → Tag AES(R2 || R1 || Key) 2 ms (transmission)
One key engineering achievement is the reuse of the AES core for both authentication and encryption — the same hardware datapath serves both CBC-MAC for authentication and CFB mode for data confidentiality. This dual use reduces gate count by approximately 25% compared to implementing separate authentication and encryption engines.

The message format uses the existing ISO/IEC 18000-6C command structure. The Authenticate command is encoded using a reserved command code (0xE0), with the payload containing the suite identifier, the challenge value, and control flags. The tag’s response is returned via the standard RN16 handshake, followed by a 128-bit encrypted payload in the response window. This careful mapping ensures that no physical-layer changes are required to support AES-128 security.

3. Hardware Implementation Considerations

Implementing the AES-128 crypto suite on an RFID tag requires careful architectural decisions. The datapath can be implemented as a full 128-bit iterative architecture (fast, high gate count) or a compact iterative architecture (slower, minimal gates). For RFID applications, the compact architecture — processing one byte per clock cycle — is the dominant choice, completing one AES round in 16 clock cycles and a full 10-round encryption in approximately 240 clock cycles (including key schedule).

The AES S-box is the most area-intensive component, consuming approximately 60% of the total gate count in a compact implementation. Designers commonly use composite-field arithmetic (mapping GF(2^8) to GF(2^4)^2) to reduce the S-box area by 30–40%, at the cost of increased critical path delay. The trade-off is acceptable for RFID because the operating frequency (100–500 kHz) is well below the timing closure limit.

Key storage is a critical security concern. The 128-bit AES key occupies 128 bits of non-volatile memory (typically EEPROM or Flash). The standard mandates that the key be stored in a reserved memory bank that is inaccessible via standard Read commands. Access to the key memory is only possible through the SMP Authenticate command sequence, and even then, the key itself is never transmitted — only cryptographic tokens derived from it. From a system perspective, key management must include secure key injection during tag personalization, typically performed in a secured facility using an HSM-backed encoding station.

A common vulnerability in early AES-128 RFID implementations was insufficient random number generation for challenges. If the 128-bit challenge nonce is predictable, an attacker can replay previous authentication traces or perform a chosen-plaintext attack on the AES engine. Always use a hardware random number generator (TRNG) with sufficient entropy, not a software pseudo-random generator, for challenge generation.

4. Frequently Asked Questions

Q: Is AES-128 strong enough for RFID security applications?
Yes. As of 2026, no practical attack breaks AES-128 faster than brute force (2^128 operations). For RFID applications with short-lived session keys and frequent re-authentication, AES-128 provides robust security. For higher-security applications, 29167-14 (AES OFB) can be layered on top.
Q: Can the same AES core be used for data encryption and authentication?
Yes. The standard specifies CBC-MAC for authentication and CFB-128 for encryption, both of which reuse the same AES encryption datapath. Only the mode controller logic differs between the two operations.
Q: What is the power consumption impact of AES on a passive tag?
A full AES-128 encryption at 100 kHz consumes approximately 3.8 µW in a 0.18 µm process. This represents 10–15% of the total power budget of a typical UHF RFID tag, leaving sufficient headroom for memory read/write and backscatter modulation.
Q: How are keys updated in the field?
The KeyUpdate command, defined in the SMP, allows a reader to send a new encrypted key to the tag. The new key is encrypted under the current session key and written to the tag’s key memory. The tag confirms the update by returning a MAC of the update command.

Leave a Reply

Your email address will not be published. Required fields are marked *