Method and system for constructing a trusted container of a kylin system in a cryptographic chip

Abstract

The application relates to the technical field of computer system security, in particular to a Kirin system endogenous trusted container construction method and system of a cryptographic chip. The method comprises the following steps: integrating a domestic cryptographic chip to a hardware platform of a Kirin system, establishing a high-speed safe communication channel of the cryptographic chip with CPU memory, and initializing and configuring the cryptographic chip when the system starts, including loading a key, setting a national secret algorithm, and configuring a security strategy. The application establishes a hardware-level safe communication channel and performs initialization configuration by deeply integrating the domestic cryptographic chip in the hardware platform of the Kirin system, provides a hardware trust root based on the cryptographic chip for the trusted container construction, and improves the trusted benchmark of the system from the bottom architecture level.

Description

Technical Field

[0001] This invention relates to the field of computer system security technology, specifically to a method and system for constructing an intrinsic trusted container for a cryptographic chip within the Kylin system. Background Technology

[0002] Container security mechanisms primarily rely on software-level access control and encryption. However, when faced with attacks such as malicious code injection and system vulnerability exploitation, they struggle to breach the trust boundaries of the software stack itself, highlighting insufficient isolation between containers. While domestically produced cryptographic chips demonstrate advantages in hardware-level security, their application in current technologies remains largely peripheral and auxiliary, failing to achieve deep architectural integration with the operating system. This is particularly true in container environments, where an intrinsic security system encompassing hardware roots of trust and application-level security policies has not yet been established. The key technical challenge in the field of computer system security is how to deeply integrate the hardware-level encryption capabilities of domestically produced cryptographic chips with the underlying architecture of the Kylin operating system to build a trusted execution environment with hardware-level encryption isolation at the container level. This would enable refined security protection for critical application data throughout its storage, transmission, and processing lifecycle. Summary of the Invention

[0003] This disclosure proposes a method and system for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system, aiming to overcome at least one of the defects existing in the prior art.

[0004] To achieve the above objectives, the technical solution disclosed in this invention is as follows:

[0005] According to one aspect of this disclosure, a method for constructing an intrinsically trusted container for a cryptographic chip in a Kylin system is provided, comprising the following steps:

[0006] The domestically produced cryptographic chip is integrated into the hardware platform of the Kylin system, a high-speed and secure communication channel is established between it and the CPU memory, and the cryptographic chip is initialized and configured when the system starts up, including loading the key, setting the national cryptographic algorithm, and configuring the security policy.

[0007] Based on the containerization technology of the Kylin system, a basic trusted container template is created, pre-installed with cryptographic chip drivers and encryption libraries, and security hardening is performed, including disabling unnecessary system services, setting strict file permissions, and configuring firewall rules to reduce the container attack surface and build a secure basic operating environment.

[0008] The critical applications and their dependent environments are encapsulated into the trusted container template, application-sensitive data is encrypted and stored in the secure storage area of ​​the cryptographic chip, and the container's resource limits and security policies are configured.

[0009] The hardware encryption function of the cryptographic chip is used to encrypt and sign the data transmission, storage and processing process within the container in real time, and to monitor the container's operating status in real time to detect abnormal behavior. When an anomaly is detected, security measures are implemented.

[0010] Furthermore, the high-speed secure communication channel is implemented through a dedicated bus or encrypted communication protocol, and the national cryptographic algorithm includes at least one of SM2, SM3, SM4 and SM9. The initialization configuration also includes verifying the firmware integrity of the cryptographic chip through the SM3 hash algorithm, which is used to establish a hardware-level root of trust for the trusted container building system.

[0011] Furthermore, the containerization technology uses Docker or Kata Containers, and the security hardening also includes trimming the operating system kernel of the trusted container template, removing unnecessary modules and services, and enabling the Kylin system's mandatory access control mechanism to perform fine-grained control over file and process access permissions within the container, so as to ensure that the trusted container template only contains the minimal environment required to run critical applications, thereby reducing security risks from the fundamental level.

[0012] Furthermore, the sensitive data includes key certificate user privacy information. The encryption process uses the SM4 symmetric encryption algorithm combined with the SM2 key negotiation mechanism to generate a session key. The encrypted data is written to the internal secure area of ​​the cryptographic chip through its secure storage interface. The resource restrictions are implemented through the cgroups technology of the Kylin system. The security policy also includes whitelist control of container network ports and integrity verification of data transmission to ensure that sensitive data is protected by hardware-level encryption during packaging and deployment, and that resource usage during container runtime complies with security specifications.

[0013] Furthermore, the real-time encryption uses the SM4-CBC mode to encrypt the data stored in the container, and the SM2 algorithm is used to sign and verify the transmitted data. The abnormal behavior detection is achieved by monitoring the system call sequence and process behavior characteristics. When illegal access to the container file system, abnormal network connection or malicious code injection behavior is detected, the relevant process is first frozen and a memory snapshot is generated. The snapshot data is solidified by the SM3 hash algorithm to form an immutable chain of evidence, and a remote alarm is triggered at the same time.

[0014] Furthermore, the method also includes identity authentication and image verification during trusted container creation. After the container creation request is initiated, the caller's identity is authenticated using the SM9 algorithm. After successful authentication, a container key pair is generated. The SM2 key negotiation mechanism is used to interact with the cryptographic chip for key exchange. The container image is subjected to SM3 hash verification to confirm that the image source is trustworthy and has not been tampered with.

[0015] Furthermore, the method also includes a whitelist control mechanism for container processes. A whitelist is established by collecting process behavior characteristics and system call patterns during normal operation. The whitelist is intercepted in real time for the startup of processes not in the whitelist and abnormal system calls. The integrity of the process code segment is measured by the trusted measurement engine of the cryptographic chip to ensure that only certified trusted code can run in the container.

[0016] Furthermore, the container image is encrypted in layers, with different encryption strategies employed for different layers: the base layer, the application layer, and the data layer. The base layer image is hardened by hardware hashing using a cryptographic chip, the application layer code is encrypted and stored using SM4, and sensitive data in the data layer is encrypted using a dynamic session key. At the same time, the integrity of the image is verified by SM2 digital signature during image deployment to ensure that the container image is not tampered with during packaging, transmission, and deployment, and that the granularity of data encryption can be flexibly configured.

[0017] Furthermore, the method also includes a self-healing recovery mechanism for container runtime. When an attack is detected on the container environment and cannot be repaired through real-time protection measures, a container reset process is triggered. A new session key is generated through SM2 key rotation, the container memory data is encrypted and destroyed, a trusted image snapshot is loaded from the secure storage area of ​​the cryptographic chip, the container environment is reinitialized, and the entire process of the attack event is recorded through the security audit module.

[0018] According to another aspect of this disclosure, a system for constructing an intrinsically trusted container for the Kylin system based on a domestically produced cryptographic chip is provided, for implementing the method for constructing an intrinsically trusted container for the Kylin system based on the cryptographic chip as described above, comprising:

[0019] The cryptographic chip management module is used to integrate domestically produced cryptographic chips and perform initial configuration, establish a high-speed and secure communication channel between the chips and the hardware platform, load keys, set national cryptographic algorithms, configure security policies, provide cryptographic chip drivers and encryption libraries, and provide hardware-level cryptographic support and a root of trust.

[0020] The Trusted Container Management module creates and manages trusted container templates based on Kylin system containerization technology, and performs security hardening on the templates, including disabling unnecessary services, setting file permissions, configuring firewall rules, and realizing lifecycle management of trusted containers.

[0021] The application packaging and deployment module provides application packaging tools to package critical applications and their dependent environments into trusted containers, encrypt sensitive data and store it in a secure area of ​​a cryptographic chip, and configure container resource limits and security policies.

[0022] The runtime security protection module uses the hardware encryption function of cryptographic chips to encrypt and sign data within the container in real time, monitors the container's running status to detect abnormal behavior and execute security measures, and builds a proactive runtime defense system to ensure data security and behavioral compliance during container runtime.

[0023] The beneficial effects of this invention are:

[0024] This invention deeply integrates domestically produced cryptographic chips into the Kylin system hardware platform, establishes a hardware-level secure communication channel and performs initial configuration, providing a hardware root of trust based on cryptographic chips for the construction of trusted containers, thereby improving the system's trust benchmark from the underlying architecture level.

[0025] Specifically, by creating a trusted container template pre-installed with cryptographic chip drivers and encryption libraries and implementing security hardening, the container attack surface is effectively reduced, a minimal secure operating environment is constructed, and potential attack paths are blocked at the fundamental level. During application encapsulation, sensitive data is encrypted and stored in the secure area of ​​the cryptographic chip. Combined with container resource limitations and security policy configuration, hardware-level encrypted isolation and controllable resource management of critical applications and the operating environment are achieved. At runtime, the hardware encryption function of the cryptographic chip is used to perform real-time encryption signature verification of data throughout the entire process. Through abnormal behavior monitoring and security measure execution, a dynamic protection system covering the entire data processing lifecycle is formed.

[0026] The technical solution of this invention, through deep integration of hardware and operating system, constructs an intrinsically trusted execution environment at the container level, breaking through the limitations of traditional software protection, improving the confidentiality and integrity of critical application data and the controllability of the operating environment, providing a systematic hardware-level solution for solving the core security needs of container technology in high-security scenarios, and promoting the practical application of independent and controllable trusted computing environments.

[0027] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, the following describes the preferred embodiments of the present invention in detail with reference to the accompanying drawings. Attached Figure Description

[0028] Figure 1 This is a flowchart of a trusted container construction method according to an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of a trusted container layered defense model in one embodiment of the present invention;

[0030] Figure 3 This is a data encryption heatmap in one embodiment of the present invention;

[0031] Figure 4 This is a topology diagram of abnormal container runtime behavior in one embodiment of the present invention;

[0032] Figure 5 This is a schematic diagram illustrating the parallel encryption performance of a cryptographic chip in one embodiment of the present invention;

[0033] Figure 6 This is a schematic diagram illustrating the principle of a container trust measurement engine in one embodiment of the present invention;

[0034] Figure 7 This is a schematic diagram comparing safety indicators in one embodiment of the present invention. Detailed Implementation

[0035] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] The term "comprising," and any variations thereof, used in the specification and claims of this application, is intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus. Furthermore, the use of "and / or" in the specification and claims indicates at least one of the connected objects, such as A and / or B, indicating the inclusion of A alone, B alone, or both A and B.

[0037] In embodiments of the present invention, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in embodiments of the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0038] The present invention provides the following preferred embodiments:

[0039] Example 1: To address the issues of insufficient hardware-level security support, weak application isolation mechanisms, and inadequate data processing security in existing container environments, this example provides a trusted container construction method that deeply integrates cryptographic chips with the Kylin system. Through collaborative design at the hardware and system layers, it achieves secure management and control throughout the container's entire lifecycle. Figure 1 As shown, the flowchart of the construction method is as follows:

[0040] S100: The hardware platform that integrates domestically produced cryptographic chips into the Kylin system establishes a high-speed and secure communication channel between the chips and the CPU memory. It also initializes and configures the cryptographic chips during system startup, including loading keys, setting national cryptographic algorithms, and configuring security policies.

[0041] S200: Based on the containerization technology of the Kylin system, a basic trusted container template is created, pre-installed with cryptographic chip drivers and encryption libraries, and security is hardened, including disabling unnecessary system services, setting strict file permissions, and configuring firewall rules to reduce the container attack surface and build a secure basic operating environment.

[0042] S300: Encapsulates critical applications and their dependent environments into a trusted container template, encrypts application-sensitive data and stores it in the secure storage area of ​​the cryptographic chip, and configures the container's resource limits and security policies.

[0043] S400: Utilizes the hardware encryption function of the cryptographic chip to perform real-time encryption and signature verification of the data transmission, storage and processing process within the container, and monitors the container's operating status to detect abnormal behavior in real time. When an anomaly is detected, security measures are implemented.

[0044] In the hardware integration and initialization phase, such as Figure 2 The trusted container layered defense model shown illustrates the "driver encryption layer" and "national cryptographic algorithm layer." Domestically produced cryptographic chips are integrated into the Kylin system's hardware platform via a dedicated bus interface, establishing a high-speed, secure communication channel between the chip and the CPU and memory. This communication channel uses the national cryptographic algorithm SM4 for link encryption, ensuring that data transmission is not eavesdropped on or tampered with during transmission. Figure 2 The secure interaction architecture between the mid-to-low-level hardware and the system kernel. During system startup, the Kylin system kernel initializes and configures the cryptographic chip through a secure bootloader: loading a pre-programmed unique device key for authentication, setting up an operating environment supporting Chinese cryptographic algorithms such as SM2 / SM3 / SM4, and configuring hardware-level security policies to restrict the cryptographic chip to responding only to legitimate commands. This process is achieved through... Figure 2 The underlying support of the "driver encryption layer" ensures that the cryptographic chip forms a trusted execution environment in its initial state, providing a hardware-level root of trust for container construction.

[0045] Furthermore, when creating a basic trusted container template based on the Kylin system's containerization technology, such as Figure 2 The "kernel trimming layer" and "driver encryption layer" work together to pre-install digitally signed and verified cryptographic chip drivers and national cryptographic libraries on a minimized system image. Security hardening measures include disabling unnecessary services, setting strict file permissions, and configuring firewall rules. Figure 2The system employs a layered design logic that reduces the attack surface through kernel trimming and provides encryption support at the driver layer. For example, firewall rules configured with iptables only open ports necessary for container communication, combined with file permission control to restrict access to critical system files, thus building a secure operating environment at the system level. Figure 2 This aligns with the design philosophy of reducing the attack surface of containers through the "kernel trimming layer".

[0046] Furthermore, in the application encapsulation and data processing stages, such as Figure 3 The data encryption heatmap shown illustrates how critical applications and their dependent environments are encapsulated within a trusted container template, and then sensitive data is encrypted using the SM4 algorithm. The original data, after encryption, is stored in the secure storage area of ​​a cryptographic chip, such as... Figure 3 The "secure storage area for the cryptographic chip," marked with a red dashed box, is physically isolated from external storage using hardware address space isolation technology. The encryption key is generated by a true random number generator within the cryptographic chip and stored in this secure hardware area, ensuring that the key is not exposed to the container file system. Simultaneously, cgroups technology is used to configure container resource limits, including CPU quotas, memory limits, and network access control, achieving secure and isolated application deployment. Figure 2 The "application protection layer" in the middle provides a resource control and security encapsulation mechanism for upper-layer services.

[0047] Furthermore, in the security assurance phase of container runtime, such as Figure 4 The container runtime abnormal behavior topology diagram shown utilizes the hardware encryption function of a cryptographic chip to implement real-time protection for data transmission, storage, and processing: SM2 signature verification ensures integrity before data transmission; dynamic decryption verification is performed when stored data is retrieved; and critical computational tasks directly invoke the hardware encryption engine for execution. Figure 2 Hardware acceleration capabilities for the Chinese national cryptographic algorithm layer. Simultaneously, the kernel-level monitoring module collects real-time container process behavior data, such as... Figure 4 Different colored nodes (green for safe processes, orange for abnormal behavior, and red for high-risk processes) and monitoring center markers trigger safety measures such as isolation containers and process termination when an anomaly is detected, forming a closed-loop control system from anomaly detection to response. Figure 2 This corresponds to the dynamic security mechanism of the "behavioral monitoring layer" in the middle. Furthermore, Figure 5 The diagram showing the parallel encryption performance distribution of cryptographic chips demonstrates that the hardware acceleration of national cryptographic algorithms such as SM4-CBC encryption, SM2 signature verification, and SM3 hash calculation provides efficient and secure support for runtime data processing, reflecting the collaborative working capabilities of cryptographic chips in different encryption scenarios.

[0048] This embodiment is illustrated by... Figure 2The layered defense architecture shown organically combines hardware integration, system hardening, application encapsulation, and runtime monitoring: secure communication and initialization configuration at the hardware level serve as the underlying support; security hardening and resource restrictions on container templates constitute system-level protection; and encrypted data storage and runtime monitoring form a three-dimensional defense at the application and behavioral levels. Figure 3 The data encryption heatmap visually illustrates the secure transformation process of sensitive data from its original distribution to encrypted storage. Figure 4 The abnormal behavior topology diagram clarifies the implementation path of the monitoring mechanism and response strategy. Figure 5 The performance graph verifies the high efficiency and security capabilities of the cryptographic chip under the collaboration of multiple algorithms. Each link collaborates with the system kernel module through standardized national cryptographic algorithm interfaces to form a security protection system covering the entire lifecycle of the container. This effectively solves the shortcomings of traditional container technology in terms of hardware-level security support and data controllability, and achieves multi-layered trust assurance from hardware to software and from static to dynamic.

[0049] Example 2: To address the technical challenges of establishing a root of trust at the underlying level in a trusted container system, this example further refines the method for establishing a hardware-level root of trust. A high-speed, secure communication channel is implemented based on a dedicated bus architecture or encrypted communication protocol, ensuring the confidentiality and integrity of data exchange between the cryptographic chip and the host system. The technical implementation can be found in [reference needed]. Figure 2 The layered defense model for trusted containers illustrates the underlying hardware interaction mechanism. The national cryptographic algorithm system encompasses standards such as SM2, SM3, SM4, and SM9, providing algorithmic support for various security scenarios. During system initialization, the firmware of the cryptographic chip is verified for integrity using the SM3 hash algorithm. The specific process includes extracting the hash value of the firmware image and comparing it with a preset benchmark value to ensure that the core components of the hardware layer have not been tampered with. It is important to understand that this verification process, as the starting point of the trust chain, operates on the same principle as... Figure 6 The logic for establishing the initial trust anchor point in the shown trust measurement engine is consistent, providing an initial trust anchor point for the upper-layer trusted container runtime environment.

[0050] Furthermore, the cryptographic chip establishes an interaction channel with the Kylin operating system kernel through a dedicated interface, and its internal secure storage area provides an isolated environment for key generation, storage, and computation. The initialization configuration binds the hardware-level verification mechanism with the software-layer trust chain, forming a trusted transmission path from the chip firmware to the operating system kernel. Figure 2 In this layered architecture, trust is passed from the bottom hardware security layer to the upper layers. This layered verification architecture lays a hardware-level security foundation for subsequent trust measurement during container runtime, ensuring the reliability and resistance to attacks of the hardware-level root of trust through the compliant application of national cryptographic algorithms.

[0051] The advantage of this embodiment lies in the fact that, through the collaborative design of national cryptographic algorithms and cryptographic chips, an initialization verification system based on a hardware-level root of trust is constructed. This ensures that the trusted container system possesses the ability to resist low-level attacks such as firmware tampering and malicious code injection during the startup phase, providing a reliable trust starting point for upper-layer security mechanisms. Its technical implementation and... Figure 6 The initial measurement phase of the measurement engine, as shown, forms a hardware-level support relationship.

[0052] Example 3: To address the security risks posed by redundant components in traditional container environments, this example specifically optimizes the operating system kernel of the trusted container template. Containerization technology employs the Docker or Kata Containers architecture. During the template building phase, kernel trimming techniques are used to remove modules and services unrelated to critical applications, such as... Figure 2 The layered defense model shown includes a "kernel trimming layer." This trimming process, based on the Kylin system's kernel customization tools, removes unnecessary device drivers, network protocol stack components, and debugging tools, creating a kernel image containing only the minimum runtime environment. It's important to understand that this trimming mechanism reduces the potential attack surface at the fundamental level, lowering the likelihood of kernel vulnerabilities being exploited. Figure 2 This aligns with the design philosophy of reducing the attack surface through a layered structure.

[0053] Furthermore, by combining the Kylin system's mandatory access control (MAC) mechanism, fine-grained control is implemented over file and process access permissions within the container. Specifically, through security policy configuration, processes within the container are restricted to accessing resources only within their designated scope, preventing unauthorized cross-boundary access. For example, read-only permissions are set for critical configuration files, and direct calls to kernel interfaces by ordinary user processes are restricted. Understandably, this combination of a minimal environment and mandatory access control constructs a "minimum necessary" runtime environment. Figure 2 In a layered architecture, this is reflected in the security isolation mechanism between the kernel layer and the application layer, which improves the container's resistance to attacks from an architectural perspective.

[0054] The benefit of this embodiment is that, through the synergistic effect of kernel trimming and mandatory access control, it ensures that the trusted container template contains only the core components required to run critical applications, effectively reducing security risks caused by redundant services and providing a cleaner and more controllable execution environment for applications within the container.

[0055] Example 4: To address the security protection and compliant use of resources for sensitive data in container environments, this example further refines the data encryption processing and runtime resource control mechanisms. Sensitive data encompasses core data assets such as key certificates and user privacy information. Its encryption process is built upon the national cryptographic algorithm system: a session key is securely generated between the cryptographic chip and the host system through the SM2 key negotiation mechanism, and then the SM4 symmetric encryption algorithm is used to encrypt data in blocks, forming ciphertext data blocks. For example... Figure 3 As shown, the encrypted data is written to the internal isolated area of ​​the cryptographic chip through a dedicated secure storage interface. This area is marked with a red dashed box in the data encryption heatmap to ensure hardware-level protection in the data storage process.

[0056] Furthermore, regarding resource management during container runtime, this embodiment leverages the cgroups technology of the Kylin system to implement fine-grained limits on resources such as CPU, memory, and storage. Kernel-level resource scheduling strategies ensure that container instances do not affect system stability due to resource abuse. Simultaneously, a network port whitelist control mechanism is integrated into the security policy system, allowing only authenticated ports to interact with data. The SM3 hash algorithm is embedded in the data transmission link for integrity verification, ensuring data integrity by comparing hash values ​​before and after transmission. It is important to understand that this design, combining encrypted storage, resource restrictions, and network access control, constructs a security protection system covering the entire lifecycle of data encapsulation, deployment, and operation. Its technical implementation and... Figure 3 The interaction logic of the secure storage area of ​​the cryptographic chip forms a specific correspondence.

[0057] The advantage of this embodiment is that by combining the application of national cryptographic algorithms with hardware-level secure storage, end-to-end protection of sensitive data is achieved from encryption processing to secure storage. At the same time, the compliance of container operation is enhanced by system-level resource control and network policies, providing multi-layered technical support for the secure flow of critical data in a trusted container environment.

[0058] Example 5: To address the issues of detecting and responding to abnormal behavior during container runtime and securing evidence, this example further optimizes the real-time encryption mechanism and security incident handling process. In the data encryption stage, the SM4-CBC mode is used to encrypt statically stored data within the container in blocks, ensuring that the data in the storage medium exists in ciphertext form. For network-transmitted data, digital signature verification is performed using the SM2 algorithm, verifying the authenticity of the data source while establishing a trusted connection between the communicating parties. Figure 4 As shown, the abnormal behavior detection module constructs a baseline of normal behavior during container runtime by monitoring system call sequences and process behavior characteristics in real time. When behaviors deviating from the baseline, such as illegal access to the container file system, abnormal network connections, or malicious code injection, are detected, a multi-level response mechanism is triggered.

[0059] Furthermore, once abnormal behavior is identified, the system first freezes the relevant processes through kernel-level mechanisms to prevent the spread of malicious behavior. Simultaneously, it generates a memory snapshot and solidifies the snapshot data using the SM3 hash algorithm, forming an immutable chain of evidence. For example... Figure 5 As shown, this hash solidification process is consistent with the SM3 algorithm application logic in the parallel encryption performance model of cryptographic chips, ensuring the integrity of the evidence data. Along with the above operations, the system automatically triggers the remote alarm module, transmitting alarm information containing abnormal behavior characteristics and hash value evidence to the security management platform, providing a basis for subsequent security incident tracing and handling. It is understandable that this closed-loop mechanism integrating detection, response, and evidence collection... Figure 4 The abnormal behavior topology diagram shows the complete path from node state identification to event propagation blocking, effectively improving the dynamic security protection capability of the container environment.

[0060] The advantage of this embodiment is that, through the deep integration of national cryptographic algorithms and dynamic monitoring technology, a full-process security system covering data encryption, anomaly detection, and response forensics has been constructed, ensuring that security threats during container operation can be identified, blocked, and evidence preserved in a timely manner, providing a systematic technical solution for handling security incidents in complex attack scenarios.

[0061] Example 6: To address the issues of identity authentication and image trustworthiness verification at the trusted container creation entry point, this example introduces a multi-level security verification mechanism in the initial stage of the container lifecycle. Upon receiving a container creation request, the caller's identity is first cryptographically authenticated using the SM9 algorithm. This algorithm, based on an identifier-based cryptography system, supports efficient identity verification and key management, ensuring that only authorized entities can initiate container creation operations. After successful authentication, the system generates a container-specific key pair and uses the SM2 key negotiation mechanism to securely exchange keys with the cryptographic chip, storing the private key of the key pair in a secure area within the chip, thus forming hardware-level key protection.

[0062] Furthermore, for the trustworthiness verification of container images, the SM3 hash algorithm is used to perform integrity verification on the image file: the hash value of the image file is extracted and compared with a preset benchmark value to confirm that the image has not been tampered with during transmission and storage, and that its source meets the requirements of trusted computing. Figure 6As shown, this image verification process, a key component of the trusted metrics engine, corresponds technically to the core mechanism of the "SM3 hash chain" in the diagram. The chained transmission of metrics ensures reliable trust transfer from the creation entry point to the container runtime environment. Only container requests that pass both identity authentication and image verification can proceed to the subsequent deployment and instantiation processes, preventing the introduction of untrusted images at the source. It's important to understand that this design, combining identity authentication, key management, and image verification, constructs a multi-layered defense during the container creation phase. Its technical implementation and... Figure 6 The logic for establishing the initial trust anchor is closely related.

[0063] The advantage of this embodiment is that, through the collaborative application of the national cryptographic algorithm system in identity authentication, key interaction and image verification, a multi-layered verification mechanism covering subject identity, key security and image trustworthiness is established at the container creation entry point, ensuring that only container instances that have undergone full-link security verification can be deployed and run, providing a prerequisite guarantee for the initial security state of the trusted container environment.

[0064] Example 7: To address the security risks of untrusted code execution during container runtime, this example further refines the control mechanism for container processes. Specifically, by constructing a process behavior feature library, continuous monitoring and data collection are performed on the process startup sequence, system call parameters, and resource access patterns during normal operation, forming a dynamically updated whitelist rule set. It is important to understand that this whitelist is not statically configured, but rather trained on historical behavior data using machine learning algorithms to adaptively identify the behavioral boundaries of normal processes.

[0065] Furthermore, during the runtime phase, when a new process startup or system call request is detected, it is first verified by matching against a whitelist rule, and a pre-interception mechanism is triggered for behaviors not recorded in the rule set. Further, combined with... Figure 6 The trusted measurement engine, as shown, calculates the SM3 hash value of the target process's code segment and compares it with the trusted benchmark value stored in the cryptographic chip to ensure the integrity of the code segment has not been tampered with. During this process, the cryptographic chip provides hardware-level secure computing power support to prevent interference from malicious programs.

[0066] Understandably, whitelist control and trust metrics form a dual verification mechanism: the former identifies abnormal startup behavior through behavioral patterns, while the latter ensures the trustworthiness of the executing entity through code integrity verification. Their synergy enables fine-grained control over the process execution environment, effectively resisting threats such as zero-day attacks and malicious code injection. The benefit of this embodiment lies in constructing a dynamic protection system covering the process lifecycle through the combination of behavioral characteristics and code metrics, providing multi-layered protection for code execution security during container runtime.

[0067] Example 8: To improve the data security and integrity of container images throughout their entire lifecycle, this example designs a differentiated encryption strategy for the layered structure of the image. For example... Figure 2 The layered defense model for trusted containers, as shown, divides the image into a base layer, an application layer, and a data layer. Each layer employs different encryption mechanisms based on security requirements: the base layer, as the core support for container operation, uses the hardware hash module of a cryptographic chip to solidify the image file, writing the hash value into the chip's secure storage area to form an immutable baseline fingerprint; the application layer code is stored using the SM4 symmetric encryption algorithm, with the encryption key generated and dynamically managed by the cryptographic chip based on true random numbers to ensure the confidentiality of the code during transmission and storage; sensitive data in the data layer is further encrypted using a dynamic session key, which is bound to the lifecycle of the container instance, enabling flexible configuration of the data encryption granularity.

[0068] Furthermore, during the image deployment phase, the SM2 asymmetric encryption algorithm is introduced to digitally sign the entire image. The receiving end verifies the integrity of the signature using a cryptographic chip, ensuring that the image has not been tampered with during packaging and transmission. It's important to understand that the layered encryption strategy fully considers the security sensitivity and usage scenarios of different data layers: the hardware hashing of the base layer ensures the trusted startup of the runtime environment; the SM4 encryption of the application layer prevents code leakage; and the dynamic key mechanism of the data layer adapts to the differentiated protection needs of sensitive data.

[0069] Furthermore, the encryption strategies at each layer and Figure 3 The data encryption heatmap shown corresponds to the encryption layer, and the scope and collaborative logic of different encryption mechanisms are clearly defined through visual security area markers, such as the secure storage area of ​​the cryptographic chip. This embodiment constructs a security protection system covering the entire lifecycle of the image by combining layered encryption and signature verification, ensuring data confidentiality while achieving refined management and flexible deployment of encryption strategies.

[0070] Example 9: To address the need for environmental remediation after a container runtime attack, this example designs a self-healing recovery mechanism based on a cryptographic chip. When Figure 4 When an attack event is detected in the abnormal behavior topology diagram shown and real-time protection measures cannot effectively block it, the container self-healing process is triggered: First, a new session key is generated through the SM2 key rotation algorithm, and the secure computing power of the cryptographic chip is used to encrypt and destroy sensitive data in the container memory to prevent residual data from being maliciously obtained; then, a pre-generated trusted image snapshot is loaded from the secure storage area of ​​the cryptographic chip. This snapshot contains a complete container runtime environment verified by SM3 hash, ensuring that the environment state after initialization is trusted.

[0071] Furthermore, during the reset process, the security audit module simultaneously records the timestamps of attack events, abnormal behavior logs, and encrypted evidence chains. This data is encrypted using the SM4 algorithm and stored in a secure area, providing an immutable original record for subsequent security analysis. It's important to understand that the core of the self-healing mechanism lies in the key management and secure storage capabilities provided by the cryptographic chip. This ensures that key rotation, data destruction, and image loading processes are all performed within a hardware-level secure environment, preventing attack remnants from affecting the trustworthiness of the new environment.

[0072] It should be noted that this mechanism is related to Figure 7 The "resilience" dimension in the system's comprehensive security metrics forms a technical mapping, achieving automated closed-loop management from attack detection to environment recovery through standardized reset procedures and evidence chain recording. This embodiment combines key rotation, trusted snapshots, and security auditing to construct a self-healing protection system for container runtime. While ensuring rapid environment recovery, it provides data support for subsequent security strategy optimization, realizing an improvement in container security management from passive defense to proactive self-healing capabilities.

[0073] Example 10: To address the modular integration and collaborative control issues of trusted container construction systems, this example provides a trusted container construction system based on domestically produced cryptographic chips within the Kylin system. Through the layered design of each functional module and the integration of hardware-level security capabilities, the construction method is systematically implemented.

[0074] Specifically, the cryptographic chip management module, serving as the underlying root of trust, achieves high-speed and secure communication with the hardware platform through a standardized driver interface. It establishes a dedicated channel using PCIe or USB-C interfaces to ensure low latency and tamper-proof key exchange and algorithm calls. This module incorporates a national cryptographic algorithm library, supports hardware acceleration of standard algorithms such as SM2 / SM3 / SM4, and provides a security policy configuration interface, allowing for dynamic loading of key versions and encryption policies based on container security levels. For example, it can assign independent session keys to different container instances and store them in the chip's secure area.

[0075] Furthermore, the trusted container management module constructs container templates based on the cgroup and namespace technologies of the Kylin system. During template initialization, it performs multi-dimensional security hardening: disabling unnecessary services such as sshd to reduce the attack surface, configuring system read-only permissions for configuration files using the chmod command, restricting container network access boundaries using iptables rules, and integrating SELinux policies to minimize process privileges. This module maintains the container lifecycle state machine, supporting atomic control of operations such as creation, startup, pause, and destruction, ensuring the trusted propagation of the template instantiation process.

[0076] Furthermore, the application packaging and deployment module provides a graphical packaging toolchain, supporting the packaging of application binary files, dependency libraries, and configuration files into layered images. During this process, it calls the SM4 encryption interface of the cryptographic chip management module to perform block-level encryption on sensitive files in the image data layer, and binds the encryption key hash value with the image metadata and stores it in the chip's secure storage area. Simultaneously, this module supports resource quota configuration, limiting the upper limits of container resources such as CPU, memory, and disk I / O through cgroups, and defining process whitelist rules in conjunction with security policy files to form the initial trusted environment for application operation.

[0077] Furthermore, the runtime security protection module monitors the container status in real time, intercepts system calls through hook functions, and uses the cryptographic chip's SM3 hash engine to perform periodic integrity checks on the process code segment, comparing it with a pre-stored baseline value to identify tampering behavior. Upon detecting an anomaly, it sequentially executes process freezing, memory data encryption protection, remote management platform alarm activation, and container reset operations. The reset process calls the trusted container management module's snapshot recovery interface to load a trusted image version from the cryptographic chip. It's important to understand that this module and the cryptographic chip management module form a hardware-software collaborative defense, with the chip providing real-time encryption and decryption computing power to ensure efficient execution and response of monitoring strategies.

[0078] This embodiment constructs a complete trusted chain from the hardware root of trust to the software execution environment by functionally dividing and coupling multiple modules with security capabilities. Each module implements on-demand invocation of security capabilities through standardized interfaces, forming a hierarchical container security protection system. Through this embodiment, the system architecture, supported by domestically produced cryptographic chips, achieves end-to-end hardware-level security assurance for key management, image hardening, and operation monitoring, providing an engineering implementation path for building trusted containers in the Kylin system environment.

[0079] Although the present invention has been specifically described above with reference to preferred embodiments, it should be understood that the present invention is not limited to the embodiments described above. Various modifications and variations can be made by those skilled in the art without departing from the spirit of the present invention, and such modifications and variations should fall within the scope defined by the appended claims and their equivalents.

Claims

1. A method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system, characterized in that, Includes the following steps: The domestically produced cryptographic chip is integrated into the hardware platform of the Kylin system, a high-speed and secure communication channel is established between the cryptographic chip and the CPU and memory, and the cryptographic chip is initialized and configured when the system starts up, including loading the key, setting the national cryptographic algorithm, and configuring the security policy. Based on the containerization technology of the Kylin system, a basic trusted container template is created, pre-installed with cryptographic chip drivers and encryption libraries, and security hardening is performed, including disabling unnecessary system services, setting strict file permissions, and configuring firewall rules to reduce the container attack surface and build a secure basic operating environment. The critical applications and dependent environments are encapsulated into the trusted container template, application-sensitive data is encrypted and stored in the secure storage area of ​​the cryptographic chip, and the container's resource limits and security policies are configured. The hardware encryption function of the cryptographic chip is used to encrypt and sign the data transmission, storage and processing process in the container in real time, and to monitor the container's running status to detect abnormal behavior in real time. When an anomaly is detected, security measures are implemented. The method also includes identity authentication and image verification when the trusted container is created. After the container creation request is initiated, the caller's identity is authenticated by the SM9 algorithm. After successful authentication, a container key pair is generated. The SM2 key negotiation mechanism is used to interact with the cryptographic chip for key exchange. The container image is subjected to SM3 hash verification to confirm that the image source is trustworthy and has not been tampered with. The container image is encrypted in layers, with different encryption strategies for different layers: the base layer, the application layer, and the data layer. The base layer image is hardened by hardware hashing using a cryptographic chip, the application layer code is encrypted and stored using SM4, and sensitive data in the data layer is encrypted using a dynamic session key. At the same time, the integrity of the image is verified by SM2 digital signature during image deployment to ensure that the container image is not tampered with during packaging, transmission, and deployment, and that the granularity of data encryption can be flexibly configured.

2. The method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system as described in claim 1, characterized in that, The high-speed secure communication channel is implemented through a dedicated bus or encrypted communication protocol. The national cryptographic algorithm includes at least one of SM2, SM3, SM4 and SM9. The initialization configuration also includes verifying the firmware integrity of the cryptographic chip using the SM3 hash algorithm, which is used to establish a hardware-level root of trust for the trusted container building system.

3. The method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system as described in claim 1, characterized in that, The containerization technology uses Docker or Kata Containers. The security hardening also includes trimming the operating system kernel of the trusted container template, removing unnecessary modules and services, and enabling the Kylin system's mandatory access control mechanism to perform fine-grained control over file and process access permissions within the container. This ensures that the trusted container template contains only the minimal environment required to run critical applications, thereby reducing security risks at the fundamental level.

4. The method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system as described in claim 1, characterized in that, The sensitive data includes key certificate user privacy information. The encryption process uses the SM4 symmetric encryption algorithm combined with the SM2 key negotiation mechanism to generate a session key. The encrypted data is written to the internal secure area of ​​the cryptographic chip through the secure storage interface of the cryptographic chip. The resource restrictions are implemented through the cgroups technology of the Kylin system. The security policy also includes whitelist control of container network ports and integrity verification of data transmission to ensure that sensitive data is protected by hardware-level encryption during packaging and deployment, and that resource usage during container runtime complies with security specifications.

5. The method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system as described in claim 1, characterized in that, The real-time encryption uses the SM4-CBC mode to encrypt the data stored in the container, and the SM2 algorithm is used to sign and verify the transmitted data. The abnormal behavior detection is achieved by monitoring the system call sequence and process behavior characteristics. When illegal access to the container file system, abnormal network connection or malicious code injection is detected, the relevant process is first frozen and a memory snapshot is generated. The snapshot data is solidified by the SM3 hash algorithm to form an immutable chain of evidence, and a remote alarm is triggered at the same time.

6. The method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system as described in claim 1, characterized in that, The method also includes a whitelist control mechanism for container processes. A whitelist is established by collecting process behavior characteristics and system call patterns during normal operation. The whitelist is intercepted in real time for the startup of processes not in the whitelist and abnormal system calls. The integrity of the process code segment is measured by the trusted measurement engine of the cryptographic chip to ensure that only certified trusted code can run in the container.

7. The method for constructing an intrinsically trusted container for a cryptographic chip in the Kylin system as described in claim 1, characterized in that, The method also includes a self-healing recovery mechanism for container runtime. When an attack is detected on the container environment and cannot be repaired through real-time protection measures, a container reset process is triggered. A new session key is generated through SM2 key rotation, the container memory data is encrypted and destroyed, a trusted image snapshot is loaded from the secure storage area of ​​the cryptographic chip, the container environment is reinitialized, and the entire process of the attack event is recorded through the security audit module.

8. A system for constructing an intrinsically trusted container for the Kylin system based on a domestically produced cryptographic chip, used to implement the method for constructing an intrinsically trusted container for the Kylin system based on a cryptographic chip as described in any one of claims 1-7, characterized in that, include: The cryptographic chip management module is used to integrate domestically produced cryptographic chips and perform initialization configuration, establish a high-speed secure communication channel between the cryptographic chip and the CPU and memory, load keys, set national cryptographic algorithms, configure security policies, provide cryptographic chip drivers and encryption libraries, and provide hardware-level cryptographic support and root of trust. The Trusted Container Management module creates and manages trusted container templates based on Kylin system containerization technology, and performs security hardening on the templates, including disabling unnecessary services, setting file permissions, configuring firewall rules, and realizing lifecycle management of trusted containers. The application packaging and deployment module provides application packaging tools to package critical applications and dependent environments into trusted container templates, encrypt sensitive data and store it in a secure area of ​​a cryptographic chip, and configure container resource limits and security policies. The runtime security protection module uses the hardware encryption function of cryptographic chips to encrypt and sign data within the container in real time, monitors the container's running status to detect abnormal behavior and execute security measures, and builds a proactive runtime defense system to ensure data security and behavioral compliance during container runtime.

Images