1. Proposal of the problem Each command passes through 4 of them, and if any one of them finds an error during processing, it will return the corresponding error message. The transmission management is responsible for data communication between the card and the interface device. The protocol used for communication is generally an asynchronous half-duplex character transmission protocol T=O as specified by 1SO7816-3 豉T=1 asynchronous half-duplex block transmission protocol. There are generally three different types of data transmission methods: plaintext, plaintext, and ciphertext. The data transmitted in clear text is sent directly to the command processing module by the transport manager. When the data is transmitted in plain text verification mode or cipher text mode, the encryption operator is required to process the data accordingly. The command interpreter simply parses each command of the external input, analyzes and checks whether the command parameters are correct, and then executes the corresponding function module according to the meaning of the command parameters. If the parameter is found to be wrong, the error message is returned directly. The file manager controls the operation and access to files. Before doing data operations, the file manager will check the security status of the card based on the security attributes of the file to determine the feasibility of the operation. Once the file's security attributes and file structure are generated, it is under the control of the file manager. The operation and management of file data will be as follows: Before you can operate on a file, you must select the file; the file system has a three-tier structure, and the operating system does not support selecting files by path, so select one. The file must be selected before its file, and cross-layer selection is not allowed. The master file is automatically selected after the card is powered on; the data in the access file is controlled by the security attribute of the file; the creation of the file is controlled by the security attributes of the file to which the file belongs. During the life cycle of the card, the hardware resources on the card do not change under normal circumstances, so the hardware resource management function and the communication transmission management function generally do not need to be updated. The security control management function, which is the core of system security, may need to be partially updated to adapt to the new application environment over time. For example, some traditional encryption algorithms may need to be replaced with new encryption algorithms after a period of use, so it is necessary to consider the update of the security management module. Since the security management module belongs to the COS core module part, the update of the security module involves the update of the COS. Therefore, it is necessary to establish a corresponding mechanism to adapt to such a situation. Since the security control module is generally provided by the COS provider, when an update is required, it should be updated using the specific update verification procedure provided by the COS provider. When the original DES needs to be upgraded to AES, it can be updated by downloading the corresponding AES module provided by the COS provider to the card without changing the card, which can improve the service life of the smart card. 4, application management Plush Bear,Teddy Plush,Polar Bears,Soft Sitting Bears Ningbo Dikai Imp&Exp Co., Ltd , https://www.longkaitoys.com
Smart Card, also known as CPU Card, is an IC card with a microcontroller chip. The microcontroller chip on the card contains a central processing unit CPU, random access memory RAM, electrically erased programmable memory EEPROM or FlashMemory, read only memory ROM and I/O interface. COS (ChipOperating System) is the chip operating system. It is the executable code of the mask in the microcontroller ROM of the IC card. It is the manager of the chip resource and the basis of security and confidentiality.
The traditional COS basic operation mode is: receiving a command from the interface device, and then processing and returning the response information to the interface device. The process is shown in Figure 1. .jpg)
In summary, for the traditional card and COS, since the COS on the card cannot be updated during the life cycle of the card, and the corresponding access control measures and the encrypted transmission mode are adopted, the security and integrity of the data on the card can be ensured. One of the development trends of smart cards is "one card multi-use", which integrates multiple applications on one smart card. This not only can effectively reduce the cost of using a single application, but is also convenient for users to carry. For a single-application smart card, since the provider of the application is usually the issuer of the card, the data security on the card is usually the responsibility of the card issuer. A smart card that supports "one card multipurpose" should allow users to download their specific applications, allowing users to expand or modify some of the COS commands. Each application can only access its own data and programs, but not other applications' data or programs. Since a smart card has multiple applications at the same time, the application may access data or programs of other applications due to its own defects or for malicious attacks. Data security cannot be guaranteed solely by the card issuer, the application provider, or the user. Therefore, how to ensure the data security on the card is the core problem that should be solved by the "one card multi-purpose" smart card system.
The most relevant part of security in COS is the management of files, that is, the management of memory (including RAM, ROM, EEPROM, Flashmemory, etc.). For the traditional COS, the commands in the COS can operate on all the storage spaces. Since the COS cannot be updated, all operations on the memory are performed by the corresponding COS commands, so the memory is under the control of the COS. The corresponding control method is adopted in the COS command to ensure the security of the data on the memory. All the memory data can be read and all the writeable memory areas (except ROM) can be written with the relevant instructions. In the "one card multi-use" system, it is obvious that you can use the method of adding new applications to attack the system (read all data for analysis, rewrite some system key data, etc.), these attack methods can bypass the COS file. The control module is directly executed, so that the file control module is ineffective. At the same time, if the added application is flawed, there may be problems that damage the system. Therefore, how to implement effective storage management to prevent such problems from occurring becomes a key issue for system security.
Programs downloaded by a specific user can access programs and data of other users. The existing smart card hardware design cannot isolate and protect multiple user areas, that is, limit the access range of specific user commands. This paper proposes a one-card multi-use smart card security model, which can support the safe use of one card multi-purpose, allowing multiple applications to download their special commands in the smart card, and achieve isolation of multiple applications. Each application can only access its own data or user commands, and cannot access data or commands from other applications.
2, "one card multi-use" smart card hardware model
In the Intel 8086/8088 system, due to hardware limitations, the system program and the user program belong to the same security level (that is, there is no difference between the system program and the user program in execution, such as DOS system), so the execution of the user-specific application may be Destroying the system and causing the entire system to crash or accessing other users' data, obviously this model is very insecure, and nowadays smart card systems are almost all based on this model, using existing smart cards to achieve "one card multi-purpose It is difficult to guarantee the safety of the entire system. Drawing on the Intel 80386 hardware to establish four privilege levels to ensure separation of system programs and user programs to achieve multi-tasking and task switching and protection of each task environment, you can add a privilege level to the smart card chip, making such a smart card chip There are two privilege levels, kernel level and user level. In order to support this function, corresponding hardware support must be provided in the smart card chip (here, it is assumed that the CPU used in the smart card is at least 16 bits because the smart card function of the 8-bit CPU is too weak). The smart card needs to increase the flag bit to determine whether the CPU is currently at the kernel level or at the user level. Need to add data address limit register, application address limit register, kernel level stack and exception register. The purpose of adding these registers is mainly to provide more support for the management of storage space from the hardware. The Data Address Limit Register is used to define the data address space of a particular application (the range of address spaces that are allowed to store data). The application address limit register is used to define the program address space of a particular application (the range of address spaces used when executing the program). At the same time, the core modules in COS need to be distinguished from the general application. The core module of COS can only be executed when the CPU is at the kernel level, and the application can only be executed when the CPU is at the application level. When the application executes, if the application attempts to access an address space outside the range of the compare register, the program is aborted and causes an interrupt. The kernel-level stack can only be accessed when the CPU is at the core level. The exception register is used to save the address where the exception occurred when an exception occurs. For this security model, it is also necessary to add new instructions or to augment instruction execution functions such as JMP, CALL, and IRET.
The control transfer in the "one card multi-purpose" smart card is divided into three types: control transfer from kernel level to user level, control transfer from user level to kernel level, and control transfer without level change. After the card is inserted, the system first enters the kernel level, and the chip operating system generates a reset response and waits to receive the command. If the received command is a user-defined command, the system will enter the user level. To achieve control transfer from kernel level to user level, the system sets the corresponding address limit register for the current application according to the application index file, saves the return address and switches control to the corresponding application and reverses the flag. When the application returns from calling the system function, it also needs to transfer control from the kernel level to the user level. In this case, simply pop the return address and so on and reverse the flag. If the application needs to use the function functions provided by COS, then the control needs to be transferred from the user level to the kernel level. In order to achieve this transfer, the system first determines whether the condition of the transfer is met. If it matches, the execution address of the current application and the parameters used by the calling function are placed in the kernel-level stack, so that the application can be used when returning, and the flag is inverted. . When the application returns to the system after execution, the control needs to be transferred from the user level to the kernel level. At this time, the system does not need to save the address executed by the current application, just pop the return address and the like and push the flag~. The privilege-level transformation transfer in the task includes two cases of transfer in the kernel and transfer in the application. This control transfer is similar to the implementation in the currently used smart card, except that the transfer instruction and the accessor access instruction are executed in the application. Before, the system will automatically use the limit register to determine whether the address is out of bounds. If it crosses the boundary, it will transfer to interrupt and exception handling.
The system assigns an interrupt number to each possible interrupt and schedules the corresponding interrupt vector table when the system is initialized. When an interrupt occurs, the system determines whether to respond to the interrupt according to certain rules. If a response is required, the current system state is saved first, and then transferred to the corresponding interrupt response program according to the interrupt vector number saved in the interrupt register. When the interrupt is executed, return to the breakpoint to continue execution. When the CPU is in user mode and kernel mode, the response rules for interrupts may be different. For example, if the CPU is in the kernel state, some interrupts may need to be masked, and the CPU does not need to mask these interrupts in the system state. The system assigns an exception number to each possible exception and arranges the corresponding exception vector table when the system is initialized. When an exception occurs, the system transfers to the corresponding exception handler according to the exception number for corresponding processing. However, after processing, an error is reported and the execution of the current program is interrupted.
3, chip operating system COS
Traditional COS generally consists of four functional modules: transmission management, file management, security management, and command processing. All commands in the traditional COS are executed in the same way. When the system calls the command, the execution authority is given to the command program. At this time, the command program has complete control over all the hardware and software resources on the card. When the application completes the corresponding processing, it returns to the system. As mentioned above, in the new model, all commands should be divided into two parts: core commands and user commands. The core commands should consist of the following parts: commands related to cryptographic operations, commands related to storage management, commands related to authentication, commands related to communication transmission, and commands related to hardware resource management. These commands are generally independent of the specific application and have full control over all hardware and software resources at execution time. A user command is a collection of all commands associated with a specific application. Only specific hardware and software resources can be used during execution, otherwise an error will occur.
After the card is powered on, the COS first sends a reset response to the terminal to establish communication between the two parties and sets the corresponding communication parameters, and then waits for the command of the receiving terminal. When receiving the command from the terminal, the COS will look up the index file. Command, and distinguish whether it is a system core command or a general user command. If it is a system core command, COS returns the corresponding result to the terminal after processing as required; if it is a general user command, COS will find out from the index file. After the application corresponding to the command is found, the system is switched to the environment of the application for corresponding processing. After processing and returning the processing result, the system waits for a new command in the switched COS environment; if the COS cannot be from the index file If the command is found, it is returned to the terminal error flag. It is worth noting that these commands should have a series of authorization verification methods to ensure the security of the system.
In order to adapt to the security model of the "one card multi-purpose" smart card proposed above, we will transform the general model of COS. In file management, an application index file needs to be created for storing indexes of all applications, commands in the application, and corresponding data address space ranges and application address space ranges, and storing this file in the system storage area, so only COS The system can access the file. In terms of technical implementation, the implementation of the file system model can be described using FIG. .jpg)
Commands are divided into core commands and user commands. If you want to update or add core commands, it involves updates to COS. If you update or add a user command, it involves the management of the application. In order to facilitate the update of COS, we divide the storage of COS into the following parts: the core management function module provided by COS and some modules that do not need to be changed during the lifetime of the card are masked into ROM; for those that may need to be updated Module, written to EEPROM or FLASHMEMORY for future update operations; taking into account the expansion of COS itself and the larger storage space that may be required for the update of some modules in x, tcos, while also leaving a portion in EEPROM or FLASHMEMORY space. The storage of COS itself is mainly composed of the above three parts, and its storage logic diagram is shown in Figure 3. .jpg)
Another important aspect of the system is the management of the application, which includes the addition, deletion, update and execution of the application.
When a new application needs to be added, the system sequentially assigns a flag to the application and adds an entry in the application index file to store the address space range and starting address that the application is allowed to use, and The rule establishes a DF file to be assigned to the application. All commands used by the application should also be included in the application index file.
There are 3 ways to delete an application: (1) Once an application is added, it is no longer allowed to be deleted. (2) Allow users to delete all applications. This method is more complicated than the previous one. When an application has time limit for use or does not need to be used again, you can consider deleting the application from the card for recycling. storage. The deletion method is: deleting the index item corresponding to the application in the application index file. Recycled storage space can be allocated to newly added applications, but the newly added application must not exceed the size of the reclaimed storage space, otherwise it should not be assigned. (3) It is allowed to delete some applications. Some applications play a very important role on the card. These applications only allow updates, but cannot be deleted. In this way, when adding applications, you should determine which applications can be deleted. Which apps cannot be deleted. For an application that can be deleted, the deletion method is the same as above, and for an application that cannot be deleted, an error is reported when deleting.
Comparing the three implementation methods, the first method is easy to implement. The disadvantage is that it is not flexible enough and wastes limited storage resources. The second method is slightly more difficult, which can save some storage resources, but it is still not flexible enough. The third method is compared. Difficult, but relatively flexible. However, in terms of technical implementation, the second method is generally preferred.
When some content in an application needs to be updated, the corresponding content in the system can be used to update the corresponding content, but the space occupied by the application after the update cannot exceed the address space allocated to the application, otherwise the update will be rejected. In the update process, the original content is generally overwritten with the updated content. If the original content still has a lot of value, then you should consider whether to perform the update operation. The main advantage of providing an update operation is that it extends the life of the card.
When executing a command in the application, the system automatically loads the address range of the application index file into the limit register. Once the application is out of bounds in the execution, exception processing is required and the application is interrupted. In this way, the application can be prevented from illegally accessing data of other applications or destroying system resources during execution.
5, summary
In theory, an unlimited number of applications can be added to such a system. However, how many applications can be added is limited by hardware and software conditions, and should be determined according to the specific conditions of the system. The "one-card multi-use" smart card has a wide range of applications, which can be applied to financial finance (cash cards, credit cards, prepaid cards, electronic checks, securities cards, etc.), social security (life and accident insurance cards, social security cards, etc.). ), medical (health check card, blood donation card, medical record card, etc.), transportation (traffic card, etc.). This paper discusses a "one card multi-purpose" smart card model from the hardware model and software model of the card, and focuses on the differences between it and the traditional smart card model, and gives some implementation methods. Using the above-mentioned "one-card multi-purpose" smart card, physical isolation can be provided on the hardware, which can realize true one-card multi-use and ensure the security of multiple applications and data on the card.
(Wen/School of Computer Science, Wuhan University, Xu Zhonghua, Liu Yuzhen, Zhang Huanguo)