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

7.7 Design criteria for CAM selection

The EMV ¢ proposes the following three card authentication methods :

1. Off-line static CAM: This method is implemented with the SDA mechanism based on digital signatures. An overview of this mechanism is presented in Appendix D, Section D.6.2. More details concerning the specification of the SDA in the EMV ¢ are presented in Section 6.4.2.

2. Off-line dynamic CAM: This method is implemented with the DDA mechanism based on digital signatures. Appendix D, Section D.7.2, gives an overview of this mechanism. More details on the specification of the DDA in the EMV ¢ are presented in Section 6.4.3.

3. On-line dynamic CAM: This method is implemented with a MACbased DDA as presented in Appendix D, Section D.7.1. Section 6.8.6 details the generation of the Application Cryptogram by the ICC for accomplishing the MAC-based DDA in the EMV ¢ specifications.

Table 7.1 presents a brief comparison of the necessary resources needed to support each of the CAMs presented above in terms of network resources, computational power of the ICC, and EEPROM space needs. The computational power and the EEPROM space will influence the ICC price.

7.7.1 On-line CAM

It can be seen from Table 7.1 that on-line CAM requires the lowest ICC resources, in terms of both computational power and storage space. The majority of the ICCs on the market support the computation of a triple DES operation with double length key, for producing the ARQC. The need for EEPROM space is reduced to the storage of a double length key of 16 bytes. This makes the lowest price for the ICC.

To implement the on-line CAM, the issuer must personalize in the ICC the CDOL1. CDOL1 is forwarded by the card application to the terminal during the execution of the transaction function read application data (see Section 6.3). CDOL1 is mandatory for inclusion in the content of the card application readable from the AFL. Some of the data objects that are recommended for inclusion in the CDOL1 are indicated in Section 6.8.6.1. Note that the implementation in the card of the GENERATE AC command, which computes the ARQC, is mandatory.

It is important to observe that the terminal is not involved in the on-line CAM, and therefore, it requires no computational resources, since the ARQC is sent over the acquirer's and payment system's networks and checked by the issuer during the authorization process performed by the IH.

The necessary condition for implementing the on-line CAM is that the acquirer processing the card application in its terminal is connected to an EMV ¢ network offering full chip support. This network must transport the data package containing the ARQC generated by the ICC for card authentication, and the data objects used for producing it. This allows the IH to verify the correctness of the ARQC during the authorization process.

On-line CAM is the authentication method recommended for ATM services, which usually require on-line authorization and thus assume the existence of an EMV ¢ network offering full chip support.

7.7.2 Off-line static CAM

The second CAM, considering the resources required by the ICC, and implicitly its price, is the off-line static CAM. Note that the ICC performs no cryptographic operations for this type of CAM. However, the price of the ICC is higher than in the case of an ICC implementing the on-line dynamic CAM due to the EEPROM storage space required. The bigger the EEPROM needs the higher the price of the ICC. To implement the off-line static CAM in a card application, the ICC has to have enough EEPROM space to store the items listed below:

• Issuer Public Key Certificate (tag 90), which is the certified public key of the issuer by the certification authority. The length of this item is equal to the length of the RSA modulus used by the CA, which is denoted N _CA . At present, EMVCo has assigned expiration dates to the RSA modulus length used by the payment systems as follows : 768-bit (N _CA = 96 bytes) with expiration date in 12/2002, 896-bit ( N _CA = 112 bytes) with expiration date in 12/2004, and 1,024-bit with expiration date in 12/2008. EMVCo reviews yearly the security of the RSA, according to the state of the art in cryptography, and makes adequate recommendations. The payment systems will introduce longer keys at the end of 2002, with a modulus of 1,152 bits ( N _CA = 144 bytes), expiring in 2010 [16];

• Issuer Public Key Exponent (tag 9F32), which is represented on 1 or 3 bytes (corresponding to the values 3 or 2 ¹⁶ + 1);

• Issuer Public Key Remainder (tag 92), on N _I ˆ’ N _CA + 36 bytes;

• Certification Authority Public Key Index (tag 8F), on 1 byte, which points to the public key of the CA in the table kept with a terminal, in case a terminal knows several CAs;

• Signed Static Application Data (tag 93), with the length equal to the RSA modulus used by the issuer, and denoted N _I . The state of the art in cryptography recommends at least N _I = 96 bytes. The issuer computes this signature with his private key during the personalization of the card application. The issuer computes this signature on the content of the card that remains unmodified during its lifetime. Recommendations concerning the data objects to be included in the computation of the Signed Static Application Data are indicated in Sections 5.8 and 6.3.2. All these data objects must be included in the AEF(s) that are publicly readable and listed in the AFL.

The card industry offers a large choice of EMV ¢ platforms that support the off-line static CAM implemented with the SDA mechanism [17 “19].

The terminal that verifies the authenticity of the card can be off-line, but it has to be able to verify the correctness of the static signed authentication data stored in the ICC by the issuer during personalization. This means that the terminal should be able to perform RSA operations. No network resources are required for performing the off-line static CAM.

7.7.3 Off-line dynamic CAM

The third CAM, considering the resources required by the ICC and implicitly its price, is the off-line dynamic CAM. The price of the ICC is higher than in the case of the off-line static CAM since an efficient computation of the RSA operation demands a cryptographic coprocessor in the chip's hardware architecture. Note, however, that the EEPROM requirements are sensibly equal to that of the off-line static CAM. In order to implement the off-line dynamic CAM in a card application, the ICC has to have enough EEPROM space to store the items listed below:

• All the data items mentioned in connection with the off-line static CAM, except for the Signed Static Application Data (tag 93);

• ICC Public Key Certificate (tag 9F46), which is the certified public key of the ICC by the issuer whose length is equal to the length of the RSA modulus used by the issuer, and denoted N _I ;

• ICC Public Key Exponent (tag 9F47) that is represented on 1 or 3 bytes (corresponding to the values 3 or 2 ¹⁶ + 1);

• ICC Public Key Remainder (tag 9F48), which is represented on N _IC ˆ’ N _I + 42 bytes, where N _IC denotes the length in bytes of the RSA modulus used by the ICC. Since recent developments in factorization techniques show that factoring a modulus of 512 bits (64 bytes) is just a matter of motivation, it is recommend that N _IC be at least 768 bits (96 bytes).

The generation by the card of the digital signature on the data received from the terminal is triggered by the INTERNAL AUTHENTICATE command, which is mandatory for implementation in the ICC if the off-line dynamic CAM is chosen . This command has as a parameter the data to be signed by the card. The card must specify the structure of this data in the Dynamic Data Object List (DDOL), with tag 9F49, which has to be included in an AEF visible from the AFL. The following data objects are recommended in the DDOL:

• Unpredictable Number (tag 9F37);

• Terminal Identification (tag 9F1C);

• Terminal Country Code (tag 9F1A);

• Transaction Date (tag 9A).

7.7.4 Security considerations regarding CAM

On-line dynamic CAM is mandatory for implementation in all the EMV ¢ debit/credit card applications. It is performed during any on-line authorization with the issuer, provided that the acquirer managing the terminal at the point of service is connected to an EMV ¢ network offering full chip support. The successful completion of the on-line dynamic CAM with the issuer guarantees that the ICC at the point of service is genuine , unless a powerful attacker has succeeded in breaking into the chip and cloning the secret key used for computing the application cryptogram. Thus, the acquirer can fully guarantee the payment for the merchant for any authorized transaction by the issuer, since in case of a counterfeit card the issuer is held responsible for the failure of the tamper-resistance of the ICC. This provides a better level of security against counterfeit transactions to both the issuer and the acquirer compared to any on-line authorization performed with magnetic stripe cards, regardless of whether they use track 2 or track 3 for storing the financial information and the security protection measures (see Section 2.6.4).

Off-line static CAM is mandatory for implementation in all cards except for ATM-only cards, which are always authorized on-line. If a terminal is only operated off-line, the off-line static CAM is the minimal security level that must be implemented in the card. In this case it is recommended that the type of transaction be limited only to a retail POS service with small floor limits. Implementing the off-line static CAM with the SDA mechanism together with a sound terminal and card risk management decreases the risk of counterfeit off-line transactions performed with ICC when compared with counterfeit off-line transactions performed with magnetic stripe. However, the off-line static CAM does not rule out this risk. We briefly describe such an attack.

Step 1 The attacker builds a pseudoterminal, consisting of a PC equipped with an EMV ¢ card reader that knows to produce the appropriate sequence of commands corresponding to the EMV ¢ application selection mechanism, the initiate application processing, and the read application data. The pseudoterminal is instructed to record all the information in the FCI of the ADF containing the card application selected for attack, the AFL and AIP, and all the publicly readable information contained in the application elementary files visible from the AFL. This information includes the data items related to the off-line static CAM/SDA.

Step 2 A waiter attack is mounted as the one described in Section 2.6.1, using the kind of pseudoterminal described in step 1.

The attacker checks whether the Static Data Authentication Tag List (tag 9F4A) is among the data objects in the EMV ¢ data objects heap. If this is the case, this list should contain only the tag corresponding to the AIP. This is an indication that the AIP was considered in the static data to be authenticated, which was signed by the issuer. If this is the case, the attacker has no freedom in proposing a convenient AIP for his purpose other than the one in the genuine card. The attacker checks whether the genuine card supports DDA or combined DDA/ GENERATE AC . If this is the case, the attacker is not able to create an appropriate emulator, without the risk that a terminal at the point of service could ask for an active DDA computation that would reveal off-line that the card is not genuine. Therefore, the attacker has to search for another ICC, which is not able to perform any form of DDA. The attack is restarted from step 1.

Step 3 If the attacker succeeds in recording the data from a card supporting only SDA, he can build an ICC emulator, containing an ADF that replicates the FCI, AFL, and the content of the publicly readable AEF(s) corresponding to the ADF in the genuine card. The emulator completely implements an EMV ¢ debit/credit application, for which the initiate application processing is adaptable according to the business environment at the point of service. To this end the PDOL includes the tag-length identifier of the Terminal Type data object.

• Whenever the Terminal Type indicates an on-line-only terminal, the emulator aborts the EMV ¢ transaction. This is because, unless the attacker does not break the tamper-resistance of the genuine ICC, the emulator cannot bypass the verification of an Application Cryptogram by the IH while not having the appropriate secret key.

• Whenever the Terminal Type indicates an attended terminal, the emulator aborts the EMV ¢ transaction. The attacker is not willing to risk an attendant becoming suspicious because of the look of the card, which could reveal imperfect artwork, logos, holograms, and other visual authentication means.

• For any other type of terminal the emulator is instructed to mount the attack. If the AIP was not included in the static data to be authenticated, the attacker may propose an AIP convenient to his attack. This AIP requires SDA, it does not require DDA; it requires cardholder verification, it does not require terminal risk management; and it indicates that the card cannot perform combined DDA/ GENERATE AC . Thus, the card supports the minimal requirement of the off-line static CAM for a transaction that is candidate for off-line completion, while it avoids any active computation that can reveal off-line that the card is not genuine. Asking that the terminal does not perform terminal risk management, the attacker hopes to maximize his gain out of the current attack. If the AIP was included in the static data to be authenticated (see Section 5.8.1), the attacker has to try the attack with the AIP proposed by the genuine card. In the latter case, if the terminal risk management is required in the AIP, the attacker is compelled to a transaction amount below the terminal floor limit.

The ICC emulator is instructed to verify positively any VERIFY command that proposes either a plaintext PIN or an enciphered PIN. The card risk management of the emulator is also instructed to rule out any proposal of the terminal other than denial or transaction accepted off-line. If the terminal proposes a denial, the GENERATE AC should end with an error code, such that the issuer has no AAC revealing that a counterfeit transaction was denied, in case the terminal records also denied transactions in batch fails forwarded to clearing. If the terminal proposes an off-line acceptance of the transaction, the TC computed in the response to the GENERATE AC is bogus , since the emulator does not have the appropriate secret key to compute a correct cryptogram.

Step 4 The emulator is used at a point of service. If the business environment is appropriate for mounting the attack, the emulator will continue the transaction. When the data of the emulator is correctly set up, then SDA should be successful. The emulator reports success in the verification of any PIN submitted from the terminal. If the amount of the transaction is below the terminal floor limit, there is a good probability that the terminal action analysis will recommend the off-line completion of the transaction with GENERATE AC with TC, which is accepted by the card risk management of the emulator. The emulator produces the required TC and returns a success status word. The terminal records the payment message corresponding to the transaction, including the bogus TC produced by the emulator.

When this payment message is cleared with the issuer, the verification failure of the TC will allow the issuer to become aware of the counterfeit transaction. This could lead to the blacklisting of the corresponding card. This could impede the operation of the emulator with any "off-line with on-line possibility" terminal, which has the blacklisting facility. However, there is room for successful operation of the emulator on "off-line only" terminals, for which the updating of the blacklist, if any, takes a longer time.

From the description of this attack, it is clear that the complexity of mounting this scenario is significantly higher than copying and replicating the content of a magnetic stripe. Moreover, the return of the attacker is low, since the attack can be successfully mounted only on candy bar-like vending machines.

If there is a need to provide the user with a retail POS service with higher floor limits, at a terminal that has no on-line connection to the issuer, the off-line dynamic CAM is the appropriate security level to be implemented in the card.

When choosing between implementing the off-line static CAM or the off-line dynamic CAM, the issuer has to perform a risk analysis that evaluates the expected loss from counterfeit transactions against the supplementary costs implied by the off-line dynamic CAM with DDA. Since the trend in the chip card industry over the last 2 years shows that the price of chips including a cryptographic coprocessor in the architecture is decreasing , one can expect that more and more EMV ¢ debit/credit card applications will implement the off-line dynamic CAM with DDA. The card producers , however, are still offering DDA as an option rather than a series product.

When both off-line CAM methods are implemented in the card, the terminal should prefer the off-line dynamic CAM to the off-line static CAM.