Smart card operating system

COS Overview As IC cards evolved from simple synchronous cards to asynchronous cards, from simple EPROM cards to smart cards with internal microprocessors (also known as CPU cards), various requirements for IC cards are increasing. The various management tasks required by the card itself are becoming more and more complicated, so there is an urgent need for a tool to solve this contradiction, and the internal microprocessor

The emergence of smart cards has made the realization of this tool a reality. Using its internal microprocessor chip, people have developed a variety of operating systems for use inside smart cards, namely the COS that will be discussed in this section. The emergence of COs not only greatly improved the interactive interface of the smart card, but also made the management of the smart card easy; more importantly, it made the smart card itself a big step towards the personal computerization, and opened up the development of the smart card. Extremely broad prospects.

The full name of COS is the Chip Operating System, which is generally developed around the characteristics of the smart cards it serves. Because it is inevitably affected by the performance and memory capacity of the microprocessor chip in the smart card, COS is largely different from the operating system (such as DOS, UNIX, etc.) on the microcomputer we usually see. First, COS is a dedicated system rather than a general purpose system. That is: a COS can only be applied to a specific (or some) smart card, and the COSs in different cards are generally different. Because coS is generally designed and developed according to the characteristics of a smart card and its application range, although most of them may follow the same international standard in the actual functions. Second, compared to the operating systems on the common microcomputers, COS is essentially closer to the monitoring program than to a so-called true operating system, which is still at least for the time being. Because at the current stage, COS needs to solve the problem of how to handle and respond to external commands. This generally does not involve sharing and concurrent management and processing, and it is blind to the current application of smart cards. Concurrency and sharing work is really not required.

COS is generally designed and developed in accordance with the functions specified in the international standard (ISO / IEC 7816 series standards). However, due to the rapid development of smart cards and the relatively long period of development of international standards, the current international standards for smart cards are still not perfect. According to this, many manufacturers have their own COS for their own development. Some extensions. For the time being, no company's CoS products have formed an industry standard. Therefore, this chapter will mainly focus on the existing (before 1994) international standards, focusing on the basic principles and basic functions of CO5, and appropriately enumerate their implementation in some products as an example.

The main function of COs is to control the exchange of information between the smart card and the outside world, manage the memory in the smart card and complete the processing of various commands inside the card. Among them, the exchange of information with the outside world is the most basic requirement of coS. In the exchange process, the information exchange protocol followed by COS currently includes two types: T=0 protocol for asynchronous character transmission and T=l protocol for asynchronous packet transmission. The specific content and implementation mechanism of these two information exchange protocols are specified in ISO/IEC7816-3 and ISO/IEC7816-3A3 standards; and the basic functions of management and control that COS should perform are in ISO/IEC7816— 4 standards are specified. In this international standard, the data structure of the smart card and the basic command set of the COS are also described in more detail.

As for ISO/IEC 7816-1 and 2, the physical parameters and physical dimensions of the smart card are specified, and their relationship with COS is not very close.

The architecture of COS relies on the hardware environment of the smart card described in the previous section, and a variety of cos can be designed. However, all COS must be able to solve at least three problems: file operation, authentication and verification, and security mechanisms. In fact, authentication and verification and security mechanisms are among the security system's security systems. Therefore, the most important two aspects of smart card coS are file and security. But after a specific analysis, we can actually divide the complete process from the command of the read/write device (ie interface device IFD) to the response given by the card into four phases, or four functional modules: Manager (TM), Security Manager (SM), Application Manager (AM), and File Manager (FM). Among them, the transfer manager is used to check whether the information is correctly transmitted.

This part is mainly related to the communication protocol adopted by the smart card; the security manager mainly checks or processes the transmitted information to prevent illegal eavesdropping or intrusion; the application manager is used to judge the execution of the received command. Possibility; the file manager finally completes the processing of the command by verifying the operational authority of the command. For a specific COS command, these four stages are not necessarily required, some stages can be omitted, or another stage of the joint; but in general, the COS with these four stages is a comparison Common. Below we will discuss COS in more detail in these four stages.

It should be noted here that the "file" concept in smart cards is different from what we usually call "files". Although the files stored in the smart card are also data units or records, they are all directly related to the specific application of the smart card.

In general, a specific application necessarily corresponds to a file in the smart card, and therefore, the file in the smart card does not have the so-called file sharing. Moreover, such documents must not only be logically complete but also contiguous in physical organization. In addition, although the file in the smart card can also have the file name (FileN8me), the file identification depends on the file identifier (F3te ldentifier) ​​corresponding to the file in the card, not the file name. Because the file name in the smart card is allowed to be repeated, it is essentially a mnemonic of the file and does not fully represent the file.


Delivery management
(Transmission Manaeer)

The transmission management mainly receives the commands issued by the reading and writing device according to the information transmission protocol used by the smart card. At the same time, the response to the command is sent in the format of the transmission protocol. It can be seen that this part is mainly related to the communication protocol specifically used by the smart card; moreover, the more complicated the communication protocol used, the more difficult and complicated the implementation of this part is.

We mentioned earlier that the information transmission protocol used by smart cards is generally T=0 protocol and T=1 protocol. If there are any differences in the implementation functions of COS between these two types of protocols, it is mainly implemented in the delivery manager. There are differences. However, whether using the T=0 protocol or the T=1 protocol, the smart card uses the asynchronous communication mode in the information exchange; and since the smart card has only one data port, the information exchange can only adopt the half-duplex mode. That is, at any one time, only one party (smart card or read/write device) on the data port can send data. The difference between the T=0 and T=1 protocols is that the units and formats of their data transmission are different. The T=0 is a single-byte character as the basic unit, and the T=1 protocol is a data block with a certain length. The basic unit for transmission.

The transfer manager also determines the correctness of the command reception while receiving the command. This kind of judgment is only for the prediction of errors that may occur during the transmission process, and does not involve the specific content of the command, so it is usually implemented by means such as parity, checksum and the like. For the packet transmission protocol, it can also be realized by judging whether the packet length is correct or not.

When it is found that the command is received incorrectly, different information exchange protocols may have different processing methods: some protocols report to the read/write device immediately, and request retransmission of the original data; others simply do the response command. A tag, which is not processed by itself, is left to react to the functional modules behind it. These are all stipulated by the exchange agreement itself.

If the delivery manager believes that the receipt of the command is correct, then it generally only passes the information part of the received command to the next-function module, ie the security manager, and filters out such as the start bit and the stop bit. Additional information about the class. Accordingly, when the transfer manager sends a response to the read/write device, each of the transfer units should be supplemented with the necessary additional information specified in the information exchange protocol.


Security System (—SecvritySCructure)


The security system of the smart card is an extremely important part of the COs of the smart card. It involves the selection of the authentication and verification methods of the card, including the permission control mechanism of the COS when accessing the files in the card, and the confidentiality of the information in the card. mechanism. It can be considered that smart cards can develop rapidly and become popular. One of the important reasons is that it can provide users with a high security guarantee through the COS security system.

The security system conceptually includes three major parts: Security Status, Security Attributes, and Security achanisms. The security state refers to a state in which the smart card is currently located, which is obtained after the smart card performs a reset response or after it processes a certain command. In fact, we can fully assume that a smart card is always in one state or the like throughout the entire work process. The security state can usually be represented by a smart card in a set of currently satisfied conditions.

The security attribute actually defines some of the conditions required to execute a command, and the command can be executed only if the smart card satisfies these conditions. Therefore, if the current security state of the smart card is compared with the security attribute of an operation, it can be easily judged according to the result of the comparison whether a command is allowed to be executed in the current state, thereby achieving security control. the goal of. Associated with the security status and security attributes is the security mechanism. The security mechanism can be considered as the transfer method and means used to implement the transfer of the security state, and generally includes: password authentication, password authentication, data authentication, and data encryption. A security state can be transferred to another state by means of the above-mentioned means, and the state is compared with a certain security attribute. If it is consistent, it indicates that the command corresponding to the attribute can be executed, which is the COS security system. Basic working principle.

From the above description of the working principle of the coS security system, we can see that the implementation of the security mechanism is a very important aspect of the security system relative to the security attributes and security status. Without security mechanisms, COS cannot do anything. From the above introduction of the security mechanism, we can see that the COS security mechanism implements the following three functions: authentication and verification, data encryption and decryption, and file access security control. Therefore, we will introduce them separately below. Among them, regarding the security control of file access, because it is very close to the file manager, we put it into the file system for discussion.

(1) Identification and verification: Identification and verification are actually two different concepts, but because they are very similar in their functions, we also discuss them at the same time, which is also beneficial to grasp this in comparison. Two concepts.

Generally, the so-called authentication refers to the verification of the legality of a smart card (or a read/write device), that is, how to determine whether a smart card (or a read/write device) is not a forged card (or a read/write device). And verify refers to the verification of the legality of the holder of the smart card, that is, how to determine that a cardholder is legally authorized. It can be seen that both of them are a kind of verification of legality, which is very similar in terms of the functions they perform. However, in the specific implementation, the means used are different because of the different objects to be verified.

Specifically, in the implementation principle, the verification is achieved by the user presenting a password to the smart card that only the person knows, and the smart card judges the correctness of the pass. During the transmission of the password, sometimes the encryption/decryption operation can be performed on the information to be transmitted in order to ensure that the user is not eavesdropped. This process is also commonly referred to as password authentication.

The authentication is performed by both the smart card and the reading and writing device performing the same encryption operation on any of the same random numbers at the same time (the DES algorithm is currently commonly used), and then judging the consistency of the two operation results to achieve the verification date.

Depending on the object being identified, COS divides the authentication into two types: internal authentication (Interna1 Authentication) and external authentication (External Authentication). The "internal" and "external" mentioned here all use smart cards as reference points. Therefore, internal authentication is the verification of the legality of the smart card by the reading and writing device; external signing is the legality of the intelligent F to the reading and writing device. verification. As for their specific implementation. We have discussed it in detail in Chapter 5 and will not be repeated here.

The smart card can effectively prevent the use of the fake card and prevent the intrusion of the illegal user through the method of authentication and verification, but it cannot prevent the eavesdropping that may occur during the information exchange process. Therefore, it is important in the communication process between the card and the read-write device. Encryption of data is presented as an effective means of anti-eavesdropping. In the following, only the important part of the encryption, the management and storage principle of the password in the COS, will be explained.

(2) Password management: Currently, the data encryption algorithm commonly used in smart cards is the DES algorithm. The reason for adopting the DES algorithm is that the algorithm has proved to be a very successful encryption algorithm, and the computational complexity of the algorithm is relatively small, which is more suitable for the case where the computing power of the smart card is not very strong. The password (or key) length of the DES algorithm is 64 bits. COS organizes the passwords used in data encryption and stores them in the form of files, called password files. The simplest password file is a collection of records of length 8 bytes, each of which corresponds to a DES password; the record of a more complex password file may also contain various passwords corresponding to the record. Attributes and checksum information attached to ensure the integrity of each record.

The part of the record header stores the attribute information of the password, for example, a password that can be applied to all application files or a password that is only available for an application file; a password that can be modified or can only be read. However: no matter what kind of password file, as a file itself, COS guarantees the security of the password file through the security control mechanism for file access.

When a data encryption operation is required, the COS selects a password from the password file to join the operation. When reading a password from a password file, just like reading the application data, just give the address where the password is located. Of course, the simple way for a member to generate a password is to randomly read a password from the password file as an encryption password. However, such a mechanism may select the same password multiple times, thereby providing the eavesdropper with a chance to decipher, and the security is not too high. Therefore, it is better to do some processing on the password itself after randomly extracting a password, so as to minimize the chance of repeated occurrence. For example, in the PBOS product, the method used is to first perform a DES encryption operation on the password selected from the password file, and then use the operation result as a data encryption password. Its calculation formula is as follows:

Key = DES(CTC, K(a))

Where K is a password randomly selected from the password file; CTC is a counter that records the number of transactions of the smart card, and the counter is incremented by one for each transaction; the key is the password to be used for the data encryption operation. Using this method can improve the security of the smart card, but it reduces the efficiency of execution. Therefore, the specific method used to generate the password should be determined according to the application scope and security requirements of the smart card.

Application manager/file manager
(Application Manager/File Manager)


Application manager

The main task of the application manager is to judge the enforceability of commands received by the smart card. As for how to judge the enforceability of a command, we have already explained it in the security system section, so we can think that the implementation of the application manager is mainly the implementation of the security mechanism of the application software in the smart card. And because the various applications of the smart card exist in the form of files, the essence of the application manager is the security control problem that we will access the file in the next section. It is on this basis that we can also think of the application manager as part of the file manager.

Document management

Like security, files are an extremely important concept in COs. A file is an organized collection of records in a data unit or card. COS implements its storage and management of individual applications by creating a corresponding file for each application. Therefore, the application files stored in the COS are all preparation data or records related to the application. In addition, the CoS for some smart cards may also contain application control files that control the application files.

In COS, all files have a unique file identifier (File ldentifier), so the file identifier can be used to directly find the desired file. In addition, each file can have a file name as a mnemonic, which differs from the file identifier in that it is repeatable. Each file in the COS is created by the publisher (Issuer) according to the application of the card during the personalization of the smart card, and the user of the card cannot usually create or delete the file. However, the user can modify the contents of the file according to the situation, and can add or delete records or data units in the file.

(l) File system: COS files can be classified into three categories according to their logical hierarchy; Master File, Dedicated File, and EIementary File. Among them, the main file is indispensable for any COS. It is the only file containing file control information and allocatable storage area. Its function is equivalent to the root file of the COS file system, which is at the highest level of the COS file system; The file is also an indispensable part. It is the file that actually stores the data unit or record of the standby application. It is at the bottom of the file system, and the special file is optional. It stores the control information of the file. Data information such as the location and size of the file. We can use the tree structure of Figure 6.38 to visually describe the basic structure of a COS file system.




Of course, for a specific COS product, it is likely that the actual classification of the file will be different depending on the application. But as long as the analysis is carefully carried out, it can be attributed to the above three logical levels. For example, the PCOS products previously granted. Its classification of files is not based on logical hierarchy, but on the purpose of the document.

Its files are divided into three categories: COS file (COSFile), password file (KeyFile) and wallet file (PursesFile).

The so-called COS file stores basic application data; the password file stores the password used for data encryption; the role of the wallet file is somewhat similar to the wallet in our daily life. It can be seen that these three types of files are essentially the same as the basic file (EF) class. In PCOS, the concept of special files is not very obvious, but in fact, if you pay attention, then from the previous discussion, it should be easy to find the bundle of files in the FAT area of ​​the product memory partition; Similar to a dedicated file; the nature of the entire PCoS card itself is actually a master file.

The cos file has four logical structures: a transparent structure, a linear fixed length structure, a linear variable length structure, and a fixed length loop structure.

Their definitions and characteristics can be found in the relevant parts of the ISO/IEC7816-4 protocol, which will not be detailed here. but. Regardless of the logical structure taken, the files in cos are physically stored continuously in the memory of the smart card. The access mode of the data in the card, the numbering method of the record, the size of the data unit, and the like are featured as a file system, and are given by the card during the reset response of the smart card. In general, the most important data access method in a smart card is the random access method, that is, the user of the card can directly access a certain data unit or record in the file after being authorized. As for what kind of operation COS can do with the file. We will discuss this in the command system of C()3.

(2) File access security: Security control of file access is a very important part of the COS system. Since the current international standard (ISO/IEC7816-4) has basically no substantive provisions in this regard, The specific implementation methods of the existing file access security control mechanisms are various. We are here to introduce two representative implementations: the authentication register mode and the state machine mode. Among them, there are PCOS, ME2000 and other products that use the authentication and registration method: STARCOS is used in the state machine.

When the authentication register mode is used, an 8-bit (or 16-bit) long area is usually set in the memory RAM as an authentication register. Identification here refers to the identification of security control passwords. The identification register reflects the security state of the smart card. In this way, the header (or file descriptor) of each file of the smart card usually stores the conditions under which the file can be accessed, generally including two conditions of reading and writing, r, respectively. Cu indicates), which constitutes the security attribute of the file. The user enters a secure password by entering the smart card. It is possible to change the security state of the card. This process is often referred to as presentation. This is the security mechanism for the authentication register. By combining the above two aspects, it is possible to control the read and write permissions of the files in the card. The specific operating mechanism is described by taking PCOS as an example.

First, the authentication register in the PBOS is an 8-bit word length, and the s-bit dI is false; the bits are respectively in one-to-one correspondence with the serial numbers of the seven security codes in the secret area of ​​the PC()3 memory. The initial value of each bit in the register is set to "0". If the user presents a secure mom to the smart card and is judged to be correct by F, the system writes "1" to the corresponding bit in the authentication register.

For example, if the second security code in the secure zone is correctly presented by the user, PCOS writes "1" in the second bit of the register. At the same time, the read and write conditions in the file descriptor are stored in Cr and Cu as a number between 0 and 7. The value corresponding to the password required to be read (or written) by the file is kept secret. The small serial number of Yu District. Before reading (or writing) a file, the system first determines whether the Cr (or Cu) bit corresponding to the authentication register has been set to "1" (if Cr is equal to 0, the file can be The user reads it at will; the same for Cu), only when the bit is "1", it means that the read (or write) permission has been met. The file can be read (or written). That is to say, if the user wants to operate on a file, it is necessary to first present the security password corresponding to the security attribute of the file. The system thus achieves the purpose of security control of access to files.

In contrast to the authentication register method, the state machine mode more clearly shows the concept of extended security state, security attributes, and security mechanisms and the relationship between them (the knowledge about state machines is not within the scope of this book, interested readers) Please check the relevant information yourself). Taking 5TARCOS as an example, it uses a mechanism for determining the state machine, which is realized by the application control file (Applicatlon ControIFile, ACF) in the system. The format of the ACF file is already a linear variable length structure file, and its rh record 01 includes the command code (INS) of all commands that the application controlled by the ACP can allow; the remaining records are respectively associated with the instruction code in record 01. A correspondence, in which all stored variants (Varient) records of the government orders. The so-called variant record refers to such records. The record stores the control information, the initial state, the possible next state, and some additional instructions for the rich, and the state transition map can be formed by using these variant records in the ACF. In the variant record, the control information part is essential. Different variant records are mainly different in two aspects: one is that the state allowed by the command is different, and the part of the instruction information starting with the CLA unit is different. This is mainly determined by the difference in the application objects that the command is to operate on.

With ACF, the COS system can achieve secure control of file access. When the system receives a command from an application to operate, it first checks if its command code is in record 01 of the corresponding ACF file. If it is not there, the system considers the command to be wrong. After finding the corresponding instruction code, the system compares the remaining part of the command with the instruction information in the standby variant record corresponding to the command according to the requirements of the control information recorded by the variant. If the comparison result is consistent, then the check is changed. Initial status information in the volume record. If all of these tests pass successfully, the system enters the next state indicated in the corresponding variant record; otherwise, continues to find the next variant record until the corresponding variant is found or all variant records corresponding to the command are checked. . If the corresponding variant record is not found, the command is illegal; otherwise, the next step is to process the command, that is, the actual processing procedure is called by COS to execute the command processing. The system enters a new state if and only if the process ends normally, and begins to wait for the next command to be received.

Basic concept / main function

basic concept

Data Element

Meaningful information in an application sense or in an internal industrial environment.

Data Unit

A minimum set of binary information that can be specifically addressed.

Record (Record)

It can be handled by the IC card as a whole, and the determined byte string can be addressed by the record number or record identifier.

Record Number

In the log file, the order, the unique number.

Record Identifier

It is possible to select at the application level that several records in a file can have the same identifier.

File

In an IC card, a collection of organized data units or records.

File Name

A byte string of a DF can be uniquely identified in the IC card.

File Identifier

Each file (MF, DF, EF) has a 2-byte identification information.

File Control Information

The logical, structural, and security attribute information of a file.

Path

Unlimited join of file identifiers.

Allocable Memory

Part of the memory contained in a file, but has not been specifically allocated.

Command- Response Pair

A collection of two messages: one command followed by a response.

Level level

From the main file, to the number of DFs in the middle of a specific file, where the level of the main file is 0.



The main function

To sum up, the smart IC card operating system should have at least the following four basic functions:

Hardware resource management function;

Communication transmission management function;

Application control management function;

Security control management function.

Each of these functions consists of several sub-functions. According to the ISO OSI reference model classification, the hardware resource management function belongs to the physical layer; the communication transmission management function belongs to the data link layer; the application control management and security control management belong to the application layer. The logical relationship between the layers is shown in the figure.



The picture shows the logical relationship between the functional layers of the smart IC card.


Hardware resource management

The hardware resources in the smart IC card are very rich, and their functions are also different, as shown in Table 3-1. Among them, EEPROM is the most important application resource for users.

Smart IC Card Hardware Function Description Hardware Resource Description Main Function

Central computing, processing, and management of MPU microprocessor systems

CAU Encryption Operation Coprocessor performs operations related to encryption and decryption

ROM read-only memory storage operating system program

Temporary storage of RAM random access temporary work data

EEPROM electrical erase memory application, data storage

I/O communication interface communication transmission

Hardware protection for SL security logic internal resources

···


The purpose of hardware resource management is to organize, coordinate and direct the operation of these hardwares, and provide corresponding program interfaces for high-level applications, making high-level application programming easier, simpler and more reliable. It is similar to the BIOS (Basic Input and Output Interface) feature on a PC, but it has a higher management level than it does. The following focuses on the organization and management of user memory.

1. The data structure of the user memory is in accordance with the ISO/IEC 7816 standard. The data structure of the user memory has four types: Linear Fixed, Linear Variable, Cyclic, and Transparent. See Figure 3-2. Users can decide which data structure to use based on the characteristics of the application data, the update rate, and other factors.


Figure 2 data organization structure

1, linear fixed structure

A typical structure is a fixed length record, in which the storage location of each record is identified by a unique record number, which can be read and written at random. According to the relevant ISO/IEC standards, the record number ranges from 1 to 253.

2, linear variable structure

For example, variable length records, in which the storage location of each record is identified by a unique record number, can be read and written randomly. According to the relevant ISO/IEC standards, the record number ranges from 1 to 254.

3, ring structure

This structure is similar to a fixed-length record of the first and last loops, and random writes are not allowed. The records are stored in a fixed order because the number of records is limited. If the number of records exceeds the limit, the newly written data will overwrite the old data.

4, transparent structure

When binary data uses this data structure, the data is generally addressed and managed by the user, and the operating system is only responsible for the allocation of storage space. The transparent data structure is suitable for storing hypertext information such as sounds and images.

Second, the file organization of the user memory According to the ISO/IEC 7816 standard, the data in the smart IC card is organized and stored in the user memory in the form of a tree file structure. The file is divided into three levels: one is the main file (Master File), forming the root of the file system, similar to the root directory in DOS; the second is the dedicated file (Dedicated File), under the main file, similar to DOS Directory; third is the child-specific file (Child-DF), the proprietary file under DF is similar to the subdirectory in DOS. Of course, there can be DF under DF, which depends mainly on the size of the user memory. In addition, there is an Elementary File that stores the actual application data and corresponding system management information. The metafile can exist at any file level.
The tree structure of the smart IC card file is shown in the figure below.

Figure 3 Smart IC card tree organization file

In the file structure of the smart IC card, the master file can only be one and generated with the operating system, and the user cannot control it; in the file access process, it cannot be accessed in layers, if you want to read and write the element under the child-specific file. The file must pass through its high-level file hierarchy; the size of a proprietary file is predetermined and unmodifiable at the time of application generation, and some operating systems can dynamically modify the size of the proprietary file during use, provided that there is sufficient storage space.

Third, the file type and its characteristics

The files of the smart IC card operating system have three levels of hierarchy. The files at each level are also divided into different categories and have different uses.

1, the main file

There must be a single master file in the system, and the master file forms the root of the smart IC card file system. The main file contains system file control information and allocable storage space, under which various files can be created.

Although the system allows various application files to be generated directly under the root, the best method for organizing files is to assign a proprietary file to each application and organize the various application data under the proprietary file of the corresponding application. The advantage of this is that the mutual interference between different applications is small, the application design is convenient, the security is higher, and the like, which is beneficial to "one card multi-purpose". The main file is generally used to store shared data between different applications, such as card serial number, cardholder data and other information.

At initialization, the main file can also be given some security features, such as prohibiting the use of certain commands of the operating system. The purpose of this is to ensure the safety management of the "one-card multi-use" cross-department or even cross-industry security management from the production of the IC card to the final application.

Once the smart IC card is inserted into the read/write device, the main file is activated immediately until the card is removed.在卡的生存期内，主文件不能被删除。

2、专有文件

专有文件含有文件控制信息及可分配的存储空间，其下可以建立各种文件。

一个专有文件将被用来存储某一应用的所有数据。每一应用的应用顺序均由该专有文件的状态机控制，使不同应用之间具有较强的独立性并且更安全。

专有文件在用户存储器中占据一块静态存储器，一旦专有文件建立，其存储器的大小就不能变动，但在该专有文件下的元文件则可以重新分配所使用存储器大小，可以被删除。专有文件下还可以再建立专有文件。此时，较高层的专有文件称为父专有文件（Parent-DF），较低层的称为子专有文件（Child-DF）。

父专有文件无论在逻辑上（操作系统管理）还是在物理上（用户存储器）均相互隔离。不同的专有文件均可使用主文件下的公共资源。父专有文件的建立一般分成两个步骤：先逻辑创建，即在操作系统中作一创建登记；再物理创建；实际分配一定数量的用户存储器。分步创建的优点是可以独立于时间和存储器位置生成具体应用。某一具体的父专有文件不能在其它专有文件或主文件中删除，该父专有文件的删除条件在其应用控制文件（ACF）中定义，只有满足该条件才删除。该父专有文件被删除之后，其下的子专有文件、元文件也同时被删除，释放的存储器块可由其它父专有文件使用。

子专有文件可以是某一子应用，子专用文件可有其自已的应用控制文件。某一具体的子专有文件不能在其它专有文件或主文件中删除。该子专有文件的删除条件在应用控制文件中定义，只有满足该条件才可删除。该子专有文件被删除之后，其下的专有文件（若还有）、元文件也同时被删除，释放的存储器块可由其它子专有文件使用。

3、元文件

元文件含有实际应用数据或文件控制信息，其下不可建立任何文件。
元文件分为三类：一类存储实际的应用数据，称为工作元文件（WEF）；另一类存储相应的系统管理信息，称为系统管理元文件（SMEF）；在ISO/IEC 7816标准中还定义有一种公共元文件（PEF）。
工作元文件（Working Elementary File）具有以下特性：

存储应用数据；

若条件满足可被读、写、删除等；

可以存在于任何文件结构；

可以是任何一种文件结构；

具有内部数据校验（如检查和）措施。

系统管理元文件（System Management EF）有以下两种。

1、内部保密文件（Internal Secret Files, ISF）具有以下特性：

存储系统或应用保密数据，如加密密钥、个人密码等；

可被输入、修改、覆盖，但不可读；

不能部分删除；

可以存在于任何文件层次；

文件结构可为线性可变结构。

2、应用控制文件（Application Control Files, ACF）具有以下特性：

存储应用状态机棗应用顺序控制数据；

不能删除；

每一文件层次必须有一ACF；

文件结构可为线性可变结构。

公共元文件（Public EF）主要用于存储系统或应用的公共数据，可以无条件存取。

四、文件属性

每一种文件均具有相应属性（Attributs），智能IC卡的文件属性一般有4种：

文件名（File Name）/文件标识（File Identifer）;

安全状态（Security Status）；

操作模式（Operation Mode）；

注释（Notation）。

1、文件名/文件标识

每一文件可以通过其文件名或文件标识来寻址。按ISO/IEC 7816标准，文件类型不同，文件标识的编码也不相同。正确识别、寻址一个文件需要一个从主文件或当前专有文件到该文件的完整的标识路径。从主文件开始的路径称为绝对路径（Absolute Path），可以唯一确定某一文件，这一点和DOS操作系统中的有关概念十分相似。

在ISO/IEC 7816标准中规定，每一文件均由一个2字节长的文件标识参考确定，但在专有文件中也可以使用文件名来标识该文件，主要是为了便于应用设计人员设计该卡，特别是将父专有文件以文件名来标识，更容易区分、理解“一卡多用”。此外，在某一张卡上文件名一定要能唯一确定某一文件。其实，以名字命名该文件时操作系统同时在内部也自动分配给它一个标识，并通过标识来管理该文件。

不同文件类型的标识具有不同的编码。按ISO/IEC 7816标准，文件标识的第一个字节为文件限定符（File Qualifier），主要用于区别文件类型（如主文件、专有文件等）；第二个字节为文件索引（File Index）。其中规定：

主文件：其标识确定为“3F00 H”（十六进制）；

父专有文件（在标准中没有作具体规定）：一般的操作系统中，文件名最长为8字节字符串（第一个字节不能为“20 H”），若文件名不足8字节长，操作系统将在其后以“20 H”补足剩余字节，所有父专有文件的名字不能相同；

子专有文件：子专有文件的文件标识为2字节。同一父专有文件下的子专有文件的标识不能相同，但不同父专有文件下的子专有文件的标识则可以相同；

元文件：文件标识为2字节。其中第一个字节为文件限定符，第二个字节为文件索引，在ISO/IEC 7816中都没有作十分明确的规定，其目的是为整个系统设计留有选择的余地。一般文件限定符可以根据情况自定，当然最好不与标准冲突。文件索引也可自定，一种典型的编码格式见表3-2。

表3-2一种元文件的典型编码
Bg b7 b6 b5 b4 b3 b2 b1 b0 定义

× × 文件类型

0 0 WEF
0.1 ACF
1.0 ISF
1 1 无用× × 文件层次

0.0 MF
0.1 Parent-DF
1.0 Child-DF
1 1 无用

× × × × 文件索引号1-15


2、安全状态

它主要用于定义不同命令在不同状态下（由某一应用的状态机决定）对该文件的存取权限。

3、操作模式

操作模式用于定义文件的静态存取特性，主要有以下几种特性：

可删除性（Erasable）；
读/写特性（R/W）;
存取特性（Access）；
一次写入、多次读出特性（WORM）；
只读特性（RO）；
只写特性（WO）；
可计算性（Compute）：定义该文件是否可被某些命令存取执行。

4、注释

注释含有某一文件的简短的说明信息，如版本号等。
在ISO/IEC 7816标准中，对诸如文件属性等的定义十分简单，很不具体。其目的就是给系统设计人员保留充分的发挥空间。当具体设计某一IC卡的应用系统时，必须按智能IC卡的供应商的技术说明书操作。

通讯传输管理

IC卡必须与相应的读写设备（IFD）通讯。从这个角度讲，智能IC卡操作系统的作用就是从读写设备（IFD）接收命令、执行命令并将结果返回读写设备（IFD）。所以，通讯管理功能模块在操作系统中具有十分重要的作用。

通讯管理功能模块主要实现以下几种功能：

实现某一通讯协议的数据链路层的传输管理功能；

实现ISO/IEC 7816标准规定的ATR（复位响应）等功能；

·为操作系统中的其它功能模块提供相应接口。

按ISO/IEC 7816标准，IC卡和读写设备之间的通讯协议有多种，一般一种特写的卡只支持某一种通讯协议。下面以符合ISO/IEC 7816-3标准的T=1块传输协议的智能IC卡为例介绍通讯管理功能（支持其它通讯协议的卡的通讯管理功能与此相似）。

ICC上电之后，IFD将向ICC发送命令数据，在这样一次典型的通讯过程中，通讯管理功能模块主要从事6个步骤的具体工作。见图。



通讯模块管理

IFD和ICC之间的通讯由IFD启动，IFD还负责给卡供电。通讯为半双工方式（Half Duplex），即同时只能有一方在传输信息。

第一步：复位响应

在ICC正确插入IFD之后，通讯管理功能模块将向IFD发送一个复位响应信息（Answer To Reset,ATR）。ATR中含有卡标识数据，如I/O缓冲区的大小、通讯速率转换因子（Conversions Factor）等信息，通知IFD本ICC的操作特性，以便IFD正确选择相应的操作参数与ICC进行通讯。ICC每次硬复位（卡插入IFD）都将发送一个ATR给IFD。

第二步：数据收发

具体监控、执行传输协议，收发数据。

第三步：链接模式传输管理因为T=1协议传输完整的信息，其大小可能超过I/O缓冲区的大小。为避免出现传输问题，通讯管理功能模块将一个完整的信息分块传输。

第四步：传输检查通过检查某一字节的奇偶校验位、某一块的检查和或长度，发现传输错误并通知IFD。在这种情况下，IFD将重发错误数据。反之，若IFD通知ICC数据发送出错，ICC将执行数据重发操作。

第五步：数据传递若经过上面步骤后数据正确接收，通讯管理功能模块将接收数据传递给下一功能模块，如安全控制管理模块作进一步处理。反之亦然。

第六步：传输结束处理若正确传输后无任何其它动作，通讯管理功能模块将MPU置于相应的节电方式，如睡眠方式（Sleep Mode）以节省功耗。

反之，ICC向IFD发送有关数据信息，也将执行以上若干类似步骤的操作。


应用控制管理

为适应智能IC卡的应用，特别是对安全性要求较高的应用，在智能IC卡的操作系统中还提供应用控制管理功能模块。在以上对用户存储器的文件组织方式的描述中曾经提到每一文件层次(如MF，DF等）均由一个应用控制文件，在该文件中就定义有应用控制管理数据。

应用控制管理功能模块主要具有两个功能：一是提供对某一应用（处于某一文件层次）的应用顺序流程控制；二是提供在不同的应用顺序状态下的命令执行权限。这两个功能虽然可以分开讨论，但在具体实施时却密不可分。

1、应用顺序流程控制应用顺序流程控制定义了某一应用的顺序流程，即状态机。例如，有一个较简单的应用分四步执行，同时该应用具有三个状态，启动该应用需满足条件1，然后进入状态1，执行相应操作；若在状态1下的操作满足了条件2，则进入状态2并执行相应操作；若在状态2下的操作满足了条件3，则进入状态3并执行相应操作；就用结束，如下图所示。



应用流程图

可见，所谓应用顺序流程控制就是定义了某一应用的具体执行过程及相应条件。一旦确定了应用流程，某一应用就必须而且只能按其要求执行，如在上图中不可以从状态1直接跳跃到状态3去执行某一操作。

2、命令执行权限进一步提高应用的安全性，在应用顺序流程中还定义了在某一应用的不同状态下对命令的执行权限。如一数据文件，在该文件建立时定义了其存取特性（如可读写但不能删除），通过在该应用的顺序流程中定义读、写命令还可以进一步限制对该文件的存取。扩展上面的例子，假设在该应用中有一数据文件存储有重要数据，该文件的属性定义为可读写，但根据应用需求读写操作只能在状态3执行，状态2只能进行读操作，这就可以通过禁止在状态2执行写命令而允许读命令，在状态3同时允许执行读、写命令的方法实现，如图6所示。



命令权限限制示意图

至此，从应用顺序控制角度可以认为，在建立某一文件时定义的属性为该文件的静态属性，而结合具体应用定义的命令执行权限则为该文件的动态属性。由此可见，利用这种机制对数据文件的存取限期安全又灵活。


安全控制管理

安全控制管理就是对智能IC卡中的静态、动态数据进行安全控制及管理。它可以具体分为两种功能：一是安全传输控制，即对传输数据的安全保护；二是对内部静态安全数据（如加密密钥等、各种认证授权操作）的控制管理。

一、安全传输控制

为防止有关信息（命令、数据）在IFD和ICC之间的传输过程中被恶意截取、篡改，提高动态传输信息的安全性和可靠性，在智能IC卡的操作系统中提供安全传输控制机制。其主要原理为：或者通过将传输的信息加密，使非法截取的信息无实际应用意义；或者将待传输的信息（或部分信息）进行加密，并将该加密信息附加在传输的明文之后再进行传输，使恶意篡改信息变为不可能；再就是将以上两种方法共同使用，既可防止对传输信息的非法截取，又可防止对传输信息的非法篡改。

在智能IC卡的操作系统中，一般具有四种信息传输方式：

明文传输方式（Plaintext Transmit Mode）;

认证传输方式（Authentic Transmit Mode）;

加密传输方式(Encipher Transmit Mode);

混合传输方式(Mixed Transmit Mode)。

其中，明文传输方式对传输的信息不作任何处理，其它三种信息传输方式则分别实现三种安全控制传输机制。这三种传输方式的具体工作原理将在下一章中结合密码技术详细介绍。

在具体应用中，设计人员可以根据不同的应用对安全性的特殊要求灵活采用不同的信息传输方式。因为并非所有的信息都需要安全传输（将增加时间和空间开销），所以大多数的智能IC卡操作系统均可对每一次传输设定一种传输方式，例如可以一次传输采用认证传输方式，而下一次采用明文传输方式，再下一次则采用混合传输方式，十分灵活。

二、内部安全控制管理

内部安全控制管理的功能主要有两个：一是对数据及功能（如某一命令）的存取执行权限的控制；二是对内部静态保密数据（如加密密钥等）的安全管理。

1、数据及功能的存取执行权限控制

以IC卡为中心，在卡的应用中主要存在两种认证授权过程，见图7。IC卡验证持卡人身份的合法性这一过程通过个人识别号（PIN）来完成；而IC卡和应用终端之间的认证则通过相应的认证过程来完成。

IC卡应用中存在的两种认证授权过程

1）、个人识别号(Personal Identification Number,PIN)

PIN是IC卡中的保密数据。PIN的主要用途是保证只有合法持卡人才能使用该卡或该卡中的某一项或几项功能，以防止拾到该卡的人恶意使用或非法伪造。卡应用发行部门将每一张IC卡均初始化一个PIN并将它经安全渠道分发给相应持卡人。使用时首先要求持卡人输入PIN，若输入的PIN和该卡中存储的PIN相同则证明此持卡人合法，可以使用该卡。

一般较简单的IC卡中只有一个PIN，在较复杂的卡（如智能IC卡）中可以存在几个PIN，如多功能卡中的每一功能就可具有一个PIN。简单IC卡中PIN的位数较短（如4位二进制），在较复杂的智能IC卡中PIN的位数较长（如1~8位十进制）。为进一步提高使用PIN的安全性，每一个PIN还配有一错误计数器（Error Counter）。该计数器用以记录、限制PIN输入错误的次数，若一次连续的输入错误次数超过卡中规定次数则卡自锁；而在该限制次数内只要PIN输入正确一次就可使用该卡，且错误计数器复位，即下次使用输入PIN时还具有卡中规定的最大的试探次数。

一旦卡自锁，简单的IC卡就不可再用，而复杂的智能IC卡还可通过个人解锁码（Personal Unblocking Code,PUC）将卡打开。一般，一个PUC只用于一个PIN，并且也可以有错误计数器。若合法持卡人忘记PIN而将卡锁住，则使用PUC将卡打开时还可以输入一个新的PIN。

在智能IC卡操作系统中，PIN还可以有以下几种属性。
·可修改性(Modifiable):PIN建立之后可以修改。
·不可修改性(Non- Modifiable):一旦PIN建立之后就不可修改。
·临时失效性(Temp-Deactivated):通过命令可使某一PIN临时失效，不起作用，当然还可以通过另一命令再将其激活等等。
另外，在智能IC卡操作系统中，PIN也可按以下两种形式出现。
·全局PIN(Global PIN):处于系统的较高层次（如主文件）中，一旦因错误计数溢出等原因自锁，也同时锁住使用该PIN的其它应用层次。
·局部PIN(Local PI N):处于某一具体应用层次，一旦因错误计数溢出等原因自锁，则仅锁住该层次有应用。

2）、安全认证

IC卡和应用终端之间的认证授权的用途就是相互确认合法性，目的在于防止伪造应用终端及相应的IC卡。它一般有三种认证方式：
内部认证(Internal Authentication)
应用终端验证IC卡的合法性；

PIN功能简单汇总

功能简单IC卡复杂IC卡如智能IC卡

PIN 否是

PIN数量一个若干个

PIN位数较短，如4位二进制数较长/可自定义，如1~8位十进制数

PIN输入错误限制次数较少，如3次较长/可自定义，如1~15次

PIN构成方式硬件软件或软硬件共同构成

全局/局部PIN 否是

可修改性等其它属性否是

个人解锁码（PUC） 否是


PIN应用示意图



外部认证(External Authentication)：IC卡验证应用终端的合法性；
相互认证(Mutual Authentication)：IC卡和应用终端相互验证合法性。

由以上论述可见，在对安全性要求较高的应用（如金融应用）中，只有综合使用PIN和安全认证才能提供较为完善的安全保护。而在一般的IC卡的应用中，可以根据具体情况优化选择各种安全措施，以达到实现较高性能价格比的目的。

2、内部静态安全数据的管理

内部静态安全数据主要指存储于IC 卡内部的PIN、PUC、加密密钥、解密密钥等重要数据。称其为内部是因为它们在应用周期（并非整个生存周期）中，一旦建立就不会在IC卡外出现，而只能在卡的内部使用。这样做的目的当然是为了进一步提高IC卡的安全性。

在智能IC卡操作系统中，专门提供ISF元文件存储这些安全数据。一般每一文件层次（每一应用，某一DF）均有一个ISF元文件存储相应层次（相应应用）的有关安全数据。

不同种类的安全数据（如PIN，加密密钥）具有不同的属性及应用特性。内部静态安全数据管理的主要功能就是当某一应用需要某一安全数据时检查其合法性、可获得性等，并具体执行相应的操作。

不同的智能IC卡操作系统，内部静态安全数据的管理也不尽相同，感兴趣的人士可以参阅有关ISO/IEC 7816标准及相应操作系统的技术说明书。

三、智能IC卡操作系统的信息结构

在IFD和ICC之间的信息交换是命令-响应对(Command-Response Pair)结构，如IFD发送一个命令到ICC，ICC执行命令并将响应信息返回给IFD，典型的传输结构见图9。


IFD和ICC之间的信息传输

按有关ISO/IEC 7816有关标准定义，一个应用协议数据单元(APDU)或者含有命令信息(Command Message)或者含有响应信息(Response Message)，可以从IFD传输到ICC，反之亦然。其中APDU可以理解为IFD和ICC之间一次通讯传输的最小信息单位，如某一命令等。
信息结构


信息结构：按ISO/IEC 7816有关标准，信息结构有两种：命令信息结构、响应信息结构。

--命令信息结构

命令信息结构由两部分组成：4个字节的命令头(Header)，必备部分；紧接命令头为一长度可变的数据体(Body)，可选。

命令信息结构

Header(命令头) Body(数据体)

CLA INS P1 P2 Lc Field Data Field Le Field


命令信息结构中每一字段均具有不同含义。若Le=0，则为请求相应响应数据的最大长度。

命令信息结构中的字段含义

字段名称长度（字节） 含义

CLA 指令类别(CLAss) 1 指令类别

INS 指令码(INStruction) 1 指令码

P1 参数1(Parameter 1) 1 指令参数1

P2 参数2(Parameter 2) 1 指令参数2

Lc字段长度可变，≤3 数据字段的长度

Data字段数据可变，=Lc 数据字段

Le字段长度可变，≤3 预计响应数据的最大长度


依据不同的命令，其信息结构也不相同，一般有以下4种结构。

结构1



在结构1中，没有Lc、Le及Data字段，既没有随命令一起发送的数据，也没有响应数据。

结构2


在结构2中，Le为空，既没有响应数据。

结构3



结构3中，Lc为空，即没有数据字段。

结构4



在结构4中，所有字段均存在。




--响应信息结构

响应信息结构也由两部分组成：可变长度的数据体(Body),可选；·2字节的状态信息(Trailer),必备。

响应信息结构中草药不同字段的含义见表

字段名称长度（字节） 含义

Data字段数据字段可变，= Lr 实际响应数据长度

SW1 状态字节1 1 命令处理状态等数据信息

SW2 状态字节2 1 命令处理状态等数据信息


综上所述，在IFD和ICC实际的通讯过程中，命令-响应对信息结构具有4种组合情况

情况命令数据信息响应数据信息

1 无数据字段无数据字段

2 有数据字段无数据字段

3 无数据字段有数据字段

4 有数据字段有数据字段


命令、响应数据信息结构中有关字段的编码规则、具体应用等，请参考ISO/IEC 7816有关标准或某一具体智能IC卡操作系统的技术说明书。




命令类型



--面向数据管理的命令

面向数据（或文件）管理的命令提供对不同结构的数据文件的存取操作及控制等命令，典型的命令如：

·创建文件命令(Create File Command);

·关闭文件命令(Close File Command);

·读二进制数据命令(Read Binary Command);

·写二进制数据命令(Write Binary Command);

·删除二进制数据命令(Erase Binary Command);

·读记录命令(Read Record Command);

·写记录命令(Write Record Command);

·删除记录命令(Erase Record Command);

·选择文件命令(Select File Command);等。



--命令类型--面向通讯传输的命令

在ISO/IEC 7816标准中还特别定义了两个面向通讯传输的命令:

获取响应命令(Get Response Command)；

包装命令(Envelope Command)。

在标准的命令说明中指出，当不能用已知协议传输命令或响应数据信息时可以使用这两个命令进行有关信息的传输。这两个命令均由IFD初始启动，获取响应命令用于从ICC到IFD方向信息的传输，包装命令用于从IFD到ICC方向信息的传输。



--面向安全控制管理的命令

内部认证命令(Internal Authenticate Command)；

外部认证命令(External Authenticate Command)；

相互认证命令(Mutual Authenticate Command)；

生成随机数命令(Create Random Number Command)；

PIN校验命令(PIN Verify Command)；

安全数据控制管理指令类（是一小类指令，主要用于密钥、PIN、PUC等安全数据的生成、删除、状态查询等，在不同的操作系统的具体实现上差别很大）。



--部分标准指令



指令指令码（INS）（十六进制） 说明

Erase Binary 0E 删除二进制数据命令

Verify 20 PIN校验命令

Extemal Authenticate 82 外部认证命令

Internal Authenticate 88 内部认证命令

Select File A4 文件选择命令

Read Binary B0 读二进制数据命令

Read Record(s) B2 读记录命令

Get Response C0 获取响应命令

Envelope C2 包装命令

Write Binary D0 写二进制数据命令

Write Record D2 写记录命令


智能卡芯片操作系统STARCOS

智能卡芯片操作系统STARCOS（Smart Cark Chip Operation System）是由德国G&D公司和GMD公司合作开发的智能卡卡片级的一个完整的操作系统。它提供适合具体应用的操作和管理的20余条指令，而且其透明的结构使得用户可以集成自定义的指令。该操作系统同样很好地考虑了与现有的和将来的ISO标准的兼容性（ISO/IEC CD 7816。4/Sept.1992）。

Giesecke&Derient是德国最大的卡片生产厂家，一个半世纪以来，以领先的钞票印刷和自动分清技术为全世界四十多个国家的中央银行服务。

在中国，G&D保

Automatic Pet Feeder

Ningbo XISXI E-commerce Co., Ltd , https://www.petspetsaccessories.com