Multi-layer operating systems
There are different approaches to implementing application programs (applications) on the card. The first approach is that IPC applications are developed for a specific “native” operating system of the card’s microprocessor. These cards are called Native cards or static cards. The latter name is due to the fact that applications of such cards cannot be transferred to cards using a different operating system.
On static cards, the application, using the functions of the operating system and application programming interfaces (API — Application Programming Interface) of the Central processor, depends entirely on the card’s microprocessor. Thus, the static card application is not portable from one manufacturer’s chip to another manufacturer’s chip. Every time the card Issuer changes the chip, it must rewrite the application under the new chip. MPCOS, StarCOS, APOLLO, and CardOS operating systems are widely used in static cards.
In static cards, the microprocessor operating system and API are stored in ROM, while the card application can be written in both ROM and EEPR0M. in most static card implementations, the application is stored in ROM and logically intertwines with the microprocessor operating system, instead of being located above the operating system, as shown in figure.2.12.
The card file system stores the data structures of card applications and some operating system data. It is always located in EEPR0M. This is because EEPR0M is non-volatile memory and allows not only data reading operations, but also write/delete operations.
A different organization of software support is provided in IPCS that operate under open multi-layer operating systems (MPOs). Today, there are two widely distributed MPOs— Java Card and MULTI0S. more recently, Microsoft tried to enter the market of operating systems for smart cards with its system Smart Cards for Windows (SCfW). But recently, information about the promotion of this system on the market has stopped coming. Although it is possible that this operating system will find its place in the Windows environment in the future.
The ROM mask of a multi-layer card contains:
processor operating system that provides secure and controlled access to chip resources;
a VM that allows you to interpret and execute applications loaded on the card. These applications use open-source VM API programming interfaces and are compiled from texts written in high-level C, Java, and Visual Basic languages;
card Manager, which controls the functions of safe loading/deleting applications and distributing commands received from the terminal to individual card applications.
Some static card applications can also be placed in ROM memory. However, if you support the concept of multi-layer cards, which allows downloading some applications after the card is issued (after the card is transferred to the cardholder), at least the applications downloaded after the issue must be stored in EEPR0M memory.
The main idea of MPOs is to create a universal open operating system, a virtual machine for interpreting and executing application programs, and a set of software interfaces that significantly simplify the process of writing card applications.
If there are MPOs specifications, the chip vendor can implement the entire specified set of MPOs system programs in its chip, thereby significantly facilitating the task of writing new applications for the card application vendor. In addition, the written application becomes chip-independent in the sense that it can function on any chip that supports this MPOs system. This property is key to the idea of an open multi-layer operating system.
For rice. 2.14 shows the IPC architecture that operates under the Java Card operating system (these cards are also called Java cards).
In Java card, the application is isolated from the operating system of the microprocessor using Java Card Virtual Machine (JCVM). JCVM interprets the application’s bytecodes and translates them into the commands of the “Native” operating system (Native OS) of the microprocessor. At the same time, each chip develops its own jcvm virtual machine, which is stored in the ROM along with the microprocessor operating system and application software APIs.
The key advantage of a Java card is that an application written for one Java card can also be successfully applied on another Java card, regardless of which microprocessor is used on that other card. This advantage is framed in the form of a common slogan: “Write Once, Run Anywhere” — Written once, used everywhere.
In addition, it simplifies the development of the Java card application, since the program uses a high-level language and the Java card application is stored in EEPR0M (you do not need to create a ROM mask that displays the application being developed).
The Java Card programming language has a large set of limitations compared to the Java language. These limitations are due to the small size of the MPC memory. As a result, Java Card is only a small subset of Java and does not support functionality such as:
multithreading;
allocation of all memory before creating objects;
loading dynamic classes;
object serialization— the ability of a program to read (write) objects in (from) a data stream;
using large data types (floating-point variables, double-length variables, and so on).);
garbage collection;
cloning objects;
the function of the security Manager (Security Manager).
In contrast to the” standard ” Java Virtual Machine, as shown in Fig. 2.15, the JCVM environment consists of two modules separated in space and time.
The first module of the JCVM, the Java Card Converter called (JCC), operates on a PC or workstation. This module is intended for generating from the applet application file.class, written in the Java Card language, a file of the applet type.cap. During the conversion of the applet file.class the JCC module performs data type checking, initializes static variables, checks for syntax violations in the Java Card language, checks for memory management violations, and defines references to classes, methods, and fields in the most compact and managed form of the JCVM virtual machine. The resulting applet file.the cap is loaded on the card, installed, and executed on it. The downloaded file is called an applet (Java Applet). As a result of installing the applet in the Java Card environment, it becomes selectable and is treated as an application. Thus, a Java card application is an instance of an executable module (applet) that is loaded on the card.
As already noted, the JCVM module located on the card includes an interpreter that allows byte-by-byte execution of the card application’s bytecodes.
Most programs written in the Java Card language are part of systems where most of the work is done outside of the card. To organize the work of such systems, in which Java-cards are an important component, VISA, MasterCard and others have developed an open platform, which has now become part of the Global standard Global Platform (www.globalplatform.org).
The Java Card standard does not use many of the security mechanisms contained in Java. In particular, secure app loading to the card is not supported. From the Java Card point of view, downloading any application is safe. All that Java Card provides is a mechanism for protecting objects from unauthorized access (firewall) by other objects. This is done via the shared interface (si).
Let’s assume that applet A wants to allow other objects access to some of the services it supports. To do this, you need to develop a shared SI interface that defines the methods available to other applets. The shared interface is implemented using a class that is created for this purpose. Class C contains methods that are available to other applets.
In terms of object-oriented programming, applet A creates a sample 0 of class C. the object protection Mechanism allows applet A to access the fields and methods of its own object 0. If applet B wants to access object 0 of applet A, it must get permission to do so via a special call to JCRE. However, there are many ways to authenticate the calling applet to determine whether it is allowed access to object 0. The Java Card standard supports authentication using cryptographic methods or using a password (PIN).
The Global Platform standard is used to solve the problem of secure remote download of applications to the Java card. This standard is implemented on the card using the Card Manager app. A mandatory element of Card Manager is the lriloge-
the Issuer Security Domain, which provides the Issuer’s control over what is uploaded to the card. This application may be written by the card Issuer, or the card may be available to the Issuer with the Issuer Security Domain application already implemented on it.
When monitoring app downloads, the Issuer Security Domain solves the tasks of organizing a secure channel for app downloads. To do this, the app authenticates the app loader and ensures the integrity and confidentiality of the downloaded data. This model assumes that the app loader (called Cryptographic Officer) knows which apps can be downloaded to a specific card and which can’t.
Sometimes the card itself knows which apps can be uploaded to it. In this case, the Application Provider Security Domain mechanism will be used. The Application Provider Security Domain application provides authentication of the provider of the downloaded application (Application Provider), as well as the integrity of the downloaded application (checks the digital signature under the downloaded applet) and data privacy, and also checks whether this application is allowed to download to the card.
Thus, a secure remote download of the application to the card is performed by the means of the Issuer Security Domain and, possibly, the Application Provider Security Domain (this application is optional). It should be noted that these tools provide not only loading the app, but also its installation and removal.
In addition to controlling the download, installation, and deletion of applications, Card Manager provides the ability to use a single PIN value (Global PIN) for all card applets.
In conclusion, it should be noted that Java Card has a set of programming APIs that implement the most common functions used by programmers when writing applications for the Java card. Note such fundamental APIs as javacard.framework (defines the Applet and PIN classes, file system and command support), javacardx.crypto, javacardx.cryptoEnc (defines cryptographic functions used on the card). Having such a set of software interfaces significantly simplifies the task of programmers in developing new applications.
There is a Java Card S solution on the market that is compatible with Java Card, but does not support downloading applications after the card is released. The Java Card S has an EEPROM size of 12 KB, supports DES and RSA, and is the first step towards future Java Card issuance. Another use of such cards is to create a single line of Native cards and multi-stack cards for the Issuer. A single line makes it easier for the Issuer to personalize cards.
Architecture of another multi-layer operating system, MULT0S
The MULTI0S operating system was developed by NatWest Bank (UK) and was originally intended for use in the banking sector. This is the only non-military system that has been certified for the highest security level of ITSEC E6. Since Maosco, which manages the MULTOS standard, considers operating system security a key factor in banking applications, It requires that all platform implementations are pre-certified at the ITSEC E6 level. This certification is carried out at the expense of the implementing party and takes approximately one year.
Relatively recently, the MULTI0S system has been certified at the EAL4+ level according to Common Criteria (ISO/IEC 15408).
Applications for MULT0S can be developed in C, Java, and MEL (MULTOS Executable Language). The latter language was specially developed for the MULTOS MPOs and is the most effective in terms of the volume of application code written in THIS language, as well as the program execution time. The language is based on the use of PI-codes (P-code) of the Pascal and virtual languages-
a machine described by David A. watt in the book “processors of programming languages”.
From the very beginning, the MULT0S MPOs was designed to have all the components necessary for a multi-platform operating system, including the Application Abstract Machine virtual machine, the MULTOS OS operating system, and the Security Manager security management module. The security management module solves all the main tasks of safely downloading (deleting) applications, organizing a secure channel between the Issuer and the card (the card application), and using a single PIN code by various card applications.
The MULTOS standard today also supports the functionality of two interfaces (pin and contactless) of the card, as well as the GSM standard.
According to a number of experts, MPOs MULTOS is more efficient in terms of the size of the application code and the speed of its execution in comparison with Java Card. At the same time, the Java Card MPOs is now much more popular than MULTOS. The main engine of the Java Card system is the telecommunications sector (GSM). Today, only four chip vendors support MULTOS MPOs: Infineon, Philips, Renesas, and Samsung Electronics.
There is a MULTOS Step One solution on the market, which is a card that is fully compatible with the MULTOS system, but does not support downloading applications after the card is released. This card only supports the DES standard and has 4 KB of EEPR0M memory. The MULTOS Step One card can be the first step to migrating to a full-featured MULTOS operating system.
By mid-2005, about 42 million cards with the MULTOS operating system were issued worldwide, of which 12 million were issued in 2004.