Due to its activities as one of the largest card issuers, Visa International was confronted relatively early with the problem of managing manifold applications from a wide variety of sources in multiapplication smart cards. This led to the generation of the Visa Open Platform (VOP) specification, which defines an interface inside smart card operating systems for managing smart card applications. Since 1999, the publisher of this specification is the Global Platform Committee [Global Platform], whose function is to standardize technologies for multiapplication smart cards. The name of the specification was also changed to ‘Open Platform’ (OP) at that time. The OP specification is the most important international specification for application management in multiapplication smart cards, and it can be obtained free of charge from the Web server of the Global Platform Committee. The OP specification is intentionally independent of any particular operating system, which allows it to be supported by all types of smart card operating systems, both proprietary and open (such as Multos and Java Card). In practice, however, the OP specification has primarily become the de facto standard for loading and managing Java-based applications with the Java Card operating system. For instance, the ETSI GSM 03.19 standard regards Open Platform as the standard interface for downloading applications. The purpose of the OP specification is to provide card issuers with mechanisms for securely managing third-party applications in the smart cards they have issued. To this end, Open Platform defines the basic architecture of a multiapplication smart card. This is shown in Figure 5.38, and it is very important for understanding these mechanisms.

The runtime environment forms the foundation for all applications. It provides an application repair facility, a hardware-independent interface (API) and storage space for the data and programs of the various applications. The card manager is built on top of this foundation. It is the core component of Open Platform, and it can be selected via a freely chosen AID. The card manager can thus be regarded as the IT representative of the card issuer in the multiapplication smart card. It manages the runtime environment with respect to the applications and provides them with interfaces for oncard services and interfaces to the outside world. This also includes offcard selection of applications in the smart card and dispatching APDUs coming from the outside world to their corresponding applications. The card manager also ensures, among other things, that the maximum memory sizes specified by the card issuer for application providers cannot be exceeded when their applications are loaded. In order to manage the information in the smart card related to the various security domains, applications, life-cycle stages of the components and the like, the card manager has a data area called the card registry. This is the central location in the smart card for managing all data related to Open Platform. In the sameway, a security domain is the representative of an application provider for matters related to informatics and security. The function of security domains is to provide keys and cryptographic services for applications that are independent of those provided by the card issuer. Some OP implementations support the downloading of security domains. The Open Platform API (OP API) allows applications to access the management services of the card manager. Applications in a multiapplication smart card can be divided into two classes with regard to Open Platform. The first class is immutable applications, which are loaded into the memory of the smart card during card completion and remain there in a fixed form. The second class is mutable applications, which can be loaded, installed and removed either when the smart card is completed or after it has been issued.

The OP specification also describes a generic data format for loading applications into smart cards. The data to be transferred are TLV-coded and consist of the actual data to be loaded for the application (the load file) preceded by an optional data authentication pattern (DAP) block to cryptographically secure the data and the loading process. Once an application has been loaded into the smart card, the first stage of its life cycle begins. This life cycle is also defined by the OP specification. The first stage is called ‘installed’, and it means that the application has been stored in the memory allocated to it and properly linked to the operating system, so that it can be run. However, the application cannot yet be selected from outside the smart card when it is in this state. This is possible in the next state, which is called ‘selectable’. The following state, which is called ‘personalized’, is entered after the newly loaded application receives its individual or person-specific data. After this comes an interval during which the application is used by the card user.Apossible further state is ‘blocked’, in which the application cannot be used, although this condition can be reversed. This state can be assumed by the application itself, for instance if it diagnoses a security problem. The ‘locked’ state is similar to the blocked state, except that it is irreversible. The ‘logically/physically deleted’ state indicates that the particular application has been logically or physically deleted from the smart card. The actual deletion state depends on the smart card operating system that is used. One of the important functions related to Open Platform is ‘delegated management’. This refers to functions that allow an application provider to load applications into a smart card (designated loading), install applications (designated installation) and delete applications (designated deletion), all independent of the card issuer. These functions are available to the application provider if his security domain is given these privileges when it is installed by the card issuer. Several special commands necessary for the functions of Open Platform are defined in theOP specification. Some of these commands are strongly based on the ISO/IEC 7816-4 standard, but they do not fully correspond to the commands in this standard. Table 5.21 provides a summary of the OP commands for smart cards, with brief descriptions.