7.3 Selection criteria of the ICC architecture

The ICC architecture refers to both the hardware organization and the software platform of the chip. In Section 3.2.1 we briefly presented a typical hardware organization of a chip and possible types of chip software platforms. In this section we first analyze the needs of the chip in terms of hardware resources according to the processing requirements of the EMV ¢ application. Second, we discuss selection criteria for choosing an appropriate type of ICC software platform, according to the business needs of the issuer.

7.3.1 ICC hardware resources

The choice of the ICC hardware architecture mainly depends on the processing needs of the EMV ¢ card application running in the chip. The dimension of the data and cryptographic parameters used by the card application determines the size of the EEPROM space needed in the card. The dimension of the application code itself can influence the size of the EEPROM, in case the application code is downloaded in the EEPROM and is not hard coded in the ROM mask of the chip.

If the card application must implement the CAM with the DDA mechanism or must implement the CVM as an enciphered PIN verified off-line by the ICC, then the chip must perform an RSA operation. This operation is needed either for producing a digital signature (DDA) or for decrypting the RSA digital envelope containing the PIN of the cardholder. The processing of the RSA operation is time consuming if it is implemented in software. This would infringe upon the business requirement of the issuer that the time allowed for the completion of an EMV ¢ transaction should be comparable to the time needed for completing the transaction with magnetic stripe. Therefore, the hardware structure of the ICC has to include a coprocessor specialized in performing arithmetic operations with long integers (of at least 768 bits), which are necessary to perform the RSA operation. This coprocessor is referred to as a cryptographic coprocessor. Certainly, the presence of the cryptographic coprocessor in the hardware architecture of the ICC increases the price of the chip. The price of the chip further varies depending on the bit length of the RSA modulus that can be processed by the cryptographic coprocessor, in the sense that the bigger the length of the modulus the higher the price. Currently, the bit length of the modulus is 1,024 bits [8 “10], but there are chips on the market that can work with a bit length of 2,048 bits [8]. The issuer might be interested in generating the ICC private key and ICC public key pair used for DDA and/or generating the ICC PIN encipherment private key and ICC PIN encipherment public key pair by the chip during the personalization of the card application. Note that the generation in the chip of these key pairs does not influence the price of the chip.

The cost of the chip is influenced by the size of the EEPROM. The bigger the EEPROM size the higher the price of the chip. Chip cards with EEPROM in the range of 2 to 32 kilobytes are currently available [8], while cards with 64 kilobytes of EEPROM are expected soon. The type of ICC software platform heavily influences the size of the EEPROM. Thus, an ICC software platform allowing application download, like a Java platform [11] or a MULTOS platform [12], requires a considerable amount of EEPROM space for the application code itself. Moreover, since an EMV application uses public key cryptography for implementing the SDA, the DDA, or the enciphered PIN verified off-line by the ICC, EEPROM space has to be reserved for storing various certified public keys in the card, as well as the corresponding private keys. Therefore, one can see that the size of the EEPROM memory is an important factor to consider in the design of the ICC by the issuer, since it impacts on the price of the chip.

7.3.2 ICC software platform

When the issuer chooses to implement the EMV ¢ card application on an ICC with a proprietary software platform (see Section 3.2.1), the intrinsic price of the chip is low. Since there is no separation between the application code and the lower level native functions, then the operating system of the ICC is compact and can completely reside in the ROM. In this case there is no separation between the card manufacturer and the card application provider, since the card manufacturer writes the entire software of the ICC.

However, while the initial price of the card is low, there are other inconveniences that can increase the issuer's card costs during the lifetime of the card application.

Since the functionality of the card application is fixed at the time of the card manufacturing, the issuer has limited possibilities of changing this functionality once the card has been produced. This means that the issuer has to spend a considerable budget for testing the card application before the card production is started, since the possibilities of subsequent repairing are limited. The repairing is only feasible for those chip operating systems allowing for patch loading.
After the issuance of the card, the issuer has limited possibilities for adding new applications to the card, determined mainly by the available EEPROM and the adequate commands of the operating system. These applications could broaden the range of services the issuer can offer to cardholders ”for example, loyalty applications, or e-purse applications. In this way the issuer could make his service more attractive for the cardholder and could better follow the trends of the market. Any new service involves the issuance of other cards, which determines comparable development efforts.
The issuer may choose to order cards with several card producers , to be independent of possible production bottlenecks and delivery delays of any one of the card producers . This means that the testing effort for each new card producer has to be supported separately. If the issuers choose from a variety of ready EMV ¢ products from card vendors, then no extra development costs are involved. However, those issuers who have special functional requirements might find that the card vendors expect to be paid for the development effort.

When the issuer chooses to implement the EMV ¢ card application on a Java card, the intrinsic price of the chip is higher. However, the flexibility of the card justifies and can pay back this initial investment.

The roles of the card manufacturer and application provider can be played by different organizations. Therefore, the issuer can more easily organize the card production process. Thus, the issuer is not compelled to pay separate development costs to each card manufacturer, since the Java card platform is standardized [11]. The development costs for the card application are lower, since the Java language is accessible to more programmers than the particular programming language of each proprietary ICC platform. Moreover, once the card application is written it can be easily ported to different Java cards from different manufacturers or from the same manufacturer when cards with more EEPROM memory are available. Thus, whenever card production reasons require multiple Java card vendors, the Java card application is not rewritten each time.
The card issuers can more easily follow the trends of the market, in the sense that they can add new applications to the card during its lifetime. This is possible because applications can be downloaded to the card even after the card is issued. It is also important to note that Java cards can accommodate multiple applications while guaranteeing a high degree of security [13].
The testing of the card application to be downloaded in Java cards is not so critical as in the case for proprietary ICC platforms. If errors are detected during a trial period, repairs can be easily made, since the applet can be rewritten and downloaded to the card, without going through a new manufacturing and issuance process.