Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 15963-10:2015 — RFID Tag Authentication Protocol for Item-Level Security
A Technical Review of the International Standard for Cryptographic Authentication in Radio Frequency Identification Systems
The need for secure, verifiable identification of individual items in radio frequency identification (RFID) systems has driven the development of dedicated authentication protocols. IEC 15963-10:2015, part of the ISO/IEC 15963 series on unique identification for RF tags, defines a cryptographic protocol that enables a reader to authenticate an RFID tag at the item level without requiring an on‑board database connection. This article examines the standard’s scope, core technical requirements, practical implementation considerations, and compliance pathways.
Scope and Purpose
IEC 15963-10:2015 specifies a challenge‑response authentication protocol designed for passive and semi‑passive RFID tags that operate in the UHF and HF bands. It extends the basic tag‑identification capabilities of ISO/IEC 15963 and ISO/IEC 18000‑6C by adding a secure cryptographic layer that verifies the tag’s identity before critical operations such as reading user memory or writing data. The protocol is intended for applications where item‑level security is essential, including pharmaceutical supply chains, high‑value asset tracking, and access‑controlled environments.
The standard does not define the entire air interface; it relies on the underlying physical and link‑layer specifications of ISO/IEC 18000‑6 (UHF) or ISO/IEC 15693 (HF). Instead, it concentrates on the authentication message flow, cryptographic primitives, and memory organisation that enable a reader to confirm that a tag possesses a secret key. This separation allows the protocol to be implemented on a wide range of tag chips without altering the radio communication layer.
Technical Requirements
The protocol defined in IEC 15963-10:2015 is based on symmetric‑key cryptography, using AES‑128 as the mandatory block cipher. The authentication procedure follows a three‑pass challenge‑response model:
- The reader sends a GetChallenge command, which returns a random number (RT) generated by the tag’s on‑chip random‑number generator.
- The reader constructs an encrypted message using the shared secret key KS and sends a Authenticate command containing the reader challenge (RR) and an encrypted block.
- The tag decrypts the reader message, verifies a checksum, and returns an encrypted acknowledgment that includes the reader challenge for mutual authentication.
To ensure interoperability across tag implementations, the standard mandates fixed frame sizes and memory maps. The key technical parameters are summarised in the table below.
| Parameter | Specification |
|---|---|
| Block cipher | AES‑128 (FIPS 197) |
| Challenge length | 64 bits (reader) / 64 bits (tag) |
| Authentication frame length | 192 bits (including header and CRC) |
| Tag memory for cryptographic context | 64 bytes (key, counter, diversifier) |
| Maximum number of successive failed authentications | 3 (tag locks after third failure) |
| Supported operating modes | Reader‑only authentication, mutual authentication |
| Random‑number generator minimum entropy | ≥ 50 bits (NIST SP 800‑22 compliant) |
Important: The standard does not prescribe key management infrastructure. It only defines the on‑tag protocol. Key diversification, storage, and provisioning are outside its scope, though recommendations are given in an informative annex.
The protocol also defines a set of three new custom commands for the ISO/IEC 18000‑6C air interface: GetChallenge, Authenticate, and ReqRN_Ext. These commands are mapped to existing command codes (C3h, C4h, C5h) and use the same slot‑counting mechanism as the standard inventory round.
Implementation Highlights
Implementing IEC 15963-10:2015 requires careful attention to the tag’s memory architecture. The standard reserves the first 16 bytes of user memory for the authentication key store. System integrators should verify that the tag chipset supports at least 64 bytes of read/write user memory beyond the mandatory TID and EPC banks.
Tip: When selecting tags, prefer chips that implement hardware AES‑128 acceleration. Tags that rely on firmware‑only cryptography may exceed the timing constraints specified in the standard (max 20 ms for an authentication round‑trip).
Backward compatibility is a central concern. The standard explicitly allows tags to operate in a transparent mode where no authentication is required—a reader that does not support authentication should still be able to read the tag’s EPC. This is achieved by using a special flag in the ReqRN_Ext command; tags that detect an authentication‑capable reader will automatically shift to the secure mode after the first successful authentication.
Another critical implementation detail is the handling of lock‑down after repeated authentication failures. Once the tag’s failure counter reaches three, the tag will refuse to respond to any further commands except Kill or a power‑cycle reset. This behaviour prevents brute‑force attacks while still allowing recovery if a key is legitimately updated.
✅ Best practice: Use the standard’s built‑in key diversifier—a 16‑byte field stored in reserved memory—to produce distinct keys for different tag populations. This ensures that compromise of one tag’s key does not affect others that share the same original master key.
Compliance and Certification
Products claiming compliance with IEC 15963-10:2015 must undergo conformance testing that validates both the protocol message flow and the cryptographic integrity of the implementation. The compliance framework includes:
- Protocol conformance: Verification that the tag responds to the three custom commands in the correct sequence and within the specified time windows.
- Cryptographic tests: Known‑answer tests (KATs) for the AES‑128 engine, including encryption, decryption, and key expansion.
- Robustness tests: Noise injection, invalid command handling, and failure‑counter behaviour under erroneous conditions.
Independent testing laboratories accredited under the ISO/IEC 17025 framework are typically sought for certification. For tag chips, certification is often combined with that of the underlying air‑interface standard (e.g., ISO/IEC 18000‑63).
Compliance risk: If a tag’s random‑number generator does not meet the minimum entropy requirement, the authentication protocol becomes vulnerable to replay attacks. Always verify RNG quality with statistical testing before finalising a chip design.
Adopters should note that IEC 15963-10:2015 was published in 2015 and may have been superseded or amended by later editions (e.g., IEC 15963-10:2019). While the 2015 version remains widely deployed, new projects are encouraged to review the latest revision for updates to cryptographic agility and memory mapping.
Frequently Asked Questions
Q: How does IEC 15963-10:2015 differ from the base IEC 15963 standard?
A: IEC 15963:2009 and its amendments focus on the unique identifier (TID) and memory architecture for RF tags, but do not specify security protocols. IEC 15963-10:2015 adds a cryptographic layer that enables mutual authentication between the reader and the tag, ensuring that only authorised devices can access sensitive memory areas.
A: IEC 15963:2009 and its amendments focus on the unique identifier (TID) and memory architecture for RF tags, but do not specify security protocols. IEC 15963-10:2015 adds a cryptographic layer that enables mutual authentication between the reader and the tag, ensuring that only authorised devices can access sensitive memory areas.
Q: Is the authentication protocol of IEC 15963-10 backward compatible with existing ISO/IEC 18000‑6C readers?
A: Yes, with minor caveats. Standard readers that do not recognise the new commands (
A: Yes, with minor caveats. Standard readers that do not recognise the new commands (
GetChallenge, Authenticate, ReqRN_Ext) will fall back to the normal inventory mode; the tag’s EPC remains readable. To leverage the full authentication capability, the reader firmware must be updated to support the custom command set. Many commercial reader chips already support the required codes since 2016.Q: What are the key security threats addressed by this standard?
A: The primary threats are tag cloning (an attacker copies a tag’s memory to another tag) and unauthorised reading of user memory. By requiring a shared secret and a fresh random challenge per session, the protocol prevents replay attacks and ensures that only a reader in possession of the same key can authenticate the tag. The 3‑failure lock‑out further deters online guessing.
A: The primary threats are tag cloning (an attacker copies a tag’s memory to another tag) and unauthorised reading of user memory. By requiring a shared secret and a fresh random challenge per session, the protocol prevents replay attacks and ensures that only a reader in possession of the same key can authenticate the tag. The 3‑failure lock‑out further deters online guessing.
Q: Can the protocol be implemented on a battery‑assisted passive (BAP) tag?
A: Yes. The standard does not restrict the power source; BAP tags with hardware AES can complete the challenge‑response sequence as fast as passive tags. However, the timing limits (20 ms round‑trip) still apply, so a firmware‑based AES implementation may be challenging on high‑latency BAP platforms.
A: Yes. The standard does not restrict the power source; BAP tags with hardware AES can complete the challenge‑response sequence as fast as passive tags. However, the timing limits (20 ms round‑trip) still apply, so a firmware‑based AES implementation may be challenging on high‑latency BAP platforms.
This technical overview is based on the published edition of IEC 15963-10:2015 and subsequent interpretations valid as of 2026. Always consult the latest official standard for compliance requirements.