Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
Verification of the cardholder is carried out in order to establish the fact of the identity of the person who received the card from its issuer (bank client) with the person performing the operation on the card. This stage of transaction processing can be performed at any time between the moment the terminal completes reading the card data and the moment the terminal completes the analysis of the results of its risk management procedures.
4.7.1. Verification methods
The EMV standard allows for various methods of cardholder verification (Cardholder Verification Method, or CVM). Each method is encoded with a 6-bit sequence in accordance with the EMV 4.2 Book 3 C3 Appendix:
Another reason has a common root with the first one and is that the issuer does not trust the security of transferring the PIN-code to the IPC. For example, the PIN code is encrypted using the RSA algorithm, but not in a cryptographic module, as required by payment systems, but using the terminal software. There are other subtleties in the implementation of PIN-code encryption using an asymmetric cryptographic algorithm, affecting the safety of the PIN-code and the security of the operation (see clause 6.3). Therefore, some issuers rely more on the proven method of online PIN verification;
Plaintext PIN verification performed by ICC ('000001'b) - verification by the card application of the PIN code transmitted to the IPC in clear text. In this case, the PIN-code, after entering it on the terminal, is transferred to the card in clear form. Since when the PIN code is transferred to the card, the latter does not go beyond the system “card - specialized keyboard for entering the PIN code”, the likelihood of fraudulent interception of the PIN code is considered to be approximately the same as in the case of using a secure transfer of the PIN block. The above-mentioned specialized keyboard in the case of ATMs and self-service terminals is called the Encrypting PIN Pad (EPP), and in the case of the POS terminal, the PIN Entry Device (PED). Analysts believe that the existing requirements for EPP and PED keyboards, formulated in the PCI EPP and PCI PED standards,
'000110' - '011101'b - for biometric methods of cardholder verification;
'100000' - * 1011111) - for use by payment systems;
'110000' - '111110'b - for use by individual issuers (for example, the one-time password method).
Note that the code '111111'b cannot be used to indicate the cardholder verification method.
Each terminal must support the verification methods specified by the second byte of the Terminal Capabilities data object (Tag '9F33'), and recognize and correctly process the No CVM required and Fail CVM Processing codes that may be contained in the CVM List object.
The key data object for cardholder verification is the Cardholder Verification Method List (CVM List, Tag '8E') object. This data object is stored on the card. The Value field of the CVM List object consists of:
• several entries (rules) Card Verification Rule (CVER), each of which is a binary sequence of 2 bytes in size;
• two values X and Y, having a binary format and a size of 4 bytes each (the values X and Y are specified in the first 8 bytes of the data field of the CVM List object).
The first byte of the CVER element is called the Cardholder Verification Method Code (CVM Code) and is used to encode the verification method. The second byte of the CVER is called the Cardholder Verification Method Condition Code (CVM Condition Code) and defines the conditions under which the verification method can be used.
The X and Y values are expressed in the currency of the card application (Application Currency Code, Tag '9F42') with an implicit decimal point determined by the currency of the application. The meaning of the X and Y values will be explained a little later.
The structure of the CVM Code byte is described below:
'00'h: CVM method can be used always: under any conditions of the transaction;
'Ol'h: CVM can be used for cash dispensing operations at ATMs and other self-service terminals;
'02'h: CVM method can be used when performing transactions that are not related to cash withdrawal, i.e. the method cannot be used when performing cash withdrawal operations at ATMs and self-service terminals, cash withdrawals at bank POS terminals (Cash Advance), as well as when making purchases with cashback (purchase with cashback);
'03'h: CVM can be used if the terminal supports it. For example, the Plaintext PIN verification method can be used if the terminal has a device for entering a PIN code and the terminal application supports entering a PIN code into the card;
'04'h: CVM method is used when performing a cash withdrawal operation at bank POS terminals (Cash Advance);
'05'h: CVM is used when performing a purchase with cashback;
'06'h: CVM method is used if the transaction currency (Transaction Currency Code, Tag' F2A ') matches the card application currency Application Currency Code and the transaction size is less than X;
'07'h: CVM method is used if the transaction currency is the same as the currency of the card application and the transaction size is greater than X;
'08'h: CVM is used if the transaction currency is the same as the card application currency and the transaction size is less than Y;
'09'h: CVM method is used if the transaction currency is the same as the currency of the card application and the transaction size is greater than Y;
'OA' - '7F'h: reserved for future use;
'8O' - 'FF'h: reserved for use by payment systems.
The result of the cardholder verification is stored by the terminal in the CVM Results data object (Tag '9F34'), the Value field of which is three bytes in size. The first two bytes encode the CVER rule used in the verification procedure, and the last byte indicates the result of the last CVM:
If bit 5 of byte 1 of AIP “Cardholder verification is supported” is equal to 1, the terminal starts performing the cardholder verification procedure. First of all, the terminal checks the presence of the CVM List object (Tag '8E') among the card data read by it.
If the CVM List object is absent among the read data, the terminal completes the verification procedure without setting the value of bit 7 of byte 1 of TSI "Cardholder verification was performed" equal to 1. In this case, the terminal sets the value of the first byte of CVM Results equal to '3F'h (No CVM performed).
If the CVM List object has been read, the terminal starts sequentially processing the Card Verification Rules entries listed in the object, starting from the first record in the order of their appearance in the CVM List, if necessary to the end of the list.
The following describes the procedure for processing each 2-byte CVER entry in the CVM List.
Step 1. Checking the second byte CVER (CVM Condition Code):
If the check of the second CVER byte was unsuccessful and the considered CVM Condition Code matches the last CVER entry in the CVM List, then the terminal performs the following actions:
- bit 8 of byte 3 TVR "Cardholder verification was not successful" is set equal to 1;
Step 2. Checking the first byte of CVER (CVM Code).
A. First, the fact that the CVM Code (the sixth rightmost bits of the first byte) is understood by the terminal is verified.
In this case, the terminal sets bytes 1 and 2 of the CVM Results equal to the first and second bytes of the CVER record in question, respectively.
If CVM Code = 'No CVM required', the terminal sets byte 3 of CVM Results equal to '02'h (Successful) and ends the verification procedure.
If CVM Code = 'Fail CVM processing', the terminal sets byte 3 of CVM Results equal to 'Ol'h (Failed), bit 8 of byte 3 TVR "Cardholder verification was not successful" equal to 1 (note that setting this bit appeared only in the specifications EMV 4.1; this was done in order to implement the initialization of online authorization using this verification method) and completes the verification procedure.
B. If the CVM Code is not clear to the terminal (for example, because the terminal does not support this verification method), then the terminal performs the following actions:
C1. If the terminal successfully completes the verification procedure according to the selected CVM method, then bit 7 of byte 1 of TSI “Cardholder verification was performed” is set to 1, byte 3 of CVM Results is set according to the result of cardholder verification, and the procedure ends.
C2. If the execution of the verification procedure according to the selected CVM method fails, then:
4.7.2. Offline PIN verification
As previously mentioned, there are two different methods of offline PIN verification (cases of combining PIN verification and customer signature are not considered):
Let us describe the algorithm for offline PIN-code verification. In this case, the terminal processes the entry CVER of the CVM List, in which the CVM Code is either 'OOOOOG' or '000100'b.
If the terminal does not support offline PIN verification, bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1.
If the terminal supports offline PIN-code verification, then:
if the PIN pad is inoperative, then bit 5 of byte 3 TVR 'PIN entry required and PIN pad not present or not working' is set to 1;
if the PIN pad is functional, but the terminal or card wants to bypass the PIN code check, then bit 4 of byte 3 TVR 'PIN entry required, PIN pad present, but PIN was not entered' is set to 1, cardholder verification according to the CVM method is considered unsuccessful, CVM Results is not set and the next CVER entry in the CVM List is selected, if one exists and bit 7 of the CVM Code is 1;
if the terminal supports offline PIN verification, the PIN pad is working properly and the cardholder or terminal is not going to bypass the PIN verification, the PIN verification is performed. The remainder of this section is devoted to describing the offline PIN verification procedure.
The offline PIN check is carried out as follows. First of all, the terminal sends the GET DATA command to the card, the main parameters of which are given in table. 4.15.
Tab. 4.15. GET DATA Command Parameters
The command is used to retrieve a primitive PIN Try Counter data object (PTC, Tag '9F17') from the card, which is not contained in any linear application file. The РТС element shows the current value of the number of PIN-code entry attempts remaining with the cardholder. When the value becomes 0, the cardholder has no more attempts to enter the PIN code value.
If in the received response R-APDU SW1SW2 = '9000'h and РТС = 0, the terminal performs the following actions:
The GET CHALLENGE command is used to get an 8-byte Unpredictable Number (Tag '9F37') from the card. As explained in 3.13, this number is used to diversify the value of the PIN encrypted using the RSA algorithm.
The terminal sends the VERIFY command to the card, the data field of which contains the open or closed value of the PIN-block. In the case of an open PIN block transfer, eight bytes of the PIN block are transferred in the data field of the VERIFY command. In the case of an encrypted PIN-block, the structure of the encrypted data was described in clause 3.10. The structure of the VERIFY command is shown in table. 4.17.
Tab. 4.17. VERIFY Command Options
The card compares the received PIN-code value with the value stored on the card. If they match, the offline PIN check is considered successful. Otherwise, the cardholder verification is considered to have failed.
Each time the PIN check fails, the PTC counter is decremented by one and the SW1SW2 bytes are '6983'h or' 6984'h. In other cases, the R-APDU response contains SW1SW2 of the form '63 Cx ', where x indicates the current value of the PTC (x may be 0).
The R-APDU response to the VERIFY command implies the following:
Note that after checking the value of the PIN-code, the card sets the value of bit 4 of byte 2 CVR equal to 1. If the check of the PIN-code fails, the card sets the value of bit 3 of byte 2 CVR equal to 1. If, in addition, the PIN Try limit has been exceeded Limit bit 2 of Byte 2 CVR is set to 1.
4.7.3. Online PIN check
This section describes the method for online PIN verification ('000010'b).
If the terminal does not support online PIN check, bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1.
If the terminal supports online PIN check, then:
4.7.1. Verification methods
The EMV standard allows for various methods of cardholder verification (Cardholder Verification Method, or CVM). Each method is encoded with a 6-bit sequence in accordance with the EMV 4.2 Book 3 C3 Appendix:
- No CVM required ('Olllll'b). When this method is selected, the cardholder is not verified. The method is relevant when it is necessary to ensure a high speed of transaction execution, possibly to the detriment of its security. Examples of using this method are paying for travel in public transport, paying for lunch at fast food restaurants (often using contactless IPCs), etc. For small transactions, the decrease in transaction security due to the lack of cardholder verification may be acceptable;
- Fail CVM processing ('000000'b). This method is used to artificially fail the verification of the cardholder by the terminal in order for the terminal to make a decision to authorize the transaction in real time. This will allow applying additional checks to the card, provided by the issuer;
- Signature ('011110'b). This method consists in verifying the signature of the cardholder on the back of the card with the signature left by the customer on the check. This method of verification of the holder is saved in EMV, among other things, because in some countries the legislation requires the client's signature as proof of the transaction;
- Enciphered PIN verified online ('000010'b) - a method for verifying the cardholder's PIN-code by its issuer during a transaction in chapter 4. TRANSACTION PROCESSING WITH MICROPROCESSOR CARD 311 Real-time mode. At the same time, according to the requirements of payment systems, the PIN code is in encrypted form almost from the moment it is entered on the terminal keyboard until the end of the check in a special cryptographic module of the issuer's host and, thus, is inaccessible to fraudsters. This method of cardholder verification has been abandoned with the IPC (rather than replaced by an offline PIN verification procedure) for several reasons. The first reason is that many issuers consider it possible to apply the PIN-code verification procedure offline only if the PIN-code is transmitted from the terminal to the card in a closed form (in Germany, this requirement arises from the country's legislation). To implement such a transfer of a PIN code to a card, it is necessary that the terminal has a cryptographic device capable of supporting the RSA algorithm. The presence of such a cryptographic device is still a problem for a number of terminals, such as ATMs. Therefore, the need for online processing of the PIN by the issuer remains. for example ATMs. Therefore, the need for online processing of the PIN by the issuer remains. for example ATMs. Therefore, the need for online processing of the PIN by the issuer remains.
Another reason has a common root with the first one and is that the issuer does not trust the security of transferring the PIN-code to the IPC. For example, the PIN code is encrypted using the RSA algorithm, but not in a cryptographic module, as required by payment systems, but using the terminal software. There are other subtleties in the implementation of PIN-code encryption using an asymmetric cryptographic algorithm, affecting the safety of the PIN-code and the security of the operation (see clause 6.3). Therefore, some issuers rely more on the proven method of online PIN verification;
Plaintext PIN verification performed by ICC ('000001'b) - verification by the card application of the PIN code transmitted to the IPC in clear text. In this case, the PIN-code, after entering it on the terminal, is transferred to the card in clear form. Since when the PIN code is transferred to the card, the latter does not go beyond the system “card - specialized keyboard for entering the PIN code”, the likelihood of fraudulent interception of the PIN code is considered to be approximately the same as in the case of using a secure transfer of the PIN block. The above-mentioned specialized keyboard in the case of ATMs and self-service terminals is called the Encrypting PIN Pad (EPP), and in the case of the POS terminal, the PIN Entry Device (PED). Analysts believe that the existing requirements for EPP and PED keyboards, formulated in the PCI EPP and PCI PED standards,
- Plaintext PIN verification performed by ICC and signature ('000011'b) - verification by the card application of the PIN-code transmitted to the IPC in clear text, and the seller verifies the client's signature on the terminal receipt;
- Enciphered PIN verification performed by ICC ('000100'b) - verification by the card application of the encrypted PIN code transmitted to the IPC. As already noted, to implement this verification method, it is required to support it from the card and the terminal;
- Enciphered PIN verification performed by ICC and signature ('OOOlOl'b) - the card application checks the encrypted PIN code transmitted to the IPC, and the seller checks the client's signature on the terminal receipt.
'000110' - '011101'b - for biometric methods of cardholder verification;
'100000' - * 1011111) - for use by payment systems;
'110000' - '111110'b - for use by individual issuers (for example, the one-time password method).
Note that the code '111111'b cannot be used to indicate the cardholder verification method.
Each terminal must support the verification methods specified by the second byte of the Terminal Capabilities data object (Tag '9F33'), and recognize and correctly process the No CVM required and Fail CVM Processing codes that may be contained in the CVM List object.
The key data object for cardholder verification is the Cardholder Verification Method List (CVM List, Tag '8E') object. This data object is stored on the card. The Value field of the CVM List object consists of:
• several entries (rules) Card Verification Rule (CVER), each of which is a binary sequence of 2 bytes in size;
• two values X and Y, having a binary format and a size of 4 bytes each (the values X and Y are specified in the first 8 bytes of the data field of the CVM List object).
The first byte of the CVER element is called the Cardholder Verification Method Code (CVM Code) and is used to encode the verification method. The second byte of the CVER is called the Cardholder Verification Method Condition Code (CVM Condition Code) and defines the conditions under which the verification method can be used.
The X and Y values are expressed in the currency of the card application (Application Currency Code, Tag '9F42') with an implicit decimal point determined by the currency of the application. The meaning of the X and Y values will be explained a little later.
The structure of the CVM Code byte is described below:
- • bit 8 is reserved for future use and takes on the value 0;
- • bit 7 = 1 means that the terminal should go to the next CVER verification rule in the CVM List, if there is one, and the current verification method was unsuccessful (note - unsuccessful, not a failure!);
- • bit 7 = 0 means that the terminal ends the cardholder verification procedure if the current verification method was unsuccessful;
- • Bits 1-6 encode the verification method as described above.
'00'h: CVM method can be used always: under any conditions of the transaction;
'Ol'h: CVM can be used for cash dispensing operations at ATMs and other self-service terminals;
'02'h: CVM method can be used when performing transactions that are not related to cash withdrawal, i.e. the method cannot be used when performing cash withdrawal operations at ATMs and self-service terminals, cash withdrawals at bank POS terminals (Cash Advance), as well as when making purchases with cashback (purchase with cashback);
'03'h: CVM can be used if the terminal supports it. For example, the Plaintext PIN verification method can be used if the terminal has a device for entering a PIN code and the terminal application supports entering a PIN code into the card;
'04'h: CVM method is used when performing a cash withdrawal operation at bank POS terminals (Cash Advance);
'05'h: CVM is used when performing a purchase with cashback;
'06'h: CVM method is used if the transaction currency (Transaction Currency Code, Tag' F2A ') matches the card application currency Application Currency Code and the transaction size is less than X;
'07'h: CVM method is used if the transaction currency is the same as the currency of the card application and the transaction size is greater than X;
'08'h: CVM is used if the transaction currency is the same as the card application currency and the transaction size is less than Y;
'09'h: CVM method is used if the transaction currency is the same as the currency of the card application and the transaction size is greater than Y;
'OA' - '7F'h: reserved for future use;
'8O' - 'FF'h: reserved for use by payment systems.
The result of the cardholder verification is stored by the terminal in the CVM Results data object (Tag '9F34'), the Value field of which is three bytes in size. The first two bytes encode the CVER rule used in the verification procedure, and the last byte indicates the result of the last CVM:
- unknown result (for example, in the case of using the holder's signature or online verification of the PIN);
- CVM has failed, that is, the verification did not confirm the validity of the cardholder (for example, as a result of an offline PIN verification);
- CVM completed successfully, ie the verification confirmed the validity of the cardholder (for example, as a result of an offline PIN verification).
If bit 5 of byte 1 of AIP “Cardholder verification is supported” is equal to 1, the terminal starts performing the cardholder verification procedure. First of all, the terminal checks the presence of the CVM List object (Tag '8E') among the card data read by it.
If the CVM List object is absent among the read data, the terminal completes the verification procedure without setting the value of bit 7 of byte 1 of TSI "Cardholder verification was performed" equal to 1. In this case, the terminal sets the value of the first byte of CVM Results equal to '3F'h (No CVM performed).
If the CVM List object has been read, the terminal starts sequentially processing the Card Verification Rules entries listed in the object, starting from the first record in the order of their appearance in the CVM List, if necessary to the end of the list.
The following describes the procedure for processing each 2-byte CVER entry in the CVM List.
Step 1. Checking the second byte CVER (CVM Condition Code):
- - the terminal's understanding of the CVM Condition Code is checked. For example, it may happen that the card supports the EMV version containing the new values of the verification conditions, but the terminal that supports the old version does not understand these values;
- - the presence on the terminal of the data elements necessary for checking the condition specified by the CVM Condition Code is checked. For example, to check conditions using X or Y values, the terminal must have an Application Currency Code and Amount, Authorized object;
- - the fulfillment of the condition specified by the CVM Condition Code byte is checked.
If the check of the second CVER byte was unsuccessful and the considered CVM Condition Code matches the last CVER entry in the CVM List, then the terminal performs the following actions:
- bit 8 of byte 3 TVR "Cardholder verification was not successful" is set equal to 1;
- - the value of the first byte of CVM Results is set equal to '3F'h (No CVM performed);
- - the verification procedure of the cardholder is completed.
Step 2. Checking the first byte of CVER (CVM Code).
A. First, the fact that the CVM Code (the sixth rightmost bits of the first byte) is understood by the terminal is verified.
In this case, the terminal sets bytes 1 and 2 of the CVM Results equal to the first and second bytes of the CVER record in question, respectively.
If CVM Code = 'No CVM required', the terminal sets byte 3 of CVM Results equal to '02'h (Successful) and ends the verification procedure.
If CVM Code = 'Fail CVM processing', the terminal sets byte 3 of CVM Results equal to 'Ol'h (Failed), bit 8 of byte 3 TVR "Cardholder verification was not successful" equal to 1 (note that setting this bit appeared only in the specifications EMV 4.1; this was done in order to implement the initialization of online authorization using this verification method) and completes the verification procedure.
B. If the CVM Code is not clear to the terminal (for example, because the terminal does not support this verification method), then the terminal performs the following actions:
- - bit 7 of byte 3 of TVR "Unrecognized CVM" is set equal to 1;
- - if the considered CVER record is the last in the CVM List, then bit 8 of byte 3 TVR "Cardholder verification was not successful" is set equal to 1 and the verification procedure ends;
- - if the considered CVER record is not the last one in the CVM List, then the terminal goes to the next CVER record in the CVM List and starts processing it from step 1.
C1. If the terminal successfully completes the verification procedure according to the selected CVM method, then bit 7 of byte 1 of TSI “Cardholder verification was performed” is set to 1, byte 3 of CVM Results is set according to the result of cardholder verification, and the procedure ends.
C2. If the execution of the verification procedure according to the selected CVM method fails, then:
- if bit 7 CVM Code is equal to 0, then bit 8 of byte 3 TVR "Cardholder verification was not successful" is set equal to 1 and the verification procedure is completed;
- if bit 7 of CVM Code is 1, then:
- if the CVER entry is the last in the CVM List, then bit 8 of byte 3 TVR "Cardholder verification was not successful" is set equal to 1 and the verification procedure ends;
- if the CVER record is not the last in the CVM List, then the terminal goes to the next CVER record in the CVM List and starts processing it from step 1.
4.7.2. Offline PIN verification
As previously mentioned, there are two different methods of offline PIN verification (cases of combining PIN verification and customer signature are not considered):
- verification of the PIN-code transmitted to the card in an open form SOOOOG);
- verification of the PIN-code transmitted to the card in encrypted form COOOlOO'b).
Let us describe the algorithm for offline PIN-code verification. In this case, the terminal processes the entry CVER of the CVM List, in which the CVM Code is either 'OOOOOG' or '000100'b.
If the terminal does not support offline PIN verification, bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1.
If the terminal supports offline PIN-code verification, then:
if the PIN pad is inoperative, then bit 5 of byte 3 TVR 'PIN entry required and PIN pad not present or not working' is set to 1;
if the PIN pad is functional, but the terminal or card wants to bypass the PIN code check, then bit 4 of byte 3 TVR 'PIN entry required, PIN pad present, but PIN was not entered' is set to 1, cardholder verification according to the CVM method is considered unsuccessful, CVM Results is not set and the next CVER entry in the CVM List is selected, if one exists and bit 7 of the CVM Code is 1;
if the terminal supports offline PIN verification, the PIN pad is working properly and the cardholder or terminal is not going to bypass the PIN verification, the PIN verification is performed. The remainder of this section is devoted to describing the offline PIN verification procedure.
The offline PIN check is carried out as follows. First of all, the terminal sends the GET DATA command to the card, the main parameters of which are given in table. 4.15.
Tab. 4.15. GET DATA Command Parameters
| Code | Meaning |
| CLA | '80'h |
| INS | 'CA'h |
| Р1Р2 | '9F17'h (corresponds to PTC) |
| Lc | Absent |
| Data | Absent |
| Le | '00'h |
The command is used to retrieve a primitive PIN Try Counter data object (PTC, Tag '9F17') from the card, which is not contained in any linear application file. The РТС element shows the current value of the number of PIN-code entry attempts remaining with the cardholder. When the value becomes 0, the cardholder has no more attempts to enter the PIN code value.
If in the received response R-APDU SW1SW2 = '9000'h and РТС = 0, the terminal performs the following actions:
- does not allow the cardholder to enter a new PIN-code value;
- sets the value of bit 6 of byte 3 TVR 'PIN Try Limit exceeded' equal to 1;
- does not display any message regarding the status of the PIN-code;
- does not set the CVM Results bytes;
- continues the verification procedure from step C2 of the CVER record processing algorithm described in clause 4.7.1.
- receives from the cardholder the value of his PIN-code;
- generates a PIN-block from a PIN-code. The format of the PIN-block is presented in clause 3.10;
- if CVM Code indicates that the encrypted PIN-code verification method is used (the last six bits of the CVM Code are '000100'b), sends the GET CHALLENGE command to the card, the parameters of which are given in Table. 4.16.
| Code | Meaning |
| CLA | '00'h |
| INS | '84'h |
| Pl | '00'h |
| P2 | '00'h |
| Lc | Absent |
| Data | Absent |
| Le | '00'h |
The GET CHALLENGE command is used to get an 8-byte Unpredictable Number (Tag '9F37') from the card. As explained in 3.13, this number is used to diversify the value of the PIN encrypted using the RSA algorithm.
The terminal sends the VERIFY command to the card, the data field of which contains the open or closed value of the PIN-block. In the case of an open PIN block transfer, eight bytes of the PIN block are transferred in the data field of the VERIFY command. In the case of an encrypted PIN-block, the structure of the encrypted data was described in clause 3.10. The structure of the VERIFY command is shown in table. 4.17.
Tab. 4.17. VERIFY Command Options
| Code | Meaning |
| CLA | '00'h |
| INS | '20'h |
| Pl | '00'h |
| P2 | '80'h (open PIN block) |
| '88'h (encrypted PIN block) | |
| Lc | Variable, depends on P2 |
| Data | PIN block data |
| Le | '00'h |
The card compares the received PIN-code value with the value stored on the card. If they match, the offline PIN check is considered successful. Otherwise, the cardholder verification is considered to have failed.
Each time the PIN check fails, the PTC counter is decremented by one and the SW1SW2 bytes are '6983'h or' 6984'h. In other cases, the R-APDU response contains SW1SW2 of the form '63 Cx ', where x indicates the current value of the PTC (x may be 0).
The R-APDU response to the VERIFY command implies the following:
- if SW1SW2 = '6983'h,' 6984'h, '63C0'h, then the PIN code check has failed and the terminal sets the value of bit 6 of byte 3 TVR “PIN Try Limit exceeded” equal to 1;
- if SWlSW2 = '63Cx'h, where x> 0, the PIN-code check has failed, but the cardholder still has attempts to enter the correct PIN-code value, about which the terminal notifies the cardholder;
- if SWlSW2 = '9000'h, PIN-code check completed successfully.
Note that after checking the value of the PIN-code, the card sets the value of bit 4 of byte 2 CVR equal to 1. If the check of the PIN-code fails, the card sets the value of bit 3 of byte 2 CVR equal to 1. If, in addition, the PIN Try limit has been exceeded Limit bit 2 of Byte 2 CVR is set to 1.
4.7.3. Online PIN check
This section describes the method for online PIN verification ('000010'b).
If the terminal does not support online PIN check, bit 5 of byte 3 of TVR “PIN entry required and PIN pad not present or not working” is set to 1.
If the terminal supports online PIN check, then:
- if the PIN pad is inoperative, then bit 5 of byte 3 TVR "PIN entry required and PIN pad not present or not working" is set to 1;
- if the PIN pad is functional, but the terminal or card wants to bypass the PIN code check, then bit 4 of byte 3 TVR "PIN entry required, PIN pad, but PIN was not entered" is set to 1, cardholder verification according to this CVM method considered unsuccessful, the CVM Results value is not set and the next CVR entry in the CVM List is selected, if there is one and bit 7 of the CVM Code is 1;
- If the terminal supports the online PIN check, the PIN pad is working correctly and the cardholder or terminal does not intend to bypass the PIN check, an online PIN check is performed. In this case, the terminal sets bit 3 of byte 3 of TVR "On-line PIN entered" equal to 1. Verification of the cardholder is completed at this point and is considered successful.
