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

5.8 Issuing signed static application data

The issuer decides which are the data objects of the card application whose authenticity it would like to protect during the utilization stage of the card. Beside the mandatory data objects in the card application, as presented in Section 6.3.2, the issuer may authenticate some other data objects:

The issuer further decides the mapping of the data objects into records. These records are further mapped into various AEF(s), together with records that may not need to be authenticated. Based on this mapping, the issuer establishes the AFL, which also has to be written in the card. The issuer may also decide that other publicly readable data objects from the card that are not readable from the records may be individually considered for authentication. If this is the case, the issuer defines the Static Data Authentication Tag List, which is created in the card as a data object with tag 9F4A and included in one of the records. Each entry in this list consists of a tag representing a data object in the card. The length of the data object is not included in the entry, which makes the Static Data Authentication Tag List have a different structure than the DOL (see Section 3.4.3). In the EMV '96 specifications there were no restrictions imposed concerning the data elements to be included in this list; the EMV 2000 specifications require that when this list exists in the card application it shall include only the tag of the AIP. An intuitive presentation of the AFL and AIP was explained in Sections 3.4.2 and 3.4.3, respectively.

To authenticate the data objects of the card, the issuer performs the following two steps. First, it creates the Static Data to Be Authenticated byte string (Section 5.8.2). Second, it signs this byte string together with other items to generate the Signed Static Application Data (Section 5.8.3). The records to be included in the Static Data to Be Authenticated are listed in the AFL, whose meaning and interpretation is presented in Section 5.8.1.

5.8.1 AFL

The AFL (with tag 94), gives the table of contents of the publicly available information provided by the card application (see also Section 3.4.2). It identifies the AEF(s) and their corresponding records to be used by the terminal for the processing of an EMV ¢ debit/credit transaction. For each AEF, the AFL also indicates which of the AEF's records are appended to the Static Data to Be Authenticated byte string to be certified by the issuer. The terminal can only read the AEF(s) indicated in the AFL.

The AFL is a list of AEF(s) file entries, each consisting of 4 bytes, the meaning of which is presented below (according to Section 6.2 in Book 3 [2]):

5.8.2 Creating the Static Data to Be Authenticated

First, the terminal adds to the Static Data to Be Authenticated byte string (which initially is empty) the records of the AEF(s) publicly readable by the terminal (with the SFI in the range of 1 “30) and which are indicated in the AFL.

To this end the terminal performs the following processing:

Second, to the rightmost position of the Static Data to Be Authenticated byte string, the issuer concatenates the value fields of all the data objects indicated in the Static Data Authentication Tag List. The elements of this list are submitted to processing from left to right. Each element of the list consists of a tag that refers to a simple data object resident in the card, which was not included in any record mentioned for authentication in the AFL. This data object must be defined for interoperability for financial transaction interchange. Note that in the EMV 2000 specifications (Section 6.3 in Book 3 [2]), it is compulsory that when the Static Data Authentication Tag List exists in the card, it will contain only one tag, corresponding to the AIP data object (tag 82). Note that this restriction did not exist with the EMV '96 specification. In fact, this requires a higher discipline from the issuer in organizing the data objects needed for authentication in contiguous records of the AEF.

5.8.3 Generate the Signed Static Application Data

The issuer, playing the role of the certifier, applies the digital signature scheme that provides message recovery implemented with the RSA algorithm, as described in Appendix F, Section F.3.1 (case 2). This algorithm is applied on the message M = M R M ² with the RSA parameters n S = n I and d S = d I to obtain a signature, which is referred to as the Signed Static Application Data.

The message M = M R M ² is referred to as the static application data to be signed by the issuer (see Table 2 in Book 2 [1]). The part M ² consists of the Static Data to Be Authenticated byte string, which is constructed as shown in Section 5.8.2. The part M R consists of four fields:

Категории