3.3 Proprietary payment application

The approach described in this section outlines an oversimplified proprietary design solution, which can be adopted by payment system operators migrating from magnetic stripe cards to integrated circuit cards. The purpose is to show the shortcoming of this approach, in case open design and interoperability are business requirements.

Let us assume that a payment system operator provides a proprietary payment application, which consists of both a card and a terminal application. It is intended for the purpose of a dedicated business goal ”for example, a national debit scheme for POS payments. The proprietary application is completely controlled by the payment system operator, who has designed and specified it according to its business requirements.

The card application is instantiated in chip cards of cardholders who are clients of an issuer. The issuer has established a business agreement for implementing the card application, which is provided by the payment system operator. The issuer has no freedom to customize the card application to its specific business needs. An ICC carrying the proprietary card application is accepted with terminals managed by an acquirer that has also established a business relationship with the payment system operator. The acquirer agrees to implement the terminal application, which is provided by the payment system operator. The acquirer has no freedom in customizing the terminal application specified by the payment system operator.

Let us assume that the card application stores the financial information characterizing the cardholder. This information consists of the following data elements:

A pplication Preferred Name : This is the name associated with the application running in the card. This name is printed on the display of the POS terminal for informing the cardholder about the application that is currently selected in the card.
Application Version Number : This is the version number of the software implementation of the card application.
Application Expiration Date: This data element represents the date after which the card application expires .
A pplication PAN : This is the information that uniquely identifies the account of the cardholder and the issuer that keeps this account.
Cardholder Name : This represents the name of the cardholder to be printed on the sale slip produced at the point of service.
Issuer's operator, first number : This is a telephone number displayed on the man-machine interface of the shopkeeper if the processing at the point of sale performed by the terminal determines that a voice referral is necessary.
Issuer's operator, second number : This is a second telephone number the shopkeeper can call for the voice referral in case the first number is congested .

When the terminal sends an INTERNAL AUTHENTICATE C-APDU, with a body containing a random number and data elements characterizing the business environment at the point of service (amount, terminal ID, date, and time), the card computes a dynamic authenticator on this data. This authenticator is computed with a MAC-based dynamic data authentication (DDA) mechanism, like that presented in Appendix D, Section D.7.1. The card sends an R-APDU, which contains the dynamic authenticator in its body, back to the terminal. More details about the computation by the card of the dynamic authenticator and its verification by the terminal are provided in Section 3.3.4.

3.3.1 Encoding data elements with a fixed format

A convenient and simple method of encoding the data elements can be obtained with a predefined fixed format, where each data element is mapped into a data object consisting of a fixed number of bytes. This number represents the maximal length of the object. If the representation of data is smaller than the maximal length, then data is justified right or left in that field and the remainder of the field is padded accordingly . For the data elements listed above, an example of their encoding is given in Table 3.2.

Table 3.2: Encoding with Fixed Format of Data Elements
Name	Format	Length
Application Preferred Name	an 16 ( alphanumeric on maximum 16 characters )	16 bytes ”maximum. Right justified, left padded with blanks
Application Version Number	b (binary)	2 bytes
Application Expiration Date	n6 (YYMMDD) (numeric on 6 digits, in the order: year, month, day)	3 bytes
Application PAN	cn 19 (numeric on 19 digits)	10 bytes ”maximum Right justified, left padded with zeros
Cardholder Name	ans 26	26 bytes ”maximum Right justified, left padded with blanks
Issuer's operator, phone number	n16 (numeric on 16 digits)	8 bytes
MAC-based dynamic authenticator	b	8 bytes
Application Transaction Counter	b	2 bytes

The definition of data elements can be proprietary to the payment system operator, but it can also be a subset of the interindustry data elements defined in ISO/IEC 7816-6 [7].

The data objects are not explicitly identified in the card application, but they are identified implicitly. This implicit identification is obtained through their location in one elementary file or another of the card's file system, and through their position in that file. This mapping of data objects into the card's file system is totally at the discretion of the payment system operator that decides which data object goes to which elementary file, and in which relative position of that file. A possible mapping is shown in Figure 3.7.

Figure 3.7: Mapping of data objects into the card's file system.

In this example, all the data objects present in the card application are mapped in three elementary files as follows :

EF11, which is a transparent file, stores the Application Preferred Name and the Application Version Number in this order. It has a total of 18 bytes, of which the first 16 bytes store the Application Preferred Name and the last 2 bytes store the Application Version Number.
EF12, which is also a transparent file, stores the following data objects: the Cardholder Name in the first 26 bytes, the application PAN in the next 10 bytes, and the Application Expiration Date in the last 3 bytes.
EF13, which is a linear fixed file, contains two records of the same length. They store the first phone number and the second phone number of the issuer's operator. These are phone numbers where the POS operator can call the issuer if any suspicions appear about the current transaction or cardholder.

3.3.2 Fixed file system organization

The file system of the card hosting the proprietary debit application is outlined in Figure 3.3.

After resetting the card, the current referenced DF is the MF, which represents the default entry in the card file system. The MF in this example has one single EF as a leaf (EF1). This elementary file keeps the ICC serial number, which is a data element that is uniquely assigned by each card manufacturer. There are two DFs that are branches of the MF. Each DF is an entry point to another card application. For example, DF1 is the entry point for the national debit card application, while DF2 is the entry point of a dedicated electronic purse scheme. Note that the payment system operator providing the first application is not necessarily the same as the payment system operator providing the second application.

The DF1 contains four leaves . Three of them are the working elementary files EF11, EF12, and EF13 presented above. The fourth leaf is an internal elementary file EF14, which contains a symmetric key for computing the dynamic authenticator. This key, which is denoted K _d and is unique for each card, is derived from the issuer master key (IMK). The IMK is managed by the issuer for the computation of dynamic authenticators. The key K _d is obtained with the formula K _d = F ₁ ( IMK )[ PAN ], according to the principles explained in Appendix E, Section E.5. The diversification information Diversification_Info consists of the PAN assigned to the cardholder. F ₁ is a one-way function, like a MAC based on a 64-bit length block cipher (see Appendix E, Section E.4). The issuer computes the key K _d and writes its value in the EF14 of the DF1 during its personalization stage. The terminal application in the POS, as well as any other agent except the card application itself, have no access to the content of EF14, which should remain secret during the whole lifetime of the card.

The terminal application uniformly references the DF1 and the elementary files EF11, EF12, and EF13, using their FID on 2 bytes. In Figure 3.3 the file identifiers are listed next to each file in the system.

3.3.3 Preestablished command and response formats

In a proprietary payment scheme, the terminal application is aware of the encoding of data elements into data objects, the mapping of data objects into elementary files, and the organization of the dedicated/elementary files in the card. All these design details are fixed beforehand by the payment system operator and are implemented in the same form by all the participants in the system.

Therefore, the format of the commands and responses is fixed. The set of data objects that is transmitted within the body of each C-APDU is always the same. The set of data objects that is returned in the body of each R-APDU is also preestablished.

Moreover, the transaction profile is fixed, since the sequence of commands in the terminal application is predetermined and is not negotiable between the card and terminal. The steps below describe this transaction profile:

Step 1: The terminal application selects DF1, which contains the debit application.
Step 2: The terminal selects EF11 and reads its binary content.
Step 3: It repeats the same sequence of commands for EF12.
Step 4: It selects the linear fixed file EF13 and reads its two records.
Step 5: The terminal prepares a message M1 containing a random number R , and some data about the business environment. This business environment data includes the amount of the transaction (which is typed in the terminal's keypad by the POS operator), the identifier of the terminal TerminalID , and the time/date when the transaction took place TimeDate . The message M1 is the body of the INTERNAL AUTHENTICATE C-APDU, which is sent to the card. This C-APDU triggers the computation of the MAC-based dynamic authenticator in the card, the value of which is denoted mac_card . A more detailed look at the computation performed by the card is postponed to Section 3.3.4. The value mac_card together with the Application Transaction Counter (ATC) is returned in the body of the R-APDU. The R-APDU body is always 10 bytes, where the first 8 bytes contain the value of mac_card and the last 2 bytes contain the ATC.

In each step of the transaction profile described above, the terminal sends a set of commands and processes the received responses. The processing performed by the terminal on these responses can be described as follows:

After reading the content of the elementary files EF11, EF12, and EF13, the terminal application identifies the data elements of the card application according to their predetermined position in an elementary file. Thus, the first 16 bytes of EF11 are identified as being the Application Preferred Name, the next 2 bytes are the Application Version Number, and so on.
The terminal displays the Application Preferred Name to inform the cardholder about the card application that is currently effective. The terminal application performs some checks. For example, the Application Version Number in the card must be equal to the Application Version Number of the terminal application. The Application Expiration Date read from the card must be smaller than the current date in the terminal (card not expired ). If all these verifications are passed, the terminal continues processing; otherwise the card session is aborted.
The terminal creates a message M0 containing the cardholder's financial information stored in the card. The Cardholder Name, the PAN, and the Application Expiration Date of the card are concatenated in M0 .
If the transaction amount is less than a threshold limit imposed as a security parameter by the acquirer, the transaction is processed off-line, without the intervention of the IH. Thus, the transaction is accepted if the value of the MAC-based dynamic authenticator produced by the card ( mac_card ) is correct. More details of this assessment process is postponed until Section 3.3.4. The validity of the dynamic authenticator proves the authenticity of the card and the fact that the card is not counterfeit, which obviously is a big step forward compared to magnetic stripe cards.
When the transaction amount is above a threshold limit, the terminal sends on-line to the IH the financial data captured from the card ( M0 ), the data characterizing the business environment of the POS terminal ( M1 ), the ATC, and the dynamic authenticator computed by the card mac_card . The IH checks whether the dynamic authenticator is valid or not in the same way that this checking is performed off-line by the terminal. The IH, however, can perform supplementary verifications compared to the off-line case, which increase the security of the authorization process. Thus, the issuer can verify whether the balance of the account indicated by the PAN has enough funds for supporting the transaction. The issuer can also verify whether the card was blacklisted, for reasons of being reported stolen, or having compromised keys, etc. If all these verifications are passed, the issuer informs the POS terminal about the outcome of the authorization, approving or denying the transaction.

3.3.4 Symmetric cryptographic technology

The security protection in the transaction profile described in Section 3.3.3 is deliberately oversimplified. It serves solely for the presentation of concepts related to the choice of an appropriate cryptographic technology for either proprietary or interoperable design solutions.

The only security service foreseen in this transaction profile is card authentication. The MAC-based dynamic data authentication, as explained in Appendix D, Section D.7.1, is the security mechanism implementing this security service.

Since the scheme is proprietary, the payment system operator can easily coordinate the whole key management process for both issuers and acquirers in the framework of symmetric cryptographic techniques.

Using a secure key distribution channel established in advance, each issuer receives an IMK. The payment system operator derives IMK from its master key (MK). The issuer identifier serves as the diversification information Diversification_Info (i.e., IMK = F ₂ ( MK )[ Issuer Identifier ]) (see Appendix E, Section E.5). As it was explained in Section 3.3.2, during the card personalization stage, the issuer uses IMK to produce the key K _d , which is a symmetric key for computing the dynamic authenticator.
The payment system operator provides acquirers with a security application module (SAM) that stores the MK. The SAM is a tamperresistant chip, which is not embedded in a plastic card but rather is directly plugged into a specialized connector inside the terminal. Note that since this chip contains the MK, its tamper resistance is an essential assumption for the security of the payment system operator.

In the remainder of the section we concentrate only on step 5 of the transaction profile described in Section 3.3.3. We zoom in on both the processing performed by the card to produce the dynamic authenticator mac_card as well as on its verification by the terminal, with the help of its SAM, in case the authorization is granted off-line.

Figure 3.8 outlines the computation of the dynamic authenticator by the card application.

Figure 3.8: Computation of the dynamic authenticator.

The terminal prepares the C-APDU with a header (CLA, INS, P1, and P2) corresponding to the internal authenticate command. The body of the C-APDU contains the message M1 = R amount TerminalID TimeDate . M1 is constructed as the concatenation from left to right of the random number R , the amount of the transaction amount , the identifier of the terminal TerminalID , and the time/date when the transaction took place TimeDate .

After receiving this C-APDU, the card application performs the following processing:

Retrieve the current ATC and use it as a diversifier for obtaining the session key SSK from the card's unique key K _d (i.e., SSK = F ₃ ( K _d )[ ATC ]).
Compute a message M0 = CN PAN ExpDate . This message is the concatenation from left to right of the Cardholder Name (CN), the PAN, and the Application Expiration Date of the card.
Retrieve the message M1 from the C-APDU body and construct the message M as the concatenation of M0 and M1 (i.e., M = M0 M1 ).
Compute the dynamic authenticator as mac_card = MAC (SSK) [ M ].
Compute the R-APDU body as the M2 = mac_card ATC . Return R-APDU.

Figure 3.9 outlines the verification of the dynamic authenticator by the terminal application with the support of the SAM.

Figure 3.9: Verification of the dynamic authenticator.

After receiving the R-APDU, the terminal can verify off-line the correctness of the dynamic authenticator mac_card received from the card, using the SAM. In this case the SAM can be regarded as the issuer's remote agent validating the dynamic authenticator. To this end the terminal constructs M0 in the same way as the card did, using the data elements CN, the PAN , and the Application Expiration Date previously read from the card. The terminal computes the message M concatenating M0 and M1 . The terminal prepares another C1-APDU, this time addressed to the SAM. Its header (CLA, INS, P1, and P2) corresponds to the Verify MAC command supported by the SAM. The body of this C1-APDU contains the message M = M0 M1 concatenated with the message M2 = mac_card ATC .

After receiving the C1-APDU, the SAM performs the verification of the dynamic authenticator mac_card , following the steps listed below:

Retrieve the PAN from M0 and isolate the issuer identifier. Use it as a diversifier to obtain the IMK as IMK = F ₂ ( MK )[ Issuer Identifier ], where MK was stored in the SAM since its personalization.
Using the PAN as a diversifier, derive the unique key of the card K _d , used for the computation of the dynamic authenticator, from the IMK (i.e., K _d = F ₁ ( IMK )[ PAN ]).
Retrieve the ATC from M2 and use it as a diversifier for deriving the session key SSK from the unique key of the card K _d (i.e., SSK = F ₃ ( K _d )[ ATC ]).
Compute the dynamic authenticator as mac_witness = MAC (SSK) [M].
Retrieve the dynamic authenticator mac_card computed by the card from M2 and compare it with the recomputed value mac_witness .
If the two values are equal, position the SW1 and SW2 status words in the trailer of the R1-APDU as OK. Otherwise, position them as NOK. Return R1-APDU.

After receiving the outcome of the dynamic authenticator verification in R1-APDU, the terminal decides whether to approve (SW1SW2="OK") or deny (SW1SW2="NOK") the transaction. The terminal keeps a transaction record (M, M2) in its permanent memory. The record will be sent to the acquirer for the clearing process.

If the terminal decides that the authorization is performed on-line by the IH, the authorization request message (1100) will transport M = M0 M1 concatenated with the message M2 = mac_card ATC . After receiving these messages, the security module of the IH will perform the same processing for verifying the dynamic authenticator as the processing described for the SAM.

As one can see, in the case of a proprietary payment application, which can authorize off-line transactions involving small amounts, symmetric key cryptographic techniques are appropriate for implementing security mechanisms. In this case the payment system operator controls the whole key management for both issuers and acquirers, which allows an easy and costeffective operation of symmetric key cryptographic algorithms. The immediate consequence is that the card does not need to implement asymmetric cryptographic algorithms, and therefore, a cryptographic coprocessor for long arithmetic computation is not needed in its hardware architecture (see Appendix D, Section D.1.2). This keeps the price of chip cards low. The use of the SAM in the structure of the terminal allows the off-line verification of the MAC-based dynamic authenticator. The SAM increases the cost of the terminal, which is the price to pay for off-line authorization of transactions involving small amounts. If the payment system operator decides that all the authorizations must be performed on-line, indifferent of the transaction amount, the presence of the SAM in the terminal is no longer needed. In this case, the verification of the dynamic authenticator is directly performed by the issuer, which simplifies the design of the terminal and its cost.

We have argued that the use of symmetric key cryptography is rather cheap for securing proprietary payment schemes, at least from the point of view of issuers. This does not mean, however, that public key cryptographic techniques are ruled out for securing the off-line authorization of transactions in proprietary payment schemes. With the advance of chip technology, it can be foreseen that the emphasis of security computations will shift towards public key enabled chips, which will render unnecessary the presence of a SAM in the hardware structure of a terminal.