Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29167-14 — AES OFB Crypto Suite for RFID Security
Information technology — Automatic identification and data capture techniques — Part 14: Crypto suite AES OFB for security services
1. AES Output Feedback Mode for RFID Security
ISO/IEC 29167-14 specifies the use of the Advanced Encryption Standard in Output Feedback (OFB) mode as a cryptographic suite for RFID security services. While 29167-10 (AES-128) uses AES in CBC mode for authentication and CFB mode for encryption, 29167-14 adopts AES OFB mode, which transforms the AES block cipher into a synchronous stream cipher. In OFB mode, the keystream is generated by repeatedly encrypting the previous encryption output: KSi = EK(KSi-1), where EK is AES-128 encryption under key K and KS0 is the initialization vector (IV). The plaintext is then XORed with the keystream to produce ciphertext.
OFB mode’s key advantage over CFB mode (used in 29167-10) is error resilience: a bit error in the ciphertext affects only the corresponding bit in the decrypted plaintext, with no error propagation to subsequent bits. In RFID environments where bit errors due to fading or interference are common (typical BER of 10^-3 to 10^-4), OFB mode provides more graceful degradation of data quality.
The standard specifies two key sizes: AES-128 (recommended) and AES-256 (optional for higher security applications). Both operate on 128-bit blocks but the AES-256 variant uses 14 rounds instead of 10. The keystream generation proceeds continuously from the initial IV, and the maximum number of blocks that can be encrypted under a single (Key, IV) pair is 2^32 blocks, after which a new IV must be established. This limit prevents the keystream from diverging into a security-compromising state due to the birthday bound on the 128-bit block cipher output.
2. Protocol and Keystream Synchronization
The OFB mode authentication protocol defined in 29167-14 builds on the same three-pass SMP structure as 29167-10 but with important differences in the keystream management. During the Authenticate command, the reader transmits a 128-bit IV to the tag. The tag uses this IV, combined with its stored key, to compute the initial keystream block. Mutual authentication is achieved by exchanging encrypted challenge values: the tag encrypts its random challenge using the first keystream block, and the reader verifies it and responds with its own encrypted challenge using the second keystream block.
| Feature | 29167-10 (AES CFB) | 29167-14 (AES OFB) | Implication |
|---|---|---|---|
| Mode Type | Block cipher feedback (CFB) | Stream cipher (OFB) | OFB pre-computes keystream |
| Error Propagation | 1 bit error → 128-bit block error + bit error in next block | 1 bit error → 1 bit error only | OFB better for noisy channels |
| Pre-computation | Not possible (needs ciphertext input) | Full keystream pre-computation possible | OFB enables lower latency |
| IV Requirement | Unique IV per session | Unique IV per session (strict) | Same requirement in practice |
| Block Limit per (Key, IV) | 2^32 blocks | 2^32 blocks | Same birthday bound applies |
OFB mode’s pre-computation capability is transformative for RFID performance. The tag can generate the first 1 KB of keystream during idle periods (between inventory rounds) and store it in a small ring buffer. When a Read command arrives, the tag simply XORs the pre-computed keystream with the data to be transmitted, achieving encryption in zero additional clock cycles. This effectively decouples the encryption latency from the data transmission path.
Keystream synchronization is managed through an IV counter mechanism. Both the reader and tag maintain a 32-bit block counter that is appended to the IV to generate unique keystream segments. After each encrypted transaction, the counter is incremented. If the counter wraps around (after 2^32 blocks, or approximately 68 GB of encrypted data), a new IV exchange is required. For typical RFID applications where each transaction encrypts 16–128 bytes, the counter provides over 17 million transactions before requiring re-keying at the maximum data rate.
3. Security Analysis and Implementation Guidance
OFB mode security relies critically on the uniqueness of IVs. If two messages are encrypted under the same (Key, IV) pair, the keystream is identical, and the ciphertexts can be XORed to cancel the keystream, revealing the XOR of the plaintexts. The standard addresses this by requiring that the reader generate IVs using either a monotonic counter or a hardware random number generator with at least 128 bits of entropy. Tags should store the last-used IV in non-volatile memory and reject any Authenticate command with a duplicate IV.
A subtle engineering trap in OFB mode is the keystream overlap problem in multi-reader environments. If two readers independently select the same IV for communication with different tags sharing the same key, the keystreams will be identical. An attacker within range of both readers can capture the two ciphertexts and perform the XOR attack. The standard recommends including a reader identifier in the IV to prevent inter-reader IV collisions.
Hardware implementation of AES OFB on a passive tag shares most of its datapath with the AES-128 core specified in 29167-10. The only additional logic required is a 128-bit register to hold the feedback state and a multiplexer to select between the IV (for initialization) and the previous output (for subsequent blocks). The total area overhead for OFB mode compared to standalone AES-128 encryption is approximately 150 GE (for the feedback register and control logic), making it a low-cost addition to an existing AES core.
OFB mode does not provide inherent message authentication — an attacker who knows the plaintext can modify the ciphertext to produce arbitrary plaintext changes after decryption. The standard mandates that OFB encryption be combined with a separate message authentication code (MAC), typically using the AES-CBC-MAC specified in 29167-10. Implementations that use AES OFB for encryption without a MAC are vulnerable to active bit-flipping attacks. Always implement the combined encrypt-then-MAC scheme specified in Annex C of the standard.
4. Frequently Asked Questions
Q: What is the practical difference between 29167-10 (AES CFB) and 29167-14 (AES OFB)?
The main difference is in the feedback mechanism. CFB feeds ciphertext back into the encryption engine, preventing pre-computation. OFB feeds the encryption output back, enabling full keystream pre-computation. For applications where latency is critical (e.g., high-speed sortation systems), OFB’s pre-computation advantage is decisive.
The main difference is in the feedback mechanism. CFB feeds ciphertext back into the encryption engine, preventing pre-computation. OFB feeds the encryption output back, enabling full keystream pre-computation. For applications where latency is critical (e.g., high-speed sortation systems), OFB’s pre-computation advantage is decisive.
Q: Can a single AES core support both CFB and OFB modes?
Yes. The AES encryption datapath is identical for both modes. Only the feedback path differs: CFB selects ciphertext as feedback, while OFB selects the encryption output. A single configuration register bit can switch between the two modes, allowing the tag to support both 29167-10 and 29167-14 with minimal area overhead.
Yes. The AES encryption datapath is identical for both modes. Only the feedback path differs: CFB selects ciphertext as feedback, while OFB selects the encryption output. A single configuration register bit can switch between the two modes, allowing the tag to support both 29167-10 and 29167-14 with minimal area overhead.
Q: How does IV management work in a large-scale deployment?
For a deployment with 10 million tags, each reader generates unique IVs per transaction. A 96-bit IV space (with 32-bit counter + 64-bit random component) provides 2^96 unique combinations — sufficient for the entire deployment lifetime without collision. The IV is transmitted in plaintext as part of the Authenticate command, so no encryption overhead is incurred for IV transmission.
For a deployment with 10 million tags, each reader generates unique IVs per transaction. A 96-bit IV space (with 32-bit counter + 64-bit random component) provides 2^96 unique combinations — sufficient for the entire deployment lifetime without collision. The IV is transmitted in plaintext as part of the Authenticate command, so no encryption overhead is incurred for IV transmission.
Q: Is AES-256 OFB supported by 29167-14?
Yes, as an optional variant. AES-256 uses a 256-bit key and 14 rounds (vs. AES-128’s 10 rounds). The area overhead is approximately 20% (additional key storage + modified key schedule), and the encryption time increases by 40% (14 vs. 10 rounds). The standard recommends AES-256 for applications protecting data with a lifespan exceeding 10 years.
Yes, as an optional variant. AES-256 uses a 256-bit key and 14 rounds (vs. AES-128’s 10 rounds). The area overhead is approximately 20% (additional key storage + modified key schedule), and the encryption time increases by 40% (14 vs. 10 rounds). The standard recommends AES-256 for applications protecting data with a lifespan exceeding 10 years.
