PCI Watch

Tracking changes across the Payment Card Industry

EMV® Contactless Card Level 1 Type Approval PICC Digital Test Cases

v3.0b Test Cases & Test Environments
ContactlessMobile NFC Consumer Device

EMV<sup>®</sup> Contactless Card Level 1 Type Approval PICC Digital Test Cases Version 3.0b December 2020

v3.0b Page i

Legal Notice

This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document.

v3.0b

Revision Log – Version 3.0b The following changes have been made to the document since the publication of Version 3.0a. Some of the numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. The numbering of existing requirements did not change, unless explicitly stated otherwise. Test coverage, test clarification, editorial correction:

  • In CC206.xy
  • Update of two execution conditions (xy=13 and xy=15) to clarify that an S Block can be either a S-DESELECT or a S(WTX) Block frame. v3.0b Contents 1. 1.1. 1.2. 1.3. 1.3.1. 1.3.2. 1.4. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 2.10. 2.11. 2.12. 2.13. 2.14. 3. 3.1. 3.2. 3.3. 3.4. Basic Type A Exchange with the minimum and longer Frame Delay Times PCD→PICC (UID size = 1) [CA010. 3.5. Basic Type A Exchange with the minimum and longer Frame Delay Times PCD→PICC (UID size = 2) [CA011. 3.6. Basic Type A Exchange with the minimum and longer Frame Delay Times PCD→PICC (UID size = 3) [CA012. 3.7. 3.8. 3.9. 3.10. Type A Handling of RATS (UID size = 1) [CA120.x] 3.11. Type A Handling of RATS (UID size = 2) [CA121.x] 3.12. Type A Handling of RATS (UID size = 3) [CA122.x] 3.13. Type A Consecutive Installations (UID size = 1, fixed UID) [CA126. v3.0b 3.14. Type A Consecutive Installations (UID size = 2) [CA127.x] 3.15. Type A Consecutive Installations (UID size = 3) [CA128.x] 3.16. Type A Handling of the REQA Command (UID size = 1) [CA130. 3.17. Type A Handling of the REQA Command (UID size = 2) [CA131. 3.18. Type A Handling of the REQA Command (UID size = 3) [CA132. 3.19. Type A Installation with error in the IDLE state [CA204. 3.20. Type A Installation with error in the READY state [CA206. 3.21. Type A Installation with error in the READY’ state (UID size = 2 or 3) [CA207. 3.22. Type A Installation with error in the READY’’ state (UID size = 3) [CA208. 3.23. Type A Installation with error in the ACTIVE state (UID size = 1) [CA216. 3.24. Type A Installation with error in the ACTIVE state (UID size = 2) [CA217. 3.25. Type A Installation with error in the ACTIVE state (UID size = 3) [CA218. 3.26. 3.27. 3.28. 3.29. 3.30. 3.31. 3.32. Type A Installation with polling and with PICC Reset [CA233. 4. 4.1. 4.2. Basic Type B Exchange with the minimum and longer Frame Delay Times PCD→PICC [CB010. 4.3. Basic Type B Exchange with the minimum supported SFGT PCD→PICC [CB015.x] 4.4. Basic Type B Exchange with the minimum and the maximum values of EGTPCD [CB021.x] 4.5. Basic Type B Exchange with minimum and maximum durations of (SoS) and (EoS) [CB025.x] 4.6. 4.7. Type B Consecutive Installations (fixed PUPI) [CB126. 4.8. Type B Handling of the REQB Command [CB130. 4.9. 4.10. Type B Correct Installation with RFU values or values to be ignored [CB155.x] 4.11. Type B Installation with error in the IDLE state [CB204. 4.12. Type B Installation with error in the READY state [CB206. v3.0b Page v 4.13. Type B Installation with error in the HALT state following the READY state [CB226.x] 4.14. Type B Installation with error in the HALT state following the ACTIVE State [CB227.x] 4.15. Type B Installation with WUPA command in the HALT state [CB228. 4.16. Type B Installation with polling and with PICC Reset [CB233. 5. 5.1. Support of the EMV CL Polling [CC001.x] 5.2. Reception of chained I-Blocks from the PCD [CC110. 5.3. Emission of APDUs with different FSDI values [CC120. 5.4. Error notification on an I-Block not indicating chaining [CC203. 5.5. Error after reception of a non-chained I-Block [CC206. 5.6. 5.7. Error notification and error after reception of a chained I-Block [CC210. 5.8. Block Protocol with PICC Reset [CC233. 5.9. Installation commands during Block Protocol [CC241. 5.10. Error at the beginning of the Block Protocol [CC245. v3.0b v3.0b S Scenario 57: Type B Correct Installation with respect of the anticollision state machine... Scenario 62: Type B Correct Installation with RFU values (x=0 to 2 and 7 to 8). v3.0b v3.0b v3.0b /211 1. About this Document 1.1.

Introduction

The present document describes the detailed organization and requirements of the executable tests the vendors has to comply with, to allow the digital part of the Contactless Terminal Level 1 Type Approval Testing. The intended audience of this document includes test tool vendors, accredited test laboratories and auditors. Describing the executable tests and the associated procedures is necessary to ensure reproducibility of the test results, even across different test laboratories. 1.2.

Scope

For each individual executable test in this document, the following information is available:

  • The test number,
  • The objective of the test,
  • The related reference specification section(s) of the Test Case,
  • The procedure of the test,
  • The acceptance criteria(s),
  • The pre- and post-processing to be performed on a specific PICC (Conditional),
  • The scenario of the test presented as a flow chart. 1.3. Reference Documents EMV documents are available on the EMVCo web site: http://www.emvco.com/approvals.aspx and http://www.emvco.com/specifications.aspx 1.3.1. Specification Documents Document EMV<sup>®</sup> Level 1 Specifications for Payment Systems ― EMV Contactless Interface Specification EMV<sup>®</sup> SB No. 212 Timing Requirements for Time-out Handling EMV<sup>®</sup> SB No. 215 Polling Collision Indication EMV<sup>®</sup> SB No. 232 Type B Minimum Modulation Index EMV<sup>®</sup> SB No. 233 Update to Polling Collision Indication (SB215) Version Issue date 3.0, February 2018 First Edition December 2018 First Edition, March 2019 First Edition, December 2019 First Edition, December 2019 v3.0b Document EMV<sup>®</sup> SB No. 235 Contactless – EMD Immunity for Type A EoS EMV<sup>®</sup> SB No. 245 Contactless – IQ Modulation Table 1: Specification Documents /211 Version Issue date First Edition, March 2020 First Edition, May 2020 v3.0b /211 1.3.2. Other Reference Documents Document ISO/IEC 14443-2 – Contactless ICCs – Radio frequency power and signal interface" + Amendment 1 "Bit rates of fc/64, fc/32 and fc/16" – 2005. "ISO/IEC 14443-3 – Contactless ICCs – Initialization and anticollision" + Amendment 1 "Bit rates of fc/64, fc/32 and fc/16" – 2005. + Amendment 3 "Handling of reserved fields and values" – 2006. "ISO/IEC 14443-4 – Contactless ICCs – Transmission protocol" + Amendment 1 "Handling of reserved fields and values" – 2006. "ISO/IEC 10373-6 – Identification cards – Test methods – Proximity cards" + FPD Amendments 1.2 "Additional PICC test methods" – 2001. + FPD Amendments 3 "Protocol test methods for proximity coupling devices" – 2001. "ISO/IEC 9646-1 – Open Systems Interconnection – Conformance Systems methodology and framework – Part 1: General concepts" "ISO/IEC 9646-2 – Open Systems Interconnection – Conformance Systems methodology and framework – Part 2: Abstract test suite specification" "ISO/IEC 9646-3 – Open Systems Interconnection – Conformance Systems methodology and framework – Part 3: The Tree and Tabular Combined Notation (TTCN)" "ISO/IEC 9646-4 – Open Systems Interconnection – Conformance Systems methodology and framework – Part 4: Test realization" "ISO/IEC 7816-4 – Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange" NFC Forum, NFC Digital Protocol, Technical Specification NFC Forum, NFC Analog Specification, Technical Specification Table 2: Other Reference Documents Version Issue date 1st edition, 2001 1st edition, 2001 1st edition, 2001 1st edition, 2001 2nd edition, 1994 2nd edition, 1994 2nd edition, 1998 2nd edition, 1994 2nd edition, 2005 1.0, 2010-11-17 1.0, 2012-07-11 v3.0b /211 1.4. Acronyms and Abbreviations The following abbreviations and notations are used in this document: Abbreviation AC ACK ADC AFI ASK ATQA ATQB ATS ATTRIB BCC b.n BPSK C-APDU CID CLn CT CRC_A CRC_B CUT EDC EGT EOF EoS etu EMD FDT fc FO fs FSC FSCI

Description

AntiCollision Positive ACKnowledgement Application Data Coding, Type B Application Family Identifier, Type B Amplitude Shift Keying

Answer

To reQuest, Type A Answer To reQuest, Type B Answer To Select, Type A Selection command, Type B Check byte, Type A Block Number Binary Phase Shift Keying Command Application Protocol Data Unit Card IDentifier Cascade Level n, Type A Cascade Tag, Type A Cyclic Redundancy Check error detection code for Type A Cyclic Redundancy Check error detection code for Type B Card Under Test. When the Instance Under Test as defined in ISO 9646 is a EMVCo Proximity IC Card Error Detection Code Extra Guard Time, Type B End Of Frame End of Sequence Elementary time unit Electro Magnetic Disturbance Frame Delay Time Carrier frequency Frame Option, Type B Subcarrier frequency Frame Size for proximity Card Frame Size for proximity Card Integer

v3.0b

/211 Abbreviation FSD FSDI FWI FWT HLTA HLTB ICS IEC INF ISO LSB LT MBL MBLI MSB NAD NAK NRZ-L PCB PCD PICC PPSE PUPI RATS R-APDU REQA REQB RF RFU SAK SEL SOF SoS Tnn Description Frame Size for proximity coupling Device Frame Size for proximity coupling Device Integer Frame Waiting time Integer Frame Waiting Time Halt Command, Type A Halt Command, Type B Implementation Conformance Statement International Electronical Commission INFormation field International Organization for Standardization Least Significant Bit Lower Tester Maximum Buffer Length Maximum Buffer Length Integer Most Significant Bit Node ADdress Negative Acknowledgment Non-Return to Zero, (L for Level) Protocol Control Byte Proximity Coupling Device (reader) Proximity IC Card Proximity Payment System Environment Pseudo-Unique PICC Identifier, Type B Request for Answer To Select Response Application Protocol Data Unit REQuest command, Type A REQuest command, Type B Radio Frequency Reserved for Future Use Select AcKnowledge, Type A SELect code, Type A Start Of Frame Start of Sequence Minimum time period during the PICC is not allowed to produce any detectable disturbance before sending its response

v3.0b Abbreviation UID uidn WTX WTXM WUPA WUPB Description Unique IDentifier, Type A Byte number n of Unique Identifier Waiting Time eXtension Waiting Time eXtension Multiplier Wake UP command, Type A Wake UP command, Type B Table 3: List of Abbreviations

/211

v3.0b 2. Generic Information about the Tests

/211 2.1. ICS (Implementation Conformance Statement) and Application Selection In the ICS (Implementation Conformance Statement) form document the PICC vendors have to indicate the parameters used by the PICC they want to go through Type Approval. This way, the tests scenarios which must be performed on the Card Under Test can be selected and configured by the laboratory. The parameters indicated in the ICS (Implementation Conformance Statement) form document shall be used. The application residing in the PICC shall respond to its AID identified in ICS following selection of PPSE. The application shall be able to provide successful response to the test application commands, C-APDUs, which allows next command to be executed (if any) as identified in ICS. ICS shall have an example of trace and log with enough C and R-APDU exchange pairs to allow the payment transaction to be completed. The laboratory should be able to enter the C-APDUs and R-APDUs to the test tool (if necessary) for the application to execute the test. However the test tool may have already setup for a full transaction that would eliminate the tool preparation process for the application residing in the Card Under Test. In the tests that ‘Continue C/R – APDU exchanges until transaction is completed’ is stated the test tool shall compare the data send in response from R-APDUs with the data and status words presented in ICS except the dynamic data (data changing each transaction). Important: the laboratory shall ensure that the parameters indicated by the vendors in the ICS (Implementation Conformance Statement) form for contactless PICC digital testing are consistent with the EMV Contactless specification.

v3.0b

/211 2.2. Default Environmental Test Conditions The following environmental conditions shall be used for all the tests described in the present document. They will be referred to as the ‘Standard Test Conditions’:

  • The Card Under Test shall be placed as close as possible to the landing plane of the test tool so that the transaction is less perturbed.
  • The external perturbations shall be suppressed: no metal objects or other perturbing elements in a volume of 30 centimeters around the test system and no other antennas (contactless terminals, cell phones,…) in a volume of 1 meter around the test system.
  • Test tool environment shall be able to progress:
  • Application transaction flow according to test cases.
  • EMD algorithm and deaf time against noise generated by the PICC unless the test procedures state otherwise. This is to alleviate any disturbance during test session and to improve interoperability between test tool and the PICCs with EMD.
  • Normal temperature: 23°C (±3°C)
  • Ambient relative humidity: 50% ± 10% 2.3. Default Tool Requirements Unless otherwise specified in the test description (i.e. for exception processing tests), the blocks sent by the LT shall never contain a CID or a NAD field as it is never used by an EMV Contactless terminal. Unless otherwise specified in the PICC parameters section of the test the relevant test shall be applicable for all PICCs. If PICC parameters section of the test indicates special condition only PICCs with that condition shall be tested against the subject test. For example if the PICC parameters section indicates ‘Type A/ UID size=1’ the test is applicable all Type A PICCs with UID size 1 including dynamic UID PICCs. Another example is that if the parameters section indicates ‘Type A’ the test is applicable to all type A PICCs with fixed or dynamic UIDs. Unless otherwise specified in the test description (i.e. to perform a PICC Reset), the LT shall never stop sending the carrier during a test transaction. Unless otherwise specified in the test description, the LT shall apply the default EMV Contactless timings and the default EMV Contactless parameters values (as defined in the present section 2). Unless otherwise specified in the test description, for PICC Type = A, the LT shall use the Type A frame format and a bit rate of 106 kb/s. Unless otherwise specified in the test description, for PICC Type = B, the LT shall use the Type B frame format and a bit rate of 106 kb/s. Unless otherwise specified in the test description, the LT shall initiate the test by generating the RF field for at least tP (to put the CUT in the IDLE state). Although it is not specified in the test description, the LT shall respect the maximum frame size FSC of the PICC and use chaining if necessary when sending commands in I-Blocks. Unless otherwise specified in the test description, the LT shall wait for at least 100 ms before considering that the CUT did not respond to a frame (i.e there is a time-out error). v3.0b /211 When, for Type Approval, a Test Tool is used as a LT, the following requirements apply:
  • Any executed subcase shall generate traces, logs and a test report.
  • The generation of traces, logs and test reports shall indicate whether the acceptance criterias have been met. All acceptance criterias and related values shall be visible in the traces, logs or test reports (e.g. for a timing measurement, the timing measured by the Test Tool shall be present, so shall be the tolerance used by the Test Tool and the expected value or expected range of values for this timing).
  • Any applied timing shall be visible in the traces, logs or test reports.
  • The Test Tool shall be able to manage WTX exchanges for at least 300ms when expecting an I-Block or R-Block from the CUT.
  • Unless indicated otherwise, the Test Tool shall send all its frames indicating chaining with a size equal to FSC.
  • All the frames sent by the CUT shall be checked. It means that the Test Tool shall check that:
  • Regarding the Type A frames: the presence of Start of Frame (SoF), parity bits and the two CRC bytes.
  • Regarding the type B frames: the presence of Start of Sequence (SoS), End of Sequence (EoS), a start bit (Logic "0") followed by 8 data bits and a stop bit (Logic "1") and the two CRC bytes.
  • The Test Tool shall implement the following options: "Check APDU", "Do not check APDU" and "Check SW only". "Check APDU" means that all the data bytes included in the I-Blocks sent by the CUT shall be checked. "Do not check APDU" means that only the bytes related to the EMV Contactless Level 1 included in the frames sent by the CUT shall be checked (i.e. PCB and CRC bytes). "Check SW only" means that only the "Status Word" bytes in the I-Blocks sent by the CUT shall be checked. In addition to the above requirements, it is recommended that the test tools comply with the following:
  • The test tool should be capable of automatically detecting the digital parameters used by the CUT (e.g. technology supported, UID size, support of extended ATQB, etc). 2.4. Default Timings For a time parameters given below, when a test description does not indicates a specific value which have to be used to perform the test, then the default time value shall be used by the LT to send sequences (i.e. the LT shall send sequences to the CUT with delays equal to the default values). The concerned parameters and their default values are as follow. Common to Type A and Type B: After RF field is ON (after a RESET or at the beginning of a test case), the test tool shall wait at least 100ms before sending the 1st command. v3.0b /211 In Type A: SFGT = 1179648/ fc between the end of the sequence sent by the CUT and the beginning of the sequence sent by the LT containing first I-Block of the half-duplex block protocol. FDTA,PCD = 8184/ fc (&gt; FDTA,PCD,MIN) between the end of a sequence sent by the CUT and the beginning of the next sequence sent by the LT. During the whole test, unless otherwise specified in the test description, the LT applies a delay of unmodulated field for at least tP before WUPA command sent following WUPB or REQB or PICC reset sent by the LT. During the whole test, the LT applies a delay of unmodulated field for at least tP between the end of the HLTA sequence sent by the LT and the beginning of the next sequence sent by the LT. In Type B: FDTB,PCD = 8184/ fc (&gt; FDTB,PCD,MIN) between the end of a sequence sent by the CUT and the beginning of the next sequence sent by the LT. EGTPCD = 384/ fc (&lt; EGTPCD,MAX) between two consecutive characters within any sequence. Start of Sequence (SoS) = 1344/ fc of logical state (0)b followed by 320/ fc of logical state (‘1’)b. End of Sequence (EoS) = 1344/ fc of logical state (0)b followed by a logical state transition. During the whole test, unless otherwise specified in the test description, the LT applies a delay of unmodulated field for at least tP before WUPB command sent following WUPA or REQA or PICC reset sent by the LT. 2.5. Definition for Timing Measurement When an executable test asks for the measurement (or the application) of a timing between two consecutive sequences sent in the same direction or in opposite directions, the delay shall be measured (or applied) between the end of the first sequence and the beginning of the second sequence:
  • Beginning of a sequence sent by a Type A PICC: the start (i.e. the first modulation transmitted) of the Start of Frame (SoF) of the PICC sequence.
  • Beginning of a sequence sent by a Type A PCD: the start of the lower level within the Start of Frame (SoF) of the PCD sequence.
  • Beginning of a sequence sent by a Type B PICC: the start of the Start of Sequence (SoS) of PICC sequence.
  • Beginning of a sequence sent by Type B PCD: the start of the Start of Sequence (SoS) of the PCD sequence.
  • End of a sequence sent by a Type A PICC: the last modulation transmitted in the PICC sequence.
  • End of a sequence sent by a Type A PCD: the rising edge of the last lower level of the PCD sequence (within the last data bit sent by the PCD if this last data bit is a Logic "1" or within the End of Frame if the last data bit sent by the PCD is a Logic "0").
  • End of a sequence sent by a Type B PICC: the start of the End of Sequence (EoS) of the PICC sequence.
  • End of a sequence sent by a Type B PCD: the end of the End of Sequence (EoS) of the PCD sequence. v3.0b /211 2.6. Scenario Notations during Half Duplex Protocol Notation I(0)x [‘HH … HH’] I(1)x [‘HH … HH’] R(ACK)x R(NAK)x S(…) Description Not chained I-Block or last I-Block of a chain with block number x and containing the hexadecimal data bytes ‘HH … HH’ (i.e. transmitted APDUs) Chained I-Block (except the last I-Block of a chain) with block number x and containing the hexadecimal data bytes ‘HH … HH’ (i.e. transmitted APDUs) R-Block indicating a positive acknowledgment with block number x R-Block indicating a negative acknowledgment with block number x S-Block Remark: The Test Tool shall never send blocks with a NAD or a CID unless indicated otherwise. v3.0b /211 2.7. Types of Frames in the Scenario In this document, when describing the transactions within the test scenarios, the following rules apply: In Type A tests, if nothing is indicated, the bytes are transported within a Type A standard frame with the 2 bytes of CRC_A (i.e. a valid CRC_A is automatically added after the bytes by the Test Tool). In Type A tests, if "(short frame)" is indicated, the bytes are transported within a Type A short frame. In Type A tests, if "(no CRC_A)" is indicated, the bytes are transported within a Type A standard frame with no CRC_A bytes. In Type A tests, if "(Type B frame)" is indicated, the bytes are transported within a Type B frame with 2 bytes of CRC_B (i.e. a valid CRC_B is automatically added after the bytes by the Test Tool). In Type B tests, if nothing is indicated, the bytes are transported within Type B frames with 2 bytes of CRC_B (i.e. a valid CRC_B is automatically added after the bytes by the Test Tool). In Type B tests, if "(Type A short frame)" is indicated, the bytes are transported within a Type A short frame (WUPA Command sent during collision detection). In Type A and Type B tests, if "(NFC-F Frame)" is indicated, the bytes are transported within an NFC-F Frame at 212 kbps as defined in NFC Forum Referenced Documents. In Type A and Type B tests, if "(Type A Frame)" is indicated, the bytes are transported within a Type A standard frame with the 2 bytes of CRC_A (i.e. a valid CRC_A is automatically added after the bytes by the Test Tool). In Type A and Type B tests, if "(Type B Frame)" is indicated, the bytes are transported within Type B frames with 2 bytes of CRC_B (i.e. a valid CRC_B is automatically added after the bytes by the Test Tool). 2.8. Notational Conventions The following notations apply: ‘00’ to ‘FF’ or "00…00" to "FF…FF": hexadecimal values (sometimes the hexadecimal values are indicated between parenthesis and followed by a lower case "h"). (0)b or ("1001")b: binary notation. Values expressed in binary form are followed by a lower case "b". u: any value (e.g. byte A = ("1u11 0101")b means that b7 of byte A can take any value). UID Size 1, 2 or 3: refers to the single, double or triple size Type A UID as defined in the EMV specification. v3.0b /211 2.9. Tests

References

The tests described in the following sections are referenced this way: Test codification: C- - - -. - - - abc. d a: Frame Type:

  • A = Type A tests
  • B = Type B tests
  • C = Common tests to Type A and Type B b: Test Type:
  • 0 = Basic tests
  • 1 = Correct tests
  • 2 = Error tests c: Test Number (within the Test Type):
  • From 00 to 99 d: Optional Subcase Reference xy:
  • From 0 to 99 (decimal) e.g. CA223.2 represents the Subcase 2 of the Test number 23 within the tests concerning the Type A transactions with error. Remark: Common tests to Type A and Type B must be performed in Type A and in Type B on dual Type PICCs. 2.10.Basic Installation When the test description indicates that the LT initiates the test by performing a basic installation of the CUT, then the following basic installation shall be applied by the test implementation. v3.0b /211 For a Type A PICC with UID Size 1: i CUT ‘52’ (short frame) LT WUPA to poll for the CUT i+1 CUT ATQA (no CRC_A) LT ATQA i+2 CUT ’93 20’ (no CRC_A) LT ANTICOLLISION CL1 i+3 CUT UID CL1 + BCC (no CRC_A) LT UID CL1 + BCC i+4 CUT ’93 70’ + UID CL1 + BCC LT SELECT CL1 i+5 CUT ("uu1u u0uu")b LT SAK i+6 CUT ‘E0 80’ LT RATS (FSD = 256) i+7 CUT ATS LT ATS Table 4: Basic installation PICC Type A – UID size = 1 For a Type A PICC with UID Size 2: i CUT ‘52’ (short frame) LT WUPA to poll for the CUT i+1 CUT ATQA (no CRC_A) LT ATQA i+2 CUT ’93 20’ (no CRC_A) LT ANTICOLLISION CL1 i+3 CUT UID CL1 + BCC (no CRC_A) LT UID CL1 + BCC i+4 CUT ’93 70’ + UID CL1 + BCC LT SELECT CL1 i+5 CUT ("uu1u u1uu")b LT SAK i+6 CUT ’95 20’ (no CRC_A) LT ANTICOLLISION CL2 i+7 CUT UID CL2 + BCC (no CRC_A) LT UID CL2 + BCC i+8 CUT ’95 70’ + UID CL2 + BCC LT SELECT CL2 i+9 CUT ("uu1u u0uu")b LT SAK i+10 CUT ‘E0 80’ LT RATS (FSD = 256) i+11 CUT ATS LT ATS Table 5: Basic installation PICC Type A – UID size = 2 For a Type A PICC with UID Size 3: i CUT ‘52’ (short frame) i+1 CUT ATQA (no CRC_A) i+2 CUT ’93 20’ (no CRC_A) i+3 CUT UID CL1 + BCC (no CRC_A) LT LT LT LT WUPA to poll for the CUT ATQA ANTICOLLISION CL1 UID CL1 + BCC v3.0b /211 i+4 CUT ’93 70’ + UID CL1 + BCC i+5 CUT ("uu1u u1uu")b i+6 CUT ’95 20’ (no CRC_A) i+7 CUT UID CL2 + BCC (no CRC_A) i+8 CUT ’95 70’ + UID CL2 + BCC i+9 CUT ("uu1u u1uu")b i+10 CUT ’97 20’ (no CRC_A) i+11 CUT UID CL3 + BCC (no CRC_A) i+12 CUT ’97 70’ + UID CL3 + BCC i+13 CUT ("uu1u u0uu")b i+14 CUT ‘E0 80’ i+15 CUT ATS LT LT LT LT LT LT LT LT LT LT LT LT SELECT CL1 SAK ANTICOLLISION CL2 UID CL2 + BCC SELECT CL2 SAK ANTICOLLISION CL3 UID CL3 + BCC SELECT CL3 SAK RATS (FSD = 256) ATS Table 6: Basic installation PICC Type A – UID size = 3 For a Type B PICC: i CUT ’05 00 08’ LT i+1 CUT ATQB (containing PUPI) LT i+2 CUT ’1D’ + PUPI + ’00 08 01 00’ LT i+3 CUT ‘00’ LT Table 7: Basic installation – PICC Type B WUPB to poll for the CUT ATQB ATTRIB ATTRIB Response 2.11.Pre- and Post-Processing Unless stated otherwise in the test description, when the CUT sends an S(WTX) Request or uses PICC chaining, the following processing is applied during any test described in the present document: On reception of an S(WTX) Request (i.e. block with PCB=’F2’) from the CUT, the test script shall be modified so that the LT checks that the S(WTX) Block sent by the CUT has a PCB (i.e. first byte of the Block) equal to (‘F2’)h (i.e. b2 of S-Block PCB is set to (1)b) and that the value of WTXM indicated in the S(WTX) Request respects 1 ≤ WTXM ≤ 59. Then, if the value of WTXM is correct, the LT shall reply, with respect of FWT, with the corresponding S(WTX) Response (i.e. send back the received block) and this S(WTX) exchange shall be ignored (the consecutive step numbers shall be adapted – no impact on the block numbers). The LT shall ensure that the delay between the end of the S(WTX) Response sequence sent by the LT and the beginning of the next sequence sent by the CUT is at most FWTTEMP = v3.0b /211 ((256 x 16/ fc) x 2FWI x WTXM) where WTXM is the FWT Extension Multiplier indicated in the S(WTX) Request. On reception of a I-Block indicating chaining (i.e. block with PCB=’12’ or ‘13’) in a frame of size S from the CUT, the test script shall be modified so that the LT checks that the INF field of the I-Block is not empty, and so that the steps: i CUT I(0)n [‘R-APDU0’ (including a Status Word’)] LT Block containing RAPDU0 i+1 CUT I(M)n+1 LT Block containing CAPDU0 Table 8: Modification of scenario in case of chaining from CUT (1/2) are replaced by: i CUT I(1)n [‘R-APDU1’ ] in a frame of size S i+1 CUT R(ACK)n+1 … As many I(1)-Blocks / R(ACK) Blocks exchanges as needed LT LT Block containing RAPDU0 … i+j CUT I(0)n+j/2 [‘R-APDU(1+j/2)’ (including a Status Word’)] in a LT last I-Block of the chain frame of size ≤ S containing R-APDU(1+j/2) i+j+1 CUT I(M)n+j/2+1 LT Block containing CAPDU0 Table 9: Modification of scenario in case of chaining from CUT (2/2) where ‘R-APDU0’ = ‘R-APDU1’ + ‘R-APDU2’+ … + ‘R-APDU(1+j/2)’ and where I - blocks above are send with b.n. ={n, n+1, n+2, n+3, …, n+j/2+1} in mod 2. And the consecutive step numbers and block numbers shall be adapted. 2.12.Transaction Completion Unless stated otherwise in the test description, where the test procedures identify as ‘Continue C/R – APDU exchanges until transaction is completed’ the I-block exchanges shall be included in the subject steps until the relevant payment transaction is completed as indicated below. Parameters:
  • ‘k’ parameter indicates step number for the last step before the ‘Continue C/R – APDU exchanges until transaction is completed’ where response sent by CUT to Select AID command
  • ‘j/2-2’ is the number of C/R – APDU pairs to complete transaction v3.0b /211 The ‘Continue C/R – APDU exchanges until transaction is completed’ process applied as below: k+1 CUT I(0)0 [‘C-APDU‘1] LT k+2 CUT I(0)0[‘R-APDU‘1] LT … ‘j/2-2’ number of I(0) Block (C/R – APDUs) exchange pairs … k+j-1 CUT I(0)j/2 [‘C-APDU‘j/2] LT Last transaction CAPDU k+j CUT I(0)j/2 [‘R-APDU‘j/2] LT Last transaction RAPDU Table 10: Scenario to be performed in case of ‘Continue C/R – APDU exchanges until transaction is completed’ where I - blocks above are send with b.n. ={0, 1, 3, …, j/2} in mod 2. 2.13.Loopback Command Description The Loopback Command is used to simulate a chaining of I-Blocks sent by the LT. The test tool shall support Loopback Command as coded in Table 11: Loopback Command Coding. The support of the Loopback Command by CUT is optional. A successful response to a Loopback Command is shown in Table 12: Response to Loopback Command. If supported, CUT shall fill in the Data field of the response and status words, ‘9000’. All status conditions are defined in ISO 7816. Field CLA INS P1 P2 Lc Data Le Content 80 EE 00 00 FA 00 01 02 03 … F7 F8 F9 00 Length 1 1 1 1 1 Up to 256 1 Table 11: Loopback Command Coding v3.0b Field Data SW1-SW2 Content Length The Data field returned by the PICC is the Up to 256 data sent in the loopback command (‘9000’)h 2 Table 12: Response to Loopback Command /211 2.14.Parameters Values This section defines the parameter values to be applied or observed during the PICC digital tests unless identified in the test descriptions otherwise. The timing values in the table below are as given in the EMV Contactless specification and do not take the test margins induced by the tool inaccuracy into account. When a timing value is applied by the test tool (e.g. FDTA,PCD,MIN), the test implementation should be as close as possible to the timing given in the table and the following rules shall be respected by the test tool:
  • In the case where a minimum timing value shall be supported by the tested PICC, the applied timing value shall never be lower than the specification value given in the table
  • In the case where a maximum timing value shall be supported by the tested PICC, the applied timing value shall never be higher than the specification value given in the table When a timing value is measured during a test, the tolerances of the test tool shall be used. The following is the maximum tolerance p accepted for a test tool:
  • If T is defined in ‘1/fc’ and T  12800 x 1/fc then p = 12.8 x 1/fc
  • If T is defined in ‘1/fc’ and 12800 &lt; T  128000 x 1/fc then p = 64 x 1/fc
  • If T is defined in ‘1/fc’ and 128000 &lt; T  1280000 x 1/fc then p = 128 x 1/fc
  • If T is defined in ‘1/fc’ and T &gt; 1280000 x 1/fc then p = 0.001 * T
  • If T is defined in ‘ms’ then p = 0.001 * T (e.g. T = 10 ms =&gt; p = 10 µs) Notation: T is the timing which shall be measured within a Test Case and p is the time precision needed for this Test Cases. For all the tests described in the present document, the following parameters values shall apply: Parameters common to Type A and Type B: Parameter name Parameter value Comments Mute_Time 100000 µs Delay following time-out after which a PICC not sending any sequence is considered as mute (specific to the tests), e.g. FWT+ ΔFWT+Mute_Time after the end of a sequence sent by the test tool tP 5000 µs tRESET 5000 µs tRETRANSMISSION 10.0 ms v3.0b /211 Parameter name FWT FWTDEFAULT FWT x WTXM FWTMAX ΔFWT FWTDESELECT Parameter value (256 x 16/ fc) x 2FWI 65536/ fc (WTXM x (256 x 16/ fc)x 2FWI 524288/ fc 49152/ fc 512 x 128/ fc FSC n bytes FSD SFGT SFGI 256 bytes (256 x 16/ fc) x 2SFGI 0 to 8 Comments Detailed in the test description Corresponding to the basic installation: FWI = 4 Detailed in the test description In function of FSCI or Max_Frame_Size (see the EMV specification for a detailed definition) Detailed in the test description Table 13: Parameter values Common Type A and Type B Parameters specific to Type A: Parameter name Parameter value FDTA,PICC,MIN (1152 + 20)/ fc if the last bit transmitted by the Test Tool is (0)b (1152 + 84)/ fc if the last bit transmitted by the Test Tool is (1)b FDTA,PICC,ANTICOLLISION (1152 + 20)/ fc if the last bit transmitted by the Test Tool is (0)b (1152 + 84)/ fc if the last bit transmitted by the Test Tool is (1)b FWTACTIVATION 65536/ fc tH 12800/ fc FSCI 2 to 8 FDTA,PCD,MIN 1172/ fc Comments Table 14: Parameter values Specific Type A Parameters specific to Type B: Parameter name Parameter value FDTB,PICC,MIN 2304/ fc TR0MIN 1024/ fc Comments = TR0MIN + TR1MIN = 1024 / fc + 1280/ fc v3.0b Parameter name TR0MAX,ATQB TR1MIN TR1MAX EGTPICC,MAX EGTPCD,MIN EGTPCD,MAX tFSOFF,MAX Max_Frame_Size FDTB,PCD,MIN Parameter value 4096/ fc 1280/ fc 3200/ fc 256/ fc 0 µs 768/ fc 256/ fc 2 to 8 1792/ fc Comments Table 15: Parameter values Specific Type B /211 3. Type A Executable Tests 3.1. Basic Type A Exchange and Timings Measurement (UID size = 1) [CA001] Test Codification: CA001 ICS Parameters: PICC Type = A / UID size = 1 Test Objective: To ensure that the Type A PICC with a single size UID respects the frame format, the timings and the order of the commands during a basic exchange (installation and block protocol). Reference Requirements: 4.7.1.1, 4.7.1.2, 4.7.1.3, 4.8.1.2, 4.8.1.5, 4.8.1.9, 4.8.1.11, 4.8.1.13, 5.2.1.1, 5.2.1.2, 5.3.2.3, 5.5.2.2, 5.7.1.1, 5.7.2.1, 5.7.2.3, 5.7.2.4, 5.7.2.7, 5.7.2.9, 5.7.2.10, 5.7.2.12, 5.7.2.15, 7.1.1.5, 10.3.4.8 Procedure: Run the following scenario. When a sequence sent by the LT is followed by a sequence sent by the CUT, the LT measures the Frame Delay Time between the end of the sequence sent by the LT and the beginning of the sequence replied by the CUT. Remark: The Frame Delay Time used by the CUT to reply to any command shall be measured, and, if the CUT uses chaining or sends WTX Requests when replying to any command, then the measurement is performed for each sequence sent by the CUT until the next command is sent by the LT. v3.0b /211 Acceptance Criteria: The CUT behaves as described in the following scenario. Each frame sent by the CUT is a Type A standard frame composed of a Start of Frame i.e. SoF = Logic "1", followed by the bytes coding the CUT response (and eventually the CRC). For each byte, the 8 bits are transmitted LSB first and are followed by an odd parity bit. Each Type A frame sent by the CUT is contained in a sequence ending with an End of Sequence i.e. EoS = the carrier is not modulated with the subcarrier for one bit dur

Shown in part. Read the original for the full text.