Issue Script Processing EMV Procedure
Using the CSU element is an alternative to the issue Script Processing procedure. This element allows the Issuer to change the card state and change the values of its parameters.
If the Issuer authentication is successful and the terminal requests a vehicle from the card, and bit 8 of byte 2 ‘Issuer Approves Online Transaction’ in the received CSU element is equal to 1, the card approves the transaction and returns the vehicle cryptogram.
If the Issuer authentication is successful and bit 8 of byte 2 ‘Issuer Approves Online Transaction’ in the received CSU element is 0, the card rejects the transaction and returns the AAC cryptogram.
Thus, using the CSU element and the ARPC cryptogram Format 2 allows ensuring the integrity of information exchange between the Issuer and the card. In particular, it ensures that unauthorized modification of the Issuer’s decision on the result of the transaction is impossible.
If the Issuer authentication is successful and bit 7 of byte 2 ‘Card Block’ in the received CSU element is equal to 1, then all card applications are blocked. The card must respond to all subsequent SELECT commands using the SW1SW2 value equal to ‘ 6A81’h.
If the Issuer authentication is successful and the bit b of byte 2 ‘Application Block’ in the received CSU element is equal to 1, the selected card application is blocked. The card must respond to all subsequent SELECT commands using the SW1SW2 value equal to ‘ 6283’h, and return the AAC cryptogram to the terminal for the GENERATE AC commands.
If the Issuer authentication is successful and bit 5 of byte 2 ‘Update PIN Try Counter’ in the received CSU element is equal to 1, then the RTS value in the CVR is set to the number specified in bits 4-1 of the first CSU byte.
If the Issuer authentication is successful and bit 5 of byte 2 ‘ Update PIN Try Counted in the received CSU element is O, the RTS value is not changed, and the values of bits 4-1 of the first CSU byte are not used by the CCD application.
If the Issuer authentication is successful and bit 4 of byte 2 ‘Set Go Online on Next Transaction’ in the received CSU element is equal to 1, the card sets the corresponding CVR bit to 1 and sends the next transaction for authorization to the Issuer, if the terminal is able to process the transaction online. The card will continue to send transactions for online authorization in the case of an online terminal as long as the value of bit 2 of byte 4 of the CVR ‘Go Online on Next Transaction’ is 1.
If the Issuer authentication is successful and bit 3 of byte 2 ‘ CSU created by Proxy for Issued in the received CSU element is O, then depending on the value of bits 2 and 1 of byte 2, the CSU card resets the VCC and CELL parameters as specified in these bits:
if B2=0, b 1=0, the parameter values are not changed;
if B2=0, S=1, the parameter values are set to the corresponding limits; after resetting the values, offline transactions on the card can occur within the established limits;
if B2=1, S=0, the parameter values are set to 0; after resetting the values, offline transactions on the card become impossible;
if B2=1, S=1, then the parameter values, even though the operation is online, are reset according to the rules adopted for offline operations.
The Issuer must set the following option in the settings of the CCD card. If in the CSU element received by the card, bit 3 of byte 2 ‘CSU created by Proxy for Issuer’ is equal to 1 (i.e. the response was prepared not directly by the Issuer, but by its representative), then should the card use the values of bits 2 and 1 of byte 2 of CSU to reset the values of VCC and HONEYCOMB. If the card must not use the specified bits, then the card configuration must explicitly specify one of the following solutions, which the card must follow in this case:
the values of the VCC and HONEYCOMB parameters are not changed;
the values of the VCC and HONEYCOMB parameters are set equal to their upper limits;
the values of the VCC and HONEYCOMB parameters are set to 0;
the values of the VCC and CELL parameters are reset according to the rules adopted for processing an offline operation.
In case of successful authentication of the Issuer, depending on the Issuer’s decision recorded on the card, either the values of bits 2 and 1 of byte 2 of the CSU are used to reset the parameters, or one of the above actions defined by the Issuer.
If the transaction was successfully sent for authorization to the Issuer (i.e. the Authorization Response Code received by the card does not indicate that the transaction could not be sent for authorization to the Issuer), the authorization is approved by the card if:
the terminal requests the vehicle cryptogram from the card;
one of two conditions is met:
the Issuer authentication was performed successfully, and the ‘Issuer Approves Online Transaction’ bit in the CSU is equal to 1.
Issuer authentication was not performed, and the CCD card does not require Issuer authentication to be performed for successful transaction authorization.
If the transaction was successfully sent for authorization to the Issuer (i.e. the Authorization Response Code received by the card does not indicate that the transaction could not be sent for authorization to the Issuer), the CCD card must reset the VCC and CELL values if the following conditions are met simultaneously:
the terminal requests the vehicle cryptogram from the card;
Issuer authentication was not performed;
The CCD card does not require that the Issuer’s authentication is performed for successful transaction authorization;
The CCD card does not require EMI authentication to successfully reset the VCC and CELL parameters tent.
If the transaction was successfully sent for authorization to the Issuer (i.e. the Authorization Response Code received by the card does not indicate that the transaction could not be sent for authorization to the Issuer), the CCD card must set the counter value of the number of commands processed by the card in the Script Processing procedure to O, if:
or Issuer authentication was successfully completed;
or all of the following conditions are met:
- Issuer authentication was not performed;
— The CCD application does not require authentication of the Issuer in order to be considered a successful transaction;
— The CCD application does not require Issuer authentication in order to reset the NVI parameter values.
Online transaction processing and Issuer authentication
The terminal may send a message to the servicing Bank initiating online transaction processing for one of the following reasons:
the terminal Type corresponds to the “online only” type, which requires mandatory sending of an authorization request to the card Issuer;
the merchant’s cashier decides to send the transaction for online authorization, for example, after noticing strange behavior of the cardholder;
the terminal’s risk management procedure selected this transaction for online authorization (for example, as a result of a random transaction selection).
the terminal decides whether to process the transaction online based on the results of TVR analysis against TAC and IAC objects;
despite the fact that the terminal offers to approve the transaction offline, the card decides to send the transaction to the Issuer for authorization based on the results of CVR analysis.
Regardless of the reason, when choosing an online transaction processing method, the card responds to the terminal by specifying the value ARQC in the Cryptogram Information Data element. The terminal sends a message containing information related to the card and the results of transaction processing in accordance with the Protocol used for working with the host terminal. Based on this data, the host of the servicing Bank generates an authorization request (ISO 8583 message) containing such data as:
arqc application cryptogram;
card information (PAN card number, PAN Sequence Number, card expiration date, AIP, etc.)
operation number on the PBX card;
transaction type, transaction size, transaction currency code, transaction generation time;
random number generated by the terminal, Unpredictable Number;
the Issuer Application Data element, which can include the Issuer’s key ID for generating the applied cryptogram and the version number of the algorithm used for calculating the cryptogram, the DAC or IDN values, the results of TVR terminal checks and the results of CVR card checks, the values of the cumulative offline transaction amount counters, and so on.
After receiving the authorization request, the Issuer first checks whether the card used for the transaction is genuine, i.e. issued by the Issuer. To do this, the Issuer host checks the ARQC value according to the following algorithm:
based on the key ID contained in the Issuer Application Data, the corresponding key of the Issuer 1MKLS is extracted to generate the applied cryptogram;
using the card data (PAN and PAN Sequence Number) and the key of the Issuer 1MKLS,the key for generating the applied cryptogram of the MK card is calculated, With;
using the PBX and possibly an Unpredictable Number, the session key SK^ for generating the cryptogram 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 resulting ARQC value. If the values match, the card authentication is considered successful, and the card itself is considered authentic. Otherwise, it is considered that the card authentication failed.
Note that the card Issuer’s authentication procedure is mandatory in accordance with the EMV standard. At the same time, payment systems allow the presence of issuers that are not able to process chip data at the migration stage to the IPC (such banks are called magnetic grade issuers). For such issuers, chip data can be processed by the payment system, and the Issuer itself receives messages in a format typical of magnetic stripe transactions.
Further, the Issuer conducts standard checks them and using cards with a magnetic strip (activity check card usage history of the card, lack of room-
RA card blocked by the card Issuer, availability of funds in the account associated with the card, etc.).
Of special importance for adoption by the Issuer of a resolution can have the information contained in the objects of the CVR and TVR. Therefore, it is highly desirable for the card to support the optional issue Application Data element, as well as to include CVR and TVR values in this element.
Using CVR and TVR data, the Issuer can get information about how the transaction was processed in the card’s dialog with the terminal. In particular, the following information is essential:
was offline card authentication performed and how did it end;
how did offline card authentication end during processing of the previous transaction;
was the PIN value checked offline and how did it end;
has the cardholder used all the opportunities provided to them to enter the PIN code correctly (has the PTL limit been exceeded);
whether the offline limits on the number of consecutive offline operations performed by the card and the amount spent on these operations were exceeded;
did the last online transaction end successfully;
how did the Issuer’s authentication end in the last online transaction;
how the issue Script Processing and so on commands were executed
The data received by the Issuer allows it, first, to make a correct decision about the result of this operation, and second, to correct the card data using the Script Processing commands. The Issuer’s decision on the transaction result is made in the ARC authorization response.
With regard to the correction of card data, it is primarily concerned with:
values of offline limits;
unblocking / blocking the card app;
card blocking;
unblocking a PIN verification procedure that was blocked due to exceeding the PIN Try Limit;
changes to the cryptographic parameters of the card that periodically change on the card for reasons of improving the security of operations performed using it;
changes to the card details, such as its expiration date (the cardholder can use it at least at an ATM until they go to the Bank and get a new card).
After making a decision on the result of the operation, the Issuer generates the Issuer Authentication Data (Tag ’91’) and generates an authorization response to the servicing Bank (message X110 of ISO 8583). In addition to the usual data typical for a transaction performed on a magnetic stripe card, this message includes special data related to the chip— ICC Related Data. This data is placed in the data element 055 of the X110 message. If Issuer authentication was used, element 055 includes ARPC and ARC, or CSU and Proprietary Authentication Data (depending on the ARPC format used by the Issuer).
If the Issuer uses corrective commands of the Script Processing procedure, they are also placed in element 055 of the X110 message.
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 passed to the Issuer (unable to go online).
After the terminal receives an authorization response with the Issuer Authentication Data (Tag ‘ 9G), it checks the contents of bit 3 of byte 1 of the AIP “Issuer authentication is supported”. If this bit is equal to 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).
During 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 the SW1SW2 values in the R-APDU block
Parameters of the EXTERNAL AUTHENTICATE command
Code Value
CLA ‘OO’h
INS ’82’h
P1P2 ‘0000’h
Lc 8-16
Data Issuer Authentication Data
Le Is Missing
the terminal must set bit 5 of byte 1 of the TSI “issue authentication was performed” to 1.
If the value of 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 the value corresponding to Tag ‘9G (Issuer Authentication Data) and Tag ‘8A’ (Authorization Response Code) in the list of references set by the CD0L2 object.
We remind the reader that the m/Chip 4 application uses the EXTERNAL AUTHENTICATE command to authenticate the Issuer, and the VIS 1.4.x application uses the GENERATE AC command.
Note that using the EXTERNAL AUTHENTICATE command and the ARPC Response Code element, if the Issuer is successfully authenticated, you can change the card parameters even before the card performs risk management procedures. Of course, the same can be achieved using the critical commands of the script processing procedure (see clause 4.3) when using the GENERATE AC command card. However, the first option is easier to implement. In addition, it is more economical in terms of the amount of data transmitted to the card and more reliable in terms of implementation (the probability of failure when changing the card parameters is lower).
If the card supports Issuer authentication (in accordance with the EMV standard, this function is optional for the card), the card checks the Issuer Authentication Data element regardless of which command was used to transmit this element to the card.
The card and Issuer use a common algorithm for generating ARQC and ARPC cryptograms. The most commonly used algorithms are those described in clause 3.14 (Method 1 and Method 2).
If Method 1 is used, the card gets the ARPC value, decrypts it on the session key SK,,- and applies the bitwise addition operation modulo 2 with the value of the ARQC cryptogram to the resulting 8-byte value. If the resulting value has the form (ARDH’O’I’O’I’o’o’o’o’o’o’o’o’o’o’o’o’), where ARD is composed of bytes 9 and 10 of the Issuer Authentication Data element, then the Issuer authentication is considered successful.
When using Method 2, the ARPC cryptogram re-calculation method is applied. From the resulting issue Authentication Data element, the card cuts off the 4 leftmost bytes, and the remaining right z bytes are concatenated with the ARQC cryptogram, so that the element Y=ARQC||z is obtained. The y element uses the 3 IS0/IEC 9797-1 Algorithm to calculate the MAC value using the 16-byte session key SK^ . In this case, the size of the MAC value is selected to be 4 bytes. If the received MAC value is equal to 4 bytes of the previously clipped Issuer Authentication Data, then the Issuer authentication was successful.
Note that if the CDA method is used for card authentication, the card/Issuer’s decision may not be final. For example, if the card generates a vehicle cryptogram, but the card authentication using the CDA method failed, the transaction will be rejected by the terminal.
To increase the security of card transactions, the merchant or card Issuer can initiate alternative authorization. Alternative authorization requested by the Issuer is implemented as follows. In the authorization response, the Issuer uses the response code indicating the need for alternative authorization (for example, in the VIS 1.4.x specifications, ARC in this case takes the values ‘Ol’h and’ 02’h). After receiving the code that requires alternative authorization, the terminal completes the transaction, requiring the card to generate the AAS cryptogram. After that, the merchant contacts its servicing Bank, which, in turn, contacts the card Issuer and provides them with information about the cardholder. Based on the additional information received, the Issuer makes a decision on the transaction result and sends the authorization Approval Code to the servicing Bank. This code must be provided in the clearing message of the servicing Bank. As for the ARQC cryptogram, it can optionally be presented in the clearing message and must be presented at the request of the Issuer. Currently, leading payment systems are working to make the transaction cryptogram (as well as other chip data) a mandatory element of the clearing message.
If alternative authorization is requested by the merchant, it continues as in the case of authorization initiated by the Issuer, starting from the step when the terminal generates the GENERATE AC command, requiring the card to use the AAC cryptogram.
Issue Script Processing Procedure
The EMV standard allows the Issuer to change the card state using special commands called Post-issue commands. This set of commands is passed by the Issuer in the authorization response. The terminal’s task is to parse the message received from the Issuer into Post-issue commands and send them one by one to the card for execution. This procedure is called issue Script Processing.
The issue Script Processing commands include:
blocking all card applications (CARD BLOCK);
blocking the application selected on the card (APPLICATION BLOCK);
unblocking the selected application (APPLICATION UNBLOCK).
changing the data of a linear file record (UPDATE RECORD).
changing the value of the card parameter (PUT DATA).
change / unlock the PIN code (PIN CHANGE/UNBLOCK).
When sending commands to issue Script Processing, the mechanisms described in secure Messaging are used. The mandatory use of the MAC value (Message Authentication Code) in the issue Script Processing commands ensures the authentication of the command source and the integrity of the data transmitted in the command. The confidentiality of cryptographic keys and PIN blocks is ensured by secret data encryption.
The issue Script Processing procedure can be executed at any time after the first GENERATE AC command has been processed. The Issuer groups the issue Script Processing commands into blocks called the issue Script Template. Each such block is of two types: critical (Tag 71′), executed before the second command GENERATE AC, and non-critical (Tag 72′), executed after the second command GENERATE AC.
The VIS 1.4.x specification uses only non-critical issue Script Processing commands, while the M/Chip 4 specification can use both types of commands (the M/Chip 2.1 specification uses only critical commands).
Each block (issue Script Template) can contain the following data objects:
Issue Script Identifier (Tag ‘9F18’, 4 bytes in size). This object is an optional identifier of the command block, which allows the Issuer to understand in more detail which commands of the block were implemented successfully;
Issue Script Command APDU (Tag ’86’) — a template containing a single issue Script Processing command. The same block can contain several templates of the Issuer Script Command APDU.
In the authorization response, the Issuer can send several blocks of the Issuer Script Template. One authorization response from the Issuer may contain critical and non-critical blocks. The only restriction is that the length of a single block of the Issuer Script Template does not exceed 128 bytes.
After receiving the authorization response, the terminal begins sequentially processing the blocks of the issue Script Template commands in the order in which they are contained in the 055 field of the X110 message. For each issue Script Template, the terminal performs the following actions.
Data structure of the Issuer Script Results
Number
byte Name
byte Assignment
Byte 1 processing Result of the Issuer Script Template the Highest half byte:
’O’ – the block was not processed;
‘1’ – the processing unit has failed;
‘2’ – block processing completed successfully.
Junior half-byte:
‘0’ – value is undefined;
T – ‘E’ – block command number, less than 15;
‘F – block command number greater than 15
Bytes
2-5 issue Script Identifier The value of the data field of the issue Script Identifier object, if present, and 0 if the ID is missing
Adds this structure, which consists of similar structures for already processed command blocks, to the end of the byte string.
Sets the value of the “command Counter” for this command block to 0.
Parses the data field of the command block being processed (Tag 71′ or Tag 72’data object):
checks for the ID of the issue Script Identifier command block (Tag ‘9F18’). If the ID is present, sets its value in bytes 2-5 of the Issuer Script Results;
creates a stack that contains the command extracted from the next-in-order data object of the issue Script Command APDU (Tag ’86’) contained in the template data field of the issue Script Template command block.
When a new command is added to the stack, the “command counter” in the issue Script Results increases by one. After that, the command is sent to the card and the received R-APDU response considers the value SW1.
If the value SW1 indicates normal command processing (SWl= ‘ 90’h) or warning processing (SWl=’62’h or ’63’h), the terminal puts the following command extracted from the data field of the template of the next in order data object of the Issuer Script Command APDU on the stack and returns to point 4 of this algorithm. If the “command Counter” is set to 1, bit 3 of byte 1 of the TSI “Script Processing was performed” is set to 1. If there are no more issues in the template data field of the issue Script Template command block, the terminal proceeds to start processing the next issue Script Template command block contained in the Issuer’s response.
Note that the value of the” command Counter ” in issue Script Results is equal to the number of commands successfully processed by the card, if this value is less than or equal to 15. If the “command Counter” value is greater than 15, the card has successfully processed at least 15 commands.
If the value SW1 indicates that a command with an error was processed, the processing of commands in this block is terminated. The terminal sets the highest half-byte of the first byte of the Issuer Script Results to Yh. The terminal sets bit b of byte 5 of the TVR “Script processing failed before final GENERATE AC” is equal to 1 if the current command block 71 has a Tag’. The terminal sets bit 5 of byte 5 of TVR “Script processing failed after GENERATE AC” to 1 if the current command block has Tag 72′.
If all commands in the current command block are processed successfully, the terminal sets the highest half-byte of the first byte of the issue Script Results to ‘ 2’h.
It has already been mentioned that for CCD cards, there is an alternative option to change certain parameters of the card in relation to the procedures of the Issuer Script Processing. Using the Card Status Update (CSU) element, which is part of the Issuer Authentication Data element, the Issuer can:
block the card or the selected card app;
change the RTS value and VCC and CELL parameters that define restrictions on servicing operations in offline authorization mode;
set the Go Online on Next Transaction parameter in the CVR, which forces the card to perform the next operation in real time.
A necessary condition for changing parameters is the successful authentication of the Issuer.
Note that using CSU to modify card parameters is more reliable than using Script Processing procedures. The Script Processing command may not be executed for many reasons. For example, the servicing Bank failed to properly process the Issuer’s response and send commands to the terminal. There may also be Issuer errors in correctly calculating MAC values for Script Processing commands.
When using CSU, the parameter modification process is much simpler and more reliable. The issue Authentication Data object is part of field 055 of the authorization response X110 and is sent by the servicing Bank to the terminal without pre-processing. Therefore, there are only two reasons for the CSU element not to be processed by the card: either the Issuer authentication failed (ARPC verification failed), or there was a memory error when writing data passed to the card in the second GENERATE AC command.
In conclusion, we note that the idea of using CSU came from the application M/Chip 4, in which the data object Issuer Authentication Data contains the ARPC Response Code element, which actually coincides in its functional load with the CSU. In comparison with ARPC Response Code, the CSU element contains additional bits indicating that the card and / or card application must be blocked.