Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The EMV standard for the issuer provides the ability to change the data and state of the card using special commands called Post-Issuance commands or Issuer Script Processing commands. This set of commands is sent by the issuer in the authorization response. The task of the terminal is to parse the message received from the issuer into Post-Issuance commands and send them one by one for execution to the card. The procedure for issuing commands to the card application by the issuer is called Issuer Script Processing.
Issuer Script Processing commands include:
When issuing Issuer Script Processing commands, the Secure Messaging mechanisms described in clause 3.15 are used. Mandatory use of the MAC (Message Authentication Code) value in Issuer Script Processing commands ensures the authentication of the command source and the integrity of the data transmitted in the command. The confidentiality of data circulating between the issuer and the card is ensured by means of encryption of secret data.
The Issuer Script Processing procedure can be executed at any time after the completion of the processing of the first GENERATE AC command. The issuer groups Issuer Script Processing commands into blocks called Issuer Script Template. Each such block is of two types: critical (Tag '71'), executed before the second GENERATE AC command starts processing, and non-critical (Tag '72'), executed after the second AC GENERATE command is processed.
The VIS 1.4.x specification uses only non-critical Issuer Script Processing commands, while the M / Chip 4 specification can use both types of commands (in the M / Chip 2.1 specification, only critical commands are used).
Each block (Issuer Script Template) can contain the following data objects:
• Issuer Script Identifier (Tag '9F18', data field size 4 bytes). This object is optional and is the identifier of the command block, allowing the issuer to understand in more detail which block commands were successfully implemented;
• Issuer Script Command APDU (Tag '86') - a template containing one Issuer Script Processing command. One block can contain several Issuer Script Command APDU templates.
In the authorization response, the issuer can submit multiple Issuer Script Template blocks. Critical and non-critical blocks may be present in one authorization response of the issuer. The only limitation is that a single Issuer Script Template block is no longer than 128 bytes.
After receiving the authorization response, the terminal begins to sequentially process the Issuer Script Template command blocks in the order in which they are contained in field 55 of the xllO message. For each Issuer Script Template, the terminal performs the following actions:
1) creates a new data structure Issuer Script Results, storing information regarding the results of processing a block of commands. The type of structure is shown in table. 4.29.
Tab. 4.29. Issuer Script Results data structure
Adds this structure, consisting of similar structures for command blocks that have already been processed, to the end of the byte string;
Note that the value of the "Command Counter" in the Issuer 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 value of the “Command Counter” is greater than 15, then the card has successfully processed at least 15 commands;
Update (CSU), which is part of the Issuer Authentication Data element, an issuer can:
It should be noted that using CSU to modify map parameters is more reliable than Script Processing procedures. The Script Processing command may fail for many reasons. For example, the servicing bank was unable to properly process the issuer's response and send commands to the terminal. Errors of the issuer are also possible when calculating MAC values for Script Processing commands.
In the case of using a CSU, the process of modifying parameters is much simpler and more reliable. The Issuer Authentication Data object is a part of field 55 of the authorization response xllO and is sent by the servicing bank to the terminal without preliminary processing. Therefore, there are only two reasons for the CSU element not to be processed by the card: either the issuer authentication failed (the ARPC check failed), or there was a memory error while writing the data transferred to the card in the second AC GENERATE command.
In conclusion, note that the idea of using a CSU came from the M / Chip 4 application, in which the Issuer Authentication Data object contains an ARPC Response Code element (see 3.14), which actually coincides in its purpose with the CSU. Compared to the ARPC Response Code, the CSU defines additional bits to indicate whether the card and / or the card application should be locked.
Issuer Script Processing commands include:
- blocking of all card applications (CARD BLOCK);
- blocking of the application selected on the card (APPLICATION BLOCK);
- unlock the selected application (APPLICATION UNBLOCK);
- changing the data of a linear file recording (UPDATE RECORD);
- changing the value of the card parameter (PUT DATA);
- changing / unblocking the PIN-code (PIN CHANGE / UNBLOCK).
When issuing Issuer Script Processing commands, the Secure Messaging mechanisms described in clause 3.15 are used. Mandatory use of the MAC (Message Authentication Code) value in Issuer Script Processing commands ensures the authentication of the command source and the integrity of the data transmitted in the command. The confidentiality of data circulating between the issuer and the card is ensured by means of encryption of secret data.
The Issuer Script Processing procedure can be executed at any time after the completion of the processing of the first GENERATE AC command. The issuer groups Issuer Script Processing commands into blocks called Issuer Script Template. Each such block is of two types: critical (Tag '71'), executed before the second GENERATE AC command starts processing, and non-critical (Tag '72'), executed after the second AC GENERATE command is processed.
The VIS 1.4.x specification uses only non-critical Issuer Script Processing commands, while the M / Chip 4 specification can use both types of commands (in the M / Chip 2.1 specification, only critical commands are used).
Each block (Issuer Script Template) can contain the following data objects:
• Issuer Script Identifier (Tag '9F18', data field size 4 bytes). This object is optional and is the identifier of the command block, allowing the issuer to understand in more detail which block commands were successfully implemented;
• Issuer Script Command APDU (Tag '86') - a template containing one Issuer Script Processing command. One block can contain several Issuer Script Command APDU templates.
In the authorization response, the issuer can submit multiple Issuer Script Template blocks. Critical and non-critical blocks may be present in one authorization response of the issuer. The only limitation is that a single Issuer Script Template block is no longer than 128 bytes.
After receiving the authorization response, the terminal begins to sequentially process the Issuer Script Template command blocks in the order in which they are contained in field 55 of the xllO message. For each Issuer Script Template, the terminal performs the following actions:
1) creates a new data structure Issuer Script Results, storing information regarding the results of processing a block of commands. The type of structure is shown in table. 4.29.
Tab. 4.29. Issuer Script Results data structure
| Byte number | Byte name | Appointment |
| Byte 1 | Issuer Script Template processing result | High nibble: '0' - the block was not processed; T - block processing failed; '2' - block processing completed successfully. Least nibble: '0' - value is undefined; Т-'Е '- block command number, less than 15; 'F' - block command number greater than 15 |
| Bytes 2-5 | Issuer Script Identifier | Issuer Script Identifier object data field value if present and 0 if not present |
Adds this structure, consisting of similar structures for command blocks that have already been processed, to the end of the byte string;
- 2) sets the value of the "Command counter" for the current block of commands equal to 0;
- 3) parses the data field of the command block being processed (data object Tag '71' or Tag '72'):
- - checks for the presence of the Issuer Script Identifier (Tag '9F18'). If present, sets its value in bytes 2-5 Issuer Script Results;
- - creates a stack into which the command is placed, extracted from the next in order Issuer Script Command APDU data object (Tag '86'), contained in the data field of the template of the Issuer Script Template command block;
- 4) when a new command "Command counter" is added to the stack, the Issuer Script Results is increased by one. After that, the command is sent to the card and the value of SW1 is considered in the received R-APDU response.
Note that the value of the "Command Counter" in the Issuer 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 value of the “Command Counter” is greater than 15, then the card has successfully processed at least 15 commands;
- 5) if the SW1 value indicates the processing of a command with an error, the processing of the commands of this block is terminated. The terminal sets the high nibble of the first byte of Issuer Script Results to Th. The terminal sets bit 6 of byte 5 of TVR "Script processing failed before final GENERATE AC" equal to 1, if the current block of commands is critical. The terminal sets bit 5 of byte 5 of TVR "Script processing failed after GENERATE AC" equal to 1 if the current block of commands is not critical;
- 6) if all commands of the current block of commands are processed successfully, the terminal sets the high nibble of the first byte of Issuer Script Results equal to '2'h.
Update (CSU), which is part of the Issuer Authentication Data element, an issuer can:
- block the card or selected card application;
- change the value of the RTS;
- change the VCC and SOTA parameters defining restrictions on servicing card transactions in offline authorization mode;
- set the Go Online on Next Transaction parameter to CVR, forcing the card to perform the next operation in real time.
It should be noted that using CSU to modify map parameters is more reliable than Script Processing procedures. The Script Processing command may fail for many reasons. For example, the servicing bank was unable to properly process the issuer's response and send commands to the terminal. Errors of the issuer are also possible when calculating MAC values for Script Processing commands.
In the case of using a CSU, the process of modifying parameters is much simpler and more reliable. The Issuer Authentication Data object is a part of field 55 of the authorization response xllO and is sent by the servicing bank to the terminal without preliminary processing. Therefore, there are only two reasons for the CSU element not to be processed by the card: either the issuer authentication failed (the ARPC check failed), or there was a memory error while writing the data transferred to the card in the second AC GENERATE command.
In conclusion, note that the idea of using a CSU came from the M / Chip 4 application, in which the Issuer Authentication Data object contains an ARPC Response Code element (see 3.14), which actually coincides in its purpose with the CSU. Compared to the ARPC Response Code, the CSU defines additional bits to indicate whether the card and / or the card application should be locked.
