PCI Watch

Tracking changes across the Payment Card Industry

Specification 4.3c Final Draft, Contact Terminal Level 1, IFM Protocol Test Bench and Test Case Requirements

v1.0
Contact Acceptance Device

EMV® Type Approval Contact Terminal Level 1 IFM Protocol Test Bench and Test Case Requirements Version 4.3c final draft August 2017

2017 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 NON-INFRINGEMENT, 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.

2017

Revision Log – Version 4.3c final draft The following changes have been made to the document since the publication of Version 4.3a. 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. Changes based on Specification Updates: Version Date Version 4.3c August 2017 Revision

Description

In 1740.DTSx: Application of SB114 Other changes (test coverage, editorial): Version Date Version 4.3c August 2017 Revision Description In 2.1. Compliance Demonstration Objective: Testing objectives have been updated In 2.4. Default Environmental Test Conditions: Reference to low and high temperature has been removed In 2.8 Warm Reset and Deactivation Windows: Wording of the generic Acceptance Criteria was updated to be clearer In 1702.DTS: Removal of useless acceptance criteria In 1703.DTSxy: Inter-character timings and ATR duration have been corrected In 1704.DTSxy: Inter-character timings and ATR duration have been corrected In 1705.DTSxy: Removal of useless acceptance criteria Editorial clarification of Acceptance Criteria In 1709.DTSxy: Editorial correction in the scenario In 1710.DTSxy: Removal of useless acceptance criteria In 1712.DTSy: Update of the scenario to add a pair of command/response APDU In 1714.DTS: Removal of useless acceptance criteria In 1715.DTSx: Test Case objective added Removal of useless acceptance criteria

2017

Version Date Revision Description In 1717.DTSxy: Scenario updated to indicate completely APDUs to be sent In 1722.DTSx: Scenario updated to indicate completely APDUs to be sent ATR value updated In 1730.DTS: Editorial update of the scenario In 1731.DTS: Editorial update of the scenario In 1732.DTSxy: Update of the scenario to be in line with the description of the Test Case In 1737.DTSxy: Error shall be generated on each byte sent by the LT In 1740.DTSx: Editorial update of the scenario In 1750.DTSxy: Editorial correction in the scenario In 1751.DTSxy: Editorial correction in the scenario In 1753.DTSx: Scenario updated to indicate completely APDUs to be sent ATR value updated In 1754.DTSxy: Correction of Cold ATR for x=3 Scenario updated to indicate completely APDUs to be sent In 1767.DTSxy: For xy=2y, scenario updated to increase the size of data from 4 to 32 bytes Addition of subcases in xy=1y to test D=1 and D=4 and CWI=0. For xy=2y, scenario updated to describe the frame to be generated by the LT instead of the frame expected to be received by the IFM In 1770.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted optional behaviour by an Acceptance Criteria depending on the ICS Clarification of errors to be generated by the LT Test Case devided into subcases In 1771.DTSxy:

2017

Version Date Revision Description For the management of Blocks with LEN=’FF’: Update of the Accepted optional behaviour by an Acceptance Criteria depending on the ICS Test Case devided into subcases Errors assumed by the LT are Parity and Other alternately Clarification of the erroneous frames to be generated by the LT Editorial update in scenario In 1772.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted optional behaviour by an Acceptance Criteria depending on the ICS Test Case devided into subcases Clarification of the erroneous frames to be generated by the LT In 1774.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted optional behaviour by an Acceptance Criteria depending on the ICS Test Case devided into subcases Clarification of the erroneous frames to be generated by the LT In 1775.DTSxy: Test objective updated: The IFM does not receive a response from the card during the test In 1776.DTS: Test Case devided into subcases Scenario updated to indicate the type of R-Blocks to be generated by the LT Clarification of the procedure to indicate the type of Block of the erroneous frames to be generated by the LT In 1777.DTS: Editorial scenario update In 1778.DTSxy: Editorial update of some APDUs in scenario For the management of Blocks with LEN=’FF’: Update of the Accepted behaviour by an Acceptance Criteria depending on the ICS Test Case devided into subcases Clarification of the procedure to indicate the type of erroneous frames to be generated by the LT In 1779.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted optional behaviour by an Acceptance Criteria

2017 Page v Version Date Revision Description depending on the ICSUpdate of the conditions to clarify the type of erroneous frames to be generated by the LT For xy=13, erroneous S(Resynch responses) from LT sent after S(Resynch request) shall contain a parity error In 1780.DTSxy: Deletion of the Test Case In 1781.DTSxy: Deletion of 1781.DTSxy In 1784.DTSxy: Correction of some blocks descriptions that were incorrect in scenario For the management of Blocks with LEN=’FF’: Update of the Accepted behaviour by an Acceptance Criteria depending on the ICSTest Case devided into subcases Update of the conditions to clarify the type of the erroneous frames to be generated by the LT In 1785.DTSxy: Update some deactivation delays present in the conditions that were incorrect For the management of Blocks with LEN=’FF’: Update of the Accepted optional behaviour by an Acceptance Criteria depending on the ICSUpdate of the conditions to clarify the type of the erroneous frames to be generated by the LT In 1786.DTS: Deletion of 1786.DTS In 1787.DTS: Merge of 1780 with 1787 Update of the the Accepted option and Acceptance Criteria In 1788.DTSxy: Editorial update of some frames of the scenario that were not correctly described Update of the conditions to indicate the type of the erroneous frames to be generated by the LT. Merge 1781.DTSxy with 1788.DTSxy In 1789.DTSxy: Update of the Acceptance criteria to separate management of BWT excess after R-Block and after S-Block Scenario updated to indicate completely APDUs to be sent The Test objective was updated: the IFM does not receive a response from the card during the test In 1790.DTSxy:

2017

Version Date Revision Description Update of the Acceptance criteria to separate management of CWT excess after R-Block and after S-Block Scenario updated to indicate completely APDUs to be sent Removal of useless acceptance criteria Update of the conditions to indicate that the CWT excess shall be implemented between last character and character sent just before In 1792.DTSy: Editorial update of the scenario In 1793.DTS: Merge 1786.DTS with 1793.DTS Update of the acceptance criteria and the accepted option In 1794.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted behaviour by an Acceptance Criteria depending on the ICS Test Case devided into subcases Update of the conditions to clarify the type of the erroneous frames to be generated by the LT In 1798.DTSxy: For xy=9y: Correction of some steps of the scenario that were not correctly described. In 1800.DTSxy: Scenario updated to indicate completely APDUs to be sent Addition of subcases to test D=1 and D=4 In 1803.DTSxy: Editorial updates in the scenario In 1804.DTSxy: Scenario updated to indicate completely APDUs to be sent Update of the conditions to clarify the type of the erroneous frames to be generated by the LT In 1807.DTSxy: Addition of an Acceptance criteria for xy=05 depending on the ICS. Editorial update of the scenario Update of the conditions to clarify the type of the erroneous frames to be generated by the LT In 1808.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted behaviour by an Acceptance Criteria depending on the ICS

2017

Version Date Revision Description Update of the conditions to clarify the types of the erroneous frames to be generated by the LT In 1809.DTSxy: For the management of Blocks with LEN=’FF’: Update of the Accepted behaviour by an Acceptance Criteria depending on the ICSUpdate of the conditions to clarify the type of the erroneous frames to be generated by the LT In 1812.DTSxy: For xy=16, management of Blocks with LEN=’FF’: Addition of an Acceptance Criteria depending on the ICS Update of the conditions to clarify the erroneous frames to be generated by the LT Scenario updated to add S(IFS Request)/ S(IFS Response) at the start of the transmission protocol In 1813.DTSx: Test Case deleted In 1814.DTSx: Merge of 1813.DTSx with 1814.DTSx Scenario updated: Transactions stops after reception of S(Resynch request) or deactivation Generic update: Removal of all the failure actions in the TCs

2017

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. 3. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12. 3.13. 3.14. 3.15. 3.16. 3.17. 3.18. 3.19. 3.20.

2017

3.21. 3.22. 3.23. 3.24. 3.25. 3.26. 3.27. 3.28. 3.29. 3.30. 3.31. 3.32. 3.33. 3.34. 3.35. 3.36. 3.37. 4. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. [1767] Card fully uses Timings: CWT, BGT, Minimum Inter-Character Timing... 125 4.8. 4.9. 4.10. 4.11. 4.12. 4.13. 4.14. 4.15. 4.16. 4.17. 4.18. 4.19. 4.20. 4.21.

2017 Page x 4.22. 4.23. 4.24. 4.25. 4.26. 4.27. 4.28. 4.29. 4.30. 4.31. 4.32. 4.33. 4.34. 4.35. 4.36. 4.37. 4.38. 4.39. 4.40. 4.41. 4.42.

2017

Scenarios Scenario 1: [1701] Etu Measurement in Direct Convention Using T=0 when TA1 and TA2 are Absent (after cold and warm reset) ___________________________________________ 11 Scenario 2: [1702] Etu Measurement in Negotiable Mode (cold ATR - y=0) ____________ 14 Scenario 3: [1702] Etu Measurement in Negotiable Mode (warm ATR - y=1) ___________ 15 Scenario 4: [1703] Valid ATR Timings (cold reset - y=0) ___________________________ 17 Scenario 5: [1703] Valid ATR Timings (warm reset - y=1) __________________________ 19 Scenario 6: [1704] ATR Timings Exceeded (cold reset - y=0) _______________________ 20 Scenario 7: [1704] ATR Timings Exceeded (warm reset - y=1) ______________________ 21 Scenario 8: [1705] Inter-Character Timings Measurement (after cold reset) in Same and Opposite Directions

  • INS Complemented in Reception (y=0) _______________________ 24 Scenario 9: [1705] Inter-Character Timings Measurement (after warm reset) in Same and Opposite Directions
  • INS Complemented in Reception (y=1) _______________________ 26 Scenario 10: [1707] Erroneous ATR before and after Warm Reset (T=0 and T=1) _______ 29 Scenario 11: [1708] ATR not Complete ________________________________________ 30 Scenario 12: [1709] Use of ‘61’ and Minimum Inter-Character Timing in Same and Opposite Directions _______________________________________________________________ 35 Scenario 13: |1710] ICC is Slow but Respects WWT: Same and Opposite Directions ____ 38 Scenario 14: [1711] ICC Exceeds WWT in Same and Opposite Directions – y=0 ________ 40 Scenario 15: [1711] ICC Exceeds WWT in Same and Opposite Directions – y=1 ________ 40 Scenario 16: [1712] Several ‘60’ _____________________________________________ 42 Scenario 17: [1713] ‘60’ amid INS Complemented________________________________ 44 Scenario 18: [1714] Error Detection Using T=0 (while IUT is receiving) _______________ 46 Scenario 19: [1715] Supported Value of TD2
  • Error Correction Using T=0 (while ICC is receiving) _______________________________________________________________ 49 Scenario 20: [1716] Incorrect TS after Cold Reset – y=0 ___________________________ 50 Scenario 21: [1716] Incorrect TS after Warm Reset – y=1__________________________ 51 Scenario 22: [1717] Correct ATR after Warm Reset (T = 0) ________________________ 53 Scenario 23: [1718] Etu Measurement in Specific Mode (cold ATR) – y=0 _____________ 55 Scenario 24: [1718] Etu Measurement in Specific Mode (warm ATR) – y=1 ____________ 55 Scenario 25: [1719] Cold & Warm ATR Initiation Delay (xy=10 and 20) _______________ 57 Scenario 26: [1719] Cold & Warm ATR Initiation Delay (xy=30) _____________________ 57 Scenario 27: [1719] Cold & Warm ATR Initiation Delay (xy=11 and 21) _______________ 57 Scenario 28: [1719] Cold & Warm ATR Initiation Delay (xy=31) _____________________ 58 Scenario 29: [1720] Etu Measurement in Specific Mode with TA2 = ‘00’ _______________ 60 Scenario 30: [1722] Maximum Length of the T=0 (x=1) ____________________________ 62 Scenario 31: [1722] Maximum Length of the T=0 (x=2) ____________________________ 62 Scenario 32: [1725] Status Words different from ‘9000’ ____________________________ 66 Scenario 33: [1726] Parity Error in the ATR after Cold Reset T=0 & T=1 – y=0 _________ 67 Scenario 34: [1726] Parity Error in the ATR after Warm Reset T=0 & T=1 – y=1 ________ 68 Scenario 35: [1727] Inverse Convention Using T=0 (after cold reset) – y=0 ____________ 70 Scenario 36: [1727] Inverse Convention Using T=0 (after warm reset) – y=1 ___________ 72 Scenario 37: [1730] INS Complemented in Reception _____________________________ 74 Scenario 38: [1731] INS Complemented / INS in Reception ________________________ 76 Scenario 39: [1732] Error Repetition (transmitting): x=1 ___________________________ 78 Scenario 40: [1732] Error Repetition (transmitting): x=2 ___________________________ 78 Scenario 41: [1733] Interpretation of Repeated Character__________________________ 79 Scenario 42: [1734] Different Values of the Second Procedure Byte after ‘6C’ and ‘61’ ___ 83 Scenario 43: [1735] Erroneous Procedure Byte Handling __________________________ 85 Scenario 44: [1736] Erroneous Status Word Handling_____________________________ 87 Scenario 45: [1737] Error Repetition (receiving) (x=1) _____________________________ 89 Scenario 46: [1737] Error Repetition (receiving) (x=2) _____________________________ 89 Scenario 47: [1738] Case 3 Command: Status Word Different from ‘9000’ _____________ 91 Scenario 48: [1740] Case 4 Command: Correct Warning Status _____________________ 93 2017 Scenario 49: [1741] Case 4 Command: Incorrect Warning Status____________________ 95 Scenario 50: [1742] Case 4 Command: Error Indicated after '61' ____________________ 97 Scenario 51: [1743] Case 4 Command: Warning after INS and Error after '61' __________ 99 Scenario 52: [1744] Case 2 Command: Abnormal Processing at Step 2 (x=1) _________ 102 Scenario 53: [1744] Case 3 Command: Abnormal Processing at Step 2 (x=2) _________ 102 Scenario 54: [1744] Case 4 Command: Abnormal Processing at Step 2 (x=3) _________ 103 Scenario 55: [1750] Etu Measurement in Direct Convention Using T=1 in Specific and Negotiable Modes (after cold reset; y=0) _____________________________________ 108 Scenario 56: [1750] Etu Measurement in Direct Convention Using T=1 in Specific and Negotiable Modes (after warm reset; y=1) ____________________________________ 110 Scenario 57: [1751] Etu Measurement in Inverse Convention Using T=1 in Specific and Negotiable Modes (after cold reset; y=0) _____________________________________ 113 Scenario 58: [1751] Etu Measurement in Inverse Convention Using T=1 in Specific and Negotiable Modes (after warm reset; y=1) ____________________________________ 115 Scenario 59: [1752] Etu Measurement in Specific Mode Using T=1 with TA2 = ‘01’ _____ 118 Scenario 60: [1753] Maximum Length of the ATR T=1 (x=1) _______________________ 120 Scenario 61: [1753] Maximum Length of the ATR T=1 (x=2) _______________________ 120 Scenario 62: [1754] Correct ATR after Warm Reset (T=1) ________________________ 122 Scenario 63: [1758] TCK is False or not Returned after Cold Reset (y=0) ____________ 123 Scenario 64: [1758] TCK is False or not Returned after Warm Reset (y=1) ___________ 124 Scenario 65: [1767] Card fully uses Timings: CWT, BGT, Minimum Inter-Character Timing (x=1 or x=3) ____________________________________________________________ 126 Scenario 66: [1767] Card fully uses Timings: CWT, BGT, Minimum Inter-Character Timing (x=2) __________________________________________________________________ 127 Scenario 67: [1768] Proper then Improper Use of WTX (behaviour 1)________________ 129 Scenario 68: [1768] Proper then Improper Use of WTX (behaviour 2)________________ 129 Scenario 69: [1769] Request for I-Block Repetition (x=1) _________________________ 131 Scenario 70: [1769] Request for I-Block Repetition (x=2) _________________________ 132 Scenario 71: [1770] Non-Chained Blocks
  • One Error in Response to an I-Block Then I-Block (x=1) __________________________________________________________________ 134 Scenario 72: [1770] Non-Chained Blocks
  • Two Consecutive Errors in Response to an IBlock Then I-Block (x=2) __________________________________________________ 135 Scenario 73: [1771] Non Chained Block
  • Error in Response to an I-Block then Error Notification on I-Block then I-Block___________________________________________ 137 Scenario 74: [1772] Error in Response to an I-Block then Error Notification on R-Block then IBlock__________________________________________________________________ 139 Scenario 75: [1774] Two Consecutive Errors in Response to an I-Block then Error Notification ______________________________________________________________________ 141 Scenario 76: [1775] ICC Exceeds WTX (behaviour 1) ____________________________ 143 Scenario 77: [1775] ICC Exceeds WTX (behaviour 2) ____________________________ 143 Scenario 78: [1776] Error in Response to a Chained I-Block _______________________ 146 Scenario 79: [1777] Chaining
  • Various Error Notifications on R-Block _______________ 149 Scenario 80: [1778] Chaining
  • Error in Response to an R-Block then I-Block _________ 152 Scenario 81: [1779] Synchronization is Never Reached (with RESYNCH) ____________ 155 Scenario 82: [1782] Chaining in both Directions ________________________________ 156 Scenario 83: [1783] Error Assumed during Chaining in both Directions ______________ 159 Scenario 84: [1784] Chaining in both Directions
  • Error Notification on Last I-Block of a Chain, then Two Errors during ICC Chaining_________________________________________ 162 Scenario 85: [1785] Non Chained Blocks
  • Excess of Errors in Response to an I-Block Deactivation ____________________________________________________________ 165 Scenario 86: [1787] IUT Chaining
  • Excess of Error Notifications on I-Block ___________ 167 Scenario 87: [1788] IUT Chaining – Excess of Errors in Response to an I-Block _______ 169 Scenario 88: [1789] ICC Exceeds BWT (x=0,1, 2 - behaviour 1) ____________________ 171 Scenario 89: [1789] ICC Exceeds BWT (x=3, 4, 5 - behaviour 1) ___________________ 171 Scenario 90: [1789] ICC Exceeds BWT (x=0, 1, 2 - behaviour 2) ___________________ 172 Scenario 91: [1789] ICC Exceeds BWT (x=3, 4, 5 - behaviour 2) ___________________ 173 2017 Scenario 92: [1790] ICC Exceeds CWT (x=0, behaviour 1) ________________________ 175 Scenario 93: [1790] ICC Exceeds CWT (x=1, behaviour 1) ________________________ 175 Scenario 94: [1790] ICC Exceeds CWT (x=0, behaviour 2) ________________________ 176 Scenario 95: [1790] ICC Exceeds CWT (x=1, behaviour 2) ________________________ 177 Scenario 96: [1791] BWT Respected _________________________________________ 179 Scenario 97: [1792] IUT Chaining
  • Reception of an S(ABORT request)______________ 181 Scenario 98: [1793] Non Chained Blocks
  • Excess of Error Notifications on I-Block _____ 183 Scenario 99: [1794] Non Chained Blocks
  • Errors in Response to an I-Block then S(WTX request) (x=1) ___________________________________________________________ 186 Scenario 100: [1794] Non Chained Blocks
  • Errors in Response to an I-Block then S(WTX request) (x=2) ___________________________________________________________ 187 Scenario 101: [1795] Non Chained Blocks
  • Error Notification on S(WTX response) ____ 189 Scenario 102: [1797] Non Chained Blocks
  • Error Notification on S(IFS request) then S(IFS response) ______________________________________________________________ 191 Scenario 103: [1798] Respect of IFSI by Terminal (x=0, y=1) ______________________ 193 Scenario 104: [1798] Respect of IFSI by Terminal (x=9, y=1) ______________________ 194 Scenario 105: [1798] Respect of IFSI by Terminal (x=0, y=2) ______________________ 194 Scenario 106: [1798] Respect of IFSI by Terminal (x=9, y=2) ______________________ 195 Scenario 107: [1798] Respect of IFSI by Terminal (y=1) (x=1 to 8) __________________ 196 Scenario 108: [1798] Respect of IFSI by Terminal (y=2) (x=1 to 8) __________________ 196 Scenario 109: [1800] Timings Respected by the IUT: EGT, BGT, CWT (cold reset) _____ 198 Scenario 110: [1800] Timings Respected by the IUT: EGT, BGT, CWT (warm reset)____ 198 Scenario 111: [1803] Chained Blocks
  • WTX Respected __________________________ 200 Scenario 112: [1804] Non Chained Blocks
  • Error in Response to an S(IFS request) then S(IFS response) _________________________________________________________ 202 Scenario 113: [1805] Chaining or Not
  • Repeated Requests to Change IFSC between Two Chains (example x=2) ____________________________________________________ 204 Scenario 114: [1806] Non Chained Blocks
  • Error Notification on S(IFS response) then IBlock__________________________________________________________________ 206 Scenario 115: [1807] Non Chained Blocks
  • Error in Response to an I-Block then S(IFS request) _______________________________________________________________ 208 Scenario 116: [1808] Non Chained Blocks
  • Error in Response to an S(IFS Response), then I-Block ________________________________________________________________ 210 Scenario 117: [1809] Non Chained Blocks
  • Error in Response to an S(IFS response), then Error Notification, then I-Block ______________________________________________ 212 Scenario 118: [1812] Resynchronization Attempt after Excess of Invalid Blocks in Response to an I-Block ____________________________________________________________ 214 Scenario 119: [1814] Non Chained Blocks
  • Excess of Errors in Response to an S(IFS request) _______________________________________________________________ 216 2017 2017 1. About this Document 1.1.

Introduction

The present document, ‘EMV® Type Approval Contact Terminal Level 1 IFM Protocol Test Bench and Test Case Requirements Version 4.3c final draft August 2017’, describes the detailed organization and requirements of the executable tests the vendors has to comply with, to allow the protocol part of the Contact 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 and codification,  The objective of the test case,  The specification references as section(s) of the EMV Book 1 specification document related to the test case,  The conditions needed to perform the test,  The procedure to perform the test – generally completed with the scenario below,  The acceptance criteria are the criteria to meet in order to pass the test,  The failure action is the action to be done if the test is fail,  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

2017

1.3.1. Specification Documents Document EMV Integrated Circuit Card Specifications for Payment Systems ─ Book 1 ─ Application Independent ICC to Terminal Interface Requirements EMVCo Terminal Type Approval ─ IFM Level 1 Administrative Process EMVCo Type Approval ─ Contact Terminal Level 1 ─ Mechanical and Electrical Test Cases EMVCo Terminal Type Approval ─ Level 1 Loopback Upper Tester Specification Table 1: Specification Documents Version Issue date version 4.3, November 2011 version 4.3a, November 2015 version 4.3a, November 2015 version 4.3a, November 2015 1.3.2. Laboratory Test Documents The test documents to be applied by EMVCo accredited laboratories when performing an EMV Contact Terminal Type Approval Level 1 session are listed in the following document:  EMVCo Type Approval  Contact Terminal Level 1  Laboratories Documentation Check the last version of this document for any update of the test documents.

2017

1.4. Acronyms and Abbreviations The following abbreviations and notations are used in this document: Abbreviation Description APDU Application Protocol Data Unit ATR

Answer

To Reset BGT Block Guard Time BWI Block Waiting time Integer BWT Block Waiting Time C-APDU Command APDU CLA Class byte of the command message CLK Clock C-TPDU Command TPDU CWI Character Waiting time Integer CWT Character Waiting Time DUT Device Under Test EDC Error Detection Code etu Elementary time unit f Frequency ICC Integrated Circuit Card ICS Implementation Conformance Statement IFD Interface Device IFM Interface Module IFS Information Field Size IFSC Information Field Size for the ICC IFSD Information Field Size for the Terminal IFSI Information Field Size Integer INF Information Field INS Instruction byte for command message IUT Implementation Under Test I/O Input/Output ISO International Organization for Standardization Lc Exact Length of Data Sent by the TAL in a Case 3 or 4 Command Le Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command Licc Exact Length of Data Available in the ICC to be Returned in Response to the Case 2 or 4 Command Received by the ICC

2017 Abbreviation LEN Lr LT NAD NAK P1 P2 P3 PCB R-APDU R-block RST R-TPDU S-block SUT SW1 SW 2 TCK TPDU TTL UT V Vpp WI WTX Description Length Length of Response Data Field Lower Tester Node Address Negative Acknowledgment Parameter 1 Parameter 2 Parameter 3 Protocol Control Byte Response-APDU Receive ready block Reset Response TPDU Supervisory-block System Under Test Status Word 1 Status Word 2 Check Character Transport Protocol Data Unit Terminal Transport Layer Upper Tester Volt Volts Peak to Peak Waiting time Integer Waiting Time extension Table 2: List of Abbreviations

2017 2. Generic Information about the Tests

2.1. Compliance Demonstration Objective Within EMVCo Level 1 type approval process, EMVCo compliance demonstration objectives are composed of 4 test types:  Type 1: functional – nominal (Valid IUT behavior,)  Type 2: functional – robustness (IUT reaction to invalid events)  Type 3: data- flow (PDUs sent to IUT, PDU received from IUT)  Type 4: control-flow (dynamic interaction between PDUs sent and received) 2.2. Device Under Test for Level 1 Approval The DUT is the Interface Module (IFM) as defined in the “Terminal Level 1 Type Approval Administrative Process” document. 2.3. Test Tool Requirements When, for applied:    Type Approval, a Test Tool is used as a LT, the following requirements should be 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. 2.4. Default Environmental Test Conditions The following environmental conditions shall be used for all the tests described in the present document:  Normal temperature: 23°C (±3°C)  Ambient relative humidity: 50% ± 10% 2.5. Loop-Back Application The Test Bench which is used to implement the EMV Contactless Terminal Type Approval tests is based on the use of the Loop-Back Application. For a description of this application, please refer to 1.3.1 Specification Documents.

2017

2.6. Test Case Format Test codification: The tests described in the following sections are coded this way: [Test Number].[DTS]xyz Where Test Number is the number of the test case:  From 1701 to 1749: T=0 Test Cases  From 1751 on: T=1 Test Cases DTS stands for Terminal L1 Protocol Test Case. b: Optional Subcase Reference xyz:  From 0 to 999 Objective: The objective describes the EMVCo requirements that will be tested. Conditions: This section describes the test conditions needed to reach the acceptance criteria Procedure. Procedure: This section describes the test procedure needed to perform this test. It is designed using flowcharts. Acceptance Criteria: This section describes the pass criteria to meet in order to pass the test. Scenario: The charts describe all the exchanges with the IUT. They use the following conventions:  A scenario step number  An arrow for the exchange direction  Comments column precises the stage of the scenario: Power-Up, APDU exchange and number…  Grey exchange box indicates an error. And under T=1: o a light grey box indicates that an error is generated during the emission of the block o a dark grey box indicates that an error is assumed during the reception of the block

2017

2.7. About the ATR Here is a table with different syntax of ATR designed to help the reading of the following tests. We present seven instances of ATR that are used in the description of the test cases. They shall be read vertically. The last column shows the general purpose of the character: ATR 1 ATR 2 ATR 3 ATR 4 ATR 5 ATR 6 ATR 7 TS T0 TA1 TB1 TC1 TD1 TA2 TB2 TC2 TD2 TA3 TB3 TC3 TCK Basic T=0 ATR. T0 indicates TB1 & TC1 3B T=0 ATR with inverse convent. & non null TC1 T=0 ATR, T0 indicate s TA1 & TB1 3F 3B T0 ->TD1 that -> T=0+TD2 which -> T=14 (so TCK) 3B 60 60 30 E0 11 00 00 00 00 00 10 00 80 0E 6E TD1 -> T=0 and TC2 3B E0 00 00 40 09 Basic T=1 ATR, TD1 -> TD2 -> TA3 and TB3 ( + TCK) 3B E0 00 00 81 31 20 01 71 T=1 ATR, inverse conv. + TD2 -> TB3 & TC3 3F F0 11 00 00 81 61 01 00 00 means direct or inverse convention indicates following TX1 + historical bytes used for computing bit duration indicates Vpp used to compute extraguard time indicates following TX2 + protocol type indicates specific / negotiable mode indicates Vpp conveys WWT integer for T=0 indicates following TX3 + protocol type used to compute IFSC for T=1 used to compute BWT & CWT for T=1 block error detection used for T=1 checks data integrity for T=1, T=14 Table 3: ATR Table

2017

2.8. Warm Reset and Deactivation Windows For all tests where a warm reset or a deactivation shall be performed by the IUT, the LT shall check that this action is initiated within the relevant warm reset or deactivation window. 2.9. T=1 Exchanges: Mandatory S(IFS request) For all T=1 tests, immediately after reception of a correct ATR, the terminal shall send S(IFS request) with 'FE' and wait for relevant response. 2.10.T=1: Terminal Chaining and IFSC In all relevant tests, the LT shall check that if the terminal sends a chained I-block and this block is not the last one of the chain, the block length shall always be equal to IFSC.

2017 3. T=0 Test Cases

3.1. [1701] Etu Measurement in Direct Convention Using T=0 when TA1 and TA2 are Absent (after cold and warm reset) Test codification: 1701.DTSy Test objective: To ensure that the terminal accepts a correct T=0 ATR: focusing on TS, T0, TB1, TC1. To ensure that the terminal continues the card session using the default values of D=1 and F=372 during subsequent exchanges (after the cold and the warm reset). To check the interpretation of procedure bytes INS, 61 and 6C. To check a case 1, case 2 (Le='00'), case 3 and basic case 4 commands. To ensure that the terminal is able to transmit a command with the 'CLA' byte different from '00'. Specifications references: 8.2, 8.3.1, 8.3.2, 8.3.3.1, 8.4 6th bullet, 9.2.2.3.1, 5.3.1.1 Conditions: Under all standard test conditions. ATR = ATR 1 (basic ATR)  y=0: cold ATR  y=1: warm ATR (Incorrect cold ATR that leads to warm reset = 3B 60 05 00 or 3F 60 05 00 according to the convention used in warm reset) Remark: With the simple loop-back concept used here, it is not possible to check what status bytes are actually passed as a mandatory trailer of the R-APDU to the Terminal Application Layer. Procedure: Run the following scenario. Acceptance criteria: The «loop-back» goes on until «End-of-Test command». The case 2 original command sent by the TTL shall have P3='00'. The case 4 commands sent by the TTL shall have P3 conformant with the length of the subsequent data sent. The IUT continues the card session using a current etu having a value of 372/f seconds, the same as the initial etu.

2017 Scenario: Step

  • Direction 1 IUT  2 IUT  Cold Reset ATR (see conditions) Exchanges 3 IUT  4 IUT  5 IUT  6 IUT  7 IUT  8 IUT  9 IUT  10 IUT  11 IUT  12 IUT  13 IUT  14 IUT  15 IUT  16 IUT  '00 A4 04 00 0E' (Case 4) ‘A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' '10 B2 01 0C 00' + '90 00' C '10 B2 01 0C 00' (Case 2) '6C 15' '10 B2 01 0C 15' '61 15' '00 C0 00 00 15' 'C0' '00 82 00 00 10 00 01 02 …0E 0F'+ '90 00' 17 IUT  18 IUT  19 IUT  20 IUT  '00 82 00 00 10' (Case 3) '82' '00 01 … 0F' '90 00' 21 IUT  22 IUT  23 IUT  24 IUT  25 IUT  26 IUT  27 IUT  28 IUT  29 IUT  '00 A4 04 00 0E' (Case 4) 'A4’ "1PAY.SYS.DDF01" '61 04' '00 C0 00 00 04' 'C0' '00 1E 00 00' + '90 00' C '00 1E 00 00 00' (Case 1) '90 00' C Comments EMV Power-Up APDU exchange 1 APDU exchange 2 APDU exchange 3 APDU exchange 4 APDU exchange 5 2017 Step
  • Direction 30 IUT  31 IUT  32 IUT  33 IUT  34 IUT  35 IUT  36 IUT  Exchanges '00 A4 04 00 0E' (Case 4) 'A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' "EOT Cmd" + '90 00' Comments APDU exchange 6 Scenario 1: [1701] Etu Measurement in Direct Convention Using T=0 when TA1 and TA2 are Absent (after cold and warm reset) 2017 3.2. [1702] Etu Measurement in Negotiable Mode (cold and warm ATR) Test codification: 1702.DTSxy Test objective: To check that the terminal accepts a correct T=0 (cold or warm) ATR indicating the negotiable mode (TA2 absent) and continues using the default values of D=1 and F=372, during all subsequent exchanges. Specifications references: 8.3.3.1, 8.4, 9.2.2.3.1, 9.3.1.1 Conditions: Under all standard test conditions.  y=0: cold ATR  y=1: warm ATR (Incorrect cold ATR that leads to warm reset = 3B 60 05 00 or 3F 60 05 00 according to the convention used in warm reset) Subcases according to x value are: x Convention TA1 D 0 '11' 1 1 Direct '12' 2 2 '13' 4 3 '11' 1 4 Inverse '12' 2 5 '13' 4 ATR 3B 70 11 00 00 3B 70 12 00 00 3B 70 13 00 00 3F 70 11 00 00 3F 70 12 00 00 3F 70 13 00 00 Procedure: Run the following scenarios. Acceptance criteria: The «loop-back» goes on until «End-of-Test command». The value of D and F used are their default values i.e. F = 372 and D = 1. The case 2 original command sent by the TTL shall have P3='00'. The case 4 commands sent by the TTL shall have P3 conformant with the length of the subsequent data sent. Accepted option for x=1, 2, 4 and 5: If the terminal supports a proprietary technique for negotiating parameters to be used (if indicated in the ICS), the terminal may send a PPS request block following the receipt of the ATR: this block starts with 'FF' and has a size between 3 and 6 bytes. After reception of this block, the ICC shall remain mute and the terminal is allowed to deactivate within WWT + D x 9600 etus. 2017 Scenarios: Step
  • Direction 1 IUT  2 IUT  Exchanges Cold Reset ATR (see conditions) – according to x 3 IUT  4 IUT  5 IUT  6 IUT  7 IUT  8 IUT  9 IUT  10 IUT  11 IUT  12 IUT  13 IUT  14 IUT  '00 A4 04 00 0E' (Case 4) ‘A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' '00 B2 01 0C 00' + '90 00' C '00 B2 01 0C 00' (Case 2) '6C 15' '00 B2 01 0C 15' 'B2' '00 82 00 00 10 00 01 02 … 0E 0F'+ '90 00' 15 IUT  16 IUT  17 IUT  18 IUT  '00 82 00 00 10' (Case 3) '82' '00 01 02 03… 0F' '90 00' 19 IUT  20 IUT  21 IUT  22 IUT  23 IUT  24 IUT  25 IUT  26 IUT  27 IUT  28 IUT  29 IUT  '00 A4 04 00 0E' (Case 4) 'A4’ "1PAY.SYS.DDF01" '61 04' '00 C0 00 00 04' 'C0' '00 1E 00 00' + '90 00' C '00 1E 00 00 00' (Case 1) '90 00' C '00 A4 04 00 0E' (Case 4) 'A4' Comments EMV Power-Up APDU exchange 1 APDU exchange 2 APDU exchange 3 APDU exchange 4 APDU exchange 5 APDU exchange 6 2017 Step
  • Direction 30 IUT  31 IUT  32 IUT  33 IUT  34 IUT  "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' "EOT Cmd" + '90 00' Exchanges Comments Scenario 2: [1702] Etu Measurement in Negotiable Mode (cold ATR - y=0) Step
  • Direction 1 IUT  2 IUT  3 IUT  4 IUT  Exchanges Cold Reset Cold ATR (see conditions) – y=1 Warm Reset Warm ATR (see conditions) – according to x Comments EMV Power-Up 5 IUT  6 IUT  7 IUT  8 IUT  9 IUT  10 IUT  11 IUT  12 IUT  13 IUT  14 IUT  15 IUT  16 IUT  '00 A4 04 00 0E' (Case 4) ‘A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' '00 B2 01 0C 00' + '90 00' C '00 B2 01 0C 00' (Case 2) '6C 15' '00 B2 01 0C 15' 'B2' '00 82 00 00 10 00 01 02 … 0E 0F'+ '90 00' APDU exchange 1 APDU exchange 2 17 IUT  18 IUT  19 IUT  20 IUT  '00 82 00 00 10' (Case 3) '82' '00 01 02 03… 0F' '90 00' APDU exchange 3 21 IUT  22 IUT  23 IUT  24 IUT  '00 A4 04 00 0E' (Case 4) 'A4’ "1PAY.SYS.DDF01" '61 04' APDU exchange 4 2017 Step
  • Direction 25 IUT  26 IUT  27 IUT  Exchanges '00 C0 00 00 04' 'C0' '00 1E 00 00' + '90 00' Comments 28 IUT  29 IUT  C '00 1E 00 00 00' (Case 1) '90 00' APDU exchange 5 30 IUT  31 IUT  32 IUT  33 IUT  34 IUT  35 IUT  36 IUT  C '00 A4 04 00 0E' (Case 4) 'A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' "EOT Cmd" + '90 00' APDU exchange 6 Scenario 3: [1702] Etu Measurement in Negotiable Mode (warm ATR - y=1) 2017 3.3. [1703] Valid ATR Timings (cold and warm reset) Test codification: 1703.DTSxy Test objective: To ensure that the IUT correctly receives and interprets an ATR with a character-to-character time minimum and maximum. Specifications references: 8.1, 8.4 4th, 5th and 6th bullet Conditions: Under all standard test conditions.  y=1: cold ATR  y=2: warm ATR (Incorrect cold ATR that leads to warm reset = 3B 60 05 00) Subcases according to x value are: x ATR Inter-character timing (initial etus) 3B 11.8 0 20 11.8 00 9.8 (duration of last character) 3B 10,080 1 20 16 00 10 (duration of last character) 3B 10,074 2 20 10,074 00 10 (duration of last character) ATR duration (initial etus) 33.4 10,106 20,158 Procedure: Run the following scenarios. Acceptance criteria: The «loop-back» goes on until «End-of-Test command». The case 2 original command sent by the TTL shall have P3='00'. The case 4 commands sent by the TTL shall have P3 conformant with the length of the subsequent data sent. Scenarios: Step
  • Direction 1 IUT  2 IUT  Cold Reset ATR (see conditions) Exchanges Comments EMV Power-Up 3 IUT  4 IUT  5 IUT  6 IUT  '00 A4 04 00 0E' (Case 4) ‘A4' "1PAY.SYS.DDF01" '61 05' APDU exchange 1 2017 Step
  • Direction 7 IUT  8 IUT  9 IUT  Exchanges '00 C0 00 00 05' 'C0' '00 B2 01 0C 00' + '90 00' 10 IUT  11 IUT  12 IUT  13 IUT  14 IUT  C '00 B2 01 0C 00' (Case 2) '6C 15' '00 B2 01 0C 15' 'B2' '00 82 00 00 10 00 01 …0E 0F'+ '90 00' Comments APDU exchange 2 15 IUT  16 IUT  17 IUT  18 IUT  '00 82 00 00 10' (Case 3) '82' '00 01 02 03… 0E 0F' '90 00' APDU exchange 3 19 IUT  20 IUT  21 IUT  22 IUT  23 IUT  24 IUT  25 IUT  26 IUT  27 IUT  28 IUT  29 IUT  30 IUT  31 IUT  32 IUT  33 IUT  34 IUT  '00 A4 04 00 0E' (Case 4) APDU exchange 4 'A4’ "1PAY.SYS.DDF01" '61 04' '00 C0 00 00 04' 'C0' '00 1E 00 00' + '90 00' C '00 1E 00 00 00' (Case 1) APDU exchange 5 '90 00' C '00 A4 04 00 0E' (Case 4) APDU exchange 6 'A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' "EOT Cmd" + '90 00' Scenario 4: [1703] Valid ATR Timings (cold reset - y=0) 2017 Step
  • Direction 1 IUT  2 IUT  3 4 Cold Reset ATR (see conditions) Warm Reset ATR (see conditions) Exchanges 5 IUT  6 IUT  7 IUT  8 IUT  9 IUT  10 IUT  11 IUT  12 IUT  13 IUT  14 IUT  15 IUT  16 IUT  '00 A4 04 00 0E' (Case 4) ‘A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' '00 B2 01 0C 00' + '90 00' C '00 B2 01 0C 00' (Case 2) '6C 15' '00 B2 01 0C 15' 'B2' '00 82 00 00 10 00 01 … 0E 0F'+ '90 00' 17 IUT  18 IUT  19 IUT  20 IUT  '00 82 00 00 10' (Case 3) '82' '00 01 02 03… 0F' '90 00' 21 IUT  22 IUT  23 IUT  24 IUT  25 IUT  26 IUT  27 IUT  28 IUT  29 IUT  30 IUT  '00 A4 04 00 0E' (Case 4) 'A4’ "1PAY.SYS.DDF01" '61 04' '00 C0 00 00 04' 'C0' '00 1E 00 00' + '90 00' C '00 1E 00 00 00' (Case 1) '90 00' C '00 A4 04 00 0E' (Case 4) Comments EMV Power-Up APDU exchange 1 APDU exchange 2 APDU exchange 3 APDU exchange 4 APDU exchange 5 APDU exchange 6 2017 Step
  • Direction 31 IUT  32 IUT  33 IUT  34 IUT  35 IUT  36 IUT  'A4' "1PAY.SYS.DDF01" '61 05' '00 C0 00 00 05' 'C0' "EOT Cmd" + '90 00' Exchanges Comments Scenario 5: [1703] Valid ATR Timings (warm reset - y=1) 2017 3.4. [1704] ATR Timings Exceeded (cold or warm reset) Test codification: 1704.DTSxy Test objective: To ensure that, if the ICC exceeds one of the ATR maximum timings (inter-character timing and ATR duration), the IUT initiates the deactivation. Specifications references: 8.4 3rd, 4th, 5th and 6th bullet Conditions: Under all standard test conditions.  y=0: cold ATR  y=1: warm ATR (Incorrect cold ATR – with correct timing - that leads to warm reset = 3B 40 00 - no TB1) Subcases according to x value are: x ATR Inter-character timing (initial etus) 3B 10,320 (= 9,600 + 480 + 240) 0 20 16 00 10 (duration of last character) 3B 6,876 1 60 6,876 00 6,876 00 10 (duration of last character) ATR duration (initial etus) 10,346 20,638 (19,200 + 960 + 478) Procedure: Run the following scenarios. Acceptance criteria:  x=0: the terminal deactivates the ICC within 14,400 (4,800 + 9,600) initial etus following the leading edge of the start bit of the TS character of the ATR (cold or warm). No command is transferred.  x=1: the terminal initiates the deactivation sequence within 24,000 initial etus (4,800 + 19,200 initial etus) following the leading edge of the start bit of the TS character. Scenarios: Step
  • Direction 1 IUT  2 IUT  Cold Reset ATR – y=0 Exchanges Comments EMV Power-Up 3 IUT The IFM rejects the card EMV Power-Down (internal call) Scenario 6: [1704] ATR Timings Exceeded (cold reset - y=0) 2017 Step
  • Direction 1 IUT  2 IUT  3 IUT  4 IUT  Cold Reset cold ATR – y=1 Warm Reset warm ATR – y=1 Exchanges Comments EMV Power-Up 5 IUT The IFM rejects the card EMV Power-Down (internal call) Scenario 7: [1704] ATR Timings Exceeded (warm reset - y=1) 2017 3.5. [1705] Inter-Character Timings Measurement (after cold and warm reset) in Same and Opposite Directions
  • INS Complemented in Reception Test codification: 1705.DTSxy Test objective: To ensure that the IUT correctly receives and interprets a cold ATR in T=0, with TC1 having any value in the range ‘00’ to ‘FF’ or TC1 absent and continues the session using the correct inter-character timing. To ensure that the IUT correctly uses the procedure byte equal to complement of INS byte when it sends the data and also a pair of INS complement/INS procedure bytes. To ensure that the IUT respects the inter-character delay between two consecutive characters sent in opposite directions. Specifications references: 8.3.2, 8.3.3.3, 8.3.3.8, 8.3.3.11, 9.2.2.1, 9.2.2.3.1 Conditions: Under all standard test conditions.  y=0: cold ATR  y=1: warm ATR (Incorrect cold ATR that leads to warm reset = 3B 60 05 00) Subcases according to x value are: x TC1 ATR 0 '00' '3B 60 00 00' 1 '80' '3B 60 00 80' 2 'F0' '3B 60 00 F0' 3 'FF' '3B 60 00 FF' 4 'FE' '3B 60 00 FE' 5 absent '3B 20 00' 6 '50' '3B E0 00 50 40 0A' minimum Inter-character timing 12 etus 140 etus 252 etus 12 etus 266 etus 12 etus 92 etus Procedure: Run the following scenarios. Acceptance criteria: The «loop-back» goes on until «End-of-Test command». The delay between the start leading edges of two consecutive characters sent by the terminal respects the minimum inter-character timing supplied in the table above.The delay between the start leading edges of the last character received by the terminal and the first character it sends exceeds 16 etus. The case 4 commands sent by the TTL shall have P3 conformant with th

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