Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The terminal must first read the card data referenced in the AFL object. To read data, the terminal uses the READ RECORD command, following the algorithm described below. When describing it, we will take into account that the Value field of the AFL object has the form AFL = p! || F 2 1 | ... || F n , where F, (i - 1, ..., n) - 4-byte links, the content of which is defined in the previous section. The F references define the elementary file records that must be read by the terminal in order to process the transaction.
For each link F; (i = 1, ..., n) the sequence of steps described below is repeated.
Step 1. Parameter P2 of the READ RECORD command is set using the SFI value specified in the first byte of the F reference (the first five bits of P2 are equal to SFI).
Step 2. The terminal checks the correctness of the F link format ; (defined in the previous section). If it is violated, transaction processing is terminated.
Two parameters are entered: "Record number" and "Last record number". The "last record number" is set equal to the value of the third byte of the link F ,. The initial value of the "Record number" is assumed to be equal to the value of the second byte F ?
Step 3. The terminal sets the parameter P1 of the READ RECORD command equal to the value of "Counter number" and sends the READ RECORD command to the card.
Step 4. If the R-APDU received by the terminal in response to the READ RECORD command contains SWlSW2 = '9000'h, the terminal parses the AEF Data Template (Tag' 70 ') and remembers the required and optional data objects contained in the record, provided what for a memorized data object:
Step 5. If the current value of the "Record number" is less than the value of the "Last record number", the "Record number" is increased by 1 and the terminal goes to step 3. Otherwise, the terminal goes to step 6.
Step 6. If the current link Fj is not the last one in AFL, the terminal starts processing the next link F j + 1 , starting from step 1 of this algorithm. If link F is the last one (i = n), the terminal ends reading the card data.
The second most important function of the terminal at the stage of reading the card data in the case when the card supports any method of offline authentication is the construction of the Static Data to be Authenticated element used for static card authentication. The algorithm for constructing this data item is described below. In practice, the implementation of this algorithm is combined with the algorithm for reading the card data described above. However, in this book, for the sake of clarity, the description of these algorithms is divided.
For each link F, (i = 1, ..., n) of the AFL element, the fourth byte is checked. If it is zero (consists only of bits '0'), then the AEF file corresponding to the link Fj does not contain the data used in Static Data to be Authenticated, and the terminal proceeds to the analysis of the next link F i + 1 . It is assumed that i <n. If i = n, the algorithm for constructing the Static Data to be Authenticated element terminates.
Suppose that as a result, for some link Fj (i = 1, n), the fourth byte is not zero. For this link Fj, the terminal defines two parameters: parameter 1, equal to the value of the number encoded by the second byte, and parameter L, equal to the sum of 1 and the value of the number encoded by the fourth byte, minus 1. In addition, the terminal determines the name from the first byte of the link Fj. SFI of the current AEF file.
After that, the terminal sequentially (in ascending order j) attaches to the right to the current value of Static Data to be Authenticated the records of the current AEF R ^ file with numbers j (1 <j <L). In other words, for the reference Fj in question, incrementing j from 1 to L sequentially, the terminal performs the assignments:
Static Data to be Authenticated: = Static Data to be Authenticated || Rjj.
Moreover, if for a given link F, the SFI file name lies in the range from 1 to 10, then the Rjj records are appended without the Tag ('70'h) and Length fields. Otherwise, when the SFI value is between 11 and 30, the Tag and Length fields in the R, are included.
After all links Fj have been processed in accordance with the above algorithm, the terminal checks for the presence of a Static Data Authentication Tag List (SDA Tag List, Tag '9F4A') object, containing a single AIP object (Tag '82'), among the read data of the card. If such an object is present in the card application, the value of its Value field is appended to the right to the received Static Data to be Authenticated value, thereby completing the formation of this data object.
It has already been noted that the Static Data to be Authenticated line is generated by all terminals that support offline card authentication methods. In accordance with the rules of payment systems, today all terminals support offline authentication, with the possible exception of so-called online-only terminals, which are capable of performing transactions only in real time.
With the READ RECORD command, the terminal reads the line file records of the card specified in AFL. Data objects presented in table. 4.9, are not read by the READ RECORD command, since they are not stored in linear card files. This data can be obtained by the terminal using the GET DATA command.
Tab. 4.9. Data retrieved by the terminal using the command
GET DATA
Among the objects presented in the table, only the Application Transaction Counter (АТС) is required for all cards. It can be obtained by the terminal either using the GET DATA command or from the response to the AC GENERATE command. The ATC object shall be received by the terminal in response to the GET DATA command only if the microprocessor card contains the Lower Consecutive Offline Limit and Upper Consecutive Offline Limit data objects intended for the terminal to perform the risk management procedure. This is due to the fact that the need for the terminal to receive the ATC value before processing the first GENERATE AC command arises only when the terminal checks the fact that the number of sequential offline transactions performed with the card does not exceed the limits set by the issuer.
If the issuer does not want the terminal to perform Velocity Checking during transaction processing, the card may not support the GET DATA command. Unfortunately, misunderstanding of this fact has led to a number of cases of fallback to the magnetic stripe. The terminal tries to receive the ATC value from a card that does not support the GET DATA command and upon receiving a corresponding response from the card stops processing the transaction.
After completing the reading of the card data, the terminal checks their completeness and correctness. When verifying the completeness of EMV applications data, the criteria established in the specifications of payment systems are used. Typically, a criterion is applied according to which all card data is divided into several categories:
Next, the terminal checks for the presence of mandatory objects among the read data, which are necessary for the transaction, in particular, objects, the need for which on the card follows from the value of the data field of the AIP object:
If at least one of the listed prerequisites is violated, the terminal sets bit 6 of byte 1 of the data field of the TVR 'ICC Data Missing' object to 1.
Note that if the card supports static and / or dynamic authentication, data objects such as CA Public Key Index (Tag '8F') and Issuer Public Key Certificate (Tag '90') must be placed in the first record pointed to by AFL ... The first records should contain other objects related to card authentication procedures. This is required so that multitasking terminals can, in parallel with reading data, perform the card authentication procedure (checking the certificates of the issuer's keys and card, signed Signed Static / Dynamic Application Data).
In conclusion, we note that the correctness of the card data is checked by the terminal throughout the entire transaction processing procedure. If the terminal detects that some data object has an incorrect format, accepts an invalid value, appears on the card several times, contains syntax errors, etc., it must stop processing the transaction and reject it. Moreover, if the terminal encounters an unknown data object, it must continue processing the transaction, ignoring the unfamiliar data.
For each link F; (i = 1, ..., n) the sequence of steps described below is repeated.
Step 1. Parameter P2 of the READ RECORD command is set using the SFI value specified in the first byte of the F reference (the first five bits of P2 are equal to SFI).
Step 2. The terminal checks the correctness of the F link format ; (defined in the previous section). If it is violated, transaction processing is terminated.
Two parameters are entered: "Record number" and "Last record number". The "last record number" is set equal to the value of the third byte of the link F ,. The initial value of the "Record number" is assumed to be equal to the value of the second byte F ?
Step 3. The terminal sets the parameter P1 of the READ RECORD command equal to the value of "Counter number" and sends the READ RECORD command to the card.
Step 4. If the R-APDU received by the terminal in response to the READ RECORD command contains SWlSW2 = '9000'h, the terminal parses the AEF Data Template (Tag' 70 ') and remembers the required and optional data objects contained in the record, provided what for a memorized data object:
- the Tag field has a value known to the terminal;
- the Tag field has not been encountered by the terminal before within the framework of data reading during the execution of the current transaction; otherwise, the terminal stops processing the transaction.
Step 5. If the current value of the "Record number" is less than the value of the "Last record number", the "Record number" is increased by 1 and the terminal goes to step 3. Otherwise, the terminal goes to step 6.
Step 6. If the current link Fj is not the last one in AFL, the terminal starts processing the next link F j + 1 , starting from step 1 of this algorithm. If link F is the last one (i = n), the terminal ends reading the card data.
The second most important function of the terminal at the stage of reading the card data in the case when the card supports any method of offline authentication is the construction of the Static Data to be Authenticated element used for static card authentication. The algorithm for constructing this data item is described below. In practice, the implementation of this algorithm is combined with the algorithm for reading the card data described above. However, in this book, for the sake of clarity, the description of these algorithms is divided.
For each link F, (i = 1, ..., n) of the AFL element, the fourth byte is checked. If it is zero (consists only of bits '0'), then the AEF file corresponding to the link Fj does not contain the data used in Static Data to be Authenticated, and the terminal proceeds to the analysis of the next link F i + 1 . It is assumed that i <n. If i = n, the algorithm for constructing the Static Data to be Authenticated element terminates.
Suppose that as a result, for some link Fj (i = 1, n), the fourth byte is not zero. For this link Fj, the terminal defines two parameters: parameter 1, equal to the value of the number encoded by the second byte, and parameter L, equal to the sum of 1 and the value of the number encoded by the fourth byte, minus 1. In addition, the terminal determines the name from the first byte of the link Fj. SFI of the current AEF file.
After that, the terminal sequentially (in ascending order j) attaches to the right to the current value of Static Data to be Authenticated the records of the current AEF R ^ file with numbers j (1 <j <L). In other words, for the reference Fj in question, incrementing j from 1 to L sequentially, the terminal performs the assignments:
Static Data to be Authenticated: = Static Data to be Authenticated || Rjj.
Moreover, if for a given link F, the SFI file name lies in the range from 1 to 10, then the Rjj records are appended without the Tag ('70'h) and Length fields. Otherwise, when the SFI value is between 11 and 30, the Tag and Length fields in the R, are included.
After all links Fj have been processed in accordance with the above algorithm, the terminal checks for the presence of a Static Data Authentication Tag List (SDA Tag List, Tag '9F4A') object, containing a single AIP object (Tag '82'), among the read data of the card. If such an object is present in the card application, the value of its Value field is appended to the right to the received Static Data to be Authenticated value, thereby completing the formation of this data object.
It has already been noted that the Static Data to be Authenticated line is generated by all terminals that support offline card authentication methods. In accordance with the rules of payment systems, today all terminals support offline authentication, with the possible exception of so-called online-only terminals, which are capable of performing transactions only in real time.
With the READ RECORD command, the terminal reads the line file records of the card specified in AFL. Data objects presented in table. 4.9, are not read by the READ RECORD command, since they are not stored in linear card files. This data can be obtained by the terminal using the GET DATA command.
Tab. 4.9. Data retrieved by the terminal using the command
GET DATA
| Tag | Value | Presence |
| '9F36' | Application Transaction Counter (АТС) | Necessarily |
| '9F17' | PIN Try Counter | Optional |
| '9F13' | Last Online АТС Register | Optional |
| '9F7F' | Card Production Life Cycle (CPLC) | Mandatory for VIS 1.4.x cards |
Among the objects presented in the table, only the Application Transaction Counter (АТС) is required for all cards. It can be obtained by the terminal either using the GET DATA command or from the response to the AC GENERATE command. The ATC object shall be received by the terminal in response to the GET DATA command only if the microprocessor card contains the Lower Consecutive Offline Limit and Upper Consecutive Offline Limit data objects intended for the terminal to perform the risk management procedure. This is due to the fact that the need for the terminal to receive the ATC value before processing the first GENERATE AC command arises only when the terminal checks the fact that the number of sequential offline transactions performed with the card does not exceed the limits set by the issuer.
If the issuer does not want the terminal to perform Velocity Checking during transaction processing, the card may not support the GET DATA command. Unfortunately, misunderstanding of this fact has led to a number of cases of fallback to the magnetic stripe. The terminal tries to receive the ATC value from a card that does not support the GET DATA command and upon receiving a corresponding response from the card stops processing the transaction.
After completing the reading of the card data, the terminal checks their completeness and correctness. When verifying the completeness of EMV applications data, the criteria established in the specifications of payment systems are used. Typically, a criterion is applied according to which all card data is divided into several categories:
- critical data (not to be confused with the data of the same name, signed in SDA), in the absence of which the processing of the transaction by the terminal stops on the card;
- mandatory data (data that must be on the card, but in the absence of which the processing of the transaction continues);
- data that must be present on the card when certain conditions are met (for example, if some other data is present on the card);
- optional data (data that may or may not be present on the card, regardless of any conditions).
- card number (Application Primary Account Number, Tag '5A');
- card expiration date (Application Expiration Date, Tag '5F24');
- data list Card Risk Management Data Object List 1 (CDOL1, Tag '8C');
- data list Card Risk Management Data Object List 2 (CDOL2, Tag '8D');
- Application Interchange Profile (AIP, Tag '82');
- Application Version Number (Tag '9F08').
Next, the terminal checks for the presence of mandatory objects among the read data, which are necessary for the transaction, in particular, objects, the need for which on the card follows from the value of the data field of the AIP object:
- support of cardholder verification by the card (in byte 1 of AIP bit 5 is equal to 1) means that the Cardholder Verification Method (CVM) List (Tag '8E') object must be present on the card;
- support of the SDA method by the card (in byte 1 of AIP bit 7 is equal to 1) means the need for the presence on the card of objects necessary for performing static card authentication (listed in clause 3.12.1);
- support by the card of the DDA and / or CDA dynamic authentication methods (in byte 1 of AIP, bit 7 and / or bit 2 are equal to 1) means the need for the presence on the card of objects necessary to perform dynamic card authentication (listed in clause 3.12.2);
- the presence of the data objects Lower Consecutive Offline Limit and Upper Consecutive Offline Limit on the card means that the terminal must receive the value of the ATC transaction counter in response to the GET DATA command.
If at least one of the listed prerequisites is violated, the terminal sets bit 6 of byte 1 of the data field of the TVR 'ICC Data Missing' object to 1.
Note that if the card supports static and / or dynamic authentication, data objects such as CA Public Key Index (Tag '8F') and Issuer Public Key Certificate (Tag '90') must be placed in the first record pointed to by AFL ... The first records should contain other objects related to card authentication procedures. This is required so that multitasking terminals can, in parallel with reading data, perform the card authentication procedure (checking the certificates of the issuer's keys and card, signed Signed Static / Dynamic Application Data).
In conclusion, we note that the correctness of the card data is checked by the terminal throughout the entire transaction processing procedure. If the terminal detects that some data object has an incorrect format, accepts an invalid value, appears on the card several times, contains syntax errors, etc., it must stop processing the transaction and reject it. Moreover, if the terminal encounters an unknown data object, it must continue processing the transaction, ignoring the unfamiliar data.
