Container system security enhancement method and electronic equipment

Abstract

The invention relates to the technical field of virtualization frameworks, in particular to a container system security enhancement method and electronic equipment. A container system security enhancement method is applied to an electronic device, a Linux kernel, an Android system, a container and a TEE are operated on the electronic device, and the method comprises the steps that the Linux kernel obtains a trusted identity certificate stored in the container in the starting stage of the container and sends the trusted identity certificate to the TEE; the TEE performs signature verification on the received trusted identity certificate, if the verification is passed, the TEE returns a corresponding trusted certificate to the Linux kernel, and after the Linux kernel receives the trusted certificate, a trusted mark is set on the namespace of the container; and based on the trusted mark, the Linux kernel receives a request of the Android system, starts the container and performs access control and allocation on resources of the container. According to the method, the Linux kernel can implement more accurate and safer dynamic management and control on the container resources, and resource access of untrusted containers is effectively isolated, so that the safety protection capability of the whole container system is enhanced.

Description

Technical Field

[0001] This invention relates to the field of virtualization framework technology, and in particular to a method and electronic device for enhancing the security of container systems. Background Technology

[0002] In existing technologies, the system architecture of intelligent financial payment terminals (such as POS machines and cash registers) mainly falls into two categories: 1. Customized solution based on Android main system: The Android main system is directly customized to meet the security and business needs of financial payment. The main system itself is used as the main body for running financial payment functions, without introducing containerization technology.

[0003] 2. Container-based solutions: LXC (Linux Container) solution: This solution leverages native features of the Linux kernel, such as namespaces and cgroups, to create multiple isolated containers on the Android system. Each container can run an independent, lightweight system. This technology is currently widely used in scenarios such as automated testing and multi-screen control in smart cockpits.

[0004] The pVM solution based on the Android Virtualization Framework (AVF) theoretically provides stronger security by running the financial payment system within a protected virtual machine (pVM). However, this solution faces issues of hardware compatibility (some common chips do not support AVF) and performance overhead, resulting in poor performance on low-cost chip platforms. Therefore, in practice, container-based solutions are often adopted instead.

[0005] However, the above solutions present significant technical contradictions in the pursuit of security, compatibility, and performance: If a customized Android main system solution is adopted, its main system is highly coupled with the general environment, making it difficult to achieve the high-strength isolation required for financial payment business, resulting in a weak security boundary.

[0006] While the AVF pVM solution can provide better isolation, it is limited by hardware support and performance loss, making it difficult to be practical on widely deployed low-cost terminals.

[0007] While the current mainstream LXC container solution is more feasible in terms of compatibility and performance, its "Linux kernel-level" isolation mechanism (which relies on namespaces and shares the Linux kernel) has inherent defects and insufficient isolation strength, which cannot meet the stringent security requirements of financial payment scenarios.

[0008] The architectures in related technologies have failed to achieve a system solution on widely available, low-cost hardware platforms that can both ensure deep isolation between the financial payment system and the host environment, meet financial-grade security standards, and maintain good performance and hardware compatibility. Specifically, solutions with high security requirements (such as AVF / pVM) are constrained by hardware and performance limitations, while solutions with good compatibility (such as LXC) sacrifice necessary isolation strength, making it difficult to balance security and universality in financial payment terminals. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to provide a container system security enhancement method and electronic device that can ensure deep isolation between the financial payment system and the host environment, achieve financial-grade security standards, and maintain good performance and hardware compatibility.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for enhancing the security of a container system, applied to an electronic device running a Linux kernel, an Android system, containers, and a TEE, the method comprising: The Linux kernel obtains the trusted identity certificate stored in the container during the container's startup phase and sends it to the TEE; The TEE performs signature verification on the received trusted identity certificate. If the verification passes, the TEE returns the corresponding trusted credential to the Linux kernel. After receiving the trusted credential, the Linux kernel sets a trusted flag on the container's namespace; Based on the trusted tag, the Linux kernel receives the request from the Android system, starts the container, and performs access control and allocation on the container's resources.

[0011] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the container system security enhancement method of claim 1.

[0012] The beneficial effects of this invention are as follows: This application obtains the trusted identity certificate stored in the container during the container startup phase through the Linux kernel and sends it to the TEE. The TEE performs signature verification on the received trusted identity certificate. If the verification is successful, the TEE returns the corresponding trusted credential to the Linux kernel. After receiving the trusted credential, the Linux kernel sets a trusted flag on the container's namespace. Based on the trusted flag, the Linux kernel receives requests from the Android system, starts the container, and performs access control and allocation on the container's resources.

[0013] This application introduces a Trusted Execution Environment (TEE) to perform hardware-level security verification of the container's trusted identity certificate, ensuring the trustworthiness of the container's startup source. The Linux kernel sets a trusted marker in the container's namespace based on the trusted credentials returned by the TEE, achieving a strong binding between container identity and resource access control. Compared to existing technologies where container startup relies on pure software verification, making it vulnerable to tampering, this application places the root of trust in a hardware-secure TEE environment, significantly improving the startup security and identity trustworthiness of the container system. Simultaneously, the access control mechanism based on the trusted marker enables the Linux kernel to implement more precise and secure dynamic management of container resources, effectively isolating untrusted containers from accessing resources, thereby enhancing the overall security protection capabilities of the container system. Attached Figure Description

[0014] Figure 1 A flowchart illustrating the steps of a container system security enhancement method provided in this embodiment of the invention; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 3 A system architecture diagram of a container system security enhancement method provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the startup process of a container and payment system, which is part of a container system security enhancement method provided in an embodiment of the present invention. Detailed Implementation

[0015] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0016] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0017] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0018] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0019] The following describes the relevant terms used in this invention: AVF: The Android Virtualization Framework (AVF) provides a secure and private execution environment for code execution. AVF is well-suited for security-oriented use cases that require a higher level of security, or even formally validated isolation guarantees, than those provided by the Android application sandbox.

[0020] TEE: Trusted Execution Environment. A secure zone created using hardware isolation technology.

[0021] MicroDroid OS: A lightweight, standalone, secure container operating system within the Android system, specifically designed for running isolated, secure tasks.

[0022] Hardware security environment: Includes TEE and SE. A payment container management TA is added to the existing TEE module to achieve secure management of the payment container during container startup, resource management, and data transfer. Compared to existing common container solutions, the collaborative management of TEE / SE improves the security level of the container system (from kernel-level isolation between the container and the host, to hardware-level isolation).

[0023] The Linux kernel, also known as the Linux Kernel, is an enhanced version of the native kernel that provides more control over the allocation of resources and space for payment containers and general-purpose resources and space, and restricts the access permissions of the host general system to multiple specific payment resources, partitions, and hardware devices.

[0024] CGroups: Cgroups stands for Control Groups, a physical resource isolation mechanism provided by the Linux kernel. This mechanism allows for the restriction, isolation, and monitoring of resources used by Linux processes or process groups. For example, Cgroups can be used to limit the resource usage of specific processes, such as the number of CPU cores and the amount of memory. If these limits are exceeded, the process will be suspended or terminated.

[0025] Namespace: A namespace is a mechanism used in programming languages ​​to organize code, especially in C++. Its main purpose is to avoid naming conflicts between different code snippets, particularly in large projects where multiple developers might define variables or functions with the same name. By using namespaces, developers can group related code, thereby improving code readability and maintainability. Namespaces can be used in the following ways: defining a namespace and declaring variables, functions, or classes within it; using the :: operator to access members within a specific namespace; and using declarations to simplify namespace usage. The importance of namespaces in C++ lies in their ability to effectively manage identifiers and reduce the likelihood of conflicts.

[0026] The container management system schedules container startup, enhances security, and manages security during container operation. It also provides a secure data area and secure communication channel for communication and data exchange between the host and containers. It includes a secure data area, a container management module, and a secure communication channel. The secure data area acts as a data cache, caching sensitive resource files that the host system and payment containers need to share. Shared data is protected through SE (Security Provider Interface) collaboration, including access management and data security. The container management module manages the startup and status of payment containers. The secure communication channel, built on top of virtual bridge communication, establishes a secure communication channel between the payment container and the host system, protecting sensitive data transmission and communication.

[0027] Host System: Utilizing the Android system, including the native Android framework and existing technologies, as well as the extended financial payment APIs, API bridging module, and Android-container payment system collaboration module provided by this solution. Financial payment APIs are extended interfaces for financial payment applications to call. In common existing solutions, the functionality of these interfaces is often implemented by the Android system framework or services. In this solution, the application's runtime environment remains on the host system, but when the application calls the financial payment APIs, the call request is forwarded by the API bridging module to the payment container system for implementation. The Android-container payment system collaboration module is used to build a secure transmission channel between the host system and the container payment system, and to collaboratively handle the business interactions between the two systems.

[0028] The system within the container, based on MicroDroid OS in the AVF solution, expands and enhances financial payment capabilities and security, serving as a financial payment system.

[0029] LXC: Linux Containers. LXC is an operating system-level virtualization technology that allows multiple isolated Linux systems (containers) to run on a single Linux host.

[0030] SELinux (Security-Enhanced Linux) is a Linux kernel module and a security subsystem. Developed by the National Security Agency (NSA), it aims to enhance system security through mandatory access control (MAC). SELinux's primary function is to minimize the resources accessible to service processes in the system, adhering to the principle of least privilege. It improves system security by restricting process access permissions to resources; even when a process runs as root, it can only access the resources it needs. SELinux uses labels (i.e., security contexts) for access control. Each process and file has its own label, and SELinux determines whether access is allowed based on these labels and predefined rules.

[0031] The following describes in detail a container system security enhancement method of the present invention, applied to electronic devices, on which Linux kernel, Android system, containers, and TEE are run. (See attached diagram.) Figure 1 ,include: Step 110: During the container startup phase, the Linux kernel obtains the trusted identity certificate stored in the container and sends it to the TEE; Step 120: The TEE performs signature verification on the received trusted identity certificate. If the verification is successful, the TEE returns the corresponding trusted credential to the Linux kernel. Step 130: After receiving the trusted credentials, the Linux kernel sets a trusted flag on the container's namespace; Step 140: Based on the trusted tag, the Linux kernel receives the request from the Android system, starts the container, and performs access control and allocation on the container's resources; As described above, this embodiment introduces a TEE (Trusted Entity Environment) to perform hardware-level security verification of the container's trusted identity certificate, ensuring the trustworthiness of the container's startup source. The Linux kernel sets a trusted marker in the container's namespace based on the trusted credentials returned by the TEE, achieving a strong binding between container identity and resource access control. Compared to existing technologies where container startup relies on pure software verification, making it susceptible to tampering, this application places the root of trust in a hardware-secure TEE environment, significantly improving the startup security and identity trustworthiness of the container system. Simultaneously, the access control mechanism based on the trusted marker enables the Linux kernel to implement more precise and secure dynamic management of container resources, effectively isolating untrusted containers from accessing resources, thereby enhancing the overall security protection capabilities of the container system.

[0032] In one embodiment of this application, in step 140, based on the trusted tag, the Linux kernel receives a request from the Android system, starts the container, and performs access control and allocation on the container's resources, including: Step 210: The Linux kernel determines whether the trusted flag of the namespace to which the target object in the operation request received from the Android system belongs is a preset value. If so, it returns an operation failure response to the Android system. Specifically, namespace refers to the container namespace, and the trusted flag refers to the container_protected flag. The kernel namespace module adds the container_protected flag (set to true by LXC when the container is created). When the host system wants to perform operations such as process invocation, IPC communication, or file system mounting, the kernel checks whether the target object of the host system's operation has the container namespace flag. If the target does not belong to a container marked with container_protected=true, it returns "Resource not found (ENOENT)". The host cannot be aware of container processes; the host is prohibited from joining the container's namespace through system calls, preventing "infiltration into the container".

[0033] As described above, this embodiment verifies the trusted flag of the namespace at the kernel level. Only when the trusted flag of the namespace to which the target object belongs is a preset value will the kernel reject the operation request and return a failure response to the Android system. Therefore, the system can isolate untrusted containers from accessing sensitive resources, effectively preventing permission escape and unauthorized operations, and enhancing the security of the container runtime environment. Furthermore, this control logic is integrated into the kernel request processing flow, requiring no involvement from upper-layer applications, thus reducing system complexity while ensuring the efficiency and reliability of access control.

[0034] In one embodiment of this application, it further includes: Step 310: The Linux kernel adds namespace verification logic to the device node access interface in the Linux kernel driver. The namespace verification logic is configured to only allow the container's namespace to access the device node. Specifically, the driver refers to the security chip driver, the access interface includes open(), read() and write(), the namespace verification logic includes Namespace verification logic, and the container refers to the payment container.

[0035] Step 320: When the container starts, the Linux kernel binds the device nodes to the container's namespace, making the device nodes visible inside the container but invisible or inaccessible on the Android system. Among these device nodes are the device nodes of the security chip (such as / dev / securechip), so that the node / dev / securechip can be seen normally inside the container, but the node does not exist in the / dev directory of the Android system host (or the node exists but cannot be opened).

[0036] As described above, this embodiment integrates namespace verification logic into the device node access interface of the Linux kernel driver. This logic is configured to only allow access requests originating from the container's own namespace. Furthermore, when the container starts, a specified device node is dynamically bound to the container's namespace, making the node visible and accessible only within the container, and invisible or inaccessible at the host Android system level. This enforces isolation between the host system and the container payment system. By implementing "complete invisibility of container resources to the host" through the kernel, it overcomes the shortcomings of the native namespace's "logical isolation," thus enhancing system security and isolation.

[0037] In one embodiment of this application, it further includes: Step 410: The Linux kernel sets the resource exclusivity flag in the corresponding Cgroups subsystem; specifically, in the Cgroups subsystems such as CPU, memory, and IO, a new container_only flag is added, and the Cgroups group to which the container is bound is added to this flag. Step 420: The Linux kernel marks the Cgroups control group bound to the container as having a resource exclusive flag, thus denying the Android system access to Cgroups resources with the resource exclusive flag; that is, when the host process attempts to use Cgroups resources marked with the container_only flag, the kernel directly restricts it.

[0038] As described above, this embodiment, based on the native CGLOS, extends and further strengthens the restrictions on the host system's access to payment system resources at the kernel level. This enforces a mandatory isolation between the host system and the container payment system. Compared to existing technologies where Cgroups only provides resource quota limits and cannot achieve strict access isolation, this embodiment, through a kernel-level mandatory access control mechanism, ensures that critical resources allocated to trusted containers (such as CPU, memory, and I / O bandwidth) are not preempted or interfered with by host-side processes. This effectively guarantees the service quality and performance isolation of applications within the container, enhancing the stability and security of the container's runtime environment. It also effectively prevents the Android host system from illegally obtaining or using the container payment system's resources through kernel sharing mechanisms.

[0039] In one embodiment of this application, it further includes: Step 510: During the container creation phase, the TEE generates a trusted identity certificate for the container and saves the public key of the trusted identity certificate in the container's configuration file; the trusted identity certificate includes the container ID, namespace configuration hash, and security chip access permissions.

[0040] Step 520: The TEE stores the private key corresponding to the trusted identity certificate in the TEE's secure memory and writes the corresponding public key into the container's configuration file; In step 120, the TEE performs signature verification on the received trusted identity certificate, including: TEE verifies the signature of the received trusted identity certificate based on the public key.

[0041] As described above, this embodiment uses TEE to participate in container creation and startup verification, binding the container's identity legitimacy to the hardware root trust, preventing isolation failure caused by malicious creation of fake containers or tampering with container configuration, and ensuring that only legitimate payment containers can obtain enhanced isolation permissions.

[0042] In one embodiment of this application, prior to the container startup phase, the following is also included: Step 610: The TEE performs signature verification on the container's system image file and compares the hash value of the system image file with the hash value of a valid system image pre-stored in the TEE; where the system image file is the payment system image.

[0043] Step 620: If both the signature verification and hash value comparison pass, the TEE notifies the Android system to start the system corresponding to the system image file; if the hash of the pre-defined valid system image file is used, the TEE's payment container management TA will only notify the container management system to start the container if the signature verification passes and the file hash matches the pre-defined identifier.

[0044] Step 630: During system startup, load SELinux, which is specific to containers; Step 640: The container management system of the Android system obtains the preset system identifier from SELinux and TEE respectively for cross-validation; Step 650: If cross-validation fails, the container management system unloads the container partition, sends a container startup exception alarm to the TEE, and prohibits container startup operations. Specifically, if the cross-validation of the system identifier between the TEE and SE fails, the container management module of the container management system immediately unloads the payment partition, sends a "container startup exception" alarm to the TEE, and prohibits subsequent container startup operations; if the partition integrity signature verification fails, a hardware-level security policy is triggered through the Secure Element (SE) to temporarily lock access to the sensitive functions of the security chip. When the partition integrity signature verification fails, the payment container management module of the SE records the partition integrity signature verification failure status. When the SE-MicroDroid communication module receives data or requests from MicroDroid, it checks the recorded partition signature verification result. If the result is a failure, the data or requests from MicroDroid are not forwarded, thereby restricting the use of the security chip.

[0045] As described above, this embodiment ensures the integrity and source trustworthiness of the system image by introducing a TEE (Transport Execution Environment) to perform digital signature verification and hash value comparison on the system image file before container startup. During system startup, container-specific SELinux is loaded, implementing container-level mandatory access control policy isolation. The container management system obtains the system identifier from both SELinux and TEE and performs cross-verification, constructing a dual verification mechanism based on a hardware root of trust and the operating system. If cross-verification fails, it automatically triggers container partition unloading, anomaly alerts, and startup prohibition operations. This effectively prevents image tampering, unauthorized system startup, and malicious bypassing of the container runtime environment, improving the security and trustworthiness of the container startup process.

[0046] In one embodiment of this application, in step 640, the container management system of the Android system obtains a preset system identifier from SELinux and TEE respectively for cross-validation, including: Step 710: The container management system generates a verification request containing the container's unique identifier, a random number, and a timestamp, and performs a hash operation on the verification request to obtain the request hash value. Specifically, the container management module of the container management system generates verification request parameters, generates a random number (Nonce), and the verification request is the verification request packet. The verification request packet data contains CID (unique identifier) ​​+ Nonce (random number) + timestamp. The verification request packet is hashed to obtain the request hash value.

[0047] Step 720: The container management system sends a verification request containing the request hash to both the TEE and SELinux; specifically, the container management module sends the verification request through the TEE.

[0048] Step 730: Based on the preset first root key and the parameters obtained from the verification request, the TEE derives the first session key and uses it to encrypt the preset TEE system identifier, generating the first encrypted identifier. The parameters obtained from the verification request include CID (unique identifier) ​​and Nonce (random number). Specifically, the payment management TA in the TEE verifies whether H_req (the parameter passed to the verification request, the hash value of the request) matches the hash value of the verification request (ensuring the request has not been tampered with). If the verification passes, a hash algorithm is used, with K_tee_root as the first root key, CID + The Nonce (random number) serves as the salt, from which the first session key K_tee_session (a session key derived from the TEE) is derived. The ID_tee (a system-preset identifier) ​​is concatenated with the Nonce and encrypted using K_tee_session (e.g., using AES-GCM encryption) to obtain the first encrypted identifier E_tee. Here, ID_tee is a unique and fixed system identifier (e.g., a string or number sequence in a specific format) pre-installed in the TEE, used to represent the legitimate identity of the TEE environment during the verification process.

[0049] Generate a TEE verification response packet, which includes E_tee, IV, and authentication tag (IV (Initialization Vector, i.e., initialization vector random number), which works with K_tee_session for AES-GCM encryption to ensure that the same plaintext generates different ciphertexts in different encryption scenarios, preventing attackers from cracking the encryption algorithm by using ciphertext patterns); TEE returns the result after completing the tag generation and signing.

[0050] Step 740: SELinux derives a second session key based on the preset second root key and the same parameters obtained from the authentication request, and uses the second session key to encrypt the preset SELinux system identifier to generate a second encrypted identifier; The container management module requests "SELinux system identifier verification data" from SELinux. SELinux verifies the MAC value and H_req (ensuring command validity and request integrity). If the verification passes, a hash algorithm is used, with K_se_root as the second root key and CID and Nonce as the salt, to derive the second session key K_se_session (since K_se_root and K_tee_root are from the same source and have the same salt, K_se_session must be completely identical to K_tee_session; this is the core prerequisite for cross-validation). ID_se and Nonce are concatenated and encrypted using K_se_session (e.g., using AEC-GCM) to obtain the second encrypted identifier E_se. The SELinux verification response is then returned to the container management module.

[0051] Step 750: The container management system receives and decrypts the first and second encrypted identifiers, and verifies whether both decrypted system identifiers conform to a preset format. If both conform, cross-validation is completed. Specifically, the container management module of the container management system decrypts the TEE / SE verification data. The verification process includes session key consistency verification and system identifier integrity verification. The two decrypted system identifiers are ID_tee_dec and ID_se_dec.

[0052] Session key consistency check: Confirm that K_local_session and the key logic derived from TEE / SE are consistent (because K_tee_session and K_se_session need to be the same as K_local_session, if decryption is successful, this check will pass by default).

[0053] System ID integrity verification: The container management system checks whether the decrypted ID_tee_dec is completely consistent with the expected ID_tee format and content, and checks whether the decrypted ID_se_dec is completely consistent with the expected ID_se format and content.

[0054] As described above, this embodiment ensures the uniqueness and integrity of each verification request by generating a verification request containing a unique container identifier, a random number, and a timestamp, and calculating its hash value, effectively resisting replay attacks. The container management system sends the request hash value to both the Trusted Execution Environment (TEE) and the Security Enhanced Linux (SELinux), triggering both parties to independently derive session keys based on their respective preset root keys and the same parameters obtained from the request, achieving key temporality and isolation. The TEE and SELinux then use their respective derived session keys to encrypt their preset system identifier, generating a first encrypted identifier and a second encrypted identifier. This process ensures the confidentiality of the system identifier during transmission. After receiving and decrypting the two encrypted identifiers, the container management system verifies whether the decrypted system identifier conforms to the preset format, thus ensuring the legitimacy and integrity of the payment system. By having the TEE and SE independently verify the same request, the system's anti-tampering capability is improved.

[0055] In one embodiment of this application, it further includes: Step 810: The Android system checks the integrity signature of the container management partition; where the container management partition refers to the containermgr partition, which is a custom partition that is an extension of the Android system's partition management.

[0056] Step 820: If the check passes, the Android system mounts the container management partition and the payment partition. The container management partition stores the root file system of the container management system, and the payment partition stores the root file system of the payment system. The payment partition is an extended custom payment partition, and the payment system is the MicroDroid payment system.

[0057] Step 830: The Android system executes the initialization program within the container management partition to start the container management system; specifically, it executes the init program within the containermgr partition to start a minimal root file system to boot and start the container management system. Step 840: The container management system reads the files in the payment partition to start the payment system. Specifically, the container management module of the container management system reads the files in the payment partition to start the MicroDroid payment system.

[0058] As described above, this embodiment verifies the integrity signature of the container management partition through the Android system, ensuring that the data in this partition has not been tampered with, thereby establishing a trusted boot chain foundation. The MicroDroid payment system shares its kernel with the host system. Therefore, compared to the native MicroDroid in AVF, the MicroDroid payment system boot process begins by mounting the base directory and file system, without requiring the MicroDroid kernel boot portion. The security verification of hardware boot and kernel startup relies on the general kernel. To further protect the security of the payment system, custom independent partition storage and dynamic mount verification ensure that the container management system and payment system images have not been tampered with, and the independent boot process avoids interference from the host system during the container boot process.

[0059] In one embodiment of this application, it further includes: Step 910: During the Android system's startup phase, the Android system does not mount the container management partition and payment partition.

[0060] Specifically, this refers to the Android system startup phase. This process follows the native Android startup flow, but differs in the partition mounting process where the containermgr partition (corresponding to the container management partition) and the payment partition (corresponding to the payment partition) are not mounted initially. A simplified overview is as follows: Create basic directories such as / dev, / proc, and / sys; Mount the devfs and sysfs virtual file systems; Mount standard partitions such as system, vendor, and data; Do not mount the containermgr and payment partitions (container-related); switch the root directory to the system partition, parse the init.rc configuration file, start core system services, etc. until the Android system enters the ready state and sends the BOOT_COMPLETED broadcast.

[0061] As described above, this embodiment effectively isolates the core system startup process from access to security-sensitive partitions by avoiding mounting the container management partition and payment partition during the Android system startup phase, thus reducing potential security risks during system initialization. This ensures that the payment application and its associated container management environment are inaccessible until the system has fully started and completed basic security checks, thereby preventing malicious code from hijacking or tampering with payment-related partitions in the early stages of startup. This enhances the security of the system startup process.

[0062] In one embodiment of this application, the payment system includes a system implemented based on a MicroDroid system extension.

[0063] Specifically, the aforementioned container system security enhancement method modularly deploys the core functions of the payment system (such as transaction processing, key management, and financial module management) within the MicroDroid environment, achieving deep isolation from the host Android system through virtualized containers. After the Android system boots up, the payment partition is dynamically mounted through the container management system, executing the MicroDroid payment system's initialization process and preventing malicious hijacking during the startup phase. A virtual bridge is extended within MicroDroid, and efficient and secure communication between the host Android system and the MicroDroid payment system is achieved through two-way authentication and session encryption between the host Android system and the payment system.

[0064] As described above, this embodiment extends the direct management of the SE driver within the container system, establishing direct driver and communication between the container system and the SE system. In contrast, MicroDroid's native driver management and communication for TEE / SE is handled by the host system. This embodiment improves execution efficiency and enhances security.

[0065] See attached document Figure 3 and attached Figure 4 , Figure 3 This is a system architecture diagram of a container system security enhancement method provided in an embodiment of the present invention. Figure 4 A flowchart illustrating the container and payment system startup process of a container system security enhancement method provided in this embodiment of the invention. Applying the above-described container system security enhancement method to a real-world scenario includes steps A to I: Step A: Android system startup phase: Create basic directories such as / dev, / proc, and / sys; mount the devfs and sysfs virtual file systems; mount standard partitions such as system, vendor, and data; do not mount the containermgr and payment partitions (related to containers); switch the root directory to the system partition, parse the init.rc configuration file, start core system services, etc. until the Android system enters the ready state and sends the BOOT_COMPLETED broadcast.

[0066] Step B: Other startup phases of the container and payment system: The Android system within the Android system listens for the BOOT_COMPLETED broadcast mentioned above and begins preparing to start the container and payment system.

[0067] Step C: Dynamic container partition mounting, including: Step C-1, checking the integrity signature of the containermgr partition. Step C-2, mounting the containermgr partition, which contains the root file system of the container management system. Step C-3, mounting the payment partition, which contains the root file system of the MicroDroid payment system. Step C-4, executing the init program within the containermgr partition to start a minimal root file system to boot and start the container management system; Step C-5, the container management system's Android system reads files from the payment partition to start the MicroDroid payment system.

[0068] Step D: Add the following process to the payment system startup procedure: The container management system's Android system starts the MicroDroid payment system, first generating a random key from the TEE (TEE pre-sets a root key and key derivation algorithm). This key is also used for subsequent data security and secure communication. The integrity and signature of the payment system image are checked; in addition to checking the signature, verification is also performed with the TEE system. The TEE system has a preset system identifier. The container-specific SELinux is loaded. Step E: Upon startup, the Android system obtains the system's default identifier from both the SE (SE Linux) and the TEE, and then cross-verifies it (the SE also has a pre-configured key and derivative algorithm). If the cross-verification of the system identifier between the TEE and the SE fails, the Android system immediately unmounts the payment partition, sends a "container startup error" warning to the TEE, and prohibits subsequent container startup operations; if the partition integrity signature verification fails, a hardware-level lock is triggered (disabling the security chip via the SE). This includes: Step E-1: Pre-configure core data, including pre-configuring the root key on the TEE side and the root key on the SE side. On the container management module side, store the container's unique identifier (CID, generated by LXC when the container is created), and obtain the "container trusted startup credential" through the TEE (ensuring that the container startup process has not been tampered with).

[0069] Step E-2: The container management module generates verification request parameters, generates a random number (Nonce), and concatenates the verification request packet. The packet data includes CID + Nonce + timestamp, and performs Hash calculation on the request packet.

[0070] Step E-3: The container management module requests "TEE system identifier verification data" from the TEE. The container management module sends the verification request through the TEE, and the TEE returns the result after completing the identifier generation and signing. The TEE TA (Payment Management TA in the TEE) verifies whether H_req (the parameter passed to the signature verification request, the hash value of the request) matches the hash value of the request packet (ensuring the request has not been tampered with). If the verification passes, a hash algorithm is used, with K_tee_root as the root key and CID + Nonce (random number) as the salt, to derive the session key K_tee_session (the session key derived from the TEE). The ID_tee (system preset identifier) ​​is concatenated with the Nonce, and AES-GCM encryption is performed using K_tee_session to obtain the encrypted identifier E_tee. A TEE verification response packet is generated, including E_tee, IV, and authentication tag (IV (Initialization Vector, random number), which works with K_tee_session for AES-GCM encryption to ensure that the same plaintext generates different ciphertexts in different encryption scenarios, preventing attackers from cracking the encryption algorithm through ciphertext patterns). Step E-4: The container management module requests "SE system identifier verification data" from the SE. The SE verifies the MAC value and H_req (ensuring the legality of the command and the integrity of the request). If the verification passes, a hash algorithm is used, with K_se_root as the root key and CID+Nonce as the salt, to derive the session key K_se_session (because K_se_root and K_tee_root are from the same source and have the same salt value, K_se_session must be completely consistent with K_tee_session, which is the core prerequisite for cross-validation). The ID_se and Nonce are concatenated, and K_se_session is used for AES-GCM encryption to obtain the encrypted identifier E_se. The SE verification response is then returned to the container management module.

[0071] Step E-5: The container management module decrypts the TEE / SE verification data. First, it performs a session key consistency check: confirming that K_local_session and the key derived from TEE / SE are logically consistent. Second, it performs a system identifier integrity check: checking whether ID_tee_dec and ID_se_dec conform to the preset format.

[0072] Step F: Enhance the trusted verification of the TEE during container creation and startup, including: Step F-1: When an LXC container is created, the TEE generates a trusted identity certificate for the container (containing the container ID, namespace configuration hash, and security chip access permissions). The private key of the certificate is stored in the secure memory of the TEE, and the public key is written to the container configuration file. Step F-2: When the container starts, the Linux kernel needs to send the container certificate to the TEE, corresponding to step 110 above. The TEE verifies the certificate signature and configuration hash (to ensure that the container configuration has not been tampered with), and returns a "trusted credential" after successful verification; corresponding to step 120 above.

[0073] Step F-3: The kernel will only enable namespace-enhanced isolation and perform security chip driver binding after receiving the TEE trusted credential; otherwise, it will directly refuse container startup. This corresponds to step 130 above.

[0074] Step G: Strengthen Namespace isolation (the payment system container's process / resources are completely invisible to the Android system), corresponding to step 140 above. The main implementation method is as follows: Step G-1: The kernel namespace module adds the container_protected flag (set to true by LXC when the payment container is created).

[0075] Step G-2: Access Control: When the Android system wants to perform operations such as process invocation, IPC communication, or file system mounting, the Linux kernel checks whether the target object of the Android system's operation has a container namespace marker. If the target does not belong to a container marked with `container_protected=true`, it returns "Resource does not exist (ENOENT)". The host cannot be aware of container processes; the host is prohibited from joining the container's namespace through system calls, preventing "infiltration into the container". For example, when a host process (belonging to the `init_ns` root namespace) calls interfaces such as `proc` traversal (e.g., `ps`), `ptrace`, and `kill`, the Linux kernel checks the target process's namespace marker. If the target process belongs to a container with `container_protected=true`, it directly returns "Resource does not exist (ENOENT)".

[0076] Step H: Security Chip Control Enhancement: Modify the Linux kernel driver for the security chip to ensure that "device nodes are only visible to containers." Add permission verification to the driver: Add namespace verification logic to the open(), read(), and write() interfaces of the security chip driver to allow only the container's namespace to access it. Device Node Binding to Container: When LXC starts the container, the Linux kernel automatically binds the security chip's device node (e.g., / dev / securechip) to the container's namespace: / dev / securechip is visible normally inside the container, but the node does not exist in the host's / dev directory (or the node exists but cannot be opened).

[0077] Step 1: Cgroups resource blocking: Add the container_only flag to the Cgroups subsystems such as CPU, memory, and IO: Add this flag to the Cgroups group to which the container is bound; when the host process attempts to use Cgroups resources marked with the container_only flag, the Linux kernel directly restricts it.

[0078] Please refer to Figure 2 The present invention also provides an electronic device 400, including a memory 402 and a processor 401, and a computer program stored on the memory 402 and running on the processor 401. When the processor 401 executes the computer program, it implements the various steps of the container system security enhancement method described above.

[0079] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0080] In summary, this invention provides a method for enhancing the security of container systems and an electronic device. By introducing a TEE (Trusted Entity Environment) to perform hardware-level security verification of the container's trusted identity certificate, the trustworthiness of the container's startup source is ensured. The Linux kernel sets a trusted marker in the container's namespace based on the trusted credentials returned by the TEE, achieving a strong binding between container identity and resource access control. Compared to existing technologies where container startup relies on pure software verification, making it vulnerable to tampering, this application places the root of trust in the hardware security environment TEE, significantly improving the startup security and identity trustworthiness of the container system. Simultaneously, the access control mechanism based on the trusted marker enables the Linux kernel to implement more precise and secure dynamic management of container resources, effectively isolating untrusted container resource access, thereby enhancing the overall security protection capabilities of the container system. Building upon the existing "kernel-level isolation," a "hardware root trust and layered security protection" system is constructed using SE (Security Entity) and TEE, achieving hardware-level isolation and further enhancing security. It ensures the dedicated use of payment container resources and restricts the use of payment-specific security resources by the host's general-purpose system. Drivers for general-purpose devices such as cameras, displays, and TEEs utilize existing technologies, without restricting the host system and payment container's use of general-purpose device resources. Modify the kernel driver of the security chip to make the device node visible only to the container.

[0081] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for enhancing the security of a container system, characterized in that, Applied to electronic devices running Linux kernels, Android systems, containers, and TEEs, the method includes: The Linux kernel obtains the trusted identity certificate stored in the container during the container's startup phase and sends it to the TEE; The TEE performs signature verification on the received trusted identity certificate. If the verification is successful, the TEE returns the corresponding trusted credential to the Linux kernel. After receiving the trusted credential, the Linux kernel sets a trusted flag on the container's namespace; Based on the trusted tag, the Linux kernel receives the request from the Android system, starts the container, and performs access control and allocation on the container's resources.

2. The container system security enhancement method according to claim 1, characterized in that, Based on the trusted tag, the Linux kernel receives a request from the Android system, starts the container, and performs access control and allocation of resources within the container, including: The Linux kernel determines whether the trusted flag of the namespace to which the target object in the operation request received from the Android system belongs is a preset value. If so, it returns an operation failure response to the Android system.

3. The method for enhancing the security of a container system according to claim 1, characterized in that, Also includes: The Linux kernel adds namespace verification logic to the device node access interface in the Linux kernel driver. The namespace verification logic is configured to only allow the container's namespace to access the device node. When the container starts, the Linux kernel binds the device node to the container's namespace, making the device node visible within the container but invisible or inaccessible on the Android system.

4. The container system security enhancement method according to claim 1, characterized in that, Also includes: The Linux kernel sets a resource exclusivity flag in the corresponding Cgroups subsystem; The Linux kernel marks the Cgroups control group bound to the container as having the resource exclusive tag, thereby denying the Android system access to the Cgroups resource with the resource exclusive tag.

5. The container system security enhancement method according to claim 1, characterized in that, Also includes: During the container creation phase, the TEE generates a trusted identity certificate for the container and stores the public key of the trusted identity certificate in the container's configuration file. The TEE stores the private key corresponding to the trusted identity certificate in the TEE's secure memory and writes the corresponding public key into the container's configuration file. The TEE performs signature verification on the received trusted identity certificate, including: The TEE verifies the signature of the received trusted identity certificate based on the public key.

6. The method for enhancing the security of a container system according to claim 1, characterized in that, Prior to the container startup phase, the following is also included: The TEE performs signature verification on the system image file of the container and compares the hash value of the system image file with the hash value of a valid system image pre-stored in the TEE; If both the signature verification and the hash value comparison pass, the TEE notifies the Android system to start the system corresponding to the system image file; During the system startup process, the container-specific SELinux is loaded; The container management system of the Android system obtains a preset system identifier from SELinux and TEE respectively for cross-validation; If the cross-validation fails, the container management system unloads the container's partition, sends a container startup exception alarm to the TEE, and prohibits the container startup operation.

7. The method for enhancing the security of a container system according to claim 6, characterized in that, The container management system of the Android system obtains a preset system identifier from SELinux and the TEE respectively for cross-validation, including: The container management system generates a verification request containing the container's unique identifier, a random number, and a timestamp, and performs a hash operation on the verification request to obtain a request hash value; The container management system sends a verification request containing the request hash value to the TEE and the SELinux, respectively. The TEE derives a first session key based on a preset first root key and parameters obtained from the verification request, and uses the first session key to encrypt a preset TEE system identifier to generate a first encrypted identifier. The SELinux derives a second session key based on a preset second root key and the same parameters obtained from the verification request, and uses the second session key to encrypt a preset SELinux system identifier to generate a second encrypted identifier. The container management system receives and decrypts the first encrypted identifier and the second encrypted identifier, and verifies whether the two system identifiers obtained by decryption both conform to the preset format. If both conform, cross-validation is completed.

8. A method for enhancing the security of a container system according to claim 6, characterized in that, Also includes: The Android system checks the integrity signature of the container-managed partition; If the check passes, the Android system mounts the container management partition and the payment partition. The container management partition stores the root file system of the container management system, and the payment partition stores the root file system of the payment system. The Android system executes the initialization program within the container management partition to start the container management system; The container management system reads files from the payment partition to start the payment system.

9. A method for enhancing the security of a container system according to claim 8, characterized in that, Also includes: During the startup phase of the Android system, the Android system does not mount the container management partition and the payment partition.

10. A method for enhancing the security of a container system according to claim 8, characterized in that, The payment system includes a system implemented based on an extension of the MicroDroid system.

11. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements a container system security enhancement method according to any one of claims 1 to 10.

Images