1 Overview
1.1 Open Smart Card Overview
As the Internet occupies an increasingly important position in e-commerce and human life, people are increasingly demanding certification and secure transactions. The smart card has the advantages of small size, light and easy to carry, can store and process data by itself and perform encryption and decryption operations, and the combination with network services makes it a device that can conveniently store user keys and download confidential data.
The smart card contains CPU, RAM, EEPROM, ROM, and I/O, such as the same small computer. The software structure of the smart card consists of the operating system, virtual machine, smart card application model and its specific application service program, as shown in Figure 1.
.jpg)
In this structure, the lowest operating system is responsible for the management of the underlying hardware; the virtual machine layer hides different operating system platforms, interprets the application represented by the assembly language; the open smart card application model defines a complete set of programming The interface class provides a unified application environment required by the application; the application provides a specific smart card service.
1.2 Overview of Open Smart Card Application Model
The functions of today's smart cards and their terminals (reading devices) vary widely from manufacturer to manufacturer, making it difficult for smart card applications to be ported between different smart card development platforms (smart card terminals, smart card operating systems and programming environments); The programming language used to develop smart cards is relatively low-level, and development is difficult and costly.
The proposed open smart card model satisfies the needs of different parts of smart card application development, so that these parts can be completed by application developers, smart card publishers, smart card developers, smart card terminal developers, and can be independently developed and compatible. use. Application developers want to develop smart card applications that can run on cards issued by different publishers. The corresponding smart card publishers also want to be able to use the applications provided by different application developers, freely choose the operating system and apply to all The application arbitrarily selects the device and hardware driver provided by the card terminal provider. The open smart card application model allows each role to be changed without any other component updates, and the functions performed by each role are independent and coordinated.
2 UML-based open smart card application model
This article describes an intermediate layer between the smart card application and the smart card platform, the Open Card Framework to address these issues. the purpose is to:
(1) High-level APIs (Application Program Interfaces) standardization: smart cards and their terminals perform various functions by exchanging commands to the APDU (Application Protocol Data Unit), and the mechanisms for different smart card terminal interactions are different. Models must provide a standard interface to hide the complexity of these mechanisms.
(2) The smart card terminal is transparent. Smart card terminals are various (such as POS machines, fingerprint entry devices), and the model should hide the specific features of the device as much as possible and transparently provide their functions.
(3) The smart card operating system is transparent. A certain command set completes certain tasks, and the smart card operating system wraps these command sets and provides them only to the corresponding interfaces of the application. The interfaces provided by different operating systems are different, and the framework should hide the differences between these interfaces.
(4) The publisher of the smart card is transparent. The publisher of the smart card determines the applications and their organization that are loaded on the smart card, and the framework also hides the details of these management and organization.
(5) Scalability: The middle layer must be able to meet the future technological development needs.
The open smart card application model is an object-oriented framework based on smart card applications. It is a unified framework for smart card developers. It conforms to the ISO7816 related standards and makes the open smart card application model applicable to any smart card type [4].
The open smart card application model divides the tasks of the application system into two parts according to their commonality and personality. They are the Card Terminal Package and the Card Service Package. UML is a kind of application that can be used in the application. The information is visualized by standard graphical elements. It is a standard representation of object-oriented analysis and design. This paper builds a related model through UML to the open smart card application model. The UML will be used to explain their tasks and their internal relationships in detail.
2.1 Modeling of smart card terminal components
The smart card terminal component contains all the classes associated with the smart card terminal and is provided by the smart card terminal developer. The main task is to provide access to the smart card physical terminal and to dynamically add and remove smart card terminals. The main classes in this component and the relationships between them are described below:
Class CardTerminal: A class that can be inherited from various smart card terminals and is produced by its corresponding CardTerminalFactory.
CardTerminalRegistry: This class has only one instance. All smart card terminals installed in the management application system can perform instance registration and logout operations on CardTerminal.
CardTerminalFactory: Like a specific factory producing a certain product, different smart card terminal manufacturers provide specific CardTerminalFactory subclasses from which the corresponding CardTerminal instances are produced.
Class SlotChannel: The channel that sends and receives APDU command pairs to the smart card inserted into the slot.
Use the abstract factory and singleton pattern [1] to build the terminal components of the open smart card application model. All CardTerminal instances in the framework are registered in the unique instance of CardTerminalRegistry, and then the CardTerminalRegistry determines which manufacturer provides the CardTerminal instance. The static class diagram of the smart card terminal component represented by UML is shown in Figure 2.
.jpg)
In the open smart card application model, the action of the smart card being inserted into the card reader or removed triggers the external application system to obtain the object CardTerminal, which uses the CardID (one-to-one corresponding to the inserted smart card) to represent the inserted smart card, and through the object SlotChannel Pass the APDU with the smart card. The related static class diagram is represented by UML as shown in Figure 3.
.jpg)
2.2 Modeling of smart card service components
The service provided by the smart card is accomplished through the interaction between the external application and the smart card (exchange of APDU command pairs). In the open smart card application model, these command sets are integrated into the services on the card, and external applications only need to access these services through standard APIs. This framework should also be extensible to add new service modules. The main classes and their relationships in this component are described below:
Class CardService: This is an abstract class, the meaning of which is the service on the card, its subclass provides specific service content by wrapping a series of APDUs. For example, the subclass FileSystemCardService is to complete the task of accessing the file system of the smart card.
Class CardServiceFactory: Similar CardTerminalFactory functions are similar. The application service provider provides its own CardServiceFactory to represent itself. The CardServiceFactory generates various services such as CardService instances.
Class CardServiceRegistry: All CardService objects on the management card, including services provided by different application providers.
Class CardServiceSheduler: arranges the channel for the communication required by the service, and provides a logical channel for the CardService object to send and receive command pairs to complete the task.
SmartCard class: The external system accesses the open smart card application model to complete the smart card service.
Similar to the CardTerminal component, the CardServiceRegistry object manages all the services on the card. When the application requests a specific service such as an e-wallet service for the inserted smart card, the CardServiceRegistry asks whether all the CardServiceFactory subclasses registered can provide the required service for the smart card. Once a CardServiceFactory subclass such as PurseServiceFactory indicates that it can provide the electronic The wallet service PurseService, then the subclass PurchaseServiceFactory produces the service instance PurseService. The static class diagram for this component is shown in Figure 4.
.jpg)
The CardServiceScheduler arranges a logical channel CardChannel for the specific service instance and the SmartCard instance corresponding to the smart card, and performs APDU exchange. Once the task is completed, it releases the CardChannel instance to provide it to other services. These actions are caused by the smart card being inserted into the card reader terminal or removing the triggered event CardTerminalEvent. The static class diagram is shown in Figure 5.
.jpg)
2.3 Smart Card Application Service
There are also some important application services that need to be built into the open smart card model, which are required for most smart cards.
The class CardManagementCardService is to be able to load, run, and manage multiple applications on a smart card. It is a subclass of CardSevice.
The class FileSystemCardService provides a series of interfaces to access operations
The file system in the system.
The class SignatureCardService performs security management and is used to complete the cardholder's identity authentication, file access authority control, secure message transmission, data encryption and decryption tasks.
Other applications can also use these classes to complete the corresponding services. The external application of the smart card service system accesses the entire application model through the SmartCard class mentioned in Section 2.2. We present a service application instantiation process that shows how the objects work together to complete the functionality. Assuming that the external application requires an A CardService object, the entire dynamic process is represented by the dynamic Coollabartion block diagram of UML as shown in Figure 6.
.jpg)
3 Summary
The application framework of the open smart card brings great convenience to application developers, smart cards and smart card terminal investors. The application of the smart card realizes the conversion from "one to one" to "many to many" and constructs a unified standard structure for the open smart card application.
(1) For applications that follow the open smart card application framework, it can be applied to any open smart card, the application does not need to be developed repeatedly, and the development cost is greatly reduced.
(2) For smart cards developed following the open smart card application framework, not only can multiple applications provided by different organizations be loaded, but once the environment changes, it is easy to load and unload to replace the applications on the card.
The open smart card application framework described in this article satisfies the openness and independence of the application, and does not require applications like traditional smart cards to be tailored for operating systems and chips.
Staff Chair,Executive Chair,Guest Chair,Traning chair,Stool Chair,Cafeteria Chair
Feat Top International(China) CO.,LTD , https://www.ft-project.com