PHASE 4 OF THE LIFE CYCLE IN DETAIL
Phase 4 of the life cycle of a smart card is well known to normal card users from daily experience with their own cards. New applications can be downloaded or activated, and applications already present in the card can be deactivated if necessary. Since the majority of this book addresses this phase, it is not described any further here, with the exception of card management systems.

Card management systems
Administrative systems for cards have been used by a variety of card issuers for many years already. However, up to now the emphasis has primarily been on inventory management and associating cards with specific persons. With the increasingly widespread use of smart cards that support modifying, downloading and deleting applications, the functions of card management systems have been fundamentally altered, since they must also deal with the aspects of card-specific applications. Such systems are called card management systems (CMS), applet management systems (AMS) or sometimes file management systems (FMS). The term ‘card management system’ is used here. A functional card management system first requires a high-performance database system containing all necessary information about issued cards, as well as at least occasional online connections to the cards to be managed. For these reasons, existing smart cards used in telecommunications applications are quite suitable for use with card management systems, since they are continuously connected online to the background system while in use. In payment systems that operate partially offline, it is still possible to utilize temporary online connections to the background system, such as when a card is used with a cash dispenser or merchant terminal. An essential prerequisite for any sort of online connection is a secure end-to-end connection between the smart card and the management system. A card management system can have a very broad range of functions. The simplest function is updating the contents of files in specific smart cards, using standard smart card commands that are sent to the cards via secure channels. A somewhat more complicated function is file management, which means deleting existing files and creating new files, using mechanisms that are similar to those used for updating file contents. All of these operations on files are referred to as ‘remote file management’ (RFM).

Significantly larger data volumes are involved in storing a new application in a smart card. If the application is file-based, all of the corresponding files must be created in the smart card and then filled with data. If the new application is program-code based, the program must be loaded into the smart card. In the case of Java Card, this is primarily done using the OP loader. However, it can sometimes be necessary to replace an application by a different application or a new version of the same application. In preparation for this, the data for applications present in the smart card must be secured. Following this, the application in question must be deleted and the new application must be created in the smart card. Finally, the secured data must be loaded into the application, which may involve converting the data to a different format. The card management systems described above relate to the period after the smart card has been issued to the end user. However, the functions of a card management system can be significantly expanded to cover the entire life cycle of the smart card. This is referred to as life-cycle management. It begins with the completion of the smart card operating system and extends over the initialization and personalization of the smart card through its actual use and any subsequent deactivation of the card that may be necessary at some time, including transferring the data to a new smart card. Naturally, this manifold of functions causes card management systems to be quite complex. Furthermore, it should be noted that it is extremely rare for the set of smart cards being managed to be homogeneous. The most common situation is a highly heterogeneous hodge-podge of different smart card operating systems in various versions running on a variety of hardware platforms with different memory sizes. The applications to be managed will also have a certain range of versions.

As an example that illustrates the resulting complexity, we can consider the situation of an operator of a telecommunications network using SIMs having three different versions of the operating system running on three different hardware platforms with three different versions of the application. In the worst case, the card management system will have to perform 27 (= 33) different types of access to the application. The card user, by contrast, sees all of these 27 variants as only a single application in his SIM. Besides the large number of variants that can quite easily arise, another consideration is that the smart cards to be managed must meet certain general conditions. In principle, the entire administrative process must be performed in an atomic manner by the card management system, since if it is somehow possible to prevent administration operations from being fully completed by means of some sort of interruption to the process, it must be possible to restore the original state. For example, consider downloading a Java applet into a SIM via the air interface. If the connection is broken, for instance because there is a coverage gap in a tunnel, this must not be allowed to have any sort of technical consequences for the existing functionality of the SIM. All of this can be technically achieved using existing mechanisms and procedures, but it requires substantial effort. There are commercially available card management systems that can provide several of the previously described functions. However, if smart cards are used on a large scale in a system in which it is necessary to dynamically manage applications, major extensions to certain aspects of existing card management systems will be necessary, regardless of the nature of the functions.