ARQC cryptogram for card authentication method

The terminal requests the ARQC cryptogram
Let’s now consider the case when the terminal offers the card to perform an operation online, transferring the decision to authorize the transaction to the card Issuer. It is obvious that online transaction execution is not possible for “offline only” terminals (in this case, Terminal Toure takes one of the values ’13’h, ’23’h, ’16’h, ’26’h, ’36’h).
To suggest that the card perform a transaction in real time, the terminal must send the GENERATE AC command to the card, requiring the arqc cryptogram from the card. To do this, the terminal sets the values of bits 8 and 7 of parameter P1 of the GENERATE AC command to 1 and 0, respectively. If the terminal also wants to perform the dynamic card authentication procedure using the Combined DDA/AC Generation method, then bit 6 of parameter P1 is set to 1. If the CD0L1 object contains the Terminal Capabilities data object (Tag ‘9F33’), the value of the bit b P1 may remain 0, since in this case the card can independently determine that the Combined DDA/AC Generation method will be used. This method of selecting the card authentication method is called the Combined DDA/AC Generation implicit selection.
As a result of its own risk management procedures, the card can support the terminal’s decision to process the transaction online and generate the ARQC cryptogram, or make a lower-level decision to generate an AAR (alternative authorization) or AAS (transaction rejection).
If the card decides to reject the transaction, the AAC cryptogram is returned to the terminal, and The cryptogram Information Data element is encoded according to the rules
If the card asks the terminal for alternative authorization, it returns the AAR cryptogram to the terminal. In this case, bits 8 and 7 of the Cryptogram Information Data element of the R-APDU response block are set to 1 each, and bit 4 (notification required) is set to 0. Bits 3 through 1 are used to indicate the reason why the card asks the terminal to perform alternative authorization.
After receiving the AAR, the terminal can independently generate an authorization response Code (Tag ‘8A’) based on, for example, the reason for alternative authorization (bits 1-3 of Cryptogram Information Data), which takes one of the following values in accordance with Appendix A6 of Book 4 of the EMV 4.1 standard:
transaction approved offline (Y1)/rejected offline (Z1);
transaction approved after card-initiated AAR (Y2)/rejected after card-initiated AAR (Z2);
unable to submit authorization request online, transaction approved offline (UZ)/unable to submit authorization request online, rejected offline (Z3).
The terminal continues processing the transaction by sending the second GENERATE AC command to the card, requesting either the TC cryptogram {yl, Y2, UZ codes) or the AAC (zl, Z2, Z3 codes). Note that the Authorization Response Code is included in the CD0L2 object.
If the terminal does not make a decision to complete the operation on its own, it can use the AAR value received from the card as an ARQC cryptogram and pass the cryptogram to the Issuer in order to get a decision on authorization of the operation from it.
Scheme for processing alternative authorization initiated by the card
Note that the leading payment systems do not use alternative authorization initiated by the card. Moreover, we are discussing the possibility of refusing to use alternative authorization initiated by the card in the EMV standard.
If the card agrees with the terminal’s decision to authorize the transaction in real time, it returns the arqc value to the terminal. In this case, the cryptogram Information Data element takes the value ‘ 80’h.
If the terminal receives an ARQC cryptogram from the card, it sends an authorization request to the card Issuer (a Huo message in ISO 8583 terms). It may happen that the authorization request cannot be transmitted to the Issuer (the Huo message was sent, but the X110 message was not received within the allotted time period). In this case, the terminal makes its own decision to authorize the transaction and, depending on the decision, sends the card an Authorization Response Code equal to UZ (it is impossible to submit the request online, approved offline) or Z3 (it is impossible to submit the request online, rejected offline).

If after processing the first GENERATE AC command card responds with ARQC cryptogram for card authentication method is used, CDA and authentication card failed, then the terminal declines the transaction code ARC equal to Z1, and forwards the card the second GENERATE AC command requesting her formation of the cryptogram AAS.
As it has been mentioned many times, the terminal uses the GENERATE command to inform the card of its decision/proposal on how to complete the transaction, and also passes it the information necessary for the card to make a decision on how to complete the transaction and calculate the cryptogram.
During transaction processing, the terminal can send the GENERATE AC command to the card only once if the transaction is authorized offline, or twice if the transaction is authorized online or if the terminal is not able to send an authorization request to the Issuer. The second GENERATE AC command, if passed, is the final command from the point of view of the terminal, and therefore only two solutions can be requested in it — the TC and the AAC. The card must allow no more than two calls to the GENERATE AC command during a single transaction. If the terminal issues more than two GENERATE AC commands, the card must respond with SWlSW2= ‘ 6985’h without returning the cryptogram.
Once again, let’s list the functions performed by the card based on the data received from the terminal in the GENERATE AC command:
risk management and decision on how to complete an operation;
implicit determination of whether dynamic card authentication was performed using the CDA method;
the calculation of the cryptogram.
The terminal learns what data the card needs to perform these functions using the Card Risk Management Data Object 1 (CD0L1) and Card Risk Management Data Object 2 (CD0L2) data objects. This data is recorded on the card during its personalization and is critical for the transaction. For this reason, CD0L1 and CD0L2 objects are often included in Static Data to be Authenticated. Both objects are required for any EMV card. If at least one of them is missing on the card, the terminal will not process the transaction.
The CDOL1 and CD0L2 objects are a list of tags and lengths of data elements whose values should be passed to the card, respectively, during the first and second GENERATE AC commands. After reading this data, the terminal passes only the values of the data fields of objects listed in CD0L1 and CD0L2 in the GENERATE AC commands. Note THAT cd0l1 and CD0L2 objects may contain references to the same object. However, the values of the data fields of such shared objects are passed to the card in each GENERATE AC command. This is because the value of some objects changes during transaction processing. An example is the TVR data object. After receiving a response from the Issuer, the terminal ascertains, for example, whether successful authentication procedure of the Issuer (contained in the message X110 value Issuer Authentication Data) or was successfully processed critical command Issuer Script Processing procedure. Depending on this, the value of the last fifth byte of TVR changes.
The only required element (Tag-Length) in the CD0L1 object is a reference to the Unpredictable Number object (Tag ‘9F37’) (for CD0L2, this reference is required only if the card supports the CDA method).
If the data object contains CD0L1 Tag ‘9F33’ corresponding to the object Terminal Capabilities, the card has an opportunity to determine whether such operations, use the method for dynamic CDA card authentication, regardless of the value of bit b of the parameter P1 block C-APDU of the GENERATE AC command.
For an approximate list of Tag-Length links contained in the CD0L1 object.
Let’s explain the purpose of the last reference to the vehicle object Hash Value in CD0L1. There may be data that the card does not need to perform the risk management procedure, but is important for generating a cryptogram, since the cryptogram is the signature of the most critical transaction data. The card Issuer verifies this signature. Such data is defined by the card Issuer in a special Transaction Certificate Data Object List (TDOL, Tag ’97’). The terminal concatenates all data fields listed in the TD0L object and applies the SHA-1 hash function to the resulting string of bits.

Object Card Risk Management Data Object List 1

Data object Tag Size, in bytes, of Finding
Amount Authorized (Numeric) ‘9F02’ b Optional
Amount, Other (Numeric) ‘9F03’ 6 Optional
Terminal Country Code ‘9F1A’ 2 Optional
Terminal Verification Results ’95’ 5 Optional
Transaction Currency Code ‘5F2A’ 2 Optional
Transaction Date ‘9A’ 3 Optional
Transaction Type, ‘9C 1 Optional
Unpredictable Number ‘9F37’ 4 Required
Data Authentication Code ‘9F45’ 2 Optional
ICC Dynamic Number ‘9F4C’ 2-8 Optional
TC Hash Value ’98’ 20 Optional

The result is the value of the value field of the TC Hash Value object, which is passed to the car * te in THE generate AC command. This approach allows you to significantly reduce the amount of data transmitted by the terminal to the card.
If TD0L is missing from the data read by the terminal, the Hash Value must be set to Default TDOL (TD0L by default). Since the Default TD0L object must be known simultaneously to the servicing Bank and the card Issuer, it can only be set by the payment system. If Default TDOL is used, the terminal must set bit 8 of byte 5 of TVR “Default TDOL used” to 1.
If Default TDOL is required by the card (via CD0L1/CD0L2), but it is not present on the card or in the terminal, it is assumed that Default TDOL is an empty list.
When using the second GENERATE AC command during transaction execution, the terminal must recalculate the TC Hash Value corresponding to the new data values defined in TDOL.
The CD0L1 and CD0L2 data objects may also contain references to some data received by the terminal during execution-
risk management procedures (TRM). Among such data it should be noted;
object Terminal Verification Results (Tag ’95’);
Data Authentication Code object (Tag ‘9F45’) that is used to confirm that the terminal has performed the static card authentication procedure;
an ICC Dynamic Number object (‘9F4C’) that is used to confirm that the terminal has completed the dynamic card authentication procedure.
The CD0L2 list usually contains the same links as CD0L1, and differs from the LATTER by adding links to additional data objects, such as the Issuer Authentication Data (Tag ’91’) and Authorization Response Code (Tag ‘8A’). This data is received from the card Issuer during the online authorization procedure.
The CD0L2 list can only contain the Issuer Authentication Data, Authorization Response Code, Terminal Verification Results, Terminal Unpredictable Number, and ICC Dynamic Number/Data Authentication Code objects, not including a number of parameters passed during processing of the first GENERATE AC command (for example, the transaction amount, terminal type, and so on). In this case, the card must store data that is not contained in CD0L2, but is necessary for it to make a decision after processing the second GENERATE AC command.
The list of data objects used by the card to generate a cryptogram is determined by the card Issuer and stored on the card in a form that is not regulated by the EMV standard. This list usually consists of data received from the terminal, as well as data from the card itself (for example, AIP, PBX).
Risk management procedures performed by the card (Card Risk Management). Card Verification Results data object
Diagram of the transaction authorization process, starting from the moment the terminal makes a decision on how to complete the operation (TC, ARQC, AAC). The authorization process involves the terminal, the card, and the card Issuer. An important part of it is taken by the card, to which the Issuer delegates a number of functions related to making a decision on how to complete the transaction. The card, like the terminal, performs its own risk management procedures (Card Risk Management or CRM). Then, based on the performed checks of the CRM procedure, the card analyzes the results obtained and makes its decision (more precisely, the Issuer’s decision) on the method of completing the transaction.
Let’s take a closer look at the risk management procedures performed by the card. Similar to a terminal, the card records the results of its checks in a special data object called Card Verification Results (CVR). This data object is only used by the card and the Issuer to make decisions based on the results of transaction processing. Therefore, in General, the format, content, and rules for processing the CVR object should be determined by the card Issuer. However, payment systems offer their own options for the format and method of processing the CVR object in order to unify it for IPC manufacturers. However, the CVR object in the VISA and MasterCard specifications has a different format (for example, in the VIS 1.4 specifications.x its size is 4 bytes, including the first byte of the Length Indicator encoding the value ’03’h, and in the m/Chip specifications it is 4-6 bytes).
The results of CVR checks can be passed to the Issuer as a component element of the Issuer Application Data object if the card supports this data object in response to THE generate AC command. For example, a card that meets the Common Core Definitions specification must support sending a CVR in the Issuer Application Data object in response to THE generate AC command.
An important difference between CVR and TVR is that the CVR stores part of the history associated with card usage. The card not only records the results of its current checks in the CVR, but also saves individual CVR data whose values were determined during previous operations. Before each new transaction, the card, unlike the terminal that resets the data field of the TVR object, does not reset the values of the CVR bits, but uses a more complex algorithm, which will be described in paragraph 4.10.2.
The card performs CRM procedures after receiving the GENERATE AC command, using, among other things, the data received in the command. The checks performed by the card (once again, the list of checks is determined by the card Issuer, and therefore, in General, it changes from Issuer to Issuer) can be divided into the following types:
checking the result and PIN verification status;
verification of card authentication;
verification of the Issuer’s authentication result and status;
analysis of the results of the previous transaction;
checking offline limits on the number of consecutive offline transactions performed by the card;
checking the offline limit on the amount of funds spent in consecutive offline transactions performed by the card;
checking the status of execution of the Issuer Script Processing procedures;
checking special card service conditions (for example, the card must be serviced in real time, the card is being used for the first time (a new card), the card cannot be serviced in real time at this terminal).
To describe the CRM procedures performed by the card, we will use the EMV application that meets the Common Core Definitions specifications as a reference. This application will be called a CCD card.

B8 B7 BB B5 B4 BZ B2 s Value
X x Application Cryptogram Type Returned in Second GENERATE AC (the type of cryptogram returned after the 2nd GENERATE AC command)
0 0 AAS
0 1 vehicle
Byte 1 CVR (leftmost)

B8 B7 BB B5 B4 BZ B2 s Value
1 0 Second GENERATE AC not requested (the second GENERATE AC command was not sent)
1 1 Reserved for use
X x Application Cryptogram Type Returned in First GENERATE AC (the type of cryptogram returned after the 1st GENERATE AC command)
0 0 AAS
0 1 vehicle
1 0 ARQC
1 1 Reserved for use
1 CDA Performed (CDA card authentication was performed)
1 Offline ODA Performed (was performed
DDA card authentication)
1 Issuer Authentication not performed)
1 Issuer Authentication failed (authentication of the Issuer failed

Byte 2 of the CVR

B8 B7 BB B5 B4 BZ B2 s Value
X X X X Low Order Nibble of PIN Try Counter (second half-byte of PIN Try Counter)

B8 B7 B6 B5 B4 BZ B2 B1 Value
1 Offline PIN Verification
Performed (offline PIN verification was performed)
1 Offline PIN Verification
Performed and PIN not Successfully Verified (offline PIN verification was performed and the holder verification failed)
1 PIN Try Limit Exceeded (the limit for the number of incorrect PIN entries is exceeded)
1 Last Online Transaction not completed)
The end of the table. 4.20

Byte 3 of the CVR

B8 B7 BB B5 B4 BZ B2 s Value
1 Lower Offline Transaction
Count Limit exceeded (exceeded the limit on the number of consecutive offline operations performed on a terminal that can work in online mode)
1 Upper Offline Transaction
Count Limit exceeded (exceeded the limit on the number of consecutive offline operations performed on a terminal that is unable to work online)

B8 B7 B6 B5 B4 BZ B2 s Value
1 Lower Cumulative Offline
Amount Limit exceeded (exceeded the limit on funds spent in consecutive offline operations performed on a terminal that can work online)
1 Upper Cumulative Offline
Amount Limit exceeded (exceeded the limit on funds spent in consecutive offline transactions performed on a terminal that is unable to work online)
1 Issuer-discretionary bit 1 (data of the Issuer)
1 Issuer-discretionary bit 2 (data of the Issuer)
1 Issuer-discretionary bit 3 (data of the Issuer)
1 Issuer-discretionary bit 4 (data of the Issuer)

Byte 4 of the CVR

B8 B7 BB B5 B4 BZ B2 s Value
X X X X Number of issue Script Commands Containing Secure Messaging Processed)
1 Issuer Script Processing failed
(script processing
flopped)

Byte 4 of the CVR

B8 B7 BB B5 B4 BZ B2 s Value
1 Offline Data Authentication failed on Previous Transaction (card authentication failed during processing of the previous transaction)
1 Go Online on Next Transaction (the next transaction must be processed in online authorization mode)
1 Unable to go Online (the terminal failed to send the transaction for authorization to the Issuer)

Byte 5 CVR (rightmost)

B8 B7 BB B5 B4 BZ B2 s Value
0 0 0 0 0 0 0 0 Reserved for use

Note that the CCD card allows only three possible solutions in response to THE generate AC command: TC, ARQC, and AAC. Alternative AAR authorization initiated by the card is not supported in this case.
Let’s describe an algorithm that changes the values of CVR bits after the first and second GENERATE AC commands are received by the CCD card. However, before we do this, we will make a final note about processing the transaction in real time and changing the value of CVR bits after the card receives the second GENERATE AC command.
It is clear that after receiving the second GENERATE AC command, the card must first check the Issuer Authentication Data element received from the Issuer. In the case of a CCD card, Method 2 is used
creating an ARPC that uses the Card Status Update (CSU) data element to calculate the cryptogram.
If the ARPC check on the received issue Authentication Data element failed, the card must reject the operation. Indeed, the card receives instructions on how to complete the operation and possibly change its parameters from some source whose authenticity is not just not proven, but it is proven that the source of information is false.
However, the question arises what to do if the card did not receive the Issuer Authentication Data element in response from the Issuer and, consequently, the Issuer was not authenticated. In this case, the Issuer of the CCD card must determine in the card configuration whether its authentication is required in order to be able to recognize the online operation as successful, or whether the Issuer’s authentication is not required. Obviously, the latter solution increases the risk of fraud for operations performed using the card, but expands its “walkability”. Indeed, there are so-called “magnetic” issuers (magstripe grade issuers) that issue IPCS, but do not support processing of data related to the card chip (chip related data) on their host. In particular, such issuers are not able to verify the ARQC cryptogram and form an ARPC for the authorization response. In this case, the payment system converts the chip data of the service Bank’s authorization request into magnetic card data.
There are also servicing banks that are unable to send IPC-related data to the network, including the ARQC cryptogram (such banks are called servicing banks of the partial grade acquirer type).
A microprocessor card can have a number of risk management parameters/ indicators that the card uses when analyzing the results of its checks. Let’s describe these parameters/indicators and give their classification.
One of the main advantages of the IPC is that a number of payment transactions can be performed in offline authorization mode. To manage risks when using this authorization mode, the Issuer can put the following parameters on the card:
• Lower Sequential Offline Limit (LCOL, Tag ‘9F14’, 1 byte) – defines the maximum number of consecutive offline operations that the card can perform on a terminal that can process a transaction in real time;
Upper Sequential Offline Limit (UCOL, Tag ‘9F23’, 1 byte) – defines the maximum number of consecutive offline operations that the card can perform on a terminal that is unable to process a transaction in real time;
Lower Cumulative Off-line Transaction Amount (LCOTA) — defines the maximum amount of money, expressed in the Application Currency Code (Tag ‘9F42’), that the Issuer allows the card to spend in consecutive offline operations on a terminal that can process the transaction in real time;
Upper Cumulative Off-line Transaction Amount (UCOTA) — defines the maximum amount of money, expressed in the Application Currency Code (Tag ‘9F42’), that the Issuer allows the card to spend in consecutive offline operations on a terminal that is unable to process the transaction in real time.
The first two parameters listed above are compared with the current value of the number of consecutive offline operations. This number of consecutive offline operations is called the velocity checking count (VCC). Obviously, VCC=ATC-LATC (LATC— Last Online Application Transaction Counter, Tag ‘9F13’ — number of the last online transaction). The last two parameters are compared with the current value of funds spent in consecutive offline transactions. These funds spent will be called cumulative offline transaction amount (COTA).
In General, payment systems distinguish between domestic and international (non-domestic) transactions. A transaction is considered intra-country if:
Terminal Country Code = Issuer Country Code;
Transaction Currency Code = Application Currency Code.
In this case, checks of the VCC parameter are performed by analyzing the ATC—LATC>LCOL/NDCF and ATC-LATC>UCOL/NDCF inequalities, where the coefficient NDCF (Non-Domestic Control Factor)=l for intra – new transactions and NDCF > 1 for international transactions.
When checking the CELL parameter, it may happen that the transaction Currency code is not equal to the application currency code. In this case, the EMV standard provides for the ability to convert the size of the AA transaction to the application currency. To do this, the card must support the reference Currency to Application Currency Conversion Rate for the transaction currency. The exchange rate is multiplied by the transaction size in the transaction currency in order to get the transaction size AA1 in the application currency. Next, the CELL parameter is checked by analyzing the lc0ta – CELL <AA1 and UC0TA – CELL <AA1 inequalities.
It should be noted that the limits described above, as well as the application of the NDCF coefficient, are typical for M/Chip applications. In the VIS 1.4 specifications.x other limits are used on the number of offline transactions and the amount of funds spent on them. These limits include:
Sequential Transaction Limit (International, Currency) — the maximum allowed number of consecutive offline transactions in which the transaction currency code differs from the card currency code (Application Currency Code);
Sequential Transaction Limit (International, Country) — the maximum allowed number of consecutive offline transactions in which the Issuer country code differs from the terminal country code);
Cumulative Total Transaction Amount Limit— the maximum amount of funds that can be spent in consecutive offline transactions, the amount of which is expressed in the Application Currency Code currency;
Cumulative Total Transaction Amount Limit (Dual Currency) — the maximum amount of funds that can be spent in consecutive offline transactions, the amount of which is expressed in the currency of the Application Currency Code and some other currency chosen by the Issuer.
Obviously, the corresponding counters are supported on the card for each of the limits listed. Note that in the VIS specifications, the limits on the number of consecutive offline transactions are defined only for international transactions (separately by currency and country code of the terminal). Thus, the internal traffic of offline operations in VIS is regulated only by the amount of funds spent in offline operations.
Obviously, the VCC and HONEYCOMB parameters must be reset periodically. Reinstalling is performed during transaction processing and is only possible if the Issuer requires approval of the transaction. If the transaction should be rejected by the Issuer’s decision, then you should not reset the parameters on the card. Indeed, one of the reasons for processing a transaction in online authorization mode is to allow the Issuer to periodically evaluate offline card expenses and, in accordance with these expenses and the state of the cardholder’s account, make a decision on the result of the current transaction. If the transaction is rejected and the VCC and CELL parameters are reset to zero, the next operation can be performed offline again. Thus, an unscrupulous cardholder has a good way of fraud: initiate an expensive purchase (as a result, an authorization request is sent with a large transaction size), deliberately receiving a refusal of authorization from the Issuer, but zeroing the VCC and CELL card counters. At the same time, the next time such a cardholder will be able to successfully perform an operation for a small amount in offline authorization mode.
To reset the parameters, it is important that the Issuer was successfully authenticated by the card. If the Issuer’s authentication fails, you should not reset the parameters, since the authorization response may have come from a third party falsely posing as the card Issuer.
As mentioned above, there may be a case when the card did not receive the Issuer Authentication Data from the Issuer. If the card indicates that Issuer authentication is required for successful transaction authorization, the transaction is rejected in this case. If Issuer authentication is optional, the Issuer must determine whether Issuer authentication is a prerequisite for changing the VCC and CELL parameters.