Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The terminal can send a message to the serving bank, initiating online processing of the transaction, for one of the following reasons:
Regardless of the reason, when choosing an online transaction processing method, the card responds to the terminal with the ARQC value in the Cryptogram Information Data. The terminal, in accordance with the protocol used for the operation of the terminal with the host, transmits a message containing information related to the card and the results of the transaction processing. Based on these data, the host of the serving bank generates an authorization request (message x100 of the ISO 8583 standard) containing such data as:
After receiving an authorization request, the issuer first of all checks whether the card used for the operation is genuine, that is, issued by the issuer. To do this, the issuer's host checks the ARQC value according to the following algorithm:
Note that the card issuer authentication procedure is mandatory in accordance with the EMV standard. At the same time, payment systems allow, at the stage of migration to the IPC, the presence of issuers that are not capable of processing chip data (magnetic grade issuer). For such issuers, the chip data can be processed by the payment system, and the issuer itself receives messages in a format typical for magnetic stripe transactions.
Further, the issuer carries out standard checks performed by it when using a card with a magnetic stripe (checking the card's activity, history of using the card, the absence of a card number in the list of cards blocked by the issuer, the presence of funds in the account associated with the card, etc.).
Information contained in CVR and TVR objects may be of particular importance for the issuer's decision-making. With the help of CVR and TVR data, the issuer can obtain information about how the transaction was processed in the dialogue between the card and the terminal. In particular, the following information is of great importance:
Correction of card data primarily concerns:
After deciding on the result of the operation, the issuer generates an Issuer Authentication Data (Tag '91') and generates an authorization response to the servicing bank (message x110 of the ISO 8583 standard). In addition to the usual data typical of a transaction performed with a magnetic stripe card, this message includes special data related to the chip - ICC Related Data (data element 55 is used in the x100 authorization request). This data is placed in data item 55 of the xllO message. If issuer authentication was used, item 55 includes ARPC and ARC or ARPC, CSU and Proprietary Authentication Data (depending on the ARPC format used by the issuer).
If the issuer uses the commands of the Script Processing procedure, then they are also placed in element 55 of the message xllO.
If the terminal did not receive an authorization response, or received it too late, or received it with syntax errors, the terminal continues to process the transaction, considering that the request cannot be sent to the issuer (unable to go online).
After the terminal has received the Issuer Authentication Data (Tag '91') in the authorization response, it checks the content of bit 3 of byte 1 of the AIP "Issuer authentication is supported". If this bit is 1, the card supports the EXTERNAL AUTHENTICATE command and issuer authentication must be performed using this command. The terminal prepares the C-APDU block corresponding to the EXTERNAL AUTHENTICATE command (Table 4.28).
Tab. 4.28. Command parameters
EXTERNAL AUTHENTICATE
During the execution of the transaction, the terminal can send the EXTERNAL AUTHENTICATE command to the card only once. If this requirement is violated, the card returns a response to the terminal with SWlSW2 = '6985'h. Regardless of SW1SW2 values in the R-APDU block, the terminal must set bit 5 of byte 1 of TSI "Issuer authentication was performed" equal to 1.
If bit 3 of Byte 1 of the AIP "Issuer authentication is supported" is 0, the second GENERATE AC command is used to authenticate the issuer. In this case, the issuer MUST put a value corresponding to Tag '91' (Issuer Authentication Data) and Tag '8A' (Authorization Response Code) in the Tag-Length reference list specified by the CDOL2 object.
Recall that in the M / Chip 4 application, the GENERATE AC command is used to authenticate the issuer, and in the VIS 1.4.x application, the EXTERNAL AUTHENTICATE command.
Note that in the M / Chip 4 application, using the GENERATE AC command and the ARPC Response Code element, provided the issuer is successfully authenticated, you can change the card parameters even before the card performs risk management procedures (in the CPA application the same effect is achieved using the Card Status Update element) ... Of course, the same result can be achieved using critical commands of the Script Processing procedure (see section 4.13). However, the first option is easier to implement. In addition, it is more economical in terms of the amount of data transferred to the card and more reliable in terms of implementation (the probability of failure when changing the parameters of the card is lower).
If the card supports issuer authentication (in accordance with the EMV standard, this function is optional for the card), then the card checks the Issuer Authentication Data element regardless of the command used to transfer this element to the card.
The card and the issuer use a common algorithm for generating ARQC and ARPC cryptograms. The most commonly used are the algorithms described in clause 3.14 (method 1 and method 2).
In the case of using method 1, the card, having received the ARPC value, decrypts it on the SK AC session key and applies the modulo 2 bitwise addition operation with the ARQC cryptogram value to the resulting 8-byte value. If the resulting value is (ARD || '00' || '00' || '00' || '00' || '00' || '00'), where ARD is composed of bytes 9 and 10 of the element Issuer Authentication Data, then the issuer authentication is considered successful.
Method 2 uses the ARPC cryptogram re-computation method. From the received Issuer Authentication Data element, the card strips off the four leftmost bytes, and the remaining right Z bytes are concatenated with the ARQC cryptogram, so that the element L = ARQC || Z. Algorithm 3 of ISO / IEC 9797-1 is applied to element Y for calculating MAC value using 16-byte session key SK AC . In this case, the size of the MAC value is chosen equal to four bytes. If the received MAC value is equal to the four previously truncated Issuer Authentication Data bytes, then the issuer authentication was successful.
Note that if the CDA method is used to authenticate the card, then the decision of the card / issuer may not be final. For example, if a card generates a TS cryptogram, but the card's CDA authentication fails, the transaction will be rejected by the terminal.
To improve the security of card transactions, the merchant or card issuer may initiate an alternate authorization. The alternative authorization requested by the issuer is implemented as follows. In the authorization response, the issuer uses a response code indicating the need for an alternative authorization. Having received a response code requiring alternative authorization, the terminal completes the transaction, requiring the card to generate an AAC cryptogram. After that, the merchant contacts its servicing bank, which in turn contacts the card issuer and provides him with information about the card holder. Based on the additional information received, the issuer makes a decision on the result of the transaction and sends the Authorization Approval Code to the servicing bank.
If an alternative authorization is requested by the merchant, it continues in the same way as in the case of authorization initiated by the issuer, starting with the step when the terminal generates the GENERATE AC command, requiring the AAC cryptogram from the card.
- the terminal type (Terminal Tour) corresponds to the online only type, which requires the obligatory sending of an authorization request to the card issuer;
- the merchant's cashier decides to send the transaction for online authorization, for example, noticing oddities in the behavior of the cardholder;
- the terminal's risk management procedure has selected this transaction for online authorization (for example, as a result of a random selection of a transaction);
- the terminal makes a decision on the need to process the transaction online based on the results of the TVR analysis against TAS and IAC objects;
- despite the fact that the terminal offers to approve the transaction offline, the card, based on the results of the CVR analysis, decides to send the transaction for authorization to the card issuer.
Regardless of the reason, when choosing an online transaction processing method, the card responds to the terminal with the ARQC value in the Cryptogram Information Data. The terminal, in accordance with the protocol used for the operation of the terminal with the host, transmits a message containing information related to the card and the results of the transaction processing. Based on these data, the host of the serving bank generates an authorization request (message x100 of the ISO 8583 standard) containing such data as:
- applied cryptogram ARQC;
- information about the card (PAN card number, PAN Sequence Number, card expiration date, etc.);
- information about the terminal (identifier, terminal type, terminal country code, etc.);
- transaction number in the ATC card application;
- transaction type, transaction size, transaction currency code, transaction generation time;
- random number generated by the terminal, Unpredictable Number;
- Issuer Application Data element, which may include the identifier of the issuer key for generating the applied cryptogram and the version number of the algorithm used to calculate the cryptogram, DAC or IDN values, TVR terminal checks and CVR card checks, offline counter values, etc.
After receiving an authorization request, the issuer first of all checks whether the card used for the operation is genuine, that is, issued by the issuer. To do this, the issuer's host checks the ARQC value according to the following algorithm:
- according to the key identifier contained in the Issuer Application Data, the corresponding key of the issuer 1МК АС is extracted to generate the applied cryptogram;
- using the card data (PAN and PAN Sequence Number) and the issuer's key 1MK AS , the key for generating the applied cryptogram of the MK AS card is calculated ;
- using the automatic telephone exchange and, possibly, the Unpredictable Number, the session key SK AC of the cryptogram generation is calculated ;
- using the MAC calculation algorithm, the version of which is specified in the Issuer Application Data, and the transaction data, the issuer calculates the cryptogram value and compares it with the received ARQC value. If the values match, the card authentication is successful and the card itself is valid. Otherwise, the card authentication is considered to have failed.
Note that the card issuer authentication procedure is mandatory in accordance with the EMV standard. At the same time, payment systems allow, at the stage of migration to the IPC, the presence of issuers that are not capable of processing chip data (magnetic grade issuer). For such issuers, the chip data can be processed by the payment system, and the issuer itself receives messages in a format typical for magnetic stripe transactions.
Further, the issuer carries out standard checks performed by it when using a card with a magnetic stripe (checking the card's activity, history of using the card, the absence of a card number in the list of cards blocked by the issuer, the presence of funds in the account associated with the card, etc.).
Information contained in CVR and TVR objects may be of particular importance for the issuer's decision-making. With the help of CVR and TVR data, the issuer can obtain information about how the transaction was processed in the dialogue between the card and the terminal. In particular, the following information is of great importance:
- whether offline card authentication was performed and how it was completed;
- how the offline card authentication was completed during the processing of a previous transaction;
- whether an offline verification of the PIN-code value was carried out and how it ended;
- whether the cardholder has used all the opportunities provided to him to enter the PIN code correctly (whether the PTL limit has been exceeded);
- whether the offline limits on the number of sequentially executed offline transactions and the amounts spent on these transactions were exceeded;
- whether the last online transaction ended successfully;
- how the issuer authentication ended in the last online transaction;
- how the Issuer Script Processing commands were executed, etc.
Correction of card data primarily concerns:
- offline limits;
- parameters of card risk management;
- unlock / lock the card application;
- card blocking;
- unblocking the PIN-code verification procedure, which was blocked due to exceeding the PIN Try Limit;
After deciding on the result of the operation, the issuer generates an Issuer Authentication Data (Tag '91') and generates an authorization response to the servicing bank (message x110 of the ISO 8583 standard). In addition to the usual data typical of a transaction performed with a magnetic stripe card, this message includes special data related to the chip - ICC Related Data (data element 55 is used in the x100 authorization request). This data is placed in data item 55 of the xllO message. If issuer authentication was used, item 55 includes ARPC and ARC or ARPC, CSU and Proprietary Authentication Data (depending on the ARPC format used by the issuer).
If the issuer uses the commands of the Script Processing procedure, then they are also placed in element 55 of the message xllO.
If the terminal did not receive an authorization response, or received it too late, or received it with syntax errors, the terminal continues to process the transaction, considering that the request cannot be sent to the issuer (unable to go online).
After the terminal has received the Issuer Authentication Data (Tag '91') in the authorization response, it checks the content of bit 3 of byte 1 of the AIP "Issuer authentication is supported". If this bit is 1, the card supports the EXTERNAL AUTHENTICATE command and issuer authentication must be performed using this command. The terminal prepares the C-APDU block corresponding to the EXTERNAL AUTHENTICATE command (Table 4.28).
Tab. 4.28. Command parameters
EXTERNAL AUTHENTICATE
| Code | Meaning |
| CLA | '00'h |
| INS | '82'h |
| Р1Р2 | '0000'h |
| Lc | 8-16 |
| Data | Issuer Authentication Data |
| Le | Absent |
During the execution of the transaction, the terminal can send the EXTERNAL AUTHENTICATE command to the card only once. If this requirement is violated, the card returns a response to the terminal with SWlSW2 = '6985'h. Regardless of SW1SW2 values in the R-APDU block, the terminal must set bit 5 of byte 1 of TSI "Issuer authentication was performed" equal to 1.
If bit 3 of Byte 1 of the AIP "Issuer authentication is supported" is 0, the second GENERATE AC command is used to authenticate the issuer. In this case, the issuer MUST put a value corresponding to Tag '91' (Issuer Authentication Data) and Tag '8A' (Authorization Response Code) in the Tag-Length reference list specified by the CDOL2 object.
Recall that in the M / Chip 4 application, the GENERATE AC command is used to authenticate the issuer, and in the VIS 1.4.x application, the EXTERNAL AUTHENTICATE command.
Note that in the M / Chip 4 application, using the GENERATE AC command and the ARPC Response Code element, provided the issuer is successfully authenticated, you can change the card parameters even before the card performs risk management procedures (in the CPA application the same effect is achieved using the Card Status Update element) ... Of course, the same result can be achieved using critical commands of the Script Processing procedure (see section 4.13). However, the first option is easier to implement. In addition, it is more economical in terms of the amount of data transferred to the card and more reliable in terms of implementation (the probability of failure when changing the parameters of the card is lower).
If the card supports issuer authentication (in accordance with the EMV standard, this function is optional for the card), then the card checks the Issuer Authentication Data element regardless of the command used to transfer this element to the card.
The card and the issuer use a common algorithm for generating ARQC and ARPC cryptograms. The most commonly used are the algorithms described in clause 3.14 (method 1 and method 2).
In the case of using method 1, the card, having received the ARPC value, decrypts it on the SK AC session key and applies the modulo 2 bitwise addition operation with the ARQC cryptogram value to the resulting 8-byte value. If the resulting value is (ARD || '00' || '00' || '00' || '00' || '00' || '00'), where ARD is composed of bytes 9 and 10 of the element Issuer Authentication Data, then the issuer authentication is considered successful.
Method 2 uses the ARPC cryptogram re-computation method. From the received Issuer Authentication Data element, the card strips off the four leftmost bytes, and the remaining right Z bytes are concatenated with the ARQC cryptogram, so that the element L = ARQC || Z. Algorithm 3 of ISO / IEC 9797-1 is applied to element Y for calculating MAC value using 16-byte session key SK AC . In this case, the size of the MAC value is chosen equal to four bytes. If the received MAC value is equal to the four previously truncated Issuer Authentication Data bytes, then the issuer authentication was successful.
Note that if the CDA method is used to authenticate the card, then the decision of the card / issuer may not be final. For example, if a card generates a TS cryptogram, but the card's CDA authentication fails, the transaction will be rejected by the terminal.
To improve the security of card transactions, the merchant or card issuer may initiate an alternate authorization. The alternative authorization requested by the issuer is implemented as follows. In the authorization response, the issuer uses a response code indicating the need for an alternative authorization. Having received a response code requiring alternative authorization, the terminal completes the transaction, requiring the card to generate an AAC cryptogram. After that, the merchant contacts its servicing bank, which in turn contacts the card issuer and provides him with information about the card holder. Based on the additional information received, the issuer makes a decision on the result of the transaction and sends the Authorization Approval Code to the servicing bank.
If an alternative authorization is requested by the merchant, it continues in the same way as in the case of authorization initiated by the issuer, starting with the step when the terminal generates the GENERATE AC command, requiring the AAC cryptogram from the card.
