introduction Face Makeup,Base Cream,Bb Cream,Sunscreen Cream,Powder Puff Guangzhou Shishi Daily Chemical Co.,Ltd. , https://www.cosmeticok.com
A smart card or IC card, the English name is SMART Card or Integrated CircuitCard. It is packaged by an integrated circuit chip embedded in a plastic substrate. The integrated circuits in the card include a central processing unit (CPU), flash memory (EEPROM), random access memory (RAM), read only memory (ROM), etc. [1]. Dynamic multi-application smart cards allow multiple applications to be accommodated on a single card at the same time, and different applications can be used in different situations, and the application itself can be downloaded to or deleted from the card at any time as needed. This brings benefits to the card issuer, the issuer and the cardholder. Dynamic multi-application smart cards will be the general trend of smart card development in the future.
1 Design model of smart card file system
1.1 Types and organization of documents
This system complies with the document standards defined in the ISO/IEC 781* standard. According to the standard, both special file (DF) and basic file (EF) files can be supported. The logical organization of files within a card consists of a structured hierarchy of the following specialized files, and the DF at the root is called the master file (MF). This MF is a must. Other DFs are optional. Define two types of EF: 1) Internal EF (KEF). Store data that is expected to be interpreted by the card. Such as a key. 2) Working EF (WEF). Store data that is not expected to be interpreted by the card.
The EF structure has the following types: 1) Transparent structure. Refers to a binary or cluttered structure. In other words, a transparent file has no internal structure at all. Files of this structure can be read and written by using offset values. The READ BINARY and UPDATE BINARY commands are available for these aspects. 2) Record structure. It is based on a fixed-length record file structure. The data of this structure can be stored freely. The minimum unit of access is a record. The operating system supports a linear fixed-length record structure, and the record length must be an even multiple of 4 bytes and less than one page size, thus preventing a record from being stored across pages.
The logical organization of the file is shown in Figure 1. The file system is a tree structure with the root directory MF. MF (main file) is a special file, the root of the file system, the only one in the card, equivalent to the root directory of DOS. The EF (Basic File) is built under the DF to store various data and management information of the application. DF (Proprietary File) is generally only equivalent to a subdirectory of DOS, but a DF of the main file MF represents an application. There is a KEF under the MF and under the application's root DF for storing keys or PINs. The EF and DF established in the DF under MF can only be used by the application, and other applications cannot access it.
The directory files (MF and DF) in the smart card consist only of the file headers, which are composed of the file header and the file body. The file header contains the file's identity, size, access rights, and other basic information. The length of the file header is fixed. The file body of EF is the data element required for various card applications. Its size is determined when the file is created.
1.2 File access and file management
All EF file headers contain an attribute field that indicates the special information for this file. The attribute field occupies two bytes, and each bit in the field represents an attribute. They are determined at creation time and no changes are allowed. Currently only the first three bits are used, which are:
1) The attribute can be deleted. This attribute bit is 1 for deletion and 0 for deletion.
2) Writable attributes. This attribute bit is 1 to indicate that it can be modified, and 0 to indicate that the file is read-only.
3) Readable attributes. This attribute bit is 1 to indicate that this file can be browsed, and 0 means it cannot be browsed.
Applications need to achieve a certain security state for file access. A process can access a file when its current state of the application's existing state meets the required state and meets the attributes requirements of the file. The security state of the current process is determined by whether it satisfies the corresponding key in the KEF under the current directory file. There is only DF (application directory) under MF, there is no EF file, and its KEF contains only the creation key, the read key, and the delete key. The general KEF file contains four keys, namely, read key, write key, create key, and delete key.
In order to facilitate file management, some typical variables are stored in RAM, and these variables are encapsulated into a structure CMB placed in the process PCB. A CMB block contains the following variables: 1) mfhead. This variable always points to the top MF file header address. 2) mfsecurity. This variable indicates the safe state that MF has reached. Its initial value is assigned when the process is established. 3) dfsecurity. This variable indicates the security status reached by the currently selected DF. Its initial value is assigned when the process is established. 4) currentdf, currentwef. These two variables are the current DF, the current WEF file header address. Their values ​​are NULL at process time and are explicitly assigned by the SELECT command while the process is running. 5) currentrecord_adr. This variable is used when the current WEF is a record structure, which points to the current usage record number, such as a transparent file, an invalid address. When a process establishes or reselects WEF, its value is assigned to 0. The read and write commands are changed by the record structure WEF. 6) currentef_kef. This variable is the KEF file header address under the current DF. When the process is created, a CMB block is created, its currentdf is assigned to the DF that was being accessed at the time, and the security state is assigned to 0. If currentdf is 0, it means the current working directory is MF.
1.3 EEPROM division
The smart card has an EEPROM size of 256K, which is divided into application data area (32K), application code to (160K), system area (16K) and swap area (48K).
The application data area stores the configuration data of the application and is stored in the form of a file. The EEPROM of the application data area is dynamically allocated to each application in the form of a page, each page size being 32 bytes. The page address information of each file is recorded in detail by the file allocation table. The application code area stores the running code of the application. The application code is divided into 40 blocks, each of which is 4K in size. Block and application are one-to-one correspondence, that is, each block maps an application. System area: Information about the operating system and some system tables for managing applications and files: application usage table, file allocation table, file open table, data area usage table. The file open table is used to prevent read and write conflicts. When a file is being rewritten, the file needs to be locked, and the file is unlocked after the file operation is completed.
The data area usage table records the storage of the application data file in the data area. When an application wants to access a certain data file, it needs to view the table to check whether the file belongs to the application, and prevent the application from tampering with the data files of other applications. The operating system information is recorded in super blocks. The swap area is to use the swap area to expand memory when there is not enough memory.
2 file system
2.1 File allocation table
In this operating system, the file system is only designed to the application data area, and has nothing to do with the application system area and the application code, so the file system occupies 32K of EEPROM space. The data area is allocated to the file in the form of a page, each page is 32 bytes in size and has a total of 1024 pages. The file allocation table stored in the system area occupies 1K space. The allocation table is shown in Figure 2: The table has a total of 1024 pages (in hexadecimal notation), and the first page represents the first 32 bytes of the data area, and so on. When the entry is FFFF, it indicates the end of the file. This page is available when recorded as FFFE. The entry for each page records the page number of the next page of the file. as the picture shows. The page numbers occupied by this file are 1,0xC, 0xD, 0x10, 0x14.
2.2 Document Management Instructions
1) SELECT FILE: After the file is created successfully, the file selection can be performed. The object-oriented file management system requires that the file can be accessed after the file is selected. File selection is to inform the operating system which file to access. A successful selection of a new file will invalidate the previous selection. This means that there is only one file selected at any time. The file system supports file selection based on the file's FID.
2) CREATE FILE: This command allows EF, KEF, DF to be established in the smart card. A specific security state must be reached before executing this command. At the time of creation, it is judged whether the creation address is valid, that is, the corresponding address of the CMB block. At the same time, it will affect the structure of the directory tree. It may need to modify its parent node or its sibling node. Therefore, it is necessary to detect whether the affected node is accessible. If the node to be modified cannot be accessed, the command cannot be executed. For EF and KEF, they all have a file body, and they are allocated according to their size. When applying for a page, all the required pages are allocated to the file at a time, and an image is created in the file allocation table. The file system then writes the file body to the EEPROM based on the file allocation table.
3) DELETE FILE: Deletes the file of the specified smart card from the memory, and the released storage space is reclaimed by the operating system. The files of the file system are stored in the application data area, so the operation object of the command is the file of the data area, and does not involve data of other storage areas. MF is the root directory of the file system and cannot be deleted.
KEF is the key file in DF. Deleting KEF only will cause great security risks to its upper DF. Therefore, it does not provide a simple delete KEF operation, and the operation is embedded in the delete DF. The command is divided into two categories: delete DF and delete EF. Deleting the DF function only deletes the DF file without the child DF file. If the deleted DF has a direct child DF file (you can have an EF file), the DF cannot be deleted directly. You need to delete the child DF file first, and then delete it with this function. This operation will affect its parent node or sibling node and child EF node, so you need to check the file open table before deleting, check whether these files are accessible, and if there are nodes that cannot be accessed, exit and return the corresponding error message.
Of course, before performing this operation, a certain required security state must be achieved. When the EF is deleted, the operation object is the current working file EF in the CMB block, so you need to select the file before deleting an EF. If the current working file address is invalid, the corresponding error message is returned. Of course, before performing this operation, a certain required security state must be reached and the EF has a deletable attribute.
4) The VERIFY command is used to compare the secret object transmitted to the smart card with the stored reference value, and change the security status in the CMB block according to the comparison result. The key of the operating system is stored in the key file KEF, and the KEF located in the MF is used as a common key for all applications in the smart card. If it is the KEF of the DF, it can only be used for related applications in the DF, ie The private key of the app.
The operation object of this command defaults to the currently used key file pointed to in the CMB block. A typical key file contains four keys, which are:
(1) Browse key: After the key is satisfied, all EF files and sub-DF headers in the directory can be read.
(2) Update key: After the key is satisfied, the update operation can be performed in all EF files in the directory.
(3) Delete key: After the key is satisfied, the delete operation can be performed in this directory.
(4) Create operation: After the key is satisfied, the delete operation can be performed in the directory. Therefore, the verify function determines that it satisfies the corresponding key, and then changes the security state in the CMB block so that it can be executed after execution.
There is one retry counter for each key. It is assigned zero for a positive comparison and incremented by 1 for a negative comparison. If the retry counter reaches a large value, there is absolutely no possibility to make further comparisons of the keys. To ensure security, first add one to the counter field and write it to the record. Then compare whether the read key and the input key match. The match writes 0 to the counter field of the record and sets the security status to the OK result status. Otherwise, set the security status to the NOK result status and return the remaining number of allowed attempts or the record is locked.
3 Conclusion
This paper studies and designs a dynamic multi-application smart card file system. Use the file allocation table to map each file, use CMB blocks for file management, set the file access mechanism to ensure the read and write security of each application, and finally design the file operation commands in detail, so that the application can create and delete files. .