ISO/IEC FDIS 15693-3

ISO/IEC DISFDIS 15693-3:2025(en)
ISO/IEC TC JTC 1/SC 17/WG 8
Secretariat: BSI
Date: 2025-032026-01-20
Cards and security devices for personal identification — Contactless
vicinity objects —
Part 3:
Anticollision and transmission protocol
Cartes et dispositifs de sécurité pour l’identificationl'identification personnelle — Objets sans contact de
voisinage —
Partie 3: Anticollision et protocole de transmission
FDIS stage
© ISO/IEC 20252026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel.Phone: + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Symbols and abbreviated terms . 2
4 Definition of data elements . 3
4.1 UID . 3
4.2 AFI . 3
4.3 DSFID . 6
4.4 CRC . 6
4.5 Security framework . 7
5 VICC memory organization . 7
6 Block security status . 7
7 Overall protocol description . 8
7.1 Protocol concept . 8
7.2 Modes . 9
7.3 Request format . 10
7.4 Response format . 12
7.5 VICC states . 15
8 Anticollision . 18
8.1 General . 18
8.2 Request parameters . 19
8.3 Request processing by the VICC . 19
8.4 Explanation of an anticollision sequence . 22
9 Timing specifications . 25
9.1 General . 25
9.2 VICC waiting time before transmitting its response after reception of an EOF from the
VCD . 25
9.3 VICC modulation ignore time after reception of an EOF from the VCD . 25
9.4 VCD waiting time before sending a subsequent request . 26
9.5 VCD waiting time before switching to the next slot during an inventory process . 26
9.6 VICC waiting time before transmitting a response for Write alike commands. . 27
9.7 Security timeout as used in the CS . 27
9.8 VICC replies as used in CS or extended functionalities . 28
9.9 Waiting time extension reply . 30
10 Commands . 32
10.1 Command types . 32
10.2 Command codes . 33
10.3 Mandatory commands . 34
10.4 Optional commands . 35
10.5 Custom commands . 65
10.6 Proprietary commands . 65
11 Secured Communication . 66
11.1 General . 66
© ISO/IEC 2026 – All rights reserved
iii
11.2 AuthComm . 66
11.3 SecureComm . 67
Annex A (informative) VCD pseudo-code for anticollision . 69
Annex B (informative) Cyclic redundancy check (CRC) . 70
Annex C (informative) Examples of crypto command sequence . 74
Annex D (normative) List of legacy commands . 81
Bibliography . 82

© ISO/IEC 2026 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and security devices for personal identification.
This fourth edition cancels and replaces the third edition (ISO/IEC 15693-3:2019), which has been technically
revised.
The main changes are as follows:
— — extended IC manufacturer code.
A list of all parts in the ISO/IEC 15693 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2026 – All rights reserved
v
Introduction
The ISO/IEC 15693 series describes the parameters for identification cards as defined in ISO/IEC 7810 and
the use of such cards for international interchange.
This document describes the anticollision and transmission protocols.
This document does not preclude the incorporation of other standard technologies on the card.
Contactless card standardsInternational Standards cover a variety of types as embodied in the ISO/IEC 10536
series (close-coupled cards), the ISO/IEC 14443 series (proximity cards) and the ISO/IEC 15693 series
(vicinity cards). These are intended for operation when very near, nearby and at a longer distance from
associated coupling devices, respectively.
© ISO/IEC 2026 – All rights reserved
vi
Cards and security devices for personal identification — Contactless
vicinity objects — Part 3: Anticollision and transmission protocol
Part 3:
Anticollision and transmission protocol
1 Scope
This document specifies:
— — protocols and commands;
— — other parameters required to initialize communications between a vicinity integrated circuit card and
a vicinity coupling device;
— — methods to detect and communicate with one card among several cards ("anticollision");
— — optional means to ease and speed up the selection of one among several cards based on application
criteria.
This document does not preclude the addition of other existing card standards on the VICC, such as
ISO/IEC 7816-6 or others listed in this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7816--6:2023, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements
for interchange
ISO/IEC 13239, Information technology — Telecommunications and information exchange between systems —
High-level data link control (HDLC) procedures
ISO/IEC 15418, Information technology — Automatic identification and data capture techniques — GS1
Application Identifiers and ASC MH10 Data Identifiers and maintenance
ISO/IEC 15693--1, Cards and security devices for personal identification — Contactless vicinity objects — Part
1: Physical characteristics
ISO/IEC 15693--2, Cards and security devices for personal identification — Contactless vicinity objects — Part
2: Air interface and initialization
ISO/IEC 29167 (all parts), Information technology — Automatic identification and data capture techniques
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 15693--1, ISO/IEC 15693--2
and the following apply.
© ISO/IEC 2026 – All rights reserved
ISO and IEC maintain terminologicalterminology databases for use in standardization at the following
addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
3.1.1 3.1.1
anticollision loop
algorithm used to prepare for and handle a dialogue between a vicinity coupling device and one or more
vicinity integrated circuit cards from several in its energizing field
3.1.2 3.1.2
byte
string that consists of 8 bits of data designated b1 to b8, from the most significant bit (MSB, b8) to the least
significant bit (LSB, b1)
3.1.3 3.1.3
payload
part of the message data which conveys information relating to the use of the security commands defined in
this document
Note 1 to entry: The message data is defined in the ISO/IEC 29167 series.
3.1.4 3.1.4
ResponseBuffer
VICCvicinity integrated circuit card memory area where the result of a cryptographic operation is stored
which mayand can be retrieved using a ReadBuffer command
3.1.5 3.1.5
Write alike
command or request resulting in a non-volatile change to the contents of the vicinity integrated circuit card
memory
3.2 Symbols and abbreviated terms
f frequency of operating field (carrier frequency)
c
AFI application family identifier
CRC cyclic redundancy check
CS Cryptographic Suite
CSI Cryptographic Suite Identifier
DSFID data storage format identifier
EOF end of frame
IC_Mfg IC manufacturer code defined in ISO/IEC 7816-6
LSB least significant bit
LSByte least significant byte
MSB most significant bit
MSByte most significant byte
RFU reserved for future use
© ISO/IEC 2026 – All rights reserved
SOF start of frame
UID unique identifier
VCD vicinity coupling device
VICC vicinity integrated circuit card
4 Definition of data elements
4.1 UID
The VICCs are uniquely identified by a 64 bits UID. This is used for addressing each VICC uniquely and
individually, during the anticollision loop and for one-to-one exchange between a VCD and a VICC.
The UID shall be set permanently by the IC manufacturer in accordance with Table 1Table 1.
Table 1 — UID format
MSB LSB
64 57 56 N+1 N 1
'E0' IC_Mfg IC manufacturer serial number
The UID comprises:
— — the MSByte (bits 64 – 57) which shall be 'E0';
— — the IC_Mfg (bits 56 – ‘N+1’) which shall be the identifier as specified in ISO/IEC 7816-6:2023, 7.2,
where N = 56 – L, and L is length in bits of IC_Mfg;
— — a unique serial number (bits N – 1) assigned by the IC manufacturer.
4.2 AFI
The AFI represents the type of application targeted by the VCD and is used to extract from all the VICCs present
only the VICCs meeting the required application criteria.
It may be programmed and locked by the respective commands.
The AFI is coded on one byte, which constitutes 2 nibbles of 4 bits each.
The most significant nibble of the AFI is used to code one specific or all application families, as defined in
Table 2Table 2.
The least significant nibble of the AFI is used to code one specific or all application sub-families. Sub-family
codes different from 0 are proprietary.
Table 2 — AFI coding
AFI most AFI least
Meaning
significant significant Examples/comments
VICCs respond from
nibble nibble
‘0’ ‘0’ All families and subfamilies No applicative preselection
X '0' All sub-families of family X Wide applicative preselection
© ISO/IEC 2026 – All rights reserved
AFI most AFI least
Meaning
significant significant Examples/comments
VICCs respond from
nibble nibble
th
X Y Only the Y sub-family of family X
‘0’ Y Proprietary sub-family Y only
‘1' ‘0’, Y Transport Mass transit, bus, airline
'2' ‘0’, Y Financial IEP, banking, retail
'3' ‘0’, Y Identification Access control
'4' ‘0’, Y Telecommunication Public telephony, GSM
‘5’ ‘0’, Y Medical
'6' ‘0’, Y Multimedia Internet services
'7' ‘0’, Y Gaming
'8' ‘0’, Y Data storage Portable files
'9' ‘0’, Y EAN-UCC system for Application
Identifiers
'A' ‘0’, Y Data Identifiers as defined in
ISO/IEC 15418
'B' ‘0’, Y UPU (Universal Postal Union)
'C' ‘0’, Y IATA (International Air Transport
Association)
'D' ‘0’, Y RFU
'E' ‘0’, Y RFU
‘F’ ‘0’, Y RFU
NOTE X = ‘1’ to ‘F’, Y = ‘1’ to ‘F’.
The support of the AFI by the VICC is optional.
If the AFI is not supported by the VICC and if the AFI_flag is set, the VICC shall not answer whatever the AFI
value is in the request.
If the AFI is supported by the VICC, it shall answer according to the matching rules described in
Table 2Table 2.
Figure 1Figure 1 shows the VICC decision tree for the AFI.
© ISO/IEC 2026 – All rights reserved
© ISO/IEC 2026 – All rights reserved
NOTE "Answer" means that the VICC answers to the Inventory request.
Figure 1 — VICC decision tree for the AFI
4.3 DSFID
The DSFID indicates how the data is structured in the VICC memory.
It may be programmed and locked by the respective commands. It is coded on one byte. It allows for instant
knowledge on the logical organisation of the data.
If its programming is not supported by the VICC, the VICC shall respond with the value zero ('00').
4.4 CRC
The CRC shall be calculated in accordance with ISO/IEC 13239.
The initial register content shall be all ones: 'FFFF'.
For examples, refer to Annex BAnnex B.
The two bytes CRC are appended to each request and each response, within each frame, before the EOF. The
CRC is calculated on all the bytes after the SOF up to but not including the CRC field.
© ISO/IEC 2026 – All rights reserved
Upon reception of a request from the VCD, the VICC shall verify that the CRC value is valid. If it is invalid, it
shall discard the frame and shall not answer (modulate).
Upon reception of a response from the VICC, it is recommended that the VCD verifies that the CRC value is
valid. If it is invalid, actions to be performed are left to the responsibility of the VCD designer.
The CRC is transmitted least significant byte first (see Table 3Table 3).).
Each byte is transmitted least significant bit first.
Table 3 — CRC bits and bytes transmission rules
LSByte MSByte
LSB MSB LSB MSB
CRC 16 (8 bits) CRC 16 (8 bits)
↑ first transmitted bit of the CRC
NOTE The probability that CRC 16 detects an error depends on the frame length and bit error rate. With a bit error
rate of 1E-4 the maximum frame length is less than 512 bytes.
4.5 Security framework
The security framework provides an interface to the crypto suites defined in the ISO/IEC 29167 series. Crypto
suites are identified by an 8-bit CSI defined in ISO/IEC 29167-1.
The security framework includes optional security features such as VICC or VCD Authentication, Mutual
Authentication, key update or secure messaging.
5 VICC memory organization
The commands specified in this document assume that the physical memory is organized in blocks (or pages)
of fixed size.
— — Up to 65 536 blocks can be addressed.
— — The block size can be of up to 256 bits.
— — This leads to a maximum memory capacity of up to 2 MBytes (16 MBits).
The commands described in this document allow the access (read and write) by block(s). There is no implicit
or explicit restriction regarding other access method, e.g. by byte or by logical object in future revision(s) of
this document or in custom commands.
6 Block security status
The block security status is sent back by the VICC as a parameter in the response to a VCD request as specified
in Clause 10Clause 10 (e.g. Read single block). It is currently coded on one byte but may be coded in 2, 4 and
8 as defined in future revisions of this document (see Table 4Table 4).).
It is an element of the protocol. There is no implicit or explicit assumption that the 8 bits are actually
implemented in the physical memory structure of the VICC.
© ISO/IEC 2026 – All rights reserved
Table 4 — Block security status
Bit Flag name Value Description
0 Not locked
b1 Lock_flag
1 Locked
b2 to b5 Proprietary X Not defined in this document
Unless otherwise specified in future
revisions of this document
b6
See warning for legacy commands listed
in Annex DAnnex D.
Unless otherwise specified in future
revisions of this document
b7
See warning for legacy commands listed
in Annex DAnnex D.
Unless otherwise specified in future
revisions of this document
b8
See warning for legacy commands listed
in Annex DAnnex D.
Only present if specified in future
revisions of this document and the
b9 to b16  RFU
block security status length_flag is set to
(0,1)b
Only present if specified in future
revisions of this document and the
b9 to b32  RFU
block security status length_flag is set to
(1, 0)b
Only present if specified in future
revisions of this document and the
b9 to b64  RFU
block security status length_flag is set to
(1, 1)b
7 Overall protocol description
7.1 Protocol concept
The transmission protocol (or protocol) defines the mechanism to exchange instructions and data between
the VCD and the VICC, in both directions.
It is based on the concept of "VCD talks first".
This means that any VICC shall not start transmitting (i.e. modulating according to ISO/IEC 15693-2) unless it
has received and properly decoded an instruction sent by the VCD.
a) a) The protocol is based on an exchange of:
— — a request from the VCD to the VICC;
— — a response from the VICC(s) to the VCD.
The conditions under which the VICC sends a response are defined in Clause 10Clause 10.
© ISO/IEC 2026 – All rights reserved
b) b) Each request and each response are contained in a frame. The frame delimiters (SOF, EOF)
shall be implemented as specified in ISO/IEC 15693-2. The maximum frame length is 8 192 bytes.
c) c) Each request consists of the following fields:
— — flags;
— — command code;
— — mandatory and optional parameters fields, depending on the command;
— — application data fields;
— — CRC.
d) d) Each response consists of the following fields:
— — flags;
— — mandatory and optional parameters fields, depending on the command;
— — application data fields;
— — CRC.
e) e) The protocol is bit-oriented. The number of bits transmitted in a frame is a multiple of eight
(8), i.e. an integer number of bytes.
f) f) A single-byte field is transmitted LSB first.
g) g) A multiple-byte field is transmitted LSByte first, each byte is transmitted LSB first.
h) h) The setting of the flags indicates the presence of the optional fields. When the flag is set (to
one), the field is present. When the flag is reset (to zero), the field is absent.
i) i) RFU flags shall be set to zero (0).
VICC or VCD receiving RFU bits set incorrectly shall disregard the command or response except for commands
listed in Annex DAnnex D. The VICC may respond with an error code.
7.2 Modes
7.2.1 General
The term mode refers to the mechanism to specify in a request the set of VICCs that shall answer to the request.
7.2.2 Addressed mode
When the Address_flag is set to 1 (Addressed mode), the request shall contain the UID of the addressed VICC.
Any VICC receiving a request with the Address_flag set to 1 shall compare the received unique ID (address) to
its own ID.
If it matches, it shall execute it (if possible) and return a response to the VCD as specified by the command
description.
© ISO/IEC 2026 – All rights reserved
If it does not match, it shall remain silent.
7.2.3 Non-addressed mode
When the Address_flag is set to 0 (Non-addressed mode), the request shall not contain a unique ID.
Any VICC receiving a request with the Address_flag set to 0 shall execute it (if possible) and shall return a
response to the VCD as specified by the command description.
7.2.4 Select mode
When the Select_flag is set to 1 (Select mode), the request shall not contain a VICC unique ID.
The VICC in the Selected state or Selected Secure state receiving a request with the Select_flag set to 1 shall
execute it (if possible) and shall return a response to the VCD as specified by the command description.
Only the VICC in the Selected state or Selected Secure state shall answer to a request having the Select flag set
to 1.
7.3 Request format
7.3.1 General
The request consists of the following fields (see Figure 2Figure 2):):
— — flags;
— — command code (see Clause 10Clause 10););
— — parameters and data fields;
— — CRC (see 4.44.4).).
Figure 2 — General request format
7.3.2 Request flags
In a request, the field "flags" specifies the actions to be performed by the VICC and whether corresponding
fields are present or not. Table 5Table 5 to Table 7Table 7 show the Request flags definition.
It consists of eight bits.
Table 5 — Request flags 1 to 4 definition
Bit Flag name Value Description
0 A single sub-carrier frequency shall be used by the VICC.
b1 Sub-carrier_flag
1 Two sub-carriers shall be used by the VICC.
© ISO/IEC 2026 – All rights reserved
Bit Flag name Value Description
Low data rate shall be used unless specified otherwise in the
definition of the command.
b2 Data_rate_flag
High data rate shall be used unless specified otherwise in the
definition of the command.
0 The meaning for flags 5 to 8 is according to Table 6Table 6.
b3 Inventory_flag
1 The meaning for flags 5 to 8 is according to Table 7Table 7.
0 No protocol format extension.
Protocol format is extended.
Protocol — — See warning for legacy commands listed in
b4
Extension_flag Annex DAnnex D.;
— — Reserved for future use for all other commands.
NOTE 1 Sub-carrier_flag refers to the VICC-to-VCD communication as specified in ISO/IEC 15693-2.
NOTE 2 Data_rate_flag refers to the VICC-to-VCD communication as specified in ISO/IEC 15693-2.
Table 6 — Request flags 5 to 8 definition when Inventory_flag is not set
Bit Flag name Value Description
The request shall be executed by any VICC according to the setting
of Address_flag.
b5 Select_flag
The request shall be executed only by the VICC in Selected state. The
1 Address_flag shall be set to 0 and the UID field shall not be included
in the request.
The request is not addressed. The UID field is not included. It shall
be executed by any VICC.
b6 Address_flag
The request is addressed. The UID field is included. It shall be
1 executed only by the VICC whose UID matches the UID specified in
the request.
The meaning is defined by the command description. It shall be set
to 0 if not otherwise defined by the command.
b7 Option_flag
1 The meaning is defined by the command description.
0 Unless otherwise specified in the command definition.
b8
1 See warning for legacy commands listed in Annex DAnnex D.
Table 7 — Request flags 5 to 8 definition when Inventory_flag is set
Bit Flag name Value Description
0 AFI field is not present.
b5 AFI_flag
1 AFI field is present.
0 16 slots.
b6 Nb_slots_flag
1 1 slot.
The meaning is defined by the command description. It shall be set
to 0 if not otherwise defined by the command.
b7 Option_flag
1 The meaning is defined by the command description.
b8  0 Unless otherwise specified in the command definition.
© ISO/IEC 2026 – All rights reserved
Bit Flag name Value Description
1 See warning for legacy commands listed in Annex DAnnex D.
7.4 Response format
7.4.1 General
The response consists of the following fields (see Figure 3Figure 3):):
— — flags;
— — one or more parameter fields;
— — data;
— — CRC (see 4.44.4).).
Figure 3 — General response format
7.4.2 Response flags
The eight bit response flags field indicates how actions have been performed by the VICC and whether
corresponding fields are present or not. Table 8Table 8 shows the Response flags definition.
Where the value "1b" for bits b2 to b8 may be used see warning for the legacy commands listed in
Annex DAnnex D.
Table 8 — Response flags 1 to 8 definition
Bit Flag name Value Description
0 No error.
b1 Error_flag
1 Error detected. Error code is in the "Error" field.
In any response if the ResponseBuffer does not contain a valid result of a
(cryptographic) calculation or if the ResponseBuffer is not supported.
ResponseBuffer
b2
Validity_flag
In any response if the ResponseBuffer contains a valid result of a
(cryptographic) calculation.
In the Final response of an In-process reply if this reply does not contain
the result of a (cryptographic) calculation.
b3 Final response_flag
In the Final response of an In-process reply if this reply contains the result
of a (cryptographic) calculation.
0 No protocol format extension.
b4 Extension_flag
1 Protocol format is extended. Reserved for future use.
b5 b6 Block security status Length
b5
Block security
status length_flag
b6
0 0 1 byte
© ISO/IEC 2026 – All rights reserved
Bit Flag name Value Description
0 1 2 bytes
These values shall not be used unless the
content of the additional bytes of the block
1 0 4 bytes
security status is defined in future
revisions of this document.
1 1 8 bytes
Waiting time 0 No Waiting time extension request.
b7 extension
Waiting time extension request.
request_flag
b8 RFU 0
The ResponseBuffer Validity_flag shall be set or reset as specified in the command description.
For each of the following commands, block security status b5 and b6 in Table 8Table 8 shall be set to zero
(1 byte).
— — Read single block with option flag = 1
— — Read multiple blocks with option flag = 1
— — Extended Read single block with option flag = 1
— — Extended Read multiple blocks with option flag = 1
— — Get multiple block security status
— — Extended get multiple block security status
7.4.3 Response error code
When the Error_flag is set by the VICC, the error code field shall be included and provides information about
the error that occurred. Error codes are defined in Table 9Table 9.
If the VICC does not support specific error code(s) listed in Table 9Table 9,, it shall answer with the error code
'0F' ("Error with no information given").
Table 9 — Response error code definition
Error code Meaning
'01' The command is not supported, i.e. the request code is not recognized.
'02' The command is not recognized, for example, a format error occurred.
'03' The command option is not supported.
'04' The command cannot be processed in time.
'0F' Error with no information given or a specific error code is not supported.
'10' The specified block is not available (doesn’t exist).
'11' The specified block is already locked and thus cannot be locked again.
'12' The specified block is locked and its content cannot be changed.
'13' The specified block was not successfully programmed.
'14' The specified block was not successfully locked.
'15' The specified block is protected.
© ISO/IEC 2026 – All rights reserved
Error code Meaning
'40' Generic cryptographic error.
'A0' – 'DF' Custom command error codes.
all others RFU.
7.4.4 In-process reply response formats
7.4.4.1 Barker field
The Barker field contains the Done flag and a Barker code.
7.4.4.2 Barker code
The Barker code is included to facilitate the synchronisation between the VCD and the VICC. It is a fixed 7-bit
value as defined in Table 10Table 10.
Table 10 — Barker field
b8 b7 b6 b5 b4 b3 b2 b1
X 0 1 0 0 1 1 1
Done
Barker code
flag
7.4.4.3 Done flag
The Done flag indicates whether the VICC is still processing a command. Done flag = 0 means the VICC is still
processing a command; Done flag = 1 means that the VICC has finished the command processing.
7.4.4.4 Barker response
If no error occurs and the Done flag is set to 0, the Barker response contains the fields defined in
Table 11Table 11.
Table 11 — Barker response
Barker
SOF Flags CRC16 EOF
field
8 bits 8 bits 16 bits
If an error occurs, the response contains the error code and is the Final response (see Table 13Table 13).).
7.4.4.5 Final response
If no error occurs and the Done flag is set to 1, the Final response contains the fields defined in
Table 12Table 12.
Table 12 — Final response
Barker
SOF Flags Data CRC16 EOF
field
8 bits 8 bits multiple of 8 bits 16 bits
© ISO/IEC 2026 – All rights reserved
The Data field shall be padded with least significant 0 bits as required to a minimum multiple of 8 bits or not
be present.
If an error occurs, the Final response contains the fields defined in Table 13Table 13.
Table 13 — Final response if error flag is set
Error
SOF Flags CRC16 EOF
code
8 bits 8 bits 16 bits
7.4.4.6 Initial response
If no error occurs and the Done flag is set to 0, the Initial response contains the fields defined in
Table 14Table 14.
Table 14 — Initial response
Barker
SOF Flags Data CRC16 EOF
field
8 bits 8 bits 16 bits 16 bits
The Done flag is set to 0. The Data field contains the timing information. Timing information is coded as a
binary integer multiple of 4 096/f (302 µs), a value of 0 indicates that the feature is not supported.
c
If an error occurs, the response contains the error code and is the Final response (see Table 13Table 13).).
7.4.5 Waiting time extension request formats
If no error occurs, the VICC Waiting time extension request contains the fields defined in Table 15Table 15.
Table 15 — Waiting time extension request
SOF Flags Data CRC16 EOF
8 bits 16 bits 16 bits
The Waiting time extension request_flag shall be set to 1.
The Data field contains the Waiting time extension delay information. Waiting time extension delay is coded
(302 µs).
as a binary integer multiple of 4 096/f
c
If an error occurs, the response shall use the format described in the command description.
7.5 VICC states
7.5.1 General
A VICC can be in one of the 5 following states:
— — Power-off;
— — Ready;
— — Quiet;
© ISO/IEC 2026 – All rights reserved
— — Selected;
— — Selected Secure.
The transition between these states is specified in Figure 4Figure 4.
The support of the Power-off, Ready and Quiet states is mandatory.
The support of the Selected and Selected Secure states is optional as represented with a dotted line in
Figure 4Figure 4.
The VICC state transition diagram shows only valid transitions. In all other cases the current VICC state
remains unchanged. When the VICC cannot process a VCD request (e.g. CRC error, etc.), it shall stay in its
current state.
The intention of the state transition method is that only one VICC should be in the Selected or Selected Secure
state at a time.
NOTE The case where one VICC is in a Selected state and another is in a Selected Secure state can happen if a first
VICC is selected, and a second VICC moves in the Selected Secure state when the VCD does a VCD or Mutual
Authentication. Only the VCD can prevent this situation to occur by deselecting the first VICC before doing the VCD or
Mutual Authentication with the second one.
7.5.2 Power-off state
The VICC is in the Power-off state when it cannot be activated by the VCD.
7.5.3 Ready state
The VICC is in the Ready state when it is activated by the VCD. It shall process any request unless otherwise
specified in the command definition where the Select_flag is not set.
In a Ready state, a VCD can perform a VICC Authentication by a successful Challenge, ReadBuffer or
Authenticate command sequence. After a VICC Authentication, the VICC remains in the Ready state.
For a transition from the Ready state to the Selected Secure state, perform a VCD Authentication or Mutual
Authentication in Addressed mode containing the correct UID as specified by the crypto suites.
See Annex CAnnex C for additional information on crypto command sequence.
7.5.4 Quiet state
When in the Quiet state, the VICC shall process any request unless otherwise specified in the command
definition where the Inventory_flag is not set and where the Address_flag is set.
For a transition from the Quiet state to the Selected Secure state, perform a VCD Authentication or Mutual
Authentication in Addressed mode containing the correct UID as specified in the crypto suites.
7.5.5 Selected state
The VICC in the Selected state shall process any request unless otherwise specified in the command definition
where the Select_flag is set.
For a transition from the Selected state to the Ready state, a VCD shall perform:
— — Reset to Ready command with the Select_flag set;
© ISO/IEC 2026 – All rights reserved
— — Select command with different VICC UID.
For a transition from the Selected state to the Quiet state, a VCD shall perform a Stay quiet command with the
correct UID number.
For a transition from the Selected state to the Selected Secure state, perform a VCD Authentication or Mutual
Authentication as specified by the crypto suites with the Select_flag set.
7.5.6 Selected Secure state
A VICC may execute any optional commands and the mandatory Stay quiet command. All commands shall be
executed with the Select_flag set except the Stay quiet or Select commands which shall be executed in
Addressed mode.
For a transition from the Selected Secure state to the Ready state, a VCD shall perform:
— — Reset to Ready command with the Select_flag set;
— — Challenge command;
— — any Authenticate command starting a new authentication process;
— — Select command with different VICC UID.
In addition the VICC shall return to the Ready state in case of cryptographic errors as specified in the crypto
suites.
For a transition from the Selected Secure state to the Quiet state, a VCD shall perform a Stay quiet command
with the correct UID number.
For a transition from the Selected Secure state to the Selected state, the VCD shall perform a Select command
in Addressed mode containing the correct UID.
© ISO/IEC 2026 – All rights reserved
Figure 4 — VICC state transition diagram
8 Anticollision
8.1 General
The purpose of the anticollision sequence is to make an inventory of the VICCs present in the VCD field by their
UID.
© ISO/IEC 2026 – All rights reserved
The VCD is the master of the communication with one or multiple VICCs. It initiates card communication by
issuing the Inventory request. See Annex AAnnex A for additional information about how the anticollision
could be implemented on the VCD.
The VICC shall send its response in the slot determined or shall not respond, according to the algorithm
described in 8.38.3.
8.2 Request parameters
When issuing the Inventory command, the VCD shall set the Nb_slots_flag to the desired setting and add after
the command field the mask length and the mask value defined in Table 16Table 16.
The mask length indicates the number of significant bits of the mask value. It can have any value between 0
and 60 when 16 slots are used and any value between 0 and 64 when 1 slot is used. LSB shall be transmitted
first.
The mask value is contained in an integer number of bytes. LSB shall be transmitted first.
If the mask length is not a multiple of 8 (bits), the mask value MSB shall be padded with the required number
of null (set to 0) bits so that the mask value is contained in an integer number of bytes.
The next field starts on the next byte boundary.
Table 16 — Inventory request format
Mask
SOF Flags Command Mask value CRC16 EOF
length
8 bits 8 bits 8 bits 0 to 8 bytes 16 bits
Table 17 — Example of the padding of the mask
MSB LSB
0000 0100 1100 1111
Pad Mask value
...