Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
There are various approaches to the implementation of application programs (applications) on the card. The first approach is that IPC applications are developed for a specific "native" operating system of the card microcircuit, created on the basis of a set of instructions supported by the microprocessor. Such cards are called Native cards or static cards. The latter name is due to the fact that applications written for such cards cannot be transferred to cards using another operating system.
On static cards, the application uses the functions of the operating system and a set of instructions supported by the microprocessor, and therefore completely depends on the microcircuit of the card (Fig. 2.12). Thus, the static card application is not portable from a single chip chip.
Rice. 2.12. The architecture of a static card from a manufacturer to a microcircuit of another manufacturer. Whenever the card issuer changes the chip, they must rewrite the application for the new chip. Operating systems MPCOS (Gemalto), STARCOS (Giesecke & Devrient), OSCAR (GIS), CardOS (Siemens) are widely used in static cards.
In static cards, the microprocessor operating system is stored in ROM, while the card application can be written to both ROM and EEPROM. In most static card implementations, the application is stored in ROM and is logically intertwined with the microprocessor's operating system, instead of being above the operating system, as shown in Figure 1. 2.12.
The file system of the card stores some of the data for the card applications and its operating system. It is always located in the EEPROM. This is due to the fact that EEPROM is non-volatile memory and allows not only data read operations, but also write / delete operations.
A different organization of application support is provided in the IPC operating under the control of open multi-application operating systems (MPOS). Today there are two widely used MEPs - Java Card and MULTOS. More recently, Microsoft was trying to enter the smart card operating system market with its Windows for Smart Cards (WfSC) system. But recently, information about the promotion of this system on the market has ceased to come.
A general view of the MPS architecture is shown in Fig. 2.13.
The ROM mask of a multi-application card contains:
• an operating system that manages the resources of the microcircuit and implements a number of routine functions;
The main idea of MPS is to create a universal open operating environment: a virtual machine for interpreting and executing application programs and a set of software interfaces that significantly simplify the process of developing card applications and make applications portable to any microcircuit that supports the same MPS.
In the presence of the MPS specifications, the card manufacturer has the opportunity to implement the entire set of MPS system programs on the selected chip, thereby greatly facilitating the application supplier's task of creating new applications. In addition, the written application becomes chip independent in the sense that it can function on any chip that supports the given MPS system. This property is key to the idea of an open multi-application operating system.
In fig. 2.14 shows the architecture of the IPC operating under the Java Card operating system (such cards are also called Java cards).
In a Java Card, an application is isolated from the microprocessor operating system using the Java Card Virtual Machine (JCVM). JCVM interprets bytecodes of the application and translates them into commands of the "native" operating system (Native OS) of the microcircuit. At the same time, for each chip, its own JCVM virtual machine is developed, which together
Rice. 2.14. Java Card architecture
with the chip's operating system and APIs is stored in ROM.
The key advantage of a Java card is that an application written for one Java card can also be successfully applied to another Java card, regardless of which chip is used on that other card. This advantage is formalized in the form of the well-known slogan: "Write Once, Run Anywhere" - "Written once, used everywhere."
It also makes it easier to develop a Java Card application because a high-level language is used to write the program.
The Java Card programming language has a large set of limitations compared to the Java language. These limitations are a consequence of the limited resources (especially memory) of the IPC. As a result, the Java Card environment is only a small subset of the Java operating system and does not support functionality such as:
di
MasierCa k '^? 1
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 JCVM module, called the Java Card Converter (JCC), runs on a PC or workstation. This module is designed to generate a file of type applet.cap from the source code file for the applet.class application written in the Java Card language.
When converting the applet.class file, the JCC module performs data type checking, initializes static variables, checks for Java Card syntax violations, checks for memory management violations, and defines class references, methods, and fields in the most compact and JCVM-driven form possible. The resulting applet.cap file is loaded onto the card, installed and executed on it.
The downloadable file is called an applet (Java Applet). Installing an applet in a Java Card environment makes it selectable and treats it as an application. Thus, a Java card application is an instance of an executable module (applet) loaded onto the card.
As noted, the JCVM module located on the card includes an interpreter that allows you to byte-byte execute the card application bytecodes.
Most programs written in the Java Card language are part of systems where much of the work is done outside the card. To organize the operation of such systems in which Java cards are an important component, VISA has developed an open
Rice. 2.15. The JCVM framework (Open Platform), which today has become part of the global GlobalPlatform standard (www.globalplatform.org). This standard is described in clause 2.7.
The Java Card standard does not use many of the security mechanisms found in Java. In particular, secure loading of the application to the card (function of the security manager) is not supported. From a Java Card perspective, loading any application is safe. All the Java Card provides is a mechanism to protect objects from unauthorized access by other objects. This is done through a shared interface (Sharing Interface, or SI).
Suppose applet A wants to allow other objects to access 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 the C class that is created for this purpose. The C class contains methods that are available to other applets.
In terms of object-oriented programming, applet A creates a sample O of class C. The mechanism for protecting objects from unauthorized access allows applet A to access the fields and methods of its own object O. If applet B wants to access object O of applet A, it must be able to do so. permission through a special challenge to the JCRE. However, there are many ways to authenticate the calling applet in order to verify its access rights to object O. The Java Card standard supports authentication using cryptographic methods or using a password (PIN).
To solve the problem of secure remote loading, installation and removal of applications, the GlobalPlatform platform is used. In addition, GlobalPlatform provides the ability to use a single Global PIN value for all authorized card applications. More details about the GlobalPlatform platform are described in section 2.7.
In conclusion, it should be noted that Java Card contains a set of APIs that implement the most common functions used by programmers when writing applications for a Java card. Note such fundamental APIs as javacard.framework (defines Applet and PIN classes, ISO 7816-4 file system and command support), java.lang (defines fundamental classes for JCVM), javacardx.crypto (defines cryptographic functions used on the card), java.rmi (defines the Java Card Remote Method Invocation mechanism, which allows an external program to use the card data and run some functions on the Java card), javacardx.biometry (allows you to create a biometric authentication server on the card that is used by other card applications).
There is a Java Card S solution on the market that is compatible with the Java Card, but does not support downloading applications after the card is issued (download is possible at the card personalization stage). The Java Card S has a 12KB EEPROM, supports DES and RSA and may be the bank's first step towards the future issuance of Java Cards.
The latest version of the Java Card operating system implemented on smart cards is Java Card 2.2.2. Compared to previous versions, it includes an expanded set of open APIs that support:
In the spring of 2008, Sun Microsystems published the Java Card 3.0 specification. These specifications are more than just another update to the previous version of Java Card 2.2.2. In addition to supporting the traditional applet-based Java development model, the Java Card 3.0 specification introduces a new architecture based on web-based applications. These two models are described in two editions of the Java Card 3.0 specification: Java Card 3.0, Classic Edition continues and improves on the previous version of the specification, 2.2.2, while Java Card 3.0, Connected Edition describes a new architecture for the Java Card platform based on a new virtual machine and a significantly improved runtime environment. The term "Connected Edition" reflects the fact that this version adds such networking capabilities, as support for web applications and communication under the Generic Connection Framework (GCF). The Java Card 3.0 standard supports:
By the end of 2009, the Java Card 3.0 operating system had not yet been implemented on microprocessor cards.
The architecture of another multi-application operating system MULTOS is shown in Fig. 2.16.
The MULTOS operating system was developed by the specialists of the NatWest bank (Great Britain) and was originally intended for use in the banking sector. It is the only non-military system that has been certified for the highest level of security ITSEC E6. Since MAOSCO, which manages the MULTOS standard, considers
Rice. 2.16. The architecture of MPS MULTOS operating system security is a key factor in banking applications, it requires all platform implementations to be pre-certified at the ITSEC E6 level. Such certification is carried out at the expense of the implementing party and takes about a year.
The MULTOS operating system is also EAL4 + certified under the Common Criteria (ISO / IEC 15408).
Applications for MULTOS can be developed in C, Java and MEL (MULTOS Executable Language). The latter language was specially developed for MULTOS and is the most efficient in terms of the amount of application code written in this language, as well as the execution time of the program. The language is based on the use of Pascal P-codes and the virtual machine described by David Watt in his book Programming Language Processors.
From the very beginning, the MULTOS MPS was developed in such a way as to have all the components necessary for a multi-application operating system, including the Application Abstract Machine virtual machine, the MULTOS OS operating system and the Security Manager software module for security management. The security management module solves all the main tasks of secure downloading (deleting) applications, organizing a secure channel between the issuer and the card (card application), using a single PIN-code by various authorized card applications.
The MULTOS standard also supports contact and contactless card interface functionality.
According to a number of experts, MULTOS MPS 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 MPS Java Card is now much more popular than MULTOS. The main engine of the Java Card system is the telecommunications sector (GSM). Today, only four chip suppliers support MULTOS MPSs: Infineon, NXP Semiconductors, Renesas, 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 issued. This card only supports DES and has a 4KB EEPROM. The MULTOS Step One card can be the bank's first step towards migration to the full-featured MULTOS operating system.
By the middle of 2005, about 42 million cards with the MULTOS operating system were issued in the world.
On static cards, the application uses the functions of the operating system and a set of instructions supported by the microprocessor, and therefore completely depends on the microcircuit of the card (Fig. 2.12). Thus, the static card application is not portable from a single chip chip.
| App 1 | App 2 | App 3 |
| Native OS | ||
| Microprocessor (and coprocessor) |
Rice. 2.12. The architecture of a static card from a manufacturer to a microcircuit of another manufacturer. Whenever the card issuer changes the chip, they must rewrite the application for the new chip. Operating systems MPCOS (Gemalto), STARCOS (Giesecke & Devrient), OSCAR (GIS), CardOS (Siemens) are widely used in static cards.
In static cards, the microprocessor operating system is stored in ROM, while the card application can be written to both ROM and EEPROM. In most static card implementations, the application is stored in ROM and is logically intertwined with the microprocessor's operating system, instead of being above the operating system, as shown in Figure 1. 2.12.
The file system of the card stores some of the data for the card applications and its operating system. It is always located in the EEPROM. This is due to the fact that EEPROM is non-volatile memory and allows not only data read operations, but also write / delete operations.
A different organization of application support is provided in the IPC operating under the control of open multi-application operating systems (MPOS). Today there are two widely used MEPs - Java Card and MULTOS. More recently, Microsoft was trying to enter the smart card operating system market with its Windows for Smart Cards (WfSC) system. But recently, information about the promotion of this system on the market has ceased to come.
A general view of the MPS architecture is shown in Fig. 2.13.
The ROM mask of a multi-application card contains:
• an operating system that manages the resources of the microcircuit and implements a number of routine functions;
| MEP structure | ||
| App 1 App 2 App 3 | Security Manager | Optional Sector Specific Functions |
| API | ||
| Virtual machine | ||
| Operating system | ||
| Microprocessor (with cryptographic coprocessor) |
- a virtual machine that allows interpreting and executing applications loaded on the card. A virtual machine is a program that uses the functions of the operating system of the microcircuit and a set of instructions supported by the microprocessor. Card applications use open APIs of the virtual machine and are compiled from source codes written in high-level languages C, Java, Visual Basic;
- the card administrator (Card Manager), which controls the functions of secure loading / uninstallation of applications, distribution of commands from the terminal between individual card applications.
The main idea of MPS is to create a universal open operating environment: a virtual machine for interpreting and executing application programs and a set of software interfaces that significantly simplify the process of developing card applications and make applications portable to any microcircuit that supports the same MPS.
In the presence of the MPS specifications, the card manufacturer has the opportunity to implement the entire set of MPS system programs on the selected chip, thereby greatly facilitating the application supplier's task of creating new applications. In addition, the written application becomes chip independent in the sense that it can function on any chip that supports the given MPS system. This property is key to the idea of an open multi-application operating system.
In fig. 2.14 shows the architecture of the IPC operating under the Java Card operating system (such cards are also called Java cards).
In a Java Card, an application is isolated from the microprocessor operating system using the Java Card Virtual Machine (JCVM). JCVM interprets bytecodes of the application and translates them into commands of the "native" operating system (Native OS) of the microcircuit. At the same time, for each chip, its own JCVM virtual machine is developed, which together
Rice. 2.14. Java Card architecture
with the chip's operating system and APIs is stored in ROM.
The key advantage of a Java card is that an application written for one Java card can also be successfully applied to another Java card, regardless of which chip is used on that other card. This advantage is formalized in the form of the well-known slogan: "Write Once, Run Anywhere" - "Written once, used everywhere."
It also makes it easier to develop a Java Card application because a high-level language is used to write the program.
The Java Card programming language has a large set of limitations compared to the Java language. These limitations are a consequence of the limited resources (especially memory) of the IPC. As a result, the Java Card environment is only a small subset of the Java operating system and does not support functionality such as:
- multithreading (multitasking);
- memory allocation before objects are created;
- loading dynamic classes;
- object serialization - the ability of a program to read (write) objects in a stream (from a stream) of data;
- using large data types (floating point variables, double length variables, etc.);
- garbage collection;
- cloning of objects;
- Security Manager function.
di
MasierCa k '^? 1
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 JCVM module, called the Java Card Converter (JCC), runs on a PC or workstation. This module is designed to generate a file of type applet.cap from the source code file for the applet.class application written in the Java Card language.
When converting the applet.class file, the JCC module performs data type checking, initializes static variables, checks for Java Card syntax violations, checks for memory management violations, and defines class references, methods, and fields in the most compact and JCVM-driven form possible. The resulting applet.cap file is loaded onto the card, installed and executed on it.
The downloadable file is called an applet (Java Applet). Installing an applet in a Java Card environment makes it selectable and treats it as an application. Thus, a Java card application is an instance of an executable module (applet) loaded onto the card.
As noted, the JCVM module located on the card includes an interpreter that allows you to byte-byte execute the card application bytecodes.
Most programs written in the Java Card language are part of systems where much of the work is done outside the card. To organize the operation of such systems in which Java cards are an important component, VISA has developed an open
Rice. 2.15. The JCVM framework (Open Platform), which today has become part of the global GlobalPlatform standard (www.globalplatform.org). This standard is described in clause 2.7.
The Java Card standard does not use many of the security mechanisms found in Java. In particular, secure loading of the application to the card (function of the security manager) is not supported. From a Java Card perspective, loading any application is safe. All the Java Card provides is a mechanism to protect objects from unauthorized access by other objects. This is done through a shared interface (Sharing Interface, or SI).
Suppose applet A wants to allow other objects to access 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 the C class that is created for this purpose. The C class contains methods that are available to other applets.
In terms of object-oriented programming, applet A creates a sample O of class C. The mechanism for protecting objects from unauthorized access allows applet A to access the fields and methods of its own object O. If applet B wants to access object O of applet A, it must be able to do so. permission through a special challenge to the JCRE. However, there are many ways to authenticate the calling applet in order to verify its access rights to object O. The Java Card standard supports authentication using cryptographic methods or using a password (PIN).
To solve the problem of secure remote loading, installation and removal of applications, the GlobalPlatform platform is used. In addition, GlobalPlatform provides the ability to use a single Global PIN value for all authorized card applications. More details about the GlobalPlatform platform are described in section 2.7.
In conclusion, it should be noted that Java Card contains a set of APIs that implement the most common functions used by programmers when writing applications for a Java card. Note such fundamental APIs as javacard.framework (defines Applet and PIN classes, ISO 7816-4 file system and command support), java.lang (defines fundamental classes for JCVM), javacardx.crypto (defines cryptographic functions used on the card), java.rmi (defines the Java Card Remote Method Invocation mechanism, which allows an external program to use the card data and run some functions on the Java card), javacardx.biometry (allows you to create a biometric authentication server on the card that is used by other card applications).
There is a Java Card S solution on the market that is compatible with the Java Card, but does not support downloading applications after the card is issued (download is possible at the card personalization stage). The Java Card S has a 12KB EEPROM, supports DES and RSA and may be the bank's first step towards the future issuance of Java Cards.
The latest version of the Java Card operating system implemented on smart cards is Java Card 2.2.2. Compared to previous versions, it includes an expanded set of open APIs that support:
- work with contactless cards;
- AES algorithms and asymmetric elliptic curve encryption algorithms, calculation of SHA-256 and HMAC-SHA1 hash functions;
- mechanism for removing objects;
- an extended version of the Java Card Remote Method Invocation protocol, which allows an external program to use card data and launch certain functions on a Java card.
In the spring of 2008, Sun Microsystems published the Java Card 3.0 specification. These specifications are more than just another update to the previous version of Java Card 2.2.2. In addition to supporting the traditional applet-based Java development model, the Java Card 3.0 specification introduces a new architecture based on web-based applications. These two models are described in two editions of the Java Card 3.0 specification: Java Card 3.0, Classic Edition continues and improves on the previous version of the specification, 2.2.2, while Java Card 3.0, Connected Edition describes a new architecture for the Java Card platform based on a new virtual machine and a significantly improved runtime environment. The term "Connected Edition" reflects the fact that this version adds such networking capabilities, as support for web applications and communication under the Generic Connection Framework (GCF). The Java Card 3.0 standard supports:
- HTTP / HTTPS protocol;
- TCP / IP protocol;
- jar files (files containing executable modules for the Java2ME operating system used in cell phones);
- multithreading;
- string variables;
- verification of the applet bytecode on the card, etc.
By the end of 2009, the Java Card 3.0 operating system had not yet been implemented on microprocessor cards.
The architecture of another multi-application operating system MULTOS is shown in Fig. 2.16.
The MULTOS operating system was developed by the specialists of the NatWest bank (Great Britain) and was originally intended for use in the banking sector. It is the only non-military system that has been certified for the highest level of security ITSEC E6. Since MAOSCO, which manages the MULTOS standard, considers
| App 1 | App 2 | App 3 | Security Manager | Contactless (verified code) |
| API | ||||
| Application Abstract Machine (Virtual Machine) | ||||
| MULTOS OS | ||||
| Microprocessor (and coprocessor) |
Rice. 2.16. The architecture of MPS MULTOS operating system security is a key factor in banking applications, it requires all platform implementations to be pre-certified at the ITSEC E6 level. Such certification is carried out at the expense of the implementing party and takes about a year.
The MULTOS operating system is also EAL4 + certified under the Common Criteria (ISO / IEC 15408).
Applications for MULTOS can be developed in C, Java and MEL (MULTOS Executable Language). The latter language was specially developed for MULTOS and is the most efficient in terms of the amount of application code written in this language, as well as the execution time of the program. The language is based on the use of Pascal P-codes and the virtual machine described by David Watt in his book Programming Language Processors.
From the very beginning, the MULTOS MPS was developed in such a way as to have all the components necessary for a multi-application operating system, including the Application Abstract Machine virtual machine, the MULTOS OS operating system and the Security Manager software module for security management. The security management module solves all the main tasks of secure downloading (deleting) applications, organizing a secure channel between the issuer and the card (card application), using a single PIN-code by various authorized card applications.
The MULTOS standard also supports contact and contactless card interface functionality.
According to a number of experts, MULTOS MPS 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 MPS Java Card is now much more popular than MULTOS. The main engine of the Java Card system is the telecommunications sector (GSM). Today, only four chip suppliers support MULTOS MPSs: Infineon, NXP Semiconductors, Renesas, 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 issued. This card only supports DES and has a 4KB EEPROM. The MULTOS Step One card can be the bank's first step towards migration to the full-featured MULTOS operating system.
By the middle of 2005, about 42 million cards with the MULTOS operating system were issued in the world.
