SeHAL-based open architecture on-chip operating system and management method thereof

Abstract

The invention discloses an open-type architecture on-chip operating system based on SeHAL and a management method of the open-type architecture on-chip operating system based on SeHAL. The system comprises a system base used for hardware initialization and driving; the security hardware abstraction layer is used for providing a unified standardized hardware interface, application loading management and maintenance of an application index list for an upper layer; and at least one application module which can be independently compiled and loaded. Hardware isomerism is shielded through SeHAL, flexible registration and routing of applications are realized in combination with a structured application index list, and application modules can be dynamically loaded and managed in an independent and safe manner, so that multi-application flexible support and cross-platform deployment capability comparable to Java COS are obtained while high efficiency and light weight of Native COS are kept, and the method has the advantages of being high in practicability and easy to popularize. And the adaptability and the development efficiency of the security chip in a complex multi-service scene are remarkably improved.

Description

Technical Field

[0001] This invention relates to an open architecture on-chip operating system based on SeHAL (Secure Hardware Abstraction Layer), and also to a method for implementing application management on the on-chip operating system, belonging to the field of embedded system technology. Background Technology

[0002] With the rapid development of the Internet of Things, mobile payment, digital identity, and other fields, the demand for hardware-level security in various smart terminals and systems is becoming increasingly urgent. As the physical foundation for building a trusted computing environment, the functionality of a security chip highly depends on its built-in Chip Operating System (COS). A COS is a highly streamlined and security-oriented embedded system designed for resource-constrained environments. Its core responsibilities include managing chip hardware resources, performing cryptographic operations, and parsing and responding to external application protocol data unit instructions.

[0003] Currently, mainstream COS implementations fall into two main technical categories: Java COS and Native COS. For example... Figure 1 As shown, JavaCOS is based on the Java Card Virtual Machine, and its open architecture supports independent application development and cross-platform deployment in the form of applets, offering good flexibility. However, the virtual machine's interpreted execution mechanism brings significant performance and resource overhead, including slow instruction execution and large storage space consumption, making it difficult to efficiently handle various complex business processes on typical single-core, small-memory security chip hardware. Furthermore, differences in JCVM implementations among different chip manufacturers mean that applications still face heavy adaptation work during actual deployment. For example... Figure 2 As shown, Native COS is developed directly using the C language, with applications tightly coupled to the underlying system drivers, offering advantages such as high execution efficiency and low resource consumption. However, this tightly coupled architecture requires applications to be compiled, solidified, and burned uniformly with the system base, making the entire on-chip operating system completely closed after leaving the factory. It is impossible to dynamically add, delete, or update any business applications after card issuance, severely lacking openness and flexibility, and making it difficult to adapt to rapidly changing multi-business scenario requirements.

[0004] To maintain the efficiency of native COS while enhancing flexibility, the industry has made improvements. For example, Chinese patent CN106127092B discloses a smart card with application separation in a COS system and its working method. The core concept of this technical solution is to separate the functions related to user customization needs in traditional COS into independent "customized application modules," which interact with the core COS system through "application interface modules" and "shared variable libraries." This design reduces the coupling between applications and underlying hardware to a certain extent, supports independent application development and online updates, and represents an important step towards an "open" architecture. However, this technical solution has a fundamental architectural limitation: its system and customized applications are deeply bound together through specific calling mechanisms and shared data interaction methods. This design determines that it can essentially only support and manage a single customized application. When a security chip needs to support multiple independent security services simultaneously (e.g., handling mobile policing, police wireless LAN encryption, and law enforcement recorder data protection in a single police terminal), this architecture cannot achieve isolation, parallelism, and flexible switching between multiple applications. Furthermore, its application interface lacks a unified and secure abstraction of the hardware cryptographic algorithm engine. If different applications need to call security functions, they may still be involved in low-level details, and the portability and adaptation problems caused by hardware heterogeneity have not been completely solved. Summary of the Invention

[0005] The primary technical problem to be solved by this invention is to provide an open architecture on-chip operating system based on SeHAL.

[0006] Another technical problem to be solved by the present invention is to provide a method for implementing application management in the above-mentioned on-chip operating system.

[0007] To achieve the above-mentioned technical objectives, the present invention adopts the following technical solution: According to a first aspect of the present invention, an open architecture on-chip operating system based on a security hardware abstraction layer is provided, comprising: The system base, deployed on the security chip, is used to initialize and drive the hardware resources of the security chip and provide the operating environment; The security hardware abstraction layer, connected to the system base, is used for: a) Provide a unified and standardized functional interface for upper-layer applications to access the cryptographic algorithm engine and storage resources of the security chip; b) Provides application loading management functions, supporting the secure loading of independently compiled applications into the storage space of the security chip and integrating them into the runtime environment of the on-chip operating system; c) Maintain an application index list to route to the corresponding installed application based on the application identifier in an external command; At least one application module implements business logic by calling the standardized function interface of the security hardware abstraction layer; The application module is compiled, encrypted, loaded, and unloaded independently of the system base and the security hardware abstraction layer.

[0008] Preferably, the security hardware abstraction layer includes: The security function module is used to abstract and manage the cryptographic algorithm hardware engine of the security chip and provide a cryptographic operation interface; The container function module is used to implement an embedded file system and manage the storage space of the security chip in a partitioned and containerized manner to isolate and store critical information of different applications. The interactive instruction module is used to verify and distribute application protocol data unit instructions from external sources, and send back responses. The application management module is used to perform secure loading, verification, status management, and runtime environment configuration of the application modules.

[0009] Preferably, the application index list is a data structure stored in a fixed storage area of ​​the security chip, and each entry is an application index triplet, which includes at least: application instruction code, application status identifier and application entry address.

[0010] Preferably, the application status identifier is used to indicate whether the corresponding application module is in an available state; the application entry address points to the storage start location of the corresponding application module and is used to locate the function pointer list of the application module.

[0011] Preferably, the application module is independently compiled and encrypted into a protected application file before loading; when the application management module of the security hardware abstraction layer is loaded, it uses a key shared with the system to decrypt and verify the integrity of the protected application file.

[0012] Preferably, the application module contains a list of function pointers to sequentially store the entry addresses of all instruction processing functions in the application module; the instruction processing functions have a unified calling interface specification.

[0013] Preferably, the unified API call specification is as follows: Where pInPara is the starting address of the input data, InLenPara is the length of the input data, pOutPara is the output data, and pOutLenPara is the length of the output data; Both the input data and the output data are concatenated in TLV format to ensure the normalization of the interface function format and avoid the influence of parameter differences.

[0014] According to a second aspect of the present invention, a method for implementing application management in the above-described on-chip operating system is provided, comprising the following steps: Receive application loading instructions and encrypted application module files; The encrypted application module file is securely decrypted and verified through the security hardware abstraction layer. The decrypted and verified application module code is written into the dedicated application-bearing storage space allocated to the application module. Update the application index list, create a corresponding application index triplet for the application module, and set the status flag to available to complete the secure loading and activation of the application.

[0015] According to a third aspect of the present invention, a method for implementing instruction processing in an on-chip operating system as described above is provided, comprising the following steps: The security hardware abstraction layer's interactive instruction module receives and verifies APDU instructions from the host computer. Extract the application instruction code from the verified APDU instruction; The application entry address and status identifier of the target application module are obtained by querying the application index list based on the application instruction code. If the status identifier is available, then the function pointer list of the target application module is located according to the application entry address; According to the operation instruction code in the APDU instruction, the corresponding instruction processing function is called from the function pointer list to execute the instruction. The instruction processing function completes the business operation by calling the standardized function interface of the security hardware abstraction layer. The execution result is encapsulated into an APDU response by the interactive instruction module and sent back to the host computer.

[0016] Preferably, before the step of calling the corresponding instruction processing function to execute the instruction, the method further includes: Invoke initialization instructions to initialize the internal state of the target application module and mount its list of function pointers.

[0017] Compared with existing technologies, the open architecture on-chip operating system provided by this invention effectively overcomes the dual shortcomings of traditional Java COS, such as high hardware resource consumption and low execution efficiency due to virtual machines, and the deep coupling and inflexibility of Native COS applications and systems. By introducing SeHAL to shield the heterogeneity of the underlying hardware and provide standardized interfaces for applications, and combining it with the Application Index List (AIL) to realize modular registration and routing management of applications, this on-chip operating system enables applications to be loaded and updated in an independently compiled and securely encrypted manner. Thus, while maintaining the high efficiency and lightweight resource consumption of Native COS, it achieves flexible support for multiple applications and cross-platform deployment capabilities similar to Java COS, significantly improving the adaptability, development efficiency, and overall security of security chips in complex multi-business scenarios. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the software architecture of Java COS in the existing technology; Figure 2 This is a schematic diagram of the software architecture of Native COS in the existing technology; Figure 3 This is a schematic diagram of the structure of an open architecture on-chip operating system based on SeHAL, as described in an embodiment of the present invention. Figure 4 This is a spatial distribution diagram of the security chip code in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the calling relationship between the security hardware abstraction layer and the application layer in an embodiment of the present invention; Figure 6 This is a flowchart illustrating the operation of an open architecture on-chip operating system based on SeHAL, as described in this embodiment of the invention. Figure 7 This is a schematic diagram of the on-chip operating system implemented using the CCM3304-H chip in an embodiment of the present invention; Figure 8 This is a schematic diagram of the data structure and memory layout of the Application Index List (AIL) in an embodiment of the present invention; Figure 9 This is a flowchart illustrating the operation of the on-chip operating system implemented using the CCM3304-H chip in an embodiment of the present invention. Detailed Implementation

[0019] The technical content of the present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0020] like Figure 3As shown in the figure, an open architecture on-chip operating system based on a security hardware abstraction layer (SeHAL) is provided in this embodiment of the invention, including: a system base, a security hardware abstraction layer (SeHAL), an application index list (AIL), and application modules.

[0021] After the system base completes system and hardware IP initialization, it provides a stable operating environment for the security hardware abstraction layer. The security hardware abstraction layer shields southbound hardware heterogeneity through a unified interface. After receiving function call requests from application modules, it distributes the requests to the corresponding sub-modules. The system base then invokes the security chip's cryptographic algorithm IP, storage resources, and other hardware capabilities to execute instructions. Application modules implement functions by calling standardized interfaces released by the security hardware abstraction layer. APDU instructions from the host computer are verified and distributed by the security hardware abstraction layer's interactive instruction module. The system then locates the target application module through the application index list. After executing the instructions, the application module feeds back the results to the host computer via the security hardware abstraction layer.

[0022] In one embodiment of the present invention, the system base is composed of C language and assembly instructions. Its core function is to provide a stable and reliable hardware operating foundation for the upper-layer modules, ensuring that the system can be initialized normally and drive each hardware IP to work after power-on. In the system architecture of the present invention, the system base is located at the bottom layer and interacts directly with the hardware resources of the security chip.

[0023] In one embodiment of the present invention, the specific functions of the system base include two aspects: First, system initialization operations. After the COS is powered on, the initialization configuration of core modules such as the system stack, cache, and MPU (memory protection unit) is completed. Stack initialization is used to allocate the memory space required for system operation, clarify the stack bottom and stack top addresses, and ensure the orderly allocation of memory space for operations such as function calls and local variable storage. Cache initialization reduces the CPU's memory access latency and improves instruction execution efficiency by enabling the caching mechanism, especially for frequently called cryptographic algorithm instructions in security chips, which can significantly improve processing speed. MPU initialization is used to divide the access permissions of memory areas, setting different read and write permissions for different areas such as the system base area, critical information storage area, and application hosting area to prevent unauthorized access and data tampering, and ensure system memory security. Second, hardware IP configuration and initialization, including chip clock control, power consumption control, DMA (direct memory access) configuration, and IO driver initialization. Clock control provides a stable clock signal to each hardware module by configuring the chip's clock source and division factor, ensuring that modules such as the cryptographic algorithm IP and storage controller operate at preset frequencies. Power consumption control dynamically adjusts hardware power consumption based on system operating status, reducing power consumption when applications are idle and ensuring stable power supply during high-intensity operations, balancing energy saving and performance. DMA configuration allows hardware modules to directly transfer data with memory without CPU intervention, improving data transfer efficiency, especially suitable for reading and writing large amounts of data during cryptographic algorithm operations. IO driver initialization completes the interface driver configuration between the security chip and external devices, ensuring the normal reception and response of APDU instructions, providing hardware support for communication between the host computer and the security chip.

[0024] The initialization and configuration of the system base are prerequisites for the operation of the entire operating system, and its stability directly determines the functionality of upper-layer modules. Without the support of the system base, the security hardware abstraction layer cannot access hardware resources, and the functions of application modules cannot be implemented. Therefore, the system base is a key hub for the interaction between system hardware and software, providing a solid hardware foundation for the entire operating system.

[0025] In one embodiment of the present invention, the security hardware abstraction layer is located between the system base and the application module. Its core function is to shield the heterogeneity of southbound chips, provide a normalized standardized interface for northbound applications, support the multi-application extension of COS, and at the same time have the three major characteristics of security, openness, and customizability. It solves the solidification problem of Native COS and avoids the resource consumption defects of Java COS.

[0026] In one embodiment of the present invention, the security hardware abstraction layer consists of four modules, and the specific functions of each module are as follows: Security Function Module: The core function of this module is to manage the cryptographic algorithm IPs of the security chip, abstracting the underlying hardware logic into specific algorithm function interfaces for upper-layer applications. The security chip has a built-in hardware cryptographic algorithm engine that supports domestic commercial cryptographic algorithms such as SM1, SM2, SM3, and SM4, as well as internationally recognized algorithms like AES and RSA. Through unified management of these algorithm IPs, the security function module shields the hardware implementation differences between different algorithms, providing standardized algorithm call interfaces to the upper layer. Examples include the SM1 symmetric encryption / decryption interface, the SM2 asymmetric encryption / decryption and signature verification interface, and the SM3 hash interface. During application development, there is no need to concern oneself with the hardware implementation details of the algorithms; simply calling the interfaces provided by the security hardware abstraction layer is sufficient to complete secure operations such as encryption, decryption, signing, and verification. This reduces the difficulty of application development and ensures the consistency of algorithm calls. Simultaneously, this module also performs security monitoring of the algorithm call process to prevent unauthorized calls or abnormal algorithm execution, ensuring the security of data processing.

[0027] Container Function Module: The core of this module is to implement an embedded file system, managing storage space through partitioned containerization. It is primarily used to store critical information such as certificates and keys, and provides standardized function interfaces for upper-layer applications to call. For example... Figure 4 As shown, in the security chip's code space, a critical information storage area is specifically used to store structured critical information. The container module manages this area, partitioning and isolating keys and certificates for different applications to prevent cross-access of critical information between applications, thus ensuring data confidentiality and integrity. This module supports key generation, storage, updating, and destruction, as well as certificate import, storage, updating, and export operations. Applications can manage critical information simply by calling the corresponding interfaces, without needing to concern themselves with the underlying file system implementation. For example, keys for mobile policing applications and police wireless LAN applications are stored in different container partitions. Even if one application is attacked, it will not lead to the leakage of critical information in other applications, significantly improving the system's security isolation.

[0028] Interactive Command Module: The core function of this module is to perform command validity verification, distribution processing, and response feedback after the security chip receives APDU commands from the host computer. As the basic data unit for communication between the smart card and the terminal device, the format and content validity of the APDU directly affect system security. This module first verifies the format of the received APDU command, checking whether the command length and command fields conform to the specifications. If the format is invalid, an error response is returned directly. Secondly, it verifies the command permissions, determining whether the operation corresponding to the command is within the application's permission scope to prevent unauthorized operations. After successful verification, based on the CLA (Application Command Code) field in the command and the mapping relationship of the application index list (as shown in Table 1), the command is distributed to the corresponding application. After the application executes the command, this module encapsulates the execution result in APDU format and sends it back to the host computer, ensuring the integrity and reliability of the communication link.

[0029] Table 1. Mapping relationship between application instruction codes and application indices Application Management Module: The core function of this module is to load and verify upper-layer application modules during the loading process. It is a key functional module for enabling flexible loading of independent application modules. This module supports the separate compilation and loading of application modules without needing to be compiled together with the system base and security hardware abstraction layer, thus solving the problem of Native COS application solidification. During the application loading process, this module uses domestic commercial cryptographic algorithms to encrypt and verify application files, combined with the PSK shared key mechanism, to ensure the legitimacy of the application module's identity and the security of the loading process, preventing malicious applications from being loaded into the system. Simultaneously, this module is also responsible for maintaining the loading status of application modules. After the application is loaded, it updates the corresponding application status identifier in the Application Index List (AIL) to 0x5A (available status), as shown in Table 2, which illustrates the correspondence between application activation identifiers and application statuses. If loading fails or the application is invalid, the status identifier is set to 0xFF (unavailable status), ensuring that the system only runs legitimate applications.

[0030] Table 2. Correspondence between application activation identifier and application status Furthermore, the security hardware abstraction layer also features customizability: on the one hand, based on a layered and modular structural design, some sub-functions of the security function module and container function module, except for the interaction command module, can be tailored according to the actual application scenario. For example, in scenarios where the SM2 asymmetric algorithm is not required, the interface corresponding to the algorithm can be tailored; on the other hand, the types of commands supported by the standard command interaction interface can be expanded or tailored according to the business functions of the corresponding application module to meet the personalized needs of different industry scenarios and improve the system's adaptability and flexibility.

[0031] In one embodiment of the present invention, the Application Index List (AIL) is a key index module connecting the security hardware abstraction layer and application modules. It is fixed in a specific area of ​​the embedded Flash memory within the security chip, and its storage area is independent of the system base area and application-bearing area, ensuring the stability and security of the index information. The core function of this table is to enable rapid location, status management, and instruction mapping of application modules, providing a basis for upper-layer instruction distribution.

[0032] The Application Index List (AIL) consists of several application index triples. Each application index triple has the structure {application instruction code, application status identifier, application entry address}, and each triple occupies 8 bytes, with the application instruction code and application status identifier each occupying 2 bytes, and the application entry address occupying 4 bytes. The specific functions of each field are as follows: Application Instruction Code: This field corresponds to the instruction category (CLA) of the application module. Its mapping to the application index follows the rules shown in Table 1 above. For example, CLA = 0xA0 corresponds to application index 1, CLA = 0xA1 corresponds to application index 2, and so on. A maximum of 8 application module index mappings are supported. This field establishes the association between the host computer instruction and the target application module. The host computer can quickly locate the corresponding application module through the application index list (AIL) using the CLA field in the APDU instruction, providing a basis for instruction distribution.

[0033] Application Status Identifier: This field indicates the availability of an application module and is categorized as either unavailable (0xFF) or available (0x5A). It is maintained by the application management module of the security hardware abstraction layer. The field is updated to 0x5A upon successful application module loading and to 0xFF upon unloading or invalidation. Before executing host computer instructions, COS checks this field to determine application module availability. If the module is unavailable, it directly returns an error code, preventing invalid instruction execution and improving system efficiency.

[0034] Application entry address: Used to locate the address of each instruction processing function interface in the corresponding application module. The application entry address of each application module points to the starting storage location of the application module in the application hosting area. Through this address, the function pointer list (FPT) of the application module can be located, and then the corresponding instruction processing function can be found according to the INS (operation instruction code) field in the APDU instruction, so as to achieve precise execution of the instruction.

[0035] The existence of the Application Index List (AIL) enables the system to quickly manage and schedule multiple application modules, locating the target application module without traversing the entire application hosting area, significantly improving instruction distribution efficiency. Meanwhile, its fixed storage area and structured design ensure the security and reliability of the index information, preventing index tampering that could lead to application module location failures or instruction distribution errors.

[0036] In one embodiment of the present invention, the application module is a functional implementation carrier of the operating system, used to implement several independent business security functions. For example... Figure 5 As shown, the application module completes various business operations by calling the standardized interface of the security hardware abstraction layer. It also has three major characteristics: isolation, independence, and low-level independence, which solves the problem of insufficient multi-application support in traditional COS systems.

[0037] The specific functions and features of the application modules are as follows: Isolation includes both software and hardware isolation. In terms of software isolation, application modules do not call each other; each application module's business logic is implemented independently, with no function calls or data sharing, preventing logical errors in one application module from affecting the operation of other application modules. In terms of hardware isolation, each application module is stored in an independent space within the application hosting area. The application hosting area allocates a dedicated storage area for each application module, preventing cross-contamination. Through MPU memory permission management, it prevents application modules from accessing the storage areas of other application modules beyond their boundaries, ensuring the security of application data.

[0038] Independence: Each application module is compiled, encrypted, loaded, and unloaded independently of the system base and the security hardware abstraction layer. After the application module is developed, it is compiled and packaged into a bin file using a toolchain, encrypted by a host computer tool to generate a cpkg file, then decrypted by the application management module of the security hardware abstraction layer and burned to the application hosting area. Finally, the application status flag in the application index list (AIL) is updated to complete the loading. This independent deployment method makes the addition or removal of application modules independent of the system base, eliminating the need to re-burn the entire operating system, greatly improving the flexibility of application deployment. For example, when adding a law enforcement recorder data encryption application, there is no need to modify the existing police wireless LAN application; it can be loaded directly.

[0039] Underlying Independence: Each application module contains only independent business logic, calling the interfaces of various functional modules released by the Security Hardware Abstraction Layer (HHBL) and receiving interactive commands distributed by the HHBL, without needing to concern itself with the specific implementation of the underlying hardware. Each application module can also iteratively self-call based on its business logic, supporting complex business logic. Because the HHBL shields the heterogeneity of southbound chips, the same application module can run on security chips with different instruction architectures and hardware configurations, achieving "develop once, deploy on multiple platforms." For example, a mobile policing application developed for a specific security chip can be directly deployed to other security chips running the same operating system without modifying the code, significantly reducing application development and adaptation costs.

[0040] Each application module, during development, requires two core components in addition to business logic implementation: First, a Function Pointer List (FPT). The FPT, organized in 4-byte units, stores pointers to all processing functions within the module. The order of instructions in the FPT increases sequentially based on the size of the operation instruction code (INS), facilitating quick function lookup. Second, dedicated memory space, exclusively for the application module and not shared by the system base or other application modules, ensuring sufficient memory resources for runtime. Before execution, the application module must call the initialization instruction `PCOS_Init App` to initialize its internal state machine and variables, and attach the FPT, preparing for instruction execution.

[0041] It should be noted that the application files in this embodiment of the invention include two forms: bin files and cpkg files. A bin file refers to an independent binary file generated after compiling and packaging the application business logic code. A cpkg file refers to a protected application file generated after encrypting the bin file.

[0042] like Figure 6 As shown below, the operating principle of the open architecture on-chip operating system provided by this invention will be explained: S1: The system base completes the initialization configuration of the system stack, cache, MPU and various hardware IPs, providing hardware support for upper-layer modules.

[0043] S2: Enable secure application loading process.

[0044] S3: Call the initialization instruction to initialize all loaded application modules, including resetting the internal state machine of the application module, initializing variables, and mounting the function pointer list (FPT), ensuring that the application module is in a ready state.

[0045] S4: Receives APDU commands sent by the host computer. These commands contain core information such as CLA (Application Code), INS (Operation Code), and data fields.

[0046] S5: The APDU command is transmitted to the interactive command module of the security hardware abstraction layer. This module first performs a legality check on the command, including format check and permission check. If the instruction verification fails, the interactive instruction module directly encapsulates the error response data and sends it back to the host computer through the IO interface, thus terminating the process. If the instruction verification passes, the interactive instruction module extracts the CLA field from the APDU instruction, queries the application index list (AIL), and finds the corresponding application index triplet based on the mapping relationship between application instruction codes and application indexes shown in Table 1.

[0047] S6: Read the application status identifier field in the application index triplet to determine whether the application module is available (if the status identifier is 0x5A, it is available; if it is 0xFF, it is unavailable). If the application status is marked as unavailable, the interactive instruction module encapsulates the "application unavailable" error response data and sends it back to the host computer, terminating the process. If the application status is marked as available, the application entry address is extracted from the application index triplet. This address is used to locate the starting storage location of the application module in the application hosting area, and the function pointer list (FPT) of the application module is found.

[0048] S7: Extract the INS field from the APDU instruction, and find the instruction processing function pointer corresponding to the INS according to the rule that the instruction order in the Function Pointer List (FPT) corresponds to the incrementing size of the INS.

[0049] S8: After the instruction is executed, the processing function writes the execution result to the output parameter and returns to the interactive instruction module of the security hardware abstraction layer.

[0050] S9: The interactive instruction module encapsulates the output parameters in APDU response format and sends them back to the host computer through the IO interface to complete one instruction interaction process. If the host computer continues to send new APDU instructions, return to step S4 and repeat the execution; If no new instruction is received, it enters a low-power standby state, waiting for the next instruction to be triggered.

[0051] In one embodiment of the present invention, the application security loading process in step S2 includes the following steps: S21: Compile and package the application module's business logic code to generate an independent bin file, ensuring the integrity and independence of the application code.

[0052] S22: Encrypt the bin file to generate an encrypted cpkg file to prevent the application from being stolen or tampered with during transmission or storage.

[0053] S23: Decrypt the cpkg file using the shared key, restore it to the original bin file, and burn the decrypted bin file to the dedicated storage space allocated to this application module in the application hosting area.

[0054] S24: After burning is complete, the status flag of the corresponding application module in the application index list (AIL) is automatically modified from unavailable (0xFF) to available (0x5A), thus completing the secure activation of the application module.

[0055] In step S7, the processing function uses a unified interface format: ; Where pInPara is the starting address of the input data, InLenPara is the length of the input data, pOutPara is the output data, and pOutLenPara is the length of the output data. Both the input and output data are concatenated in TLV format to ensure the interface function format is normalized and to avoid the influence of parameter differences.

[0056] The application module's instruction processing function completes business logic execution (such as data encryption, key query, certificate verification, etc.) by calling standardized function interfaces such as security function modules and container function modules of the security hardware abstraction layer.

[0057] The working principle of the on-chip operating system will be explained again below, using the CCM3304-H chip as an example: The CCM3304-H chip is a domestically produced security chip. It has a built-in 32-bit domestic CPU and features strong processing performance and large storage space.

[0058] like Figure 7 As shown, the application module of the open architecture on-chip operating system based on the CCM3304-H chip includes three applications (APP1, APP2, and APP3). Therefore, its Application Index List (AIL) has three sets of application index triples, and the mapping relationship between the corresponding application instruction code, application index, and instruction type INS is shown in Table 3.

[0059] Table 3 Instruction Mapping Relationship The Application Index List (AIL) consists of multiple sequentially stored application index triples. For example... Figure 8 As shown, three triples are listed, corresponding to three loaded application modules: APP1, APP2, and APP3.

[0060] Each application index triple has a uniform and fixed format, and its memory arrangement from left to right contains the following fields: Application instruction code: occupies bytes 1-2. Figure 8 The example values ​​are 0xA0 (APP1), 0xA1 (APP2), and 0xA2 (APP3). These code values ​​correspond to the CLA field in the APDU instruction and are used to uniquely identify and address an application module.

[0061] Application status identifier: occupies bytes 3-4. Figure 8 The example values ​​are all 0x5A, indicating that the corresponding application modules are all in an "available" state.

[0062] Application entry address: occupies several subsequent bytes ( Figure 8 (Illustrated by "FPT BaseAddr"). This address points to the starting storage location of the function pointer list (FPT) of the corresponding application module in the application hosting area. For example, the entry address of APP1 points to the base address of its FPT.

[0063] Figure 8 This demonstrates the core function of the Application Index List (AIL): as a system-level fixed index table, it efficiently and accurately maps the logical address (CLA) of external instructions to the physical entry point of the executable code of internal application modules through the structured data unit {application instruction code, application status identifier, application entry address}. It is a key data structure foundation for realizing flexible management of multiple applications and fast instruction routing.

[0064] like Figure 9 As shown, the operating principle of the open architecture on-chip operating system based on the CCM3304-H chip is as follows: S01: The CCM3304-H security chip is powered on, and the system base starts initialization, completing the configuration of the system stack (stack address 0x0023D000~0x0023FFFF), cache, and MPU. At the same time, it initializes hardware IPs such as chip clock (main frequency is 100MHz), power consumption control (normal operation mode), DMA controller, and IO interface (UART interface, baud rate 115200). After initialization, it enters the system ready state.

[0065] S02: Call the initialization instruction PCOS_Init App to initialize APP1, APP2, and APP3 in sequence: reset the internal state machine of each application module to the initial state, initialize application variables (such as key cache, data buffer, etc.), and mount the function pointer list (FPT) of each application module. The function pointer list (FPT) of APP1 is stored in 0x000B7800~0x000B7880, the function pointer list (FPT) of APP2 is stored in 0x000BF800~0x000BF880, and the function pointer list (FPT) of APP3 is stored in 0x000C7800~0x000C7880.

[0066] S03: The host computer (such as a police wireless LAN gateway, mobile police terminal, or law enforcement recorder) sends APDU commands through the UART interface, such as sending the command "CLA=0xA0, INS=0x05, P1=0x00, P2=0x00, Lc=0x10, Data=police terminal identity information, Le=0x04", to request APP1 to perform identity authentication.

[0067] S04: The security chip's IO interface receives the APDU instruction and transmits it to the interactive instruction module of the security hardware abstraction layer.

[0068] S05: The interactive instruction module performs a validity check on the received APDU instruction: First, it checks the format and confirms the instruction length (Lc=0x10, Data field 16 bytes, which meets the APDU format requirements); second, it checks the permissions and confirms that APP1 corresponding to CLA=0xA0 has the authentication permissions, and the verification passes.

[0069] S06: The interactive instruction module extracts CLA=0xA0 from the instruction, queries the application index list (AIL) (stored at addresses 0x00085800~0x0008583F), and finds the triple {0xA0, 0x5A, 0x000B7800} corresponding to application index 1 according to the mapping relationship in Table 1.

[0070] S07: Read the application status identifier in the triplet as 0x5A (available), and extract the application entry address 0x000B7800.

[0071] S08: Extract INS=0x05 from the instruction. According to the function pointer list (FPT) order of APP1 (INS increments from 0x01 to 0x10), find the 5th function pointer in the function pointer list (FPT) (address 0x000B7814). This pointer points to the authentication processing function.

[0072] S09: Adhere to the unified interface format The system calls the identity authentication processing function, where pInPara points to the Data field (police terminal identity information), InLenPara = 0x10, pOutPara points to the output buffer (address 0x00201000), and pOutLenPara points to the output length variable. S010: The identity authentication processing function calls the SM3 hash interface of the security function module of the security hardware abstraction layer to perform a hash operation on the identity information of the police terminal and obtain a 16-byte hash value.

[0073] S011: Call the key storage interface of the security hardware abstraction layer container function module to read the authentication key of APP1 (stored in the critical information storage area 0x00085840~0x000B77FF).

[0074] S012: The identity authentication processing function compares the hash value with the authentication key; If they match, the authentication is successful, and “0x0000” (authentication success identifier) ​​is written to the output buffer, with the output length set to 0x04; If there is a discrepancy, write "0x0001" (authentication failure flag).

[0075] S013: After the authentication processing function is completed, the output buffer data and output length are returned to the interaction instruction module of the security hardware abstraction layer.

[0076] S014: The interactive instruction module encapsulates the data according to the APDU response format and obtains the response instruction "SW1=0x90, SW2=0x00, Data=0x0000" (authentication successful), which is then sent back to the host computer via the UART interface.

[0077] S015: The host computer receives the response command and confirms that the identity authentication is successful. Data transmission can then be carried out via APP1 for the police wireless LAN. If the host computer sends a command for APP2 or APP3, such as "CLA=0xA1, INS=0x15" (data encryption command for APP2), the process repeats steps S03 to S014, locates APP2 through the application index list (AIL), calls the corresponding encryption processing function, completes the data encryption operation and returns the result; If the host computer sends an illegal command (such as CLA=0xA3, no corresponding application), the interactive command module will return an error response of "SW1=0x6E, SW2=0x00" (application not found) after verification; if the application status is 0xFF (such as APP3 not loaded), it will return an error response of "SW1=0x69, SW2=0x85" (application unavailable).

[0078] It should be noted that the above embodiments are merely illustrative examples. The technical solutions of each embodiment can be combined, and all are within the protection scope of this invention.

[0079] The above provides a detailed description of the SeHAL-based open architecture on-chip operating system and its management method provided by this invention. Any obvious modifications made by those skilled in the art without departing from the essence of this invention will constitute an infringement of the patent rights of this invention and will incur corresponding legal liability.

Claims

1. An open architecture on-chip operating system based on a secure hardware abstraction layer, characterized in that... include: The system base, deployed on the security chip, is used to initialize and drive the hardware resources of the security chip and provide the operating environment; The security hardware abstraction layer, connected to the system base, is used for: a) Provide a unified and standardized functional interface for upper-layer applications to access the cryptographic algorithm engine and storage resources of the security chip; b) Provides application loading management functions, supporting the secure loading of independently compiled applications into the storage space of the security chip and integrating them into the runtime environment of the on-chip operating system; c) Maintain an application index list to route to the corresponding installed application based on the application identifier in an external command; At least one application module implements business logic by calling the standardized function interface of the security hardware abstraction layer; The application module is compiled, encrypted, loaded, and unloaded independently of the system base and the security hardware abstraction layer.

2. The on-chip operating system as described in claim 1, characterized in that... The security hardware abstraction layer includes: The security function module is used to abstract and manage the cryptographic algorithm hardware engine of the security chip and provide a cryptographic operation interface; The container function module is used to implement an embedded file system and manage the storage space of the security chip in a partitioned and containerized manner to isolate and store critical information of different applications. The interactive instruction module is used to verify and distribute application protocol data unit instructions from external sources, and send back responses. The application management module is used to perform secure loading, verification, status management, and runtime environment configuration of the application modules.

3. The on-chip operating system as described in claim 1, characterized in that: The application index list is a data structure stored in a fixed storage area of ​​the security chip. Each entry is an application index triplet, which includes at least: application instruction code, application status identifier, and application entry address.

4. The on-chip operating system as described in claim 3, characterized in that: The application status identifier is used to indicate whether the corresponding application module is in an available state; the application entry address points to the storage start location of the corresponding application module and is used to locate the function pointer list of the application module.

5. The on-chip operating system as described in claim 1, characterized in that: Before loading, the application module is independently compiled and encrypted into a protected application file; when the application management module of the security hardware abstraction layer is loaded, it uses a key shared with the system to decrypt and verify the integrity of the protected application file.

6. The on-chip operating system as described in claim 1, characterized in that: The application module contains a list of function pointers, which is used to sequentially store the entry addresses of all instruction processing functions in the application module; the instruction processing functions have a unified calling interface specification.

7. The on-chip operating system as described in claim 6, characterized in that... The unified API call specification is as follows: Where pInPara is the starting address of the input data, InLenPara is the length of the input data, pOutPara is the output data, and pOutLenPara is the length of the output data; Both the input data and the output data are concatenated in TLV format to ensure the normalization of the interface function format.

8. A method for implementing application management using an on-chip operating system as described in any one of claims 1 to 7, characterized in that... Includes the following steps: Receive application loading instructions and encrypted application module files; The encrypted application module file is securely decrypted and verified through the security hardware abstraction layer. The decrypted and verified application module code is written into the dedicated application-bearing storage space allocated to the application module. Update the application index list, create a corresponding application index triplet for the application module, and set the status flag to available to complete the secure loading and activation of the application.

9. A method for implementing instruction processing using an on-chip operating system according to any one of claims 1 to 7, characterized in that... Includes the following steps: The security hardware abstraction layer's interactive instruction module receives and verifies APDU instructions from the host computer. Extract the application instruction code from the verified APDU instruction; The application entry address and status identifier of the target application module are obtained by querying the application index list based on the application instruction code. If the status identifier is available, then the function pointer list of the target application module is located according to the application entry address; According to the operation instruction code in the APDU instruction, the corresponding instruction processing function is called from the function pointer list to execute the instruction. The instruction processing function completes the business operation by calling the standardized function interface of the security hardware abstraction layer. The execution result is encapsulated into an APDU response by the interactive instruction module and sent back to the host computer.

10. The method as described in claim 9, characterized in that... Before the step of calling the corresponding instruction processing function to execute the instruction, the method further includes: Invoke initialization instructions to initialize the internal state of the target application module and mount its list of function pointers.

Images