Implementing Electronic Card Payment Systems (Artech House Computer Security Series)

7.10 Card risk management

In order to determine the type of Application Cryptogram (i.e., TC, ARQC, or AAC) computed by the card application in response to the terminal's first and second GENERATE AC command, the card must run its own risk management.

Card risk management is not specified in the EMV 2000 specifications, since it does not impact on interoperability. This is why the payment system has to define its own card risk management in the proprietary ICC specifications (see Section 7.2). The issuer can further refine this definition according to its own business case, considering the trade-off between the availability degree of the financial service and the level of risk willing to be accepted.

The aim of this section is to identify which are the components that participate in the definition of the card risk management (CRM) system. This analysis is carried out in a top-down approach, from general principles towards the necessary proprietary data objects that must be foreseen in the file structure of the card. We have chosen this approach believing that an understanding of the general picture helps the designer both in the analysis of a particular CRM solution proposed by a proprietary ICC specification and in tuning it according to its own needs. For a complete design example of the CRM, we refer to [7].

7.10.1 CRM Components

Figure 7.5 outlines an input/output perspective of the CRM system. This system can be seen as a set of CRM functions. It takes the CRM data as input and runs each and every CRM function that is included in the set. This is also true when the terminal asks for the transaction's denial (i.e., GENERATE AC with AAC), or when the card decides to answer with AAC following the execution of any CRM function in the set. Since each and every CRM function in the set must be executed, the order of execution of these functions is not necessary to be defined. After the processing of the CRM data, the CRM system produces the CRM results, which logically consists of two items:

1. The type of Application Cryptogram the card agrees to compute in response to the GENERATE AC command;

2. The complete status of the card application, reflected in the CVR register. This register witnesses the processing of the EMV ¢ transaction from the card application's perspective. Therefore, its meaning is similar to that of the TVR and complements it. Each CRM function positions dedicated bits in the Card Verification Results Register (CVRR).

Figure 7.5: CRM system from the input/output perspective.

In the following sections, we present some possible types of CRM functions, the data objects that can be included in the CRM data, and several examples that define the CRM functions.

7.10.2 The set of CRM functions

The CRM functions effectively perform the risk evaluation during each EMV ¢ transaction. Depending on the nature of the identified security risks, the CRM functions can be grouped into several categories:

• CRM functions that evaluate the risks resulting from errors in the processing of the EMV ¢ transaction or from an incorrect EMV ¢ transaction flow;

• CRM functions that evaluate the financial risks due to overspending. (In the example considered below, we make a simplifying assumption that the card application(s) in the ICC is (are) used only for providing a financial service domestically);

• CRM functions that evaluate the financial risks due to frequent use of the card in off-line transactions.

In the first category one can define the following CRM functions ”listed in the order of the EMV ¢ transaction stage where the processing error is considered:

• PDOL processing error in the current transaction: This CRM function is conditionally included in the set of CRM functions. Indeed, any time the PDOL is present in the FCI of the ADF corresponding to the card application, this CRM function is included in the CRM system. It indicates the actions to be taken by the card application in case the terminal does not provide the value filed of a data object indicated in the PDOL. This CRM function is associated with a processing error in the card application occurring in the current EMV ¢ transaction.

• SDA processing error in the last transaction: This CRM function is conditionally included in the set of CRM functions. The condition that must be fulfilled is that the SDA is foreseen in the transaction profile defined by the AIP of the card application. This means that bit 7 of byte 1 of the AIP, "Off-line SDA is supported", is set. It could be that the terminal does not correctly verify the signed static application data. This could lead the terminal to ask for the off-line denial of the transaction, which consists of computing the AAC in response to the GENERATE AC command. Usually, the card does not ask the terminal to generate an advice message to inform the issuer about the declined transactions unless the PIN try limit is exceeded. Therefore, the goal of this function is to identify whether SDA failed in the last transaction and whether the transaction was declined off-line, for informing the issuer during the current transaction about this incident. This CRM function is associated with a processing error in the terminal application.

• DDA processing error in the last transaction: This CRM function is conditionally included in the set of CRM functions, depending on whether the DDA is foreseen in the transaction profile defined by the AIP of the card application. This means that bit 6 of byte 1 of the AIP, "Off-line DDA is supported", is set. The motivation for the inclusion of this function in the CRM set is similar to the motivation given in the case of SDA. The goal of this function is to identify whether DDA failed in the last transaction and the transaction was declined off-line, for informing the issuer during the current transaction about this incident. This CRM function is associated with a processing error in the terminal application.

• PIN Try Limit exceeded in the last transaction: This CRM function is conditionally included in the set of CRM functions. Three conditions must be simultaneously fulfilled: (1) the cardholder verification is included in the transaction profile (AIP, byte 1, bit 5 = 1), (2) "Plaintext/Enciphered PIN verification performed by ICC" method is included in the CVM List, and (3) the VERIFY command was not issued in the current transaction. The function checks whether the PIN try limit in the card application was exceeded in the previous transaction.

• On-line authorization not completed in the last transaction: This CRM function is always included in the set of CRM functions. If the issuer must check the conditions of an EMV ¢ transaction, an on-line authorization is required. To this end, the card application computes an ARQC, which is sent in an authorization request message to the IH. After processing the authorization request, the IH computes an authorization response message, which is sent back to the terminal. Based on this authorization response message, the terminal computes the Authorization Response Code to be forwarded to the card. This CRM function checks whether during the previous transaction the card was removed from the terminal after computing the ARQC, but before receiving the Authorization Response Code.

• Issuer authentication error in the last transaction: This CRM function is conditionally included in the set of CRM functions, whenever the card application supports issuer authentication through the EXTERNAL AUTHENTICATE command in the transaction profile (AIP, byte 1, bit 3 = 1). The function checks whether during the previous transaction the ARPC was received from the IH in an authorization response message and whether the ARPC correctly authenticated the issuer to the card application.

• Issuer script processing error in the last transaction: This CRM function is unconditionally included in the set of CRM functions. The function checks whether during the previous transaction the card application failed to process issuer scripts received from the IH. The function also informs how many of the issuer scripts were successfully executed.

The CRM functions that evaluate the financial risks due to overspending include the following:

• Overspending in a (specify: day/month) period by the application: This type of CRM function is conditionally present in the CRM system, depending on whether the issuer personalizes the Application Currency Code in the card application. It protects the issuer against overspending by the cardholder above a threshold amount, expressed in the application currency code. The amount currently spent by the cardholder is monitored during a specified period of time. There could be several such CRM functions, for daily checking and/or monthly checking, depending on the type of card product, the payment behavior, and the type of financial service. The amount currently spent is monitored both in transactions completed off-line and in transactions completed on-line.

• Overspending in consecutive off-line transactions by the application: This type of CRM function is conditionally present in the CRM system. It protects the issuer against overspending, but the amount currently spent is monitored only in consecutive transactions completed off-line, regardless of the period of time.

• Overspending in a (specify: day/month) period by the card: This CRM function is included in the CRM system only for multiapplication cards hosting more than one EMV ¢ debit/credit card application. This function is subjected to the same conditions as the similar CRM function for an application, except for the fact that the amount currently spent is monitored in transactions completed by any EMV ¢ debit/credit card application present in the ICC.

• Overspending in consecutive off-line transactions by the card: This CRM function is included in the CRM system only for multiapplication cards hosting more than one EMV ¢ debit/credit card application. This function is subjected to the same conditions as the similar CRM function for an application. The difference is that the amount currently spent is monitored in consecutive transactions completed off-line by any EMV ¢ debit/credit card application present in the ICC.

Of the CRM functions that evaluate the financial risks due to frequent use of the card in off-line transactions, one is the CRM function of the type "Frequent off-line use of the application". This type of CRM function is optionally included in the CRM system. It protects the issuer against excessive use of a card application only in transactions completed off-line. This would prevent the issuer from controlling time to time on a card application during an on-line authorization.

7.10.3 CRM data

The CRM functions take their input values from the set of CRM data. For the actual set of CRM functions proposed in Section 7.10.2, two groups of CRM data objects can be identified.

First, one can consider the group of CRM external data objects, which are requested by the card application from the business environment at the point of service. The tag-length identifiers of these objects are listed in CDOL1 and CDOL2. The terminal provides these data objects, which represent the input data to the first and second GENERATE AC command, respectively. They allow the card to update its internal state, to figure out the actual conditions in which the transaction is held, and to determine accordingly the level of risk. For example, when considering the CRM functions that evaluate the financial risks due to overspending as explained in Section 7.10.2, the data objects required from the point of service are the Amount, Authorized, the Amount, Other, the transaction date, and the Transaction Currency Code. When considering the CRM functions that deal with errors identified during the processing of the EMV ¢ transaction, the card also requires the TVR. Two bits of the TVR are relevant to this goal: the "Off-line static data authentication failed" (bit 7 in byte 1 of TVR) and the "Off-line dynamic data authentication failed" (bit 4 in byte 1 of TVR). They provide to the CRM system of the card the appropriate information as to whether the terminal has correctly completed the SDA or the DDA.

Second, the CRM data includes a set of CRM internal data objects. The data objects in this group represent a subset of the internal state of the card application. They allow the card to keep a history of the EMV ¢ transactions already processed , which could impact on the decision of completion elaborated in the current transaction. For the concrete set of CRM functions exemplified in Section 7.10.2, several categories of data objects can be identified (e.g., transaction flow flags, processing counters/counter limit parameters, and financial accumulators/ accumulator limit parameters).

Transaction flow flags The data objects in this category witness the correct or erroneous completion of a certain processing stage in the card application or in the terminal application. One flag is foreseen for the completion of every stage monitored for errors by the CRM functions. Every flag has only two possible values: 1 for error occurring during the monitored stage, and 0 for the correct completion of that stage. For the example we discuss, the following set of flags is relevant:

• PDOL Processing with Error: This flag is reset after the successful selection of the card application by the terminal. This flag is positioned by the card application after the processing of the data objects received in the data input of the GET PROCESSING OPTIONS . If the terminal fails to correctly provide the card with all the data required in the PDOL, this flag is set. Otherwise, the status of the flag does not change.

• SDA Processing with Error: This flag is reset after a successful authentication of the issuer following an on-line authorization of an EMV ¢ transaction by the issuer. The card application positions this flag after the completion of the card action analysis for the current transaction. The flag is set if the card action analysis decides that the current transaction is declined off-line and bit 7, "Off-line static data authentication failed", in byte 1 of the TVR is set. Otherwise, the status of the flag does not change.

• DDA Processing with Error: This flag is reset after a successful authentication of the issuer following an on-line authorization of an EMV ¢ transaction by the issuer. The card application positions this flag after the completion of the card action analysis for the current transaction. The flag is set if the card action analysis decides that the current transaction is declined off-line and bit 4, "Off-line dynamic data authentication failed", in byte 1 of the TVR is set. Otherwise, the status of the flag does not change.

• On-Line Completion with Error: This flag is reset following the receipt by the card of the issuer authentication information ”namely, the ARPC. The receipt of this data item indicates the successful completion of the on-line authorization by the issuer, regardless of the value of the response code indicated in the authorization response message, and the correctness of ARPC. The card application positions this flag after the completion of the card action analysis for the current transaction. The flag is set if the card action analysis decides that the card responds with an ARQC to the first GENERATE AC , which means that the current transaction is recommended for on-line monitoring by the issuer.

• Issuer Authentication with Error: The card application positions this flag during the issuer authentication stage, which is triggered by an EXTERNAL AUTHENTICATE command following an on-line authorization request. The flag is reset whenever the ARPC, received in the authorization response, verifies correctly. If the ARPC does not verify correctly, then the flag is set. If the issuer authentication is mandatory to be performed, following an on-line authorization by the issuer, but the second GENERATE AC is required before the EXTERNAL AUTHENTICATE , the flag is also set. In any other case the status of the flag does not change.

• Issuer Script Processing with Error: This flag is reset after each successful authentication of the issuer, following an on-line authorization of a transaction by the issuer. The flag is set if the card fails to correctly execute any of the scripts forwarded by the issuer.

The set of the transaction flow flags is kept in a proprietary data object, which is accessible only to the appropriate card application.

Processing counters and counter limit parameters The data objects in this category keep track of the number of repetitive processing performed in the card application. Sometimes, a processing counter is associated with a counter limit parameter, which determines the card application to perform a predefined action when the counter reaches that limit.

• PIN Try Counter (PTC, tag 9F17): This counter maintains the number of possible PIN trials that are still available for the cardholder. This counter is associated with a counter limit parameter referred to as the PIN try limit, which is personalized by the issuer in the card application. This limit prevents the exhaustive search by an attacker of the correct PIN. The higher this limit the lower the security against fraudulent transactions but the better the availability of the card application for the legitimate cardholder who incorrectly types in a PIN or forgets the PIN. The PTC is counted down with each wrong PIN submission to the card. Its value is reset to the value of the PIN try limit after a successful verification of the PIN by the card application or following an appropriate issuer script command sent by the issuer and executed by the card.

• Application Transaction Counter (ATC, tag 9F36) and last on-line ATC Register (tag 9F13): These two counters maintain the total number of transactions performed by the card application and the number of the last transaction that was sent for on-line authorization to the issuer, respectively. Following any card action analysis recommending the ARQC as an outcome of the first GENERATE AC , the last on-line ATC Register is updated to the value of the ATC. The difference between these two parameters, which gives the number of consecutive off-line transactions performed by the card, is associated with a counter limit parameter referred to as the velocity limit, which is personalized by the issuer in the card application. The higher this limit the lower the control of the issuer on the card application but the better the availability of the financial service for the legitimate cardholder in situations where there are no POS terminals with the possibility of on-line authorization (remote villages, remote resort and vacation sites).

• Issuer Script Counter: This parameter keeps track of the number of issuer scripts successfully executed by the card. This counter is not associated with a counter limit parameter. When the issuer is informed about the value of this counter, it can appreciate the effect of the issuer scripts on the internal state of the card. The issuer script counter is a proprietary data object accessible directly only to the card application.

Financial accumulators and accumulator limit parameters These are proprietary data objects accessible only from a card application. One category of accumulators keeps track of the cumulative value of the transactions performed both on-line and off-line in a period of time (e.g., 1 day or 1 month). Another type of accumulator keeps track of the cumulative value of the consecutive transactions performed off-line.

CRM data objects of the accumulator type are always associated with accumulator limit parameters, which are security thresholds that limit the tendency of overspending by the cardholder. The accumulator limit parameters are proprietary data objects personalized by the issuer according to the desired trade-off between security against overspending and the availability of the financial service. Thus, the higher the value of the accumulator limits, the higher the risk of overspending. However, the higher the value of the accumulator limits, the better the availability of the payment service for the cardholder.

Financial accumulators and their corresponding accumulator limit parameters can be associated with one card application or can be globally associated with the entire card, when at least two EMV ¢ debit/credit applications coexist in the same multiapplication card.

Several examples of such parameters, serving as input data to the CRM functions that evaluate the financial risks due to overspending (see Section 7.10.2), are listed below:

• Application period (specify: day /month) accumulator: Any accumulator in this category is updated with every transaction performed by a card application, regardless of whether it is completed off-line or on-line, if the following two conditions are observed . First, the Transaction Currency Code, as reported by the terminal, is the same as the application currency code, as personalized by the issuer in the card application. Second, the current date when the transaction is performed, as reported by the terminal in the transaction date, fits in the period considered for monitoring against overspending (i.e., the current day and/or the current month). The amount added to the accumulator consists of the Amount, Authorized and Amount, Other (if any). The accumulator is reset whenever the current date is outside the monitored period. This also updates the application last transaction day and application last transaction month. For every accumulator in this category, the issuer must define the appropriate application period (specify: day/month) accumulator limit. The issuer specifies both application period accumulators and the corresponding limits as proprietary application data objects (see Section 7.4.2).

• Card period (specify: day/month) accumulator: This accumulator is updated with every transaction performed by any of the EMV ¢ debit/credit applications existing in the card. The same two conditions as those explained for the application period (specify: day/month) accumulator are observed. For every defined card accumulator, the issuer must define the appropriate card period (specify: day/month) accumulator limit. All the card accumulators and their limits must be visible from all the concerned card applications participating in the monitoring of the global overspending risk. Therefore, the issuer specifies both card period accumulators and the corresponding limits as proprietary card data objects (see Section 7.4.2).

• Application off-line accumulator: This accumulator is updated with every off-line transaction performed by a card application, if the following two conditions are observed. First, the Transaction Currency Code, as reported by the terminal, is the same as the application currency code, as personalized by the issuer in the card application. Second, the card action analysis performed in the current transaction decides for the off-line approval of the transaction (TC computed in response to the first GENERATE AC ). Corresponding to this accumulator the issuer defines the application off-line accumulator limit. The issuer specifies both the application off-line accumulator and the corresponding limit as proprietary application data objects.

• Card off-line accumulator: This accumulator is updated with every off-line transaction performed by any of the EMV ¢ debit/credit card applications existing in the card. The same two conditions as those explained for the application off-line accumulator are observed. Corresponding to this accumulator, the issuer defines the appropriate card off-line accumulator limit. The card off-line accumulator and its limit must be visible from all the concerned card applications participating in the monitoring of the global overspending risk. Therefore, the issuer specifies them as proprietary card data objects.

7.10.4 CRM function definitions

The execution of any CRM function processes one or several CRM data objects (as identified in Section 7.10.3) which represent the input data. The execution of each CRM function can be further parameterized with a set of issuer result flags. This allows the issuer to define one single general purpose CRM function, the result of which can be finer tuned , depending on the type of card application, the type of service, and the type of payment behavior. In the remainder of this section we examine the definition of two CRM functions, one of each of the first two categories of CRM functions as identified in Section 7.10.2. The other functions can be defined following the same methodology.

Issuer authentication error in the last transaction This function belongs to the first category of CRM functions, which evaluate the risks resulting from errors in the processing of the EMV ¢ transaction. The Issuer Authentication with Error flag represents the input data to this function.

The set of issuer result flags that parameterize this function consists of only 1 bit, whose values have the following meaning: 1 ”if issuer authentication failed in the last transaction, submit the current transaction on-line; 0 ”if issuer authentication failed in the last transaction, continue with the next function in the set of CRM functions.

The processing of the function is formalized as follows :

• If "Issuer authentication with error" is 0, the CRM system considers the next function in the set of CRM functions.

• If "Issuer authentication with error" is 1, the CRM performs the following processing:

  • The CRM system signals this anomaly, setting 1 bit allocated in the CVRR, which has the meaning "Issuer authentication with error in the last transaction".

  • If the issuer result flag is personalized to 1, the function votes for the on-line transmission of the transaction to the issuer, proposing the computation of the ARQC in response to the first GENERATE AC .

  • If the issuer result flag is personalized to 0, the function does not participate in the decision of what kind of completion is recommended for the current transaction, and the execution is transferred to the next function in the CRM system.

Overspending in a (Specify: Day) period by the application This function belongs to the second category of CRM functions, which evaluate the financial risks due to overspending. The monitored period with which the function is concerned is 1 day.

• The following CRM internal data objects are considered as input for this function:

  • Application period (specify: day) accumulator;

  • Application period (specify: day) accumulator limit;

  • Application currency code;

  • Application last transaction day;

  • Application last transaction month.

If any of the objects mentioned above are not present in the card application, the execution is transferred to the next function in the CRM system.

• The following CRM external data objects are considered as input for this function:

  • Amount, Authorized;

  • Amount, Other;

  • Transaction Currency Code;

  • Transaction date.

If the terminal does not provide any of the objects mentioned above, the execution is transferred to the next function in the CRM system.

• This function is not parameterized through a set of issuer result flags.

• The processing of the function is formalized as follows:

  • If the Application Currency Code is different than the Transaction Currency Code, the CRM system considers the next function in the set.

  • If either the day or the month in the Transaction Date is different from either the application last transaction day or the application last transaction month, then the CRM internal data objects are updated as follows:

    • The application period (specify: day) accumulator is reset.

    • The application last transaction day and the application last transaction month are set to the corresponding values read from the transaction date.

  • If the day and month in the Transaction Date are the same as the application last transaction day and the application last transaction month in the card application, then the CRM internal data objects are updated as follows:

    • The value of the Amount, Authorized and the value of the Amount, Other (if any) are added to the application period (specify: day) accumulator.

    • If the value of this accumulator is smaller than the associated application period (specify: day) accumulator limit, the CRM system considers the next function in the set.

    • If the value of this accumulator is larger than the associated application period (specify: day) accumulator limit, the CRM system signals this anomaly by setting 1 bit allocated in the CVRR, which has the meaning "Accumulator limit overflow". The function votes for the on-line transmission of the transaction to the issuer, proposing the computation of the ARQC in response to the first GENERATE AC .