Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
A Payment System Environment (PSE) file is a DDF file that defines card payment applications. The PSE file is optional for the card and follows the rules in Section 12.2.2 of Book 1 of the EMV 4.2 standard. The PSE file is identified by its reserved DDF Name, which is 1PAY.SYS.DDF01. Quite often, in practice, a PSE file is simultaneously an MF file (FID = '3F00'h), i.e., the root file of the card file system.
The FCI Template data object for PSE has the same structure as for any other DDF file (Figure 3.8).
Tag 6F - FCI Template (М)
Rice. 3.8. FCI Template structure for PSE
A possible difference is that the FCI Proprietary Template PSE data object contains two additional optional elements: Language Preference (Tag '5F2D') and Issuer Code Table Index (Tag '9F1T). A list of all objects of the FCI Proprietary Template PSE file is presented in Table. 3.9.
Tab. 3.9. FCI Proprietary Template Data Object for PSE File
The values of all data items in table. 3.9 have been clarified in paragraphs 3.5 and 3.7.
In the case of the IPC, the terminal interacts with the card in accordance with the client-server architecture. In this case, the card plays the role of a server, and the terminal plays the role of a client. The terminal sends data and instructions (in the form of a command) to the card that determine the further actions of the card during the transaction, and receives back the data (in the form of a response to the command) required by the terminal to continue processing the operation.
To clarify the nature of the information exchange of data between the card and the terminal, the applications of the card and the terminal (obviously, it is between them that information exchange takes place) can be considered as deterministic finite state machines. In finite state machines, the next state of an automaton is determined by its present state and an external event. In the case of the IPC, the state of the card application is a collection of all data items and cryptographic pairs of the MasterCard
^? 9
meters of the application at a given time. An external event for the IPC is a command coming from the terminal. Depending on the data contained in the command, including the purpose of the command, as well as the current state of the card, the IPC application changes its state (in the terminology of state machines, it goes into a new state). In addition, the IPC application, based on the current state and command parameters of the terminal, calculates an output signal representing a response to the terminal.
Note that the initial state of the card application is the state it enters into after receiving the Reset signal from the terminal.
The exchange of information between card and terminal applications from the point of view of communications is carried out in accordance with the seven-level reference model for open systems interaction (EMVOS). EMVOC levels are shown in table. 2.6. In the dialogue between the IPC and the terminal, only three levels of interaction of open systems are used: physical, channel and application (see clause 2.4).
The physical layer defines the characteristics of the electrical signals exchanged between the card and the terminal. The link layer is represented by half-duplex asynchronous protocols T = 0 and T = 1 (see clauses 2.4.1 and 2.4.2) for contact cards and half-duplex asynchronous protocol T = CL for contactless cards (see clause 7.3).
The C-APDU (Command Application Protocol Data Unit) and R-APDU (Response Application Protocol Data Unit) data blocks are used for interaction between the card and the terminal at the application level. With the help of C-APDU blocks, the terminal transmits data to the card and an instruction defining what the card should do using the information received in the block. An instruction together with data is a command. The card transmits its response to the command in the R-APDU unit.
The structure of the C-APDU is shown in Fig. 3.9.
The description of the purpose of the individual elements of the C-APDU unit is given in table. 3.10.
Tab. 3.10. Purpose of the elements of the C-APDU block
As seen from Fig. 3.9, the block consists of a mandatory 4-byte header and an optional command body. The header includes a command class (CLA), an instruction code (INS), and two parameters P1 and P2. All listed data items are 1 byte in size each.
The most significant (left) nibble of the CLA command class determines whether the command is common to smart cards or refers to a specific smart card standard (eg EMV). The corresponding values of the left nibble are given in table. 3.11.
Tab. 3.11. Left nibble CLA
The ISO 7816-4 standard defines the basic commands used by any IPC. These commands include commands for selecting a file, reading and modifying data, card authentication, etc. Additional commands appear in the EMV standard (for example, GET PROCESSING OPTIONS or GENERATE AC).
The right nibble of the CLA value represents the Access Condition Nibble and determines the condition of the command's access to the file (see p. 3.3). The EMV standard uses three values for the access condition: '0'h,' 4'h, or 'C'h. As follows from the table. 3.5, the value '0'h means that no security mechanisms are used when processing the command, the value' 4'h means that the integrity of the command data is ensured. Finally, the meaning of Chapter 3. FILE STRUCTURE, COMMANDS AND DATA PROTECTION MECHANISMS ...
MasterCard
The second byte of the C-APDU (INS) header is used to encode the command destination. The various commands used in EMV will be discussed below.
The semantics and values of the parameters P1 and P2 depend on the purpose of a particular command (for an explanation of the commands used in the EMV standard, see section 3.10).
If the size of the C-APDU is five bytes, then the fifth byte encodes the parameter L e , which is the expected number of bytes in the data field of the R-APDU.
If the size of the C-APDU is greater than five bytes, then the fifth byte encodes the L c parameter , which is the number of bytes in the Data field of the C-APDU, and the L c bytes following the fifth byte constitute the Data field of the C-APDU. It follows that the maximum number of bytes in the Data field of the command is 255 bytes.
If the Data field is followed by one more byte of information, then it determines the value of L e . A zero value of L e means that the maximum number of bytes (256 bytes) is expected in the data field of the R-APDU.
As seen from Fig. 3.10, the R-APDU block consists of an optional block body of L r bytes in size , where L r <L c , and a mandatory block tail (Trailer) of 2 bytes. The tail of the block defines the status words (Status Word) SW1 and SW2, each 1 byte in size, which determine the result of the command execution.
Rice. 3.10. R-APDU structure
To represent data in the R-APDU block, two template formats are used. Response Message Format 1 (Tag '80') is used to return data to the terminal without using BER-TLV encoding. In contrast, Response Message Format 2 (Tag '77') is used to return BER-TLV encoded data objects to the terminal.
The status bytes SW1 and SW2 in accordance with EMV 4.2 take the following values (values are given in hexadecimal notation):
'62' '83' - the state of the nonvolatile memory has changed; the selected file is invalid.
'63' '00' - the state of the nonvolatile memory has changed; authentication failed.
'63' 'Cx' - the state of the non-volatile memory has not changed. The "x" value is the counter value, ranging from 0 to 15. The status bytes SWl = '63'h, SW2 =' Cx'h are used in response to the VERIFY command in cases when:
• While processing a command, an error was detected (Checking Errors) and the command was not processed.
The following status bytes are used in the case when command processing is impossible, for example, because command processing is not allowed by the card for various reasons, or incorrect parameters are specified in the command.
'69' '83' - command not allowed; the authentication method is blocked (used, for example, in response to the VERIFY command, in the case when the PIN code check is blocked because the PIN Try Counter has been reset);
'69' '84' - the command is not allowed; the data used is incorrect (for example, the current value of the PBX is 'FFFF'h; in this case, the response to the GET PROCESSING OPTIONS command will be SWlSW2 =' 6984'h);
'69' '85' - command not allowed; the conditions for using the command are not satisfied;
'6A' '81' - incorrect values of parameters P1 and / or P2; the function is not supported;
'6A' '82' - incorrect values of parameters P1 and / or P2; File not found;
'6A' '83' - incorrect values of parameters P1 and / or P2; record not found;
'6A' '88' - Required data was not found.
The FCI Template data object for PSE has the same structure as for any other DDF file (Figure 3.8).
Tag 6F - FCI Template (М)
- ----? Thad 84 - DF Name = “1PAY.SYS.DDF01” (M)
- -----? Tag А5 - FCI Proprietary Template (М)
- -----? Thad 88 - SFI of the directory elementary file (M)
- ----? Tag 5F2D - Language Preference (0)
- -----? Tag 9F11 - Issuer Code Table Index (0)
- -----? Tag BFOC - FCI Issuer Discretionary Data (0)
Rice. 3.8. FCI Template structure for PSE
A possible difference is that the FCI Proprietary Template PSE data object contains two additional optional elements: Language Preference (Tag '5F2D') and Issuer Code Table Index (Tag '9F1T). A list of all objects of the FCI Proprietary Template PSE file is presented in Table. 3.9.
Tab. 3.9. FCI Proprietary Template Data Object for PSE File
| Tag | Data object content | Obligation of data object |
| '88'h | SFI of Directory Elementary File | Mandatory |
| '5F2DT1 | Language Preference | Optional |
| '9Fll'h | Issuer Code Table Index | Optional |
| 'BFOC'h | FCI Issuer Discretionary Data | Optional |
The values of all data items in table. 3.9 have been clarified in paragraphs 3.5 and 3.7.
Commands
The card and the terminal are the key participants in any transaction using a plastic card. In the case of a card with a magnetic stripe, information exchange between the card and the terminal usually boils down to the terminal reading the information located on the magnetic stripe of the card. In some cases, the terminal has the ability to write data to the third track of the magnetic stripe. In any case, the magnetic stripe card plays a passive role as a custodian of information.In the case of the IPC, the terminal interacts with the card in accordance with the client-server architecture. In this case, the card plays the role of a server, and the terminal plays the role of a client. The terminal sends data and instructions (in the form of a command) to the card that determine the further actions of the card during the transaction, and receives back the data (in the form of a response to the command) required by the terminal to continue processing the operation.
To clarify the nature of the information exchange of data between the card and the terminal, the applications of the card and the terminal (obviously, it is between them that information exchange takes place) can be considered as deterministic finite state machines. In finite state machines, the next state of an automaton is determined by its present state and an external event. In the case of the IPC, the state of the card application is a collection of all data items and cryptographic pairs of the MasterCard
^? 9
meters of the application at a given time. An external event for the IPC is a command coming from the terminal. Depending on the data contained in the command, including the purpose of the command, as well as the current state of the card, the IPC application changes its state (in the terminology of state machines, it goes into a new state). In addition, the IPC application, based on the current state and command parameters of the terminal, calculates an output signal representing a response to the terminal.
Note that the initial state of the card application is the state it enters into after receiving the Reset signal from the terminal.
The exchange of information between card and terminal applications from the point of view of communications is carried out in accordance with the seven-level reference model for open systems interaction (EMVOS). EMVOC levels are shown in table. 2.6. In the dialogue between the IPC and the terminal, only three levels of interaction of open systems are used: physical, channel and application (see clause 2.4).
The physical layer defines the characteristics of the electrical signals exchanged between the card and the terminal. The link layer is represented by half-duplex asynchronous protocols T = 0 and T = 1 (see clauses 2.4.1 and 2.4.2) for contact cards and half-duplex asynchronous protocol T = CL for contactless cards (see clause 7.3).
The C-APDU (Command Application Protocol Data Unit) and R-APDU (Response Application Protocol Data Unit) data blocks are used for interaction between the card and the terminal at the application level. With the help of C-APDU blocks, the terminal transmits data to the card and an instruction defining what the card should do using the information received in the block. An instruction together with data is a command. The card transmits its response to the command in the R-APDU unit.
The structure of the C-APDU is shown in Fig. 3.9.
The description of the purpose of the individual elements of the C-APDU unit is given in table. 3.10.
| CLA | INS | Р1 | P2 | Lc | Data | Le |
| ? * - Required header -? | * - Optional body - * |
Tab. 3.10. Purpose of the elements of the C-APDU block
| Code | Description | Length |
| CLA | Team class | 1 |
| INS | Command code | 1 |
| Pl | Command parameter 1 | 1 |
| P2 | Command parameter 2 | 1 |
| Lc | Number of bytes in the Data field | 0 or 1 |
| Data | Data string (= Lc) | Variable |
| Le | Maximum number of bytes expected in the card response data field | 0 or 1 |
As seen from Fig. 3.9, the block consists of a mandatory 4-byte header and an optional command body. The header includes a command class (CLA), an instruction code (INS), and two parameters P1 and P2. All listed data items are 1 byte in size each.
The most significant (left) nibble of the CLA command class determines whether the command is common to smart cards or refers to a specific smart card standard (eg EMV). The corresponding values of the left nibble are given in table. 3.11.
Tab. 3.11. Left nibble CLA
| Meaning | Interpretation |
| '0'h | Inter-industry team |
| '8'h | Command defined in EMV |
The ISO 7816-4 standard defines the basic commands used by any IPC. These commands include commands for selecting a file, reading and modifying data, card authentication, etc. Additional commands appear in the EMV standard (for example, GET PROCESSING OPTIONS or GENERATE AC).
The right nibble of the CLA value represents the Access Condition Nibble and determines the condition of the command's access to the file (see p. 3.3). The EMV standard uses three values for the access condition: '0'h,' 4'h, or 'C'h. As follows from the table. 3.5, the value '0'h means that no security mechanisms are used when processing the command, the value' 4'h means that the integrity of the command data is ensured. Finally, the meaning of Chapter 3. FILE STRUCTURE, COMMANDS AND DATA PROTECTION MECHANISMS ...
MasterCard
The second byte of the C-APDU (INS) header is used to encode the command destination. The various commands used in EMV will be discussed below.
The semantics and values of the parameters P1 and P2 depend on the purpose of a particular command (for an explanation of the commands used in the EMV standard, see section 3.10).
If the size of the C-APDU is five bytes, then the fifth byte encodes the parameter L e , which is the expected number of bytes in the data field of the R-APDU.
If the size of the C-APDU is greater than five bytes, then the fifth byte encodes the L c parameter , which is the number of bytes in the Data field of the C-APDU, and the L c bytes following the fifth byte constitute the Data field of the C-APDU. It follows that the maximum number of bytes in the Data field of the command is 255 bytes.
If the Data field is followed by one more byte of information, then it determines the value of L e . A zero value of L e means that the maximum number of bytes (256 bytes) is expected in the data field of the R-APDU.
As seen from Fig. 3.10, the R-APDU block consists of an optional block body of L r bytes in size , where L r <L c , and a mandatory block tail (Trailer) of 2 bytes. The tail of the block defines the status words (Status Word) SW1 and SW2, each 1 byte in size, which determine the result of the command execution.
| Data | SW1 | SW2 |
| ? * - Block body - * | ? * - Tail of the block --- |
Rice. 3.10. R-APDU structure
To represent data in the R-APDU block, two template formats are used. Response Message Format 1 (Tag '80') is used to return data to the terminal without using BER-TLV encoding. In contrast, Response Message Format 2 (Tag '77') is used to return BER-TLV encoded data objects to the terminal.
The status bytes SW1 and SW2 in accordance with EMV 4.2 take the following values (values are given in hexadecimal notation):
- Normal processing '90' '00' - Command processing completed normally.
- Warning processing.
'62' '83' - the state of the nonvolatile memory has changed; the selected file is invalid.
'63' '00' - the state of the nonvolatile memory has changed; authentication failed.
'63' 'Cx' - the state of the non-volatile memory has not changed. The "x" value is the counter value, ranging from 0 to 15. The status bytes SWl = '63'h, SW2 =' Cx'h are used in response to the VERIFY command in cases when:
- - the PIN-code value is incorrect;
- - the control field of the PIN-block (see the description of the VERIFY command in p. 3.10) is not equal to '02'h;
- - the length of the PIN-code is strictly less than 4 or strictly more than 12;
- - the value of the fill character in the PIN block is not equal to 'F'h.
• While processing a command, an error was detected (Checking Errors) and the command was not processed.
The following status bytes are used in the case when command processing is impossible, for example, because command processing is not allowed by the card for various reasons, or incorrect parameters are specified in the command.
'69' '83' - command not allowed; the authentication method is blocked (used, for example, in response to the VERIFY command, in the case when the PIN code check is blocked because the PIN Try Counter has been reset);
'69' '84' - the command is not allowed; the data used is incorrect (for example, the current value of the PBX is 'FFFF'h; in this case, the response to the GET PROCESSING OPTIONS command will be SWlSW2 =' 6984'h);
'69' '85' - command not allowed; the conditions for using the command are not satisfied;
'6A' '81' - incorrect values of parameters P1 and / or P2; the function is not supported;
'6A' '82' - incorrect values of parameters P1 and / or P2; File not found;
'6A' '83' - incorrect values of parameters P1 and / or P2; record not found;
'6A' '88' - Required data was not found.
