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:

• Application Version Number (tag 9F08);

• Application Usage Control (tag 9F07);

• Application Currency Code (tag 9F42) and Application Currency Exponent (tag 9F44);

• Application PAN Sequence Number (tag 5F34);

• Track 2 Equivalent Data (tag 57);

• Cardholder Name (tag 5F20);

• Issuer Action Code ”Default/Denial/On-line (tag 9F0D, tag 9F0E, and tag 9F0F, respectively).

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]):

• The first byte encodes in the 5 most significant bits the SFI of the AEF. The least significant 3 bits in this byte are set to 0.

• The second byte encodes the number of the first (or the only) record to be read from the AEF. This number, which is also referred to as the first record number , shall never be 0.

• The third byte encodes the number of the last record to be read from the AEF. This number, which is also referred to as the last record number , can be greater than or equal to the number in the second byte. In the former case the terminal must read all the records of that AEF referred to with numbers between the first record number and the last record number. In the latter case only the record referred to with the first record number shall be read from the AEF.

• The fourth byte indicates the number of records in that AEF, starting from the first record number, which shall be considered by the terminal in the off-line data authentication processing. This number can be 0 when no records of the actual file are considered for the off-line data authentication. When this number is not zero, the sum of the first record number and the number in the fourth byte minus one is referred to as the last authenticated record number .

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:

• For each entry Fi, i = 1, , n in the AFL = F1 F2 Fn , check the fourth byte of Fi . When its value is zero none of the records of the current AEF are considered for authentication. The terminal increments the counter i to consider the next AEF indicated in the AFL.

• When the value of the fourth byte of Fi is not zero, the terminal considers l equal to the first record number, as indicated in the second byte of Fi . The terminal also computes L as the sum of the second and the fourth byte of the AFL entry Fi minus one, which represents the last authenticated record number. For each record Rij with a number j such that l ‰ j ‰ L the terminal concatenates this record to the right most position of Static Data to Be Authenticated (i.e., Static Data to Be Authenticated = Static Data to Be Authenticated Rij ).

• If the SFI, which is read from the first byte of Fi , is in the range of 1 to 10, then the record tag (70) and the record length are not included in Rij .

• If the SFI is in the range of 11 to 30, then the record tag (70) and the record length are included in Rij .

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:

• Field 1 ”Signed Data Format (1 byte): This has the fix value 03h.

• Field 2 ”Hash Algorithm Indicator (1 byte): This identifies the hash algorithm used to produce the hash code H . This value is used in step 1 of the algorithm described in Appendix F, Section F.3.1 (case 2). At the moment, SHA-1 is the hash algorithm recommended by the EMV 2000 specifications in Annex B3.1 of Book 2 [1]. Thus, the value of the hash algorithm indicator is set to 01h.

• Field 3 ”Data Authentication Code (2 bytes): This represents a code assigned by the issuer, which can be a part (the most significant 2 bytes, for example) of a cryptogram, and which is unique for each card. This cryptogram can be a MAC computed by the issuer on the PAN associated with the card. The MAC is computed with a key diversified for each card from a unique master key of the issuer assigned for the data authentication codes calculation. When receiving this data element in an authorization request sent on-line or even in a payment capture message during the clearing, the issuer can check the correctness of the code. Assuming that the terminal did not find out this data element from the execution of another EMV ¢ transaction with the same card, the issuer increases its confidence that the terminal indeed verified the Signed Static Application Data in order to obtain the value of this code. Otherwise, a terminal, which is not able to check an RSA signature, could falsely claim that it performed the off-line static data authentication when in fact it did not do it.

• Field 4 ”Pad Pattern: This contains a number of N _I ˆ’ 26 bytes of value BBh, where N _I is the number of bytes of the modulus n _I .