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

4.4 EMV ¢ application selection

In order to support the multiapplication business requirement, the terminal should implement appropriate procedures for card application selection. To this end the acquirer that manages the terminal shall maintain a list of the card applications supported by the terminal and their AID(s). This list is determined by the business relationships existing between the acquirer and various national and international payment system operators and card associations proposing payment card applications.

Only a limited number of the card applications accepted by the terminal are implemented in the ICC present at the point of service. Thus, the terminal must determine which of the card applications in its list the ICC currently supports. This process consists of building the candidate list.

• Section 4.4.1 introduces a procedure of building the candidate list when both the ICC and the terminal implement the indirect application selection service (as described in Section 4.3.3.3). To this end, the ICC must implement the PSE and the terminal must be able to interpret the payment system directory file (DIR file) of the PSE and to construct the corresponding directory structure of the PSE. From this directory structure the terminal obtains the complete list of card applications in the PSE, which the issuer of the card wants to be visible in an interoperable environment. In order to obtain the candidate list, the terminal compares the card applications in its list of supported applications with the list of card applications existing in the PSE. Thus, the terminal applies for each AID in its list of supported applications the matching criterion explained below.

• In case either the ICC or the terminal does not support indirect application selection, the candidate list is built according to the procedure described in Section 4.4.2. In this case the terminal will try each AID it knows from its list of supported applications through direct application selection against the ICC (as described in Section 4.3.1.2). All the card applications responding positively to this inquiry will be inserted in the candidate list if their DF name fulfills the matching criterion against the AID (tag 9F06) in the list of supported applications kept by the terminal.

Building the candidate list with any of the two aforementioned procedures needs a matching criterion between the AID (tag 9F06) of a card application as known to the terminal and the DF name (tag 84)/AID (tag 4F) of a card application as reported by the ICC.

• Complete name matching: In this case, the terminal supports the ICC application only if the DF name/AID of the card application as reported by the ICC has the same length and value as the AID of the card application in the list of supported applications stored in the terminal. Since each AID in the file system of the ICC is unique, for each AID in the list of supported applications there is at most one matching ADF in the ICC, whose FCI will be copied in the candidate list.

• Partial name matching: In this case, the terminal supports the ICC application only if the DF name/AID of the card application as reported by the ICC begins with the entire AID of the card application in the list of supported applications stored in the terminal. This allows the ICC to have multiple ADF(s) matching the terminal application by adding unique information to the DF name used by each of the ADF(s). If the card has only one ADF matching the terminal AID, it should identify the DF name of that ADF with the exact AID known to the terminal. If the ICC has multiple ADF(s) supported by a single terminal AID, three conditions must be simultaneously fulfilled:

  1. The ICC must support partial name selection.

  2. All of the matching DF name/AID in the ICC must be distinguished by adding unique data to the PIX;

  3. None of the ICC's DF name/AID shall be of the same length as the AID in the terminal.

For each of the AID(s) within the list of applications supported by the terminal, the terminal shall keep in the data element Application Selection Indicator an indication of which matching criterion to use.

To better illustrate the concept of matching criteria, we assume the list of supported applications in the terminal proposed in Table 4.3.

If the list of card applications existing in the PSE of the card is given in the first column of Table 4.4, then the other two columns determine which of these applications are recorded in the candidate list built by the terminal and for which rationale.

4.4.1 Building the candidate list from the PSE

If the terminal implements the indirect application selection service it can easily build the candidate list from the directory structure of the PSE, if the PSE is implemented in the ICC. This directory structure can be built with an algorithm similar to that already described in Section 4.3.3.3. This algorithm is presented below and is overtaken from Section 8.3.2 of Book 1 [1].

• Step 1: Determine the existence of PSE in the card. The terminal issues a SELECT command using file name = 1PAY.SYS.DDF01, P2 = 00h ("First and only occurrence"), and Lc = 0Eh.

  • If SW1SW2 = 6A81 ("Wrong parameters P1 P2; function not supported"), this means that either the card is blocked or it does not support the SELECT command with referencing by the DF Name. In this case the terminal aborts the card session.

  • If SW1SW2 = 6A82 ("Wrong parameters P1 P2; file not found"), this means that there is no PSE implemented in the card. The direct application selection as presented in Section 4.4.2 should be run instead.

  • If SW1SW2 = 6283 ("State of the nonvolatile memory unchanged; selected file invalidated"), this means that there is a PSE in the card but it is blocked. The direct application selection as presented in Section 4.4.2 should be run instead.

  • If SW1SW2 = 9000, the terminal reads from the FCI of the PSE (returned in the response to the SELECT command beside SW1SW2) the SFI of the payment system directory file (DIR file) of the PSE.

• Step 2: The terminal reads all the records in the DIR file with the READ RECORD command, beginning with record number 1 and continuing with successive record numbers until the card returns SW1 SW2 = 6A83 ("Wrong parameter(s) P1 P2; record not found"). The details of this operation are similar to those described in steps 2 and 3 in Section 4.3.3.3. If the card returns SW1 SW2 = 6A83 in response to a READ RECORD for record number 1, no directory entries exist in the DIR file, and step 5 (below) applies. For each record of the DIR file, the terminal begins with the first directory entry and processes each entry in turn as described in steps 3 to 5 below.

• Step 3: If the directory entry corresponds to an ADF, and its AID (tag 4F) fulfills the matching criterion of any AID in the list of supported applications kept in the terminal, the AID of the card application joins the candidate list for the final application selection procedure.

• Step 4: If the directory entry corresponds to a DDF, the terminal selects that DDF using the DDF name (tag 9D) from the directory entry. Using the SFI of the directory file introduced by this DDF (read from the FCI of the selected DDF), the terminal reads the directory file of the current DDF and processes it in the same way as the DIR file of the PSE (steps 2 through 5). After finishing the processing of all the directory entries in the hierarchically inferior directory file, the terminal resumes the processing of the previously interrupted directory file one level higher.

• Step 5: When the terminal exhausts all the directory entries in the DIR file of the PSE, all the ADF(s) that are visible in an interoperable environment have been determined. The search and the candidate list are complete. The terminal continues with the final application selection procedure.

This procedure of building the candidate list is recommended whenever the number of EMV ¢ compliant applications in the list of supported applications kept in the terminal is large and there is a PSE present in the ICC card.

4.4.2 Building the candidate list directly

The method of building the candidate list presented in this section overtakes the algorithm introduced in Section 8.3.3 of Book 1 [1]. This method is used when the terminal does not implement indirect application selection. This is the case when the list of supported applications kept by the terminal is small. Otherwise , the method is used whenever the terminal has an empty candidate list following the indirect application selection procedure based on the PSE.

The following steps describe the algorithm of building the candidate list through direct application selection:

• Step 1: The terminal issues a SELECT command using as the value for the file name parameter the first AID in the list of supported applications.

• Step 2: If the SELECT command fails because the card is blocked or the card does not support the command (SW1 SW2 = 6A81), the terminal terminates the card session. If the SELECT command reports that the application is blocked (SW1 SW2 = 6283) the FCI of the selected ADF is not added to the candidate list. The terminal proceeds to step 5. If the SELECT command reports any other SW1 SW2 different than 6A81, 6283, and 9000, the terminal proceeds to step 5. Otherwise, the terminal continues with step 3.

• Step 3: If the SELECT command is successful (SW1 SW2 = 9000), the terminal compares the DF name returned in the FCI of the selected ADF with the current AID in the list of supported applications. If the two identifiers are identical, continue with step 4; otherwise continue with step 6.

• Step 4: The terminal adds to the candidate list the current AID regardless of its application status indicator. The candidate list must also store, besides the AID, the Application Priority Indicator of the matching application. Thus, the terminal can arrange the applications in the candidate list in the order preferred by the issuer. If the terminal displays the candidate list to allow the cardholder to make his or her choice, other data elements in the FCI of the eligible ADF (the Application Label, the Application Preferred Name) have to be saved in the candidate list.

• Step 5: The terminal issues a new SELECT command using as file name the next AID in its list of supported applications and returns to step 2. If there are no other AID(s) left in the list of supported applications, the terminal starts the final application selection procedure as described in Section 4.4.3.

• Step 6: This step is reached when the DF name of the selected ADF begins with the current AID in the list of supported applications in the terminal and is longer than this AID.

  • When the application selection indicator corresponding to the current AID is set to "Complete name matching", the terminal does not add the FCI of the selected ADF to the candidate list. The processing continues with step 7.

  • When the application selection indicator corresponding to the current AID is set to "Partial name matching", the terminal adds the FCI of the selected ADF to the candidate list only if SW1SW2 = 9000. The processing continues with step 7.

• Step 7: The terminal issues a new SELECT command, with the same file name but with P2 set to 02h ("Next occurrence"). The terminal returns to step 2.

4.4.3 Final application selection

• Step 1: If there are no mutually supported applications, the terminal ends the card session.

• Step 2: If there is only one mutually supported application, the terminal checks the bit b8 of the Application Priority Indicator:

  • If b8 = 0, the terminal selects the application.

  • If b8 = 1, the terminal requires confirmation by the cardholder. The application is selected if the cardholder approves. If the terminal requires confirmation and the cardholder does not approve, the terminal ends the card session.

• Step 3: If there are several applications mutually supported by the card and the terminal, there are two possibilities:

  • The terminal may offer a selection possibility to the cardholder. Processing continues with step 4.

  • The terminal makes the selection itself. Processing continues with step 5.

• Step 4: If a list is presented to the cardholder, it shall be in a priority sequence, with the application having the highest priority listed first. If there is no priority sequence specified in the card, the list should be displayed in the order in which the applications were encountered in the card, unless the terminal has its own preferred order. The same applies whenever duplicate priorities are assigned to multiple applications or individual entries are missing the Application Priority Indicator. This means that the terminal may use its own preferred order for displaying these applications, or the terminal may display the duplicate priority applications or nonprioritized applications in the order encountered in the card.

• Step 5: The terminal may select the application without the assistance of the cardholder. In this case, the terminal shall select the highest priority application from the candidate list of mutually supported applications. If the terminal does not provide the possibility for confirming the selected application, applications prohibiting such a selection (b8 = 1 in the Application Priority Indicator) shall be excluded from possible selection. The terminal sends the SELECT command with the value of the file name parameter identical to the AID corresponding to the card application chosen in the candidate list.