SB nº 185: Biometric Terminal Specification

2017-03-26T00:00:00+00:00 v1.0 Specification Bulletins

Contact

EMV® Specification Bulletin No. 185 First Edition March 2017 Biometric Terminal Specification This Specification Bulletin updates the EMV ICC books to add optional biometric verification functionality. Effective Date and Approval Readiness Date January 1, 2018

Applicability

This Specification Bulletin applies to:  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.3 Book 2  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.3 Book 3  EMV Integrated Circuit Card Specifications for Payment Systems Version 4.3 Book 4 Related Documents  ISO/IEC 7816-4 Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange  ISO/IEC 7816-11 Identification cards – Integrated circuit cards – Personal verification through biometric methods  ISO/IEC 9797-2 Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function  ISO/IEC 18033-2 Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers  ISO/IEC 18033-3 Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers  ISO/IEC 19785-3 Information technology – Common Biometric Exchange Formats Framework – Patron format specifications  ISO/IEC 19794 Information technology – Biometric data interchange formats  ISO/IEC 19794-2 Information technology – Biometric data interchange formats – Part 2: Finger minutiae data

Description

This bulletin introduces biometric verification functionality to the EMV Integrated Circuit Card Specifications for Payment Systems to support the Biometric Cardholder Verification Method (CVM) solution in chip-based contact card transactions. Changes to the EMV ICC books are shown using underlined text.

countries.

Specification Change EMV Book 2 In Section 2 Normative References, add the following reference before the reference for ISO/IEC 18033-3: ISO/IEC 18033-2 Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers Add the following reference after the reference for ISO/IEC 9797-1:2011: ISO/IEC 9797-2 Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function In Section 3 Definitions, add the following terms: Biometric Data Block A block of data with a specific format that contains information captured from a biometric capture device and that could be used as follows:  stored in the card as part of the biometric reference template  sent to the ICC in the data field of the PIN CHANGE/UNBLOCK command  sent to the ICC in the data field of the VERIFY command for offline biometric verification  sent online for verification The format of the BDB is outside the scope of this specification. biometric reference Biometric data stored in the card as reference. Data provided by a biometric template capture device would be compared against the biometric reference template to determine a match. DEM1 A family of data encapsulation mechanisms defined in ISO/IEC 18033-2 I2OSP An integer to octet string conversion primitive function defined in ISO/IEC 18033-2 RSA-KEM A family of key encapsulation mechanisms defined in ISO/IEC 18033-2 RSATransform The RSA exponentiation that is used for encryption and decryption, and generating and verifying a signature In Section 4.1 Abbreviations, add the following entries: BDB Biometric Data Block BEK Biometric Encryption Key BMK Biometric MAC Key HMAC Keyed-hash Message Authentication Code KDF Key Derivation Function SHA-256 Secure Hash Algorithm 256 In Section 7 Personal Identification Number Encipherment, update the section as shown below: 7. Personal Identification Number and Biometric Data Encipherment If supported, Personal Identification Number (PIN) encipherment for offline PIN verification is performed by the terminal using an asymmetric based encipherment mechanism in order to ensure the secure transfer of a PIN from a secure tamper-evident PIN pad to the ICC.

countries.

More precisely, the ICC shall own a public key pair associated with PIN encipherment. The public key is then used by the PIN pad or a secure component of the terminal (other than the PIN pad) to encipher the PIN, and the private key is used by the ICC to decipher the enciphered PIN for verification. The PIN block used in the data field to be enciphered shall be 8 bytes as shown in section 6.5.12 of Book 3. If offline Biometric CVM is supported, the biometric data encipherment is performed by the terminal using both symmetric and asymmetric based encipherment mechanisms in order to ensure the secure transfer of biometric data from the biometric capture device to the ICC. More precisely, the ICC shall own a public/private key pair associated with biometric data encipherment. The public key is then used by the Biometric Processing Application, as shown in Figure 6a of Book 4, or a secure component of the terminal (other than Biometric Processing Application) to encipher a seed, which generates the AES-128 key used to encrypt the biometric data, and the private key is used by the ICC to decipher the seed, which generates the AES-128 key used to decrypt the Enciphered Biometric Data for verification.

7.1 Keys and Certificates If offline PIN encipherment or offline biometric data encipherment is supported, the ICC shall own a unique public/private key pair consisting of a public encipherment key and the corresponding private decipherment key. This specification allows the following two possibilities. 1. The ICC owns a specific ICC PIN Encipherment Private and Public Key. The ICC PIN Encipherment Public Key shall be stored on the ICC in a public key certificate in exactly the same way as for the ICC Public Key for offline dynamic data authentication as specified in section 6.31 The ICC PIN encipherment public key pair has an ICC PIN Encipherment Public Key Modulus of NPE bytes, where NPE ≤ NI ≤ NCA ≤ 248, NI being the length of the Issuer Public Key Modulus (see section 6.1). If NPE > (NI  42), the ICC PIN Encipherment Public Key Modulus is divided into two parts, one part consisting of the NI  42 most significant bytes of the modulus (the Leftmost Digits of the ICC PIN Encipherment Public Key) and a second part consisting of the remaining NPE  (NI  42) least significant bytes of the modulus (the ICC PIN Encipherment Public Key Remainder). The ICC PIN Encipherment Public Key Exponent shall be equal to 3 or 216 + 1. The ICC PIN Encipherment Public Key Certificate is obtained by applying the digital signature scheme as specified in Annex A2.1 on the data in Table 23 using the Issuer Private Key. The terminal shall use the ICC PIN Encipherment key pair also for biometric data encipherment. Field Name Length Description Format Certificate Format 1 Hex Value '04' b Application PAN 10 PAN (padded to the right with Hex 'F's) cn 20 Certificate Expiration 2 MMYY after which this certificate is n 4 Date invalid Certificate Serial Number 3 Binary number unique to this certificate b assigned by the issuer 31In the case that the ICC owns a specific ICC PIN Encipherment Public Key, the format of the data recovered from the certificate is exactly the same as for dynamic data authentication (see Table 14 in section 6.4) however the data that is input to the hash algorithm when computing the certificate (see Table 23) does not include the Static Data to be Authenticated. Hence all the verification steps specified in section 6.4 are performed except in step 5 the static data to be authenticated is not included in the concatenation of data elements to be hashed in step 6.

countries.

Hash Algorithm Indicator 1 Identifies the hash algorithm used to b produce the Hash Result in the digital signature scheme 32 ICC PIN Encipherment 1 Identifies the digital signature algorithm b Public Key Algorithm to be used with the ICC PIN Indicator Encipherment Public Key 32 ICC PIN Encipherment 1 Identifies the length of the ICC PIN b Public Key Length Encipherment Public Key Modulus in bytes ICC PIN Encipherment 1 Identifies the length of the ICC PIN b Public Key Exponent Encipherment Public Key Exponent in Length bytes ICC PIN Encipherment NI – 42 If NPE  NI – 42, consists of the full ICC b Public Key or Leftmost PIN Encipherment Public Key padded to Digits of the ICC PIN the right with NI – 42 – NPE bytes of Encipherment Public Key value 'BB' If NPE > NI – 42, consists of the NI – 42 most significant bytes of the ICC PIN Encipherment Public Key33 ICC PIN Encipherment 0 or NPE Present only if NPE > NI – 42 and b Public Key Remainder – NI + 42 consists of the NPE – NI + 42 least significant bytes of the ICC PIN Encipherment Public Key ICC PIN Encipherment 1 or 3 ICC PIN Encipherment Public Key b Public Key Exponent Exponent equal to 3 or 216 + 1 Table 23: ICC PIN Encipherment Public Key Data to be Signed by Issuer (i.e. input to the hash algorithm) 2. The ICC does not own a specific ICC PIN encipherment public key pair, but owns an ICC public key pair for offline dynamic data authentication as specified in section 6.1. This key pair can then be used for PIN encipherment and biometric data encipherment. The ICC Public Key is stored on the ICC in a public key certificate as specified in section 6.1. The first step of PIN encipherment or biometric data encipherment shall be the retrieval of the public key to be used by the terminal for the encipherment of the PIN or biometric data. This process takes place as follows. 1. If the terminal has obtained all the data objects specified in Table 24 from the ICC, then the terminal retrieves the ICC PIN Encipherment Public Key in exactly the same way as it retrieves the ICC Public Key for offline dynamic data authentication (see section 6). 2. If the terminal has not obtained all the data objects specified in Table 24, but has obtained all the data objects specified in Table 12, then the terminal retrieves the ICC Public Key as described in section 6. 3. If the conditions under points 1 and 2 above are not satisfied or if as described in Section 6.1.2 for dynamic data authentication, the Issuer Public Key Certificate has been revoked, then PIN encipherment has failed and the Offline Enciphered PIN CVM has failed, or biometric data encipherment has failed and the Offline Biometric CVM has failed. 32 See Annex B for specific values assigned to approved algorithms. 33 As can be seen in Annex A2.1, NI − 22 bytes of the data signed are retrieved from the signature. Since the length of the first through the eighth data elements in Table 23 is 20 bytes, there are NI − 22 − 20 = NI − 42 bytes left for the data to be stored in the signature.

countries.

Tag — '8F' '90' '92' '9F32' '9F2D' '9F2E' '9F2F' Length 5 1 NCA NI – NCA + 36 1 or 3 NI 1 or 3 NPE – NI + 42 Value Registered Application Provider Identifier (RID) Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Remainder, if present Issuer Public Key Exponent ICC PIN Encipherment Public Key Certificate ICC PIN Encipherment Public Key Exponent ICC PIN Encipherment Public Key Remainder, if present Format b b b b b b b b Table 24: Data Objects Required for Retrieval of ICC PIN Encipherment Public Key After Section 7.2 PIN Encipherment and Verification, add the following new section:

7.3 Biometric Data Encipherment and Recovery The exchange and decipherment of Enciphered Biometric Data between terminal and ICC takes place in the following steps, as illustrated in Book 3 Figure 12a. 1. The biometric template is captured on a biometric capture device and the Biometric Data Block (BDB) is constructed by the Biometric Processing Application. 2. The terminal issues a GET CHALLENGE command to the ICC to obtain an 8-byte unpredictable number from the ICC. When the response to the GET CHALLENGE command is anything other than an 8 byte data value with SW1 SW2 = '9000', then the terminal considers that the Offline Biometric CVM has failed. 3. Using the public key specified above, the terminal shall generate the Enciphered Biometric Data, as follows: a) The public key recovered, as described in section 7.1, has exponent e and modulus n. b) The terminal generates a random number r, which has the same number of bits as n, and shall be less than n, i.e. r < n. Then the terminal converts r into a byte string R as defined in ISO/IEC 18033-2: R = I2OSP(r, Len(n)). c) The random number R is then used to generate K using the key derivation function KDF1 defined in ISO/IEC 18033-2 with SHA-256 as the hash function: K= KDF1 (R, 48). d) Split K from step c into two keys K = (BEK || BMK), where the 16 most significant bytes of K are the Biometric Encryption Key BEK used to encrypt the biometric data, and the 32 least significant bytes of K are the Biometric MAC Key BMK used to generate the MAC in step g. e) The random number R shall be enciphered using the RSA Transform algorithm as defined in ISO/IEC 18033-2: C = RSATransform (R, e, n). The result is the Enciphered Biometric Key Seed. f) Encrypt the data specified in Table 25a using the DEM1 mechanism as defined in ISO/IEC 18033-2, with the Biometric Encryption Key BEK generated in step d, in order to generate the Enciphered Biometric Data. The symmetric cipher (SC) used in the DEM1 mechanism shall be the SC1 defined in ISO/IEC 18033-2 with the block cipher being the AES-128 defined in ISO/IEC 180333. g) Use the Biometric MAC Key BMK generated in step d to generate an 8-byte MAC on the Enciphered Biometric Data according to the DEM1 mechanism as defined in ISO/IEC 18033-2. The MAC algorithm used in the DEM1 mechanism shall be HMAC, as defined in

countries.

ISO/IEC 9797-2 using SHA-256 as the hash function. Note that the label L defined in DEM1 shall be null, and thus according to DEM1 the HMAC is computed over the Enciphered Biometric Data appended with 8 zero bytes. Field Name Length Description Format ICC Unpredictable 8 Unpredictable number obtained b Number from the ICC with the GET CHALLENGE command Biometric Solution ID 1 Length of Biometric Solution ID b Length Biometric Solution ID value of As defined in Book 3 Table 43a b Biometric Solution ID Length Biometric Type Length 1 Length of Biometric Type data b element Biometric Type value of As defined in Book 3 Table 43b b Biometric Type Length Biometric Subtype 1 As defined in Book 3 Table 43c b Biometric Data Block (BDB) Length Biometric Data Block (BDB) 2 Length of BDB data element b value of BDB A block of data with a specific b Length format that contains information captured from a biometric capture device Table 25a: Data to be enciphered for Biometric Encipherment Note: The length bytes in Table 25a are simple binary bytes, and are not coded as BER-TLV length fields. 4. The terminal shall construct the Biometric Verification Data Template, and order the data elements as indicated in Table 25b. a) The value of Biometric Type is set as the plaintext value referenced in step 3-f b) The value of Biometric Solution ID is set as the plaintext value referenced in step 3-f c) The value of Enciphered Biometric Key Seed is set as the value generated in step 3-e d) The value of Enciphered Biometric Data is set as the value generated in step 3-f e) The value of MAC of Enciphered Biometric Data is set as the value generated in step 3-g. Tag Length Field Name '81' var. '90' var. 'DF50' NI 'DF51' var. 'DF52' 8 Biometric Type Biometric Solution ID Enciphered Biometric Key Seed Enciphered Biometric Data MAC of Enciphered Biometric Data Table 25b: Biometric Verification Data Template Note: The data objects in Table 25b are BER-TLV coded. The length of all TLV coded data objects are coded on the minimum number of bytes (that is, on 1 byte if < 128, on 2 bytes if in the range 128 to 255, and so on). See Book 3 Annex B.2 for BER-TLV coding rules."

countries.

5. The terminal shall construct and issue VERIFY command(s) as following: a) If the total length of the Biometric Verification Data Template is no more than 255 bytes, the terminal shall set Biometric Verification Data Template as the data field of the single VERIFY command. b) If the total length of the Biometric Verification Data Template is more than 255 bytes, the terminal shall divide the Biometric Verification Data Template into 255 byte data blocks. The last data block may be 1 to 255 bytes in length. Then the terminal shall set these data blocks as the data fields of the commands and chain the commands using command chaining defined in Book 3 Section 6.5.13. c) The terminal shall issue the VERIFY command(s). 6. With the ICC Private key, the ICC decrypts the Enciphered Biometric Data in the following way: a) The private key owned by the ICC has exponent d and modulus n. b) The ICC decrypts the Enciphered Biometric Key Seed using the RSA Transform algorithm as defined in ISO/IEC 18033-2: R = RSATransform (C, d, n), where C is Enciphered Biometric Key Seed (tag 'DF50'). c) The ICC generates two keys using the key derivation function KDF1 as defined in ISO/IEC 18033-2 with SHA-256 as the hash function: K = KDF1 (R, 48). The 16 most significant bytes of K is the Biometric Encryption Key BEK and the 32 least significant bytes of K is the Biometric MAC Key BMK. d) The ICC uses the BMK generated in step c to generate an 8-byte MAC on the Enciphered Biometric Data according to the DEM1 mechanism as defined in ISO/IEC 18033-2. The MAC algorithm used in the DEM1 mechanism shall be HMAC, as defined in ISO/IEC 9797-2 using SHA-256 as the hash function. Note that the label L defined in DEM1 shall be null, and thus according to DEM1 the HMAC is computed over the Enciphered Biometric Data appended with 8 zero bytes. If the generated MAC is not equal to the MAC of Enciphered Biometric Data (tag 'DF52') included in the Biometric Verification Data Template, Offline Biometric CVM has failed. e) The ICC decrypts the Enciphered Biometric Data using the DEM1 mechanism as defined in ISO/IEC 18033-2, with the Biometric Encryption Key BEK generated in step c. The symmetric cipher (SC) used in the DEM1 mechanism shall be the SC1 defined in ISO/IEC 18033-2 with the block cipher being the AES-128 defined in ISO/IEC 180333. 7. The ICC verifies whether the ICC Unpredictable Number recovered in step 6-e is equal to the ICC Unpredictable Number generated by the ICC with the GET CHALLENGE command. If they are not the same, Offline Biometric CVM has failed. 8. The ICC verifies whether the Biometric Solution ID recovered in step 6-e is equal to the Biometric Solution ID (tag '90') included in the Biometric Verification Data Template. If they are not the same, Offline Biometric CVM has failed. 9. The ICC verifies whether the Biometric Type recovered in step 6-e is equal to the Biometric Type (tag '81') included in the Biometric Verification Data Template. If they are not the same, Offline Biometric CVM has failed. The ordering of steps 1 and 2 is representative, not mandatory. Key retrieval as described in Section 7.1 and steps 1 and 2 can be conducted in any order, provided they are all completed before the terminal applies the RSA-KEM algorithm (as described in step 3).

countries.

EMV Book 3 In Section 2 Normative References, add the following reference after the reference for ISO/IEC 7816-6: ISO/IEC 7816-11 Identification cards – Integrated circuit cards – Personal verification through biometric methods Add the following references as the new last three rows: ISO/IEC 19785-3 Information technology – Common Biometric Exchange Formats Framework – Patron format specifications ISO/IEC 19794 Information technology – Biometric data interchange formats ISO/IEC 19794-2 Information technology – Biometric data interchange formats – Part 2: Finger minutiae data In Section 3 Definitions, add the following terms: Biometric Data Block A block of data with a specific format that contains information captured from a biometric capture device and that could be used as follows:  stored in the card as part of the biometric reference template  sent to the ICC in the data field of the PIN CHANGE/UNBLOCK command  sent to the ICC in the data field of the VERIFY command for offline biometric verification  sent online for verification The format of the BDB is outside the scope of this specification. biometric reference Biometric data stored in the card as reference. Data provided by a biometric template capture device would be compared against the biometric reference template to determine a match. biometric verification The process of determining that the biometrics presented, such as finger, palm, iris, voice or facial, are valid. command chaining A mechanism where consecutive command-response pairs can be chained. facial verification The process of determining that the face presented is valid. finger verification The process of determining that the finger presented is valid. iris verification The process of determining that the iris presented is valid. palm verification The process of determining that the palm presented is valid. voice verification The process of determining that the voice presented is valid. In Section 4.1 BDB BEK BHT BIT BMK CBEFF CCYYMMDD SHA-256 Abbreviations, add the following entries: Biometric Data Block Biometric Encryption Key Biometric Header Template Biometric Information Template Biometric MAC Key Common Biometric Exchange Formats Framework Year (4 digits), Month, Day Secure Hash Algorithm 256 In Section 4.2 Notations, add the following notation: MIN (x, y) The smaller of values x and y.

countries.

In Section 6.3.5 Coding of the Status Bytes, add the following entries to Table 4, after "Checking errors": '68' '00' Command chaining failed '68' '83' Last command of chain was expected but not received '68' '84' Command chaining not supported Add the following entries to Table 5: '68' '00' X '68' '83' X '68' '84' X Update Section 6.5.7 GET DATA Command-Response APDUs as shown below:

6.5.7 GET DATA Command-Response APDUs 6.5.7.1 Definition and Scope The GET DATA command is used to retrieve a primitive or constructed data object not encapsulated in a record within the current application. The usage of the GET DATA command in this specification is limited to the retrieval of the following primitive or constructed data objects that are defined in Annex A and interpreted by the application in the ICC:  ATC (tag '9F36')  Last Online ATC Register (tag '9F13')  PIN Try Counter (tag '9F17')  Log Format (tag '9F4F')  Biometric Try Counters Template ('BF4C')  Preferred Attempts Template ('BF4D') 6.5.7.2 Command Message The GET DATA command message is coded as shown in Table 16: Code CLA INS P1 P2 Lc Data Le Value '80' 'CA' '9F36', '9F13', '9F17', '9F4F', 'BF4C' and 'BF4D' Not present Not present '00' Table 16: GET DATA Command Message 6.5.7.3 Data Field Sent in the Command Message The data field of the command message is not present.

6.5.7.4 Data Field Returned in the Response Message

countries.

The data field of the response message contains the primitive or constructed data object referred to in P1 P2 of the command message (in other words, including its tag and its length).

6.5.7.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. Update Section 6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs as shown below:

6.5.10 PIN CHANGE/UNBLOCK Command-Response APDUs 6.5.10.1 Definition and Scope The PIN CHANGE/UNBLOCK command is a post-issuance command. Its purpose is to provide the issuer the capability either to unblock the PIN or to simultaneously change and unblock the reference PIN. It also provides the issuer the capability either to unblock the specified Biometric Type, or to simultaneously update the specified biometric reference template and unblock the associated Biometric Type, or to store the biometric reference templates in the card during enrollment. If the PIN CHANGE/UNBLOCK command is used either to unblock the PIN or to simultaneously change and unblock the reference PIN, upon successful completion of the PIN CHANGE/UNBLOCK command, the card shall perform the following functions:  The value of the PIN Try Counter shall be reset to the value of the PIN Try Limit.  If requested, the value of the reference PIN shall be set to the new PIN value. If PIN data is transmitted in the command it shall be enciphered for confidentiality. Note: The reference PIN, which is stored within the card, is the one that is associated with the application and which the card uses to check the Transaction PIN Data transmitted within the VERIFY command. If the PIN CHANGE/UNBLOCK command is used either to unblock the specified Biometric Type, or to simultaneously enroll or update the specified biometric reference template and unblock the associated Biometric Type, then upon successful completion of the command the card shall perform the following functions:  In order to unblock the Biometric Type, the value of the Biometric (Facial, Finger, Iris, Palm, or Voice) Try Counter for the Biometric Type being updated shall be reset to the value of the associated Biometric (Facial, Finger, Iris, Palm, or Voice) Try Limit.  If requested, the biometric reference templates in the card shall be set to or replaced by the new template in the Biometric Data Block (BDB), received in the PIN CHANGE/UNBLOCK command. The BDB transmitted in the PIN CHANGE/UNBLOCK command shall be enciphered for confidentiality. Due to the large size of the BDB, multiple PIN CHANGE/UNBLOCK commands are typically required, as described in Section 6.5.13. Note: The biometric reference template, which is stored within the card, is the one that is associated with the application and which the card uses to check the template captured by the biometric capture device and transmitted within the VERIFY command.

countries.

6.5.10.2 Command Message The PIN CHANGE/UNBLOCK command message is coded as shown in Table 19: Code CLA INS P1 P2 Lc Data Value '8C','84', '9C' or '94'; coding according to the secure messaging specified in Book 2 and command chaining specified in Section 6.5.13 '24' '00' '00', '01', '02', '03', '04' Number of data bytes If P2 = '00', then the data field contains the MAC data component coded according to the secure messaging specified in Book 2. If P2 = '03', then the data field contains the Biometric Type, as shown in Table 43b, and the MAC data component coded according to the secure messaging specified in Book 2. The P2 values '01', '02', and '04' are reserved for the payment systems, but the data field should contain one of the following:  Enciphered PIN data component, if present, and MAC data component; coding according to the secure messaging specified in Book 2  The following enciphered biometric data:

Biometric Type, as shown in Table 43b
Biometric Subtype, as shown in Table 43c
Biometric Solution ID, as shown in Table 43a
Biometric Data Block (BDB) followed by the MAC data component coded according to the secure messaging specified in Book 2. If the length of the enciphered biometric data plus MAC is greater than 255 bytes, then the data should be sent to the card over several PIN CHANGE/UNBLOCK commands. The data encipherment and MACing should be applied to each command. Le Not present Table 19: PIN CHANGE/UNBLOCK Command Message P2: If P2 is equal to '00', the reference PIN is unblocked and the PIN Try Counter is reset to the PIN Try Limit. There is no PIN update, since the PIN CHANGE/UNBLOCK command does not contain a new PIN value. If P2 is equal to '03', the try counter associated with the Biometric Type specified in the data field of the command is reset to the try limit of the specified Biometric Type. There is no biometric update, since the PIN CHANGE/UNBLOCK command does not contain a new BDB. The usage of P2 equal to '01', '02', '04' is reserved for payment systems. Any other value of P2 allowing PIN/Biometric Type unblocking and/or PIN/biometric reference template changing is out of the scope of this specification and shall be described for each payment system individually. countries.

6.5.10.3 Data Field Sent in the Command Message The data field of the command message contains one of the following:  The PIN data component, if present, followed by the MAC data component coded according to the secure messaging format specified in Book 2.  The Biometric Type, Biometric Subtype, Biometric Solution ID and BDB followed by the MAC data component coded according to the secure messaging format specified in Book 2.  The Biometric Type followed by the MAC data component coded according to the secure messaging format specified in Book 2.

6.5.10.4 Data Field Returned in the Response Message No data field is returned in the response message.

6.5.10.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. Update Section 6.5.12 VERIFY Command-Response APDUs as shown below:

6.5.12 VERIFY Command-Response APDUs 6.5.12.1 Definition and Scope If the CVM chosen from the CVM List is an offline PIN, as described in section 10.5, the VERIFY command initiates in the ICC the comparison of the Transaction PIN Data sent in the data field of the command with the reference PIN data associated with the application. The manner in which the comparison is performed is proprietary to the application in the ICC. If the CVM chosen from the CVM List is any of the offline biometric verification methods, the VERIFY command initiates in the ICC the comparison of the biometric template captured by the biometric capture device and sent in the data field of the command with the biometric reference template(s) associated with the application. The manner in which the comparison is performed is proprietary to the application in the ICC. The biometric data to be sent in the VERIFY command shall be enciphered for confidentiality, as described in Book 2 Section 7.3. Due to the large size of the biometric data to be sent in the VERIFY command, command chaining is typically required, as described in Book 3 Section 6.5.13.

6.5.12.2 Command Message The VERIFY command message is coded as shown in Table 22: Code CLA INS P1 P2 Lc Value '00' or '10'; coding according to the command chaining specified in Book 3 Section 6.5.13 '20' '00' Qualifier of the reference data (see Table 23) Var.

countries.

Data Le Transaction PIN Data or Biometric Verification Data Template Not present Table 22: VERIFY Command Message Table 23 defines the qualifier of the reference data (P2): b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 0 0 0 0 0 0 As defined in ISO/IEC 7816-4 1 0 0 0 0 0 0 0 Plaintext PIN, format as defined below 1 0 0 0 0 x x x RFU for this specification 1 0 0 0 1 0 0 0 Enciphered PIN, format as defined in Book 2 1 0 0 0 1 0 0 1 Enciphered Biometric 1 0 0 0 1 0 1 x RFU for this specification 1 0 0 0 1 1 x x RFU for the individual payment systems 1 0 0 1 x x x x RFU for the issuer Table 23: VERIFY Command qualifier of reference data (P2) The processing of the VERIFY command in the ICC will be defined in combination with the CVM rules as specified in section 10.5. The plaintext offline PIN block shall be formatted as follows: C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F where: Name C Control field N PIN length P PIN digit P/F PIN/filler F Filler Value 4 bit binary number with value of 0010 (Hex '2') 4 bit binary number with permissible values of 0100 to 1100 (Hex '4' to 'C') 4 bit binary number with permissible values of 0000 to 1001 (Hex '0' to '9') Determined by PIN length 4 bit binary number with a value of 1111 (Hex 'F') Table 24: Plaintext Offline PIN Block Format P2 = '00' indicates that no particular qualifier is used. The processing of the VERIFY command in the ICC should know how to find the PIN data unambiguously.

6.5.12.3 Data Field Sent in the Command Message The data field of the command message contains the value field of tag '99'.

6.5.12.4 Data Field Returned in the Response Message No data field is returned in the response message.

6.5.12.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. If command chaining is required, when the VERIFY command has CLA = '10' and the SW1 SW2 ≠ '9000', the terminal shall discontinue sending the remainder of the chained VERIFY commands.

countries.

When the VERIFY command has CLA = '10' and command chaining fails, the ICC shall return SW1 SW2 = '6800' to indicate command chaining failed (due to a failure other than the specific error conditions described in 6.5.13). For the VERIFY command with CLA = '00', when for the currently selected application the comparison between the Transaction PIN Data and the reference PIN data, or the comparison between the biometric template captured on the biometric capture device and contained in the command and the biometric reference template stored on the card, performed by the VERIFY command fails, the ICC shall return SW2 = 'Cx', where 'x' represents the number of retries still possible. When the card returns 'C0', no more retries are left, and the CVM shall be blocked. Any subsequent VERIFY command applied in the context of that application shall then fail with SW1 SW2 = '6983'. After Section 6.5.12 VERIFY Command-Response APDUs, add the following new section:

6.5.13 Command Chaining When more than one command is required to perform a function, multiple VERIFY or PIN CHANGE/UNBLOCK commands need to be sent to the card, in which case the consecutive commandresponse pairs can be chained. As defined in ISO/IEC 7816-4, bit 5 of the class byte CLA of the command is used to indicate command chaining, as shown in Table 24a. b8 b7 b6 b5 b4 b3 b2 b1 Meaning - - - x - - - - Command chaining control - - - 0 - - - - – The command is the last or only command of a chain - - - 1 - - - - – The command is not the last command of a chain Table 24a: Values of CLA in command chaining As defined in ISO/IEC 7816-4, in response to a command that is not the last command of a chain, SW1 SW2 is set to '9000', meaning that the process has been completed so far. Moreover, the following specific error conditions may occur.  If SW1 SW2 is set to '6883', then the last command of the chain was expected but was not received.  If SW1 SW2 is set to '6884', then command chaining is not supported. Update Section 10.5 Cardholder Verification as shown below:

10.5 Cardholder Verification Purpose: Cardholder verification is performed to ensure that the person presenting the ICC is the person to whom the application in the card was issued. Conditions of Execution: Ability of the ICC to support at least one cardholder verification method is indicated in the Application Interchange Profile, as shown in Annex C1. If this bit is set to 1, the terminal shall use the cardholder verification related data in the ICC to determine whether one of the issuer-specified cardholder verification methods (CVMs) shall be executed. This process is described below. Sequence of Execution:

countries.

This function may be performed any time after Read Application Data and before completion of the terminal action analysis. Description: The CVM List (tag '8E') is a composite data object consisting of the following: 1. An amount field (4 bytes, binary format), referred to as ‘X’ in Table 40: CVM Condition Codes. ‘X’ is expressed in the Application Currency Code with implicit decimal point. For example, 123 (hexadecimal '7B') represents £1.23 when the currency code is '826'. 2. A second amount field (4 bytes, binary format), referred to as ‘Y’ in Table 40. ‘Y’ is expressed in Application Currency Code with implicit decimal point. For example, 123 (hexadecimal '7B') represents £1.23 when the currency code is '826'. 3. A variable-length list of two-byte data elements called Cardholder Verification Rules (CV Rules). Each CV Rule describes a CVM and the conditions under which that CVM should be applied (see Annex C3). If the CVM List is not present in the ICC, the terminal shall terminate cardholder verification without setting the ‘Cardholder verification was performed’ bit in the TSI. Note: A CVM List with no Cardholder Verification Rules is considered to be the same as a CVM List not being present. If the CVM List is present in the ICC, the terminal shall process each rule in the order in which it appears in the list according to the following specifications. Cardholder verification is completed when any one CVM is successfully performed or when the list is exhausted. If the terminal encounters formatting errors in the CVM List such as a list with an odd number of bytes (that is, with an incomplete CVM Rule), the terminal shall terminate the transaction as specified in Book 3 section 7.5. If any of the following is true:  the conditions expressed in the second byte of a CV Rule are not satisfied, or  data required by the condition (for example, the Application Currency Code or Amount, Authorised) is not present, or  the CVM Condition Code is outside the range of codes understood by the terminal (which might occur if the terminal application program is at a different version level than the ICC application), then the terminal shall bypass the rule and proceed to the next. If there are no more CV Rules in the list, cardholder verification has not been successful, and the terminal shall set the ‘Cardholder verification was not successful’ bit in the TVR to 1. If the conditions expressed in the second byte of the CV Rule are satisfied, the terminal next checks whether it recognises the CVM coded in the first byte of the CV Rule and proceeds according to the following steps: 1. If the CVM is recognised, the terminal next checks to determine whether it supports the CVM.  If the CVM is supported, the terminal shall attempt to perform it.

If the CVM is performed successfully, cardholder verification is complete and successful. If the CVM just processed was ‘Fail CVM Processing’, the terminal shall set the ‘Cardholder verification was not successful’ bit in the countries. TVR (b8 of byte 3) to 1 and no further CVMs shall be processed regardless of the setting of b7 of byte 1 in the first byte of the CV Rule.
If the CVM is not performed successfully, processing continues at step 2.  If the CVM is not supported, processing continues at step 2. In addition, the terminal shall perform the following:
Set the ‘PIN entry required and PIN pad not present or not working’ bit (b5 of byte 3) of the TVR to 1 for the following cases:  The CVM was online PIN and online PIN was not supported  The CVM included any form of offline PIN, and neither form of offline PIN was supported.
Set the ‘A selected Biometric Type not supported’ bit (b2 of byte 4) of the TVR to 1 for the following case:  The CVM included any Biometric Type, and no common Biometric Type was supported. If the CVM is not recognised, the terminal shall set the ‘Unrecognised CVM’ bit in the TVR (b7 of byte 3) to 1 and processing continues at step 2. 2. If cardholder verification was not completed in step 1 (that is, the CVM was not recognised, was not supported, or failed), the terminal examines b7 of byte 1 of the CV Rule.  If b7 is set to 1, processing continues with the next CV Rule, if one is present.  If b7 is set to 0, or there are no more CV Rules in the list, cardholder verification is complete and unsuccessful. The terminal shall set the ‘Cardholder verification was not successful’ bit in the TVR (b8 of byte 3) to 1. When cardholder verification is completed, the terminal shall:  set the CVM Results according to Book 4 section 6.3.4.5  set the ‘Cardholder verification was performed’ bit in the TSI to 1. After Section 10.5.5 CVM Processing Logic, add the following new section:

10.5.6 Offline Biometric Verification Processing This section applies to the verification by the ICC of an enciphered biometric template presented by the terminal. The offline biometric verification methods include offline facial, finger, iris, palm, and voice. If any of the offline biometric verification methods is the selected CVM, offline biometric verification processing may not be successfully performed for any of the following reasons:  The terminal does not support the selected offline Biometric CVM. In this case, the terminal shall set the ‘A selected Biometric Type not supported’ bit in the TVR to 1.  The terminal supports the selected offline Biometric CVM, but the biometric capture device is malfunctioning. In this case, the terminal shall set the ‘Biometric required but Biometric capture device not working’ bit in the TVR to 1.  The terminal bypassed the selected offline Biometric Subtype entry at the direction of either the merchant or the cardholder. In this case, the terminal shall set the ‘Biometric required, Biometric capture device present, but Biometric Subtype entry was bypassed’ bit in the TVR to 1.  The selected offline Biometric CVM is blocked upon initial use of the VERIFY command or if recovery of the Enciphered Biometric Data has failed (the ICC returns SW1 SW2 = '6983' or '6984' in response to the final VERIFY command). In this case, the terminal shall set the ‘Biometric Try Limit exceeded’ bit in the TVR to 1.

countries.

 The number of remaining tries of the selected offline Biometric CVM is reduced to zero (indicated by an SW1 SW2 of '63C0' in the response to the final VERIFY command). In this case, the terminal shall set the ‘Biometric Try Limit exceeded’ bit in the TVR to 1.  The terminal does not support the format specified in any of the Biometric Information Templates (BITs), as specified in Annex C7, retrieved from the card for the selected Biometric Type. In this case, the terminal shall set 'Biometric template format not supported' bit in the TVR to 1. When the VERIFY command is chained, the SW1 SW2 in response to the final VERIFY command indicates the outcome of biometric verification processing. If SW1 SW2 = '6800', '6883' or '6884', the terminal shall consider this CVM unsuccessful and shall continue cardholder verification processing in accordance with the card’s CVM List. The only case in which the selected offline biometric verification processing is considered successful is when the ICC returns an SW1 SW2 of '9000' in response to a single or all of multiple VERIFY command(s). In this case, the terminal shall set 'Biometric performed and successful' bit in the TVR to 1. As shown in Figure 12a, the terminal shall determine if tag '87' and '88' (format owner and format type) of the BIT in the Card BIT Group Template, as specified in Annex C8, match tag '87' and '88' of any BIT in the Terminal BIT Group Template, as specified in Annex C8, using the following procedures:  If the BIT in the Card BIT Group Template does not contain level 2 Biometric Header Template (BHT) 1 and BHT 2, as shown in Table 43a, and if the values of tag '87' and '88' of the BIT in the Card BIT Group Template are equal to the values of tag '87' and '88' (respectively) of any BIT in the Terminal BIT Group Template, the terminal shall determine that there is a match.  If the BIT in the Card BIT Group Template contains level 2 BHT 1 and BHT 2, as shown in Table 43a, and if the values of tag '87' and '88' in the BHT 1 of the BIT in the Card BIT Group Template are equal to the values of tag '87' and '88' (respectively) of any BIT in the Terminal BIT Group Template, the terminal shall determine that there is a match.  Otherwise, the terminal shall determine that there is no match. Moreover, the terminal shall use the sequence of BITs in the Card BIT Group Template and the Preferred Attempts Template (tag 'BF4D') to determine which Biometric Subtype the terminal shall ask the user to present for verification. As an example, if the Preferred Finger Attempts is configured as 3 and the Card BIT Group Template is configured as following:  BIT 1 – right index finger  BIT 2 – right middle finger Then, if Finger is selected by the terminal as the CVM, the terminal shall ask the user to present the right index finger first since it is first in the list. If the verification of the right index finger fails after 3 tries and the Finger Try Counter is not zero, the terminal shall move to the next finger on the list and ask the user to present the right middle finger up to 3 tries. The process continues until either the ICC returns SW1 SW2 = '9000' or the Finger Try Counter is zero. After Section 10.5.5 CVM Processing Logic, add the following new section:

10.5.7 Online Biometric Verification Processing If online biometric verification is a required CVM as determined by the process described in Figure 8, the processing may not be successfully performed for any one of the following reasons:

countries.

 The terminal does not support the selected online Biometric CVM. In this case, the terminal shall set the ‘A selected Biometric Type not supported’ bit in the TVR to 1.  The terminal supports the selected online Biometric CVM, but the biometric capture device is malfunctioning. In this case, the terminal shall set the ‘Biometric required but Biometric capture device not working’ bit in the TVR to 1.  The terminal bypassed the selected online Biometric Subtype entry at the direction of either the merchant or the cardholder. In this case, the terminal shall set the ‘Biometric required, Biometric capture device present, but Biometric Subtype entry was bypassed’ bit in the TVR to 1.  The terminal does not support the format specified in any of the BITs retrieved from the card for the selected Biometric Type. In this case, the terminal shall set 'Biometric template format not supported' bit in the TVR to 1. If the online biometric verification is successfully captured, the terminal shall set the 'Online CVM captured' bit in the TVR to 1. In this case, cardholder verification is considered successful and complete.

countries.

Update Figure 8 CVM Processing (Part 1 of 5) as shown below: CVM List Processing NO AIP supports CVM processing YES Set TVR 'ICC Data Missi ng' NO CVM List present with CV rules? YES D Set CVM Results to 3F0000 - 'No CVM performed' Terminal selects fi rst or next CV Rule in CVM Li st A * Note: For EMV d efin ed codes, suppor t is indi cated in Terminal Capab ilitie s. For non-EMV defined codes, suppor t is known imp licitly. For Co mbi nation CVMs, both CV Ms must be su pported. For Biometric CVMs, suppor t is indi cated in Biometric Termin al Capab ilitie s YES Is CVM Code NO supported? * CVM YES Condition = 'Al ways'? NO CVM Condition = 'If termi nal supports CVM'? NO CVM Condition rules YES satisfied? (See S in Part 2 of flow) NO YES YES NO B D Any more CVM entries? CVM = Fail CVM YES C NO T erm inal recognises CVM? NO Set 'Unrecognised CVM' in TVR YES Is CVM Code NO Supported? * Perform 'Selected CVM Code is not Supported' Logic (See T in Part 2 of YES flow) Perform CV M (See U in Part 3

Online PIN V i n Part 3 – Signature B W i n Part 3 – No CVM Req d X in Par t 4 – Offline PIN Z i n Part 5 – Combo. CVM R in Part 6 – Offline Biometri c Q i n Part 7 – Online Biometric) CVM Y ES Failed '1'
App ly next CVM C CV Rule Byte 1 bit 7 =... '0' Fail CV M processing Set CVM Results to Failed (See Y in Part 5 of flow) Set 'Cardhol der verification not successful' in TVR. C CVM Fa ile d? NO Set Cardholder Verification was Performed in TSI. A CVM List Processing Complete Figure 8: CVM Processing (Part 1 of 7) countries. Add the following under Figure 8: Note: When a biometric card is presented to a terminal without biometric support, the Biometric CVM Code is either not recognized or recognized but not supported by the terminal. As described in Book 3 Section 10.5, the terminal will process the next CVM if CVM Code Byte 1 bit 7 has the value 1b, or will complete cardholder verification, set CVM Results to 'Failed' and set 'Cardholder verification not successful' bit in TVR, if CVM Code Byte 1 bit 7 has the value 0b. When a non-biometric card is presented to a terminal with biometric support, the terminal will not select a Biometric CVM Code, as described in Book 3 Section 10.5. Update Figure 9 CVM Processing (Part 2 of 5) as shown below: 'CVM Condition Rules Satisfied?' Logic S (From Part 1 of flow) 'Selected CVM Code Is Not Supported' Logic T (From Part 1 of flow) Terminal understands CVM Condition? YES CVM Condition data available? YES CVM Condition satisfied? YES CVM Condition rules satisfied. NO NO NO CVM Condition rules not satisfied. Continue with Part 1 of flow CVM = Online PIN? NO CVM includes any form of offline PIN?1 Set 'PIN entry req'd YES but PIN pad not present or not working' in TVR. NO Terminal YES supports any YES form of offline PIN? NO CVM is any Biometric Type?2 YES Set 'A selected Biometric Type not supported' in TVR. NO Continue with Part 1 of flow 1 "CVM includes any form of offline PIN" includes the following CVMs:  Plaintext PIN verification performed by ICC  Enciphered PIN verification performed by ICC  Plaintext PIN verification performed by ICC and Signature  Enciphered PIN verification performed by ICC and Signature 2 "CVM is any biometric type" includes the following CVMs:  Online or offline facial  Online or offline finger  Online or offline iris  Online or offline palm  Online or offline voice Figure 9: CVM Processing (Part 2 of 7) countries. Update the titles of Figure 10, 11 and 12 as shown below: Figure 10: CVM Processing (Part 3 of 7) Figure 11: CVM Processing (Part 4 of 7) Figure 12: CVM Processing (Part 5 of 7) countries. After Figure 12 CVM Processing (Part 5 of 5), add the following new figure: Offline Biometric Verification R (From Part 1 of flow) Terminal issues GET DATA for Biometric Try Counters Template Biometric Try Counters Template retrieved? YES Try counter of selected Biometric YES Type = 0? G NO NO Terminal issues GET DATA for Preferred Attempts Template Preferred Attempts Template retrieved? YES NO H Set Template Try Counter to the value of MIN (Preferred Attempts of the selected Biometric Type, Try Counter of the selected Biometric Type) Card Offline BIT Group Template present?11 NO H YES Set Biometric template format not supported in TVR Retrieve first BIT of the selected Biometric Type Reset Biometric template format not supported in TVR YES Biometric Solution ID YES matches?22 NO NO K Both field 87 & 88 match? Another BIT of the selected Biometric Type present? NO H YES Retrieve next BIT of the selected Biometric Type Ask cardholder to present the specified subtype of the Biometric Type identified in the BIT33 Biometric Type capture device malfunctioning? Set Biometric required but YES Biometric capture device not working in TVR NO Biometric Set Biometric required, Subbytpyapseseedn?try YES preBseionmt,ebturitcBciaopmtuertericdeSvuibcteype K entry was bypassed in TVR NO Recover the key to be used for biometric data encipherment Recovery OK? NO YES Get unpredictable number from card with GET CHALLENGE GET CHALLENGE NO OK? YES Encipher biometric data Set CSVuMcceRsessfuullts to J as defined in Book 2 section 7.3 Send Biometric Verification Data Template to card in VERIFY command(s) Decrement Template Try Counter by 1 Consider that Biometric Type CVM is successful Set Biometric performed and successful in TVR YES SW1SW24 = 63Cx NO with x>0? YES YES Template Try Counter > 0? NO Set Template Try Counter to the value of MIN (Preferred Attempts of the YES selected Biometric Type, Try Counter of the selected Biometric Type) H K SW1SW24 = 9000 ? H NO G SW1SW24 = 63C0, YES 6983, or 6984 ? NO Set Biometric Try Limit exceeded in TVR SW1SW24 = 6800, 6883, or 6884 ? NO Terminate transaction Consider that Biometric Type CVM is not successful J Continue with Part 1 of flow countries. 1The Offline BIT Group Template shall be present and contain at least one BIT. 2The terminal shall determine if the Biometric Solution ID of the BIT being processed equals to the Biometric Solution ID of any BIT in Terminal BIT Group Template. 3It is assumed that the biometric template is captured after the cardholder is advised on which Biometric Subtype is required, and the BDB is obtained from the Biometric Processing Application. 4The SW1 SW2 shall be in response to the final VERIFY command. Figure 12a: CVM Processing (Part 6 of 7) After Figure 12 CVM Processing (Part 5 of 5), add the following new figure: Online Biometric Verification Q (From Part 1 of flow) Card Online BIT Group Template present1? YES Set Biometric template format not supported in TVR Request biometric entry defined in the BIT3 Biometric capture device is malfunctioning? NO Set 'Biometric required but YES Biometric capture device not working' in TVR. Retrieve next BIT of NO the selected Retrieve first BIT of the selected Biometric Type Biometric Set 'Biometric required, Biometric capture device M Subtype entry bypassed? YES present, but Biometric Subtype entry was bypassed' in TVR. Biometric Type NO Biometric Solution ID Set CVM Results to N YES matches?2 'Unknown' NO YES Another BIT of selected Biometric NO Type present? Value of both 87 & 88 match? Set Online CVM captured in TVR to 1 M YES Consider that Online Biometric CVM is successful Consider that Online Biometric CVM is not successful NO Reset Biometric template format not supported in TVR N Continue with Part 1 of flow 1The Online BIT Group Template shall present and contain at least one BIT. 2The terminal shall determine if the Biometric Solution ID of the BIT being processed equals to the Biometric Solution ID of any BIT in Terminal BIT Group Template. 3It is assumed that the biometric template is captured after the cardholder is advised on which Biometric Subtype is required, and the BDB is obtained from the Biometric Processing Application. Figure 12b: CVM Processing (Part 7 of 7) countries. Add the following entries to Table 33 of Annex A1 Data Elements by Name: A1 Data Elements by Name Name Biometric Encryption Key (BEK) Biometric MAC Key (BMK) Biometric Key Seed Biometric Header Template (BHT) Biometric Information Template (BIT) Biometric Information Template (BIT) Biometric Solution ID Biometric Subtype Biometric Terminal Capabilities Description An AES-128 key generated from the Biometric Key Seed, that is used to encrypt/decrypt the BDB constructed on the Biometric Processing Application A key generated from the Biometric Key Seed, that is used to ensure the integrity of the BDB A random number generated by the terminal, that is used as the seed to generate the Biometric Encryption Key (BEK) and Biometric MAC Key (BMK) A template defined in ISO/IEC 19785-3, that is nested under the BIT. A template defined in ISO/IEC 19785-3, that describes information regarding the biometric format and solution supported in a card. A template defined in ISO/IEC 19785-3, that describes information regarding the biometric format and solution supported in a terminal. A unique identifier assigned by EMVCo that is used to identify a biometric program, regional or global, supported by the card or terminal. The Biometric Solution ID is referred to within ISO/IEC 19785-3 as the "Index". A data element defined in ISO/IEC 19785-3, that describes the subtype of the Biometric Type supported by the card or terminal, as shown in Table 43c. A data element that identifies the Biometric CVM capabilities of the terminal Source Terminal Terminal Terminal Card, Terminal Card Terminal Terminal, Card Terminal, Card Terminal Format b b b b b b b b b Template — — — '7F60' 'BF4A', 'BF4B' — 'A1' 'BF4E' Tag Length — 16 — — 'A1' '7F60' 32 NPE or NIC var. var. '7F60' var. '90' var. 'A1' '82' 1 — '9F30' 3 countries. Name Biometric Try Counters Template Description A template that contains one or more of the following Biometric Try Counters:  Facial Try Counter  Finger Try Counter  Iris Try Counter  Palm Try Counter  Voice Try Counter Source Card Biometric Type Biometric Verification Data Template Card BIT Group Template Enciphered Biometric Data Enciphered Biometric Key Seed Facial Try Counter Finger Try Counter Iris Try Counter MAC of Enciphered Biometric Data A data element defined in ISO/IEC 19785-3, that describes the type of biometrics supported by the card or terminal among facial, finger, iris, palm and voice, as shown in Table 43b. A template that contains the TLV-coded values for the data to be included in the VERIFY command. The Biometric Verification Data Template contains Biometric Type ('81'), Biometric Solution ID ('90'), Enciphered Biometric Key Seed ('DF50'), Enciphered Biometric Data (tag 'DF51'), and MAC of Enciphered Biometric Data (tag 'DF52'). A template in the card that contains one or more Biometric Information Templates (BITs) The enciphered data sent in the VERIFY command The Biometric Key Seed enciphered using the public key from the ICC Identifies the number of facial verification tries remaining Identifies the number of finger verification tries remaining Identifies the number of iris verification tries remaining An HMAC generated on the Enciphered Biometric Data to ensure integrity Terminal, Card Terminal Card Terminal Terminal Card Card Card Terminal Format b b b b b b b b b b Template — Tag 'BF4C' Length var. 'A1' 'BF4E' — '81' var. 'BF4E' var. — 'BF4E' 'BF4E' 'BF4C' 'BF4C' 'BF4C' 'BF4E' '9F31' 'DF51' 'DF50' 'DF50' 'DF51' 'DF52' 'DF52' var. var. NPE or NIC 1 1 1 8 countries. Name Offline BIT Group Template Online BIT Group Template Palm Try Counter Preferred Attempts Template4 Preferred Facial Attempts Preferred Finger Attempts Preferred Iris Attempts Preferred Palm Attempts Preferred Voice Attempts Description A template, defined in ISO/IEC 7816-11, that is nested under the Card BIT Group Template, as shown in Table 43d, and contains one or more multiple Biometric Information Templates (BITs) for offline biometric verification supported by card A template, defined in ISO/IEC 7816-11, that is nested under the Card BIT Group Template, as shown in Table 43d, and contains one or more multiple Biometric Information Templates (BITs) for online biometric verification supported by card Identifies the number of palm verification tries remaining A template that contains the TLV-coded values for the preferred attempts of any BIT of a Biometric Type. It contains one or more of the following:  Preferred Facial Attempts  Preferred Finger Attempts  Preferred Iris Attempts  Preferred Palm Attempts  Preferred Voice Attempts Number of preferred attempts for any BIT of the facial Biometric Type stored in the card. Number of preferred attempts for any BIT of the finger Biometric Type stored in the card. Number of preferred attempts for any BIT of the iris Biometric Type stored in the card Number of preferred attempts for any BIT of the palm Biometric Type stored in the card. Number of preferred attempts for any BIT of the voice Biometric Type stored in the card. Source Card Card Card Card Card Card Card Card Card Format b b b b b b b b b Template '9F31' Tag 'BF4A' Length var. '9F31' 'BF4B' var. 'BF4C' 'DF53' 1 'BF4D' var. 'BF4D' 'BF4D' 'BF4D' 'BF4D' 'BF4D' 'DF50' 1 'DF51' 1 'DF52' 1 'DF53' 1 'DF54' 1 4The preferred attempts for each Biometric Type are used to define how many attempts the issuer allows the terminal to verify using a single BIT. It is different from any biometric try limit used within the card to limit how many tries are allowed by the issuer for a Biometric Type. For example, an issuer may set a finger try limit in the card (associated with the Finger Try Counter) to five, and set the Preferred Finger Attempts to three, allowing three attempts to verify the primary finger before two additional attempts are allowed using a secondary finger. countries. Name Template Try Counter Terminal BIT Group Template Voice Try Counter Description Identifies the number of biometric verification tries remaining for a specific BIT A template in the terminal, defined in ISO/IEC 781611, that contains one or more Biometric Information Templates (BITs) Identifies the number of voice verification tries remaining Source Terminal Terminal Card Format b b b Template — — 'BF4C' Tag Length — 1 — var. 'DF54' 1 countries. Add the following entries to Table 34 of Annex A2 Data Elements by Tag: Name Biometric Information Template (BIT), card Biometric Information Template (BIT), terminal Biometric Type Biometric Subtype Biometric Solution ID Biometric Terminal Capabilities Card BIT Group Template Biometric Header Template (BHT) Offline BIT Group Template Online BIT Group Template Biometric Try Counters Template Preferred Attempts Template Biometric Verification Data Template Facial Try Counter Preferred Facial Attempts Enciphered Biometric Key Seed Finger Try Counter Preferred Finger Attempts Enciphered Biometric Data Iris Try Counter Preferred Iris Attempts MAC of Enciphered Biometric Data Palm Try Counter Preferred Palm Attempts Voice Try Counter Preferred Voice Attempts Template 'BF4A' or 'BF4B' – 'A1' or 'BF4E' 'A1' 'A1' or 'BF4E' – – '7F60' '9F31' '9F31' – – – 'BF4C' 'BF4D' 'BF4E' 'BF4C' 'BF4D' 'BF4E' 'BF4C' 'BF4D' 'BF4E' 'BF4C' 'BF4D' 'BF4C' 'BF4D' Tag '7F60' '7F60' '81' '82' '90' '9F30' '9F31' 'A1' 'BF4A' 'BF4B' 'BF4C' 'BF4D' 'BF4E' 'DF50' 'DF50' 'DF50' 'DF51' 'DF51' 'DF51' 'DF52' 'DF52' 'DF52' 'DF53' 'DF53' 'DF54' 'DF54' Update Table 39 CVM Codes as shown below: CV Rule Byte 1 (Leftmost): Cardholder Verification Method (CVM) Codes countries. b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 RFU 0 Fail cardholder verification if this CVM is unsuccessful 1 Apply succeeding CV Rule if this CVM is unsuccessful 0 0 0 0 0 0 Fail CVM processing 0 0 0 0 0 1 Plaintext PIN verification performed by ICC 0 0 0 0 1 0 Enciphered PIN verified online 0 0 0 0 1 1 Plaintext PIN verification performed by ICC and signature 0 0 0 1 0 0 Enciphered PIN verification performed by ICC 0 0 0 1 0 1 Enciphered PIN verification performed by ICC and signature 0 0 0 1 1 0 Facial biometric verified offline (by ICC) 0 0 0 1 1 1 Facial biometric verified online 0 0 1 0 0 0 Finger biometric verified offline (by ICC) 0 0 1 0 0 1 Finger biometric verified online 0 0 1 0 1 0 Palm biometric verified offline (by ICC) 0 0 1 0 1 1 Palm biometric verified online 0 0 1 1 0 0 Iris biometric verified offline (by ICC) 0 0 1 1 0 1 Iris biometric verified online 0 0 1 1 1 0 Voice biometric verified offline (by ICC) 0 0 1 1 1 1 Voice biometric verified online 0 x x x x x Values in the range 010000-011101 reserved for future use by this specification 0 1 1 1 1 0 Signature 0 1 1 1 1 1 No CVM required 1 0 1 x x x Values in the range 100000-101111 reserved for use by the individual payment systems 1 1 x x x x Values in the range 110000-111110 reserved for use by the issuer 1 1 1 1 1 1 This value is not available for use Table 39: CVM Codes countries. Update Table 42 Terminal Verification Results as shown below: TVR Byte 1: (Leftmost) b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 x x x x x x x Offline data authentication was not performed x 1 x x x x x x SDA failed x x 1 x x x x x ICC data missing x x x 1 x x x x Card appears on terminal exception file x x x x 1 x x x DDA failed x x x x x 1 x x CDA failed x x x x x x 1 x SDA Selected x x x x x x x 0 RFU TVR Byte 2: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 x x x x x x x ICC and terminal have different application versions x 1 x x x x x x Expired application x x 1 x x x x x Application not yet effective x x x 1 x x x x Requested service not allowed for card product x x x x 1 x x x New card x x x x x 0 x x RFU x x x x x x 1 x Biometric performed and successful x x x x x x x 1 Biometric template format not supported TVR Byte 3: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 x x x x x x x Cardholder verification was not successful x 1 x x x x x x Unrecognised CVM x x 1 x x x x x PIN Try Limit exceeded x x x 1 x x x x PIN entry required and PIN pad not present or not working x x x x 1 x x x PIN entry required, PIN pad present, but PIN was not entered x x x x x 1 x x Online CVM captured x x x x x x 1 x Biometric required but Biometric capture device not working x x x x x x x 1 Biometric required, Biometric capture device present, but Biometric Subtype entry was bypassed Table 42: Terminal Verification Results countries. TVR Byte 4: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 x x x x x x x Transaction exceeds floor limit x 1 x x x x x x Lower consecutive offline limit exceeded x x 1 x x x x x Upper consecutive offline limit exceeded x x x 1 x x x x Transaction selected randomly for online processing x x x x 1 x x x Merchant forced transaction online x x x x x 1 x x Biometric Try Limit exceeded x x x x x x 1 x A selected Biometric Type not supported x x x x x x x 0 RFU Table 42: Terminal Verification Results, continued TVR Byte 5 (Rightmost): b8 b7 b6 b5 b4 b3 b2 b1 Meaning 1 x x x x x x x Default TDOL used x 1 x x x x x x Issuer authentication failed x x 1 x x x x x Script processing failed before final GENERATE AC x x x 1 x x x x Script processing failed after final GENERATE AC x x x x 0 x x x RFU x x x x x 0 x x RFU x x x x x x 0 x RFU x x x x x x x 0 RFU Table 42: Terminal Verification Results, continued After Annex C6 Transaction Status Information, add the following two new annexes: C7 Biometric Information Template (BIT) The BIT provides descriptive information regarding the biometric formats and solutions supported in a card or in a terminal. The format of the BIT is defined in ISO/IEC 19785-3 with TLV-encoded patron format, as shown in Table 43a. The Biometric Solution ID is present to ensure that a biometric card certified by a program will only perform biometric verification on the terminal that is certified by the same program, and a terminal certified by a program will only perform biometric CVM on the biometric card that is certified by the same program. The terminals and cards certified by the same program shall contain the same Biometric Solution ID. Such program can be global or r

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