Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
The first procedure performed by the terminal and the card after the terminal reads the card data (or in parallel with the data reading) is card authentication. The procedure begins with the terminal determining which offline authentication method will be used to process this transaction. For this, the terminal analyzes the data of two objects: AIP (Tag '82') and Terminal Capabilities (Tag '9F33'). The structure of the Terminal Capabilities element is shown in Table 1. 4.10-4.12.
The Value field of the Terminal Capabilities data object is three bytes. The first byte determines the terminal's ability to enter card data (whether the terminal can read and transmit magnetic stripe data, whether it can work with the IPC and can it be used to enter transaction details (card number, expiration date, etc.) in manual mode) ...
Tab. 4.10. Byte 1 Terminal Capabilities (leftmost)
B8
Meaning
Manual entry of transaction details (Manual Key Entry)
Magnetic Stripe Insertion
Data entry from the contact IPC (ICC with contacts)
Reserved for use
Reserved for use
Reserved for use
Reserved for use
Reserved for use
Tab. 4.11. Byte 2 Terminal Capabilities
B8 b7 b6 b5 b4 b3 b2 b
Meaning
Entering an open PIN-code on the card
Entering an encrypted PIN for transmission to the issuer
Check signature (Signature)
Entering an encrypted PIN-code on the card
Verification of the owner of the card is not supported (No the CVM)
Reserved for use
Reserved for use
О Reserved for use
Tab. 4.12. Byte 3 Terminal Capabilities (rightmost)
B8 b7 b6 b5 b4 b3 b2 b
Meaning
SDA support
DDA support
Card Capture Support
Reserved for use
CDA support
Reserved for use
Reserved for use
О Reserved for use
The second byte defines the capabilities of the terminal to verify the cardholder. Finally, the third byte defines the card authentication methods supported by the terminal.
The choice of a specific card authentication method (SDA, DDA or CDA) is made by the terminal using the value of the third byte of the Terminal Capabilities object (Tag '9F33') as follows.
Step 1. If bits 2, 3 and 7 of the first byte of AIP are simultaneously 0, then the card does not support any offline authentication procedure and, therefore, this procedure is not performed by the terminal. In this case, the terminal sets bit 8 "Offline data authentication was not performed" byte 1 of TVR equal to 1 and goes to step 5 (the same is done by the terminal if it is an online only terminal).
Step 2. The terminal considers the possibility of card authentication using the CDA method. To do this, the simultaneous fulfillment of two conditions is checked: the card supports CDA (bit 2 = 1 in the first byte of AIP) and the terminal supports CDA (bit 5 = 1 in the third byte of Terminal Capabilities). If the specified conditions are simultaneously met, the CDA method is selected and proceeds to step 5. Otherwise, the terminal proceeds to step 3.
Step 3. The terminal is considering the possibility of card authentication using the DDA method. To do this, the simultaneous fulfillment of two conditions is checked: the card supports DDA (bit 6 = 1 in the first byte of AIP) and the terminal supports DDA (bit 7 = 1 in the third byte of Terminal Capabilities). If the specified conditions are simultaneously met, the DDA method is selected and goes to step 5. Otherwise, the terminal goes to step 4.
Step 4. The terminal is considering the possibility of card authentication using the SDA method. To do this, the simultaneous fulfillment of two conditions is checked: the card supports SDA (bit 7 = 1 in the first byte of AIP) and the terminal supports SDA (bit 8 = 1 in the third byte of Terminal Capabilities). If the specified conditions are simultaneously met, the SDA method is selected. Otherwise, the terminal sets bit 8 "Offline data authentication was not performed" byte 1 of TVR equal to 1 and goes to step 5.
Step 5. The procedure for selecting the card authentication method is considered complete.
If the terminal is an online-only terminal, it can skip the offline card authentication procedure and go straight to the next stages of transaction processing. In this case, mutual authentication of the card and its issuer is performed. So don't the need for offline card authentication in this case disappears. At the same time, in accordance with the principle “you cannot spoil the porridge with butter”, offline authentication can be carried out, just in case, when using an online-only terminal. In theory, this significantly increases the reliability of card authentication, however, in the range of values of this reliability that is not required in practice.
The terminal type is specified by a data object called Terminal Type (Tag '9A35', 1 byte) and is stored on the terminal. In general, the Terminal Toure object determines the communication capabilities of the terminal, the controlling body of the terminal (financial institution, trading company or the absence of a controlling body, i.e. in the latter case, the terminal is controlled only by the cardholder during the transaction), as well as the presence of a representative of the controlling body when executing transactions (attended terminal if a delegate is present and unattended terminal if there is no delegate).
The structure of the Terminal Toure object is shown in table. 4.13.
Tab. 4.13. Terminal Toure data object structure
Unattended Terminal
As can be seen from the table, the high nibble of the Terminal Toure element determines the controlling authority of the terminal ('l'h - financial institution,' 2'h - a trading company, '3'h - the absence of a controlling authority), and the low nibble determines the communication capabilities of the terminal and the presence of a representative of the supervisory authority at the point of service provision.
It follows from the above definition that the terminals for which Terminal Toure takes the values' 14'h, '15'h,' 16'h are ATMs and self-service terminals of the bank's client.
A terminal with a Terminal Type value equal to one of the values' ll'h, '12'h,' 13'h is a terminal located in a bank branch, for example, to perform cash advance operations (Cash Advance).
A terminal with a Terminal Toure value equal to one of the values' 21'h, '22'h,' 23'h is a terminal installed in retail outlets (the most popular terminal type in practice) for performing cashless card purchases.
A terminal with a Terminal Toure value of '24'h,' 25'h, '26'h is a CAT terminal and is, for example, a gas station machine, a ticket vending machine or a vending machine ) etc.
A terminal with a Terminal Type value of '34'h,' 35'h, '36'h is a home personal computer, a mobile phone, or an interactive digital television set or the like.
Sometimes the Additional Terminal Capabilities data object (Tag '9F40') is used to describe terminal capabilities. This object is required for use in the largest payment systems MasterCard and VISA. It is 5 bytes in size, of which the most common is the first byte, which defines the types of transactions supported by the terminal. The structure of the first byte of the Additional Terminal Capabilities object is shown in Table. 4.14.
Tab. 4.14. The structure of the first byte of the Additional Terminal Capabilities object
B7 | b61 b51 b4 | b3 | b21 b ~
B8
Meaning
About Account Information (Inquiry)
О Transfer of funds between client accounts in the same bank (Transfer)
About Payments
About Administrative transaction
After completing the procedure for choosing an offline authentication method, the terminal starts its implementation. With dynamic card authentication, the card itself takes an active part in this process. (The card authentication procedures have been described in detail in clause 3.12.)
If, when trying to perform the offline authentication procedure, the terminal detects the absence of the necessary data (see sections 3.12.1 and 3.12.2), then the following bits of the first TVR byte are set equal to 1:
If the terminal does not perform offline card authentication, bit 8 of the first TVR byte is set to 1.
In any case, if the terminal performs offline card authentication and it fails, one of bits 3 "Combined CDA / Generate AC Failed", 4 "Offline DDA Failed" or 7 "Offline SDA Failed" of the first byte of TVR corresponding to the selected authentication method, is set to 1.
Since the issuer learns about the result of card authentication only by the TVR data generated by the terminal of the merchant, the EMV standard provides for a mechanism for the issuer to verify that the terminal has performed card authentication. This mechanism protects the issuer from unscrupulous merchants / service banks claiming that the card was authenticated, when in fact it was not.
The verification mechanism is as follows. As already noted, the terminal stores the Data Authentication Code (DAC) values in case of static authentication and ICC Dynamic Number (IDN) in case of dynamic DDA / CDA authentication in data objects tagged '9F45' and '9F4C', respectively (see section 3.12 .1, 3.12.2.1 and 3.12.2.2). If the issuer includes the values of these tags in the CDOL1 and CDOL2 objects, then the card receives the DAC and IDN values when it processes the AC GENERATE command. The received DAC / IDN data can be sent by the card to the issuer inside the data object
Issuer Application Data (Tag '9F10') contained in the response data field to the AC GENERATE command.
In the case of an online transaction, the issuer can verify the fact that the terminal has authenticated the card during the processing of the transaction and take the result of the verification into account when deciding how to complete the transaction. In the case of an offline transaction, the fact of card authentication is verified by a clearing message received by the issuer. Payment systems can provide for the possibility of the issuer forming a refusal to pay if the issuer refutes the fact of card authentication by the merchant.
Thus, for the issuer to verify that the terminal has performed card authentication, it is necessary:
The Value field of the Terminal Capabilities data object is three bytes. The first byte determines the terminal's ability to enter card data (whether the terminal can read and transmit magnetic stripe data, whether it can work with the IPC and can it be used to enter transaction details (card number, expiration date, etc.) in manual mode) ...
Tab. 4.10. Byte 1 Terminal Capabilities (leftmost)
B8
| B71b6 | B5 | B4 | B3 | B2 | NS |
Meaning
Manual entry of transaction details (Manual Key Entry)
Magnetic Stripe Insertion
Data entry from the contact IPC (ICC with contacts)
Reserved for use
Reserved for use
Reserved for use
Reserved for use
Reserved for use
Tab. 4.11. Byte 2 Terminal Capabilities
B8 b7 b6 b5 b4 b3 b2 b
Meaning
Entering an open PIN-code on the card
Entering an encrypted PIN for transmission to the issuer
Check signature (Signature)
Entering an encrypted PIN-code on the card
Verification of the owner of the card is not supported (No the CVM)
Reserved for use
Reserved for use
О Reserved for use
Tab. 4.12. Byte 3 Terminal Capabilities (rightmost)
B8 b7 b6 b5 b4 b3 b2 b
Meaning
SDA support
DDA support
Card Capture Support
Reserved for use
CDA support
Reserved for use
Reserved for use
О Reserved for use
The second byte defines the capabilities of the terminal to verify the cardholder. Finally, the third byte defines the card authentication methods supported by the terminal.
The choice of a specific card authentication method (SDA, DDA or CDA) is made by the terminal using the value of the third byte of the Terminal Capabilities object (Tag '9F33') as follows.
Step 1. If bits 2, 3 and 7 of the first byte of AIP are simultaneously 0, then the card does not support any offline authentication procedure and, therefore, this procedure is not performed by the terminal. In this case, the terminal sets bit 8 "Offline data authentication was not performed" byte 1 of TVR equal to 1 and goes to step 5 (the same is done by the terminal if it is an online only terminal).
Step 2. The terminal considers the possibility of card authentication using the CDA method. To do this, the simultaneous fulfillment of two conditions is checked: the card supports CDA (bit 2 = 1 in the first byte of AIP) and the terminal supports CDA (bit 5 = 1 in the third byte of Terminal Capabilities). If the specified conditions are simultaneously met, the CDA method is selected and proceeds to step 5. Otherwise, the terminal proceeds to step 3.
Step 3. The terminal is considering the possibility of card authentication using the DDA method. To do this, the simultaneous fulfillment of two conditions is checked: the card supports DDA (bit 6 = 1 in the first byte of AIP) and the terminal supports DDA (bit 7 = 1 in the third byte of Terminal Capabilities). If the specified conditions are simultaneously met, the DDA method is selected and goes to step 5. Otherwise, the terminal goes to step 4.
Step 4. The terminal is considering the possibility of card authentication using the SDA method. To do this, the simultaneous fulfillment of two conditions is checked: the card supports SDA (bit 7 = 1 in the first byte of AIP) and the terminal supports SDA (bit 8 = 1 in the third byte of Terminal Capabilities). If the specified conditions are simultaneously met, the SDA method is selected. Otherwise, the terminal sets bit 8 "Offline data authentication was not performed" byte 1 of TVR equal to 1 and goes to step 5.
Step 5. The procedure for selecting the card authentication method is considered complete.
If the terminal is an online-only terminal, it can skip the offline card authentication procedure and go straight to the next stages of transaction processing. In this case, mutual authentication of the card and its issuer is performed. So don't the need for offline card authentication in this case disappears. At the same time, in accordance with the principle “you cannot spoil the porridge with butter”, offline authentication can be carried out, just in case, when using an online-only terminal. In theory, this significantly increases the reliability of card authentication, however, in the range of values of this reliability that is not required in practice.
The terminal type is specified by a data object called Terminal Type (Tag '9A35', 1 byte) and is stored on the terminal. In general, the Terminal Toure object determines the communication capabilities of the terminal, the controlling body of the terminal (financial institution, trading company or the absence of a controlling body, i.e. in the latter case, the terminal is controlled only by the cardholder during the transaction), as well as the presence of a representative of the controlling body when executing transactions (attended terminal if a delegate is present and unattended terminal if there is no delegate).
The structure of the Terminal Toure object is shown in table. 4.13.
Tab. 4.13. Terminal Toure data object structure
| Terminal communication capabilities | Terminal controlled by a financial institution | Merchant-controlled terminal | Terminal controlled only by the cardholder |
| Attended Terminal | |||
| Online Only | 'll'h | '2 l'h | - |
| Offline with online capabilities | '12'h | '22'h | - |
| Offline Only | T3'h | '23' | - |
Unattended Terminal
| Online Only | '14'h | '24'h | '34'h |
| Offline with online capabilities | '15'h | '25'h | '35'h |
| Offline Only | '16'h | '26'h | '36'h |
As can be seen from the table, the high nibble of the Terminal Toure element determines the controlling authority of the terminal ('l'h - financial institution,' 2'h - a trading company, '3'h - the absence of a controlling authority), and the low nibble determines the communication capabilities of the terminal and the presence of a representative of the supervisory authority at the point of service provision.
It follows from the above definition that the terminals for which Terminal Toure takes the values' 14'h, '15'h,' 16'h are ATMs and self-service terminals of the bank's client.
A terminal with a Terminal Type value equal to one of the values' ll'h, '12'h,' 13'h is a terminal located in a bank branch, for example, to perform cash advance operations (Cash Advance).
A terminal with a Terminal Toure value equal to one of the values' 21'h, '22'h,' 23'h is a terminal installed in retail outlets (the most popular terminal type in practice) for performing cashless card purchases.
A terminal with a Terminal Toure value of '24'h,' 25'h, '26'h is a CAT terminal and is, for example, a gas station machine, a ticket vending machine or a vending machine ) etc.
A terminal with a Terminal Type value of '34'h,' 35'h, '36'h is a home personal computer, a mobile phone, or an interactive digital television set or the like.
Sometimes the Additional Terminal Capabilities data object (Tag '9F40') is used to describe terminal capabilities. This object is required for use in the largest payment systems MasterCard and VISA. It is 5 bytes in size, of which the most common is the first byte, which defines the types of transactions supported by the terminal. The structure of the first byte of the Additional Terminal Capabilities object is shown in Table. 4.14.
Tab. 4.14. The structure of the first byte of the Additional Terminal Capabilities object
B7 | b61 b51 b4 | b3 | b21 b ~
B8
Meaning
- 1 Cash withdrawal
- 1 Goods
- 1 Provision of service (Services)
About Account Information (Inquiry)
О Transfer of funds between client accounts in the same bank (Transfer)
About Payments
About Administrative transaction
After completing the procedure for choosing an offline authentication method, the terminal starts its implementation. With dynamic card authentication, the card itself takes an active part in this process. (The card authentication procedures have been described in detail in clause 3.12.)
If, when trying to perform the offline authentication procedure, the terminal detects the absence of the necessary data (see sections 3.12.1 and 3.12.2), then the following bits of the first TVR byte are set equal to 1:
- bit 6 "ICC Data missing";
- one of bits 3 ("Combined CDA / Generate AC Failed"), 4 ("Offline DDA Failed") or 7 ("Offline SDA Failed") corresponding to the selected authentication method.
If the terminal does not perform offline card authentication, bit 8 of the first TVR byte is set to 1.
In any case, if the terminal performs offline card authentication and it fails, one of bits 3 "Combined CDA / Generate AC Failed", 4 "Offline DDA Failed" or 7 "Offline SDA Failed" of the first byte of TVR corresponding to the selected authentication method, is set to 1.
Since the issuer learns about the result of card authentication only by the TVR data generated by the terminal of the merchant, the EMV standard provides for a mechanism for the issuer to verify that the terminal has performed card authentication. This mechanism protects the issuer from unscrupulous merchants / service banks claiming that the card was authenticated, when in fact it was not.
The verification mechanism is as follows. As already noted, the terminal stores the Data Authentication Code (DAC) values in case of static authentication and ICC Dynamic Number (IDN) in case of dynamic DDA / CDA authentication in data objects tagged '9F45' and '9F4C', respectively (see section 3.12 .1, 3.12.2.1 and 3.12.2.2). If the issuer includes the values of these tags in the CDOL1 and CDOL2 objects, then the card receives the DAC and IDN values when it processes the AC GENERATE command. The received DAC / IDN data can be sent by the card to the issuer inside the data object
Issuer Application Data (Tag '9F10') contained in the response data field to the AC GENERATE command.
In the case of an online transaction, the issuer can verify the fact that the terminal has authenticated the card during the processing of the transaction and take the result of the verification into account when deciding how to complete the transaction. In the case of an offline transaction, the fact of card authentication is verified by a clearing message received by the issuer. Payment systems can provide for the possibility of the issuer forming a refusal to pay if the issuer refutes the fact of card authentication by the merchant.
Thus, for the issuer to verify that the terminal has performed card authentication, it is necessary:
- include tags '9F45' and '9F4C' in the CDOL1 and CDOL2 lists;
- include tags '9F45' and '9F4C' in the Issuer Application Data object returned in response to the AC GENERATE command.
