Safety environment implementation method based on AVF and open source gap and electronic equipment

Abstract

The invention provides a secure environment implementation method based on an AVF and an open source gap, and the method is applied to electronic equipment, and comprises the steps: operating an open source gap system in a secure virtual machine of an Android system; establishing an inter-process communication link between the Android system and an open source gap system based on the virtualization framework of the Android system; and through the inter-process communication link, interaction between the application on the open source gap system side and the application on the open source gap system side in the secure virtual machine is realized. According to the application, the single mobile computing device can simultaneously meet the dual requirements on the safety purity of the system and the richness of the ecological function of the application.

Description

Technical Field

[0001] This invention relates to the field of mobile terminal operating systems, and in particular to a method and electronic device for implementing a secure environment based on AVF and the open-source HarmonyOS. Background Technology

[0002] As mobile terminal functions become increasingly complex, the business scenarios they need to undertake are showing a trend of polarization: on the one hand, in scenarios such as financial payment, digital certificates, and private communication, the business places extremely high demands on the security, purity, and trustworthiness of the operating system; on the other hand, in scenarios such as entertainment, social interaction, and office work, users have a strong reliance on the rich application ecosystem and diverse functions of the operating system.

[0003] However, existing mobile devices typically only run a single operating system framework (such as Android). This architecture has inherent limitations: to accommodate a rich application ecosystem, the system must open up sufficient permissions and interfaces, but this also increases the risk of attacks and makes it difficult to guarantee its security and purity; conversely, if the system is deeply locked and trimmed for security, its application compatibility and feature richness will be sacrificed.

[0004] In other words, the two core requirements of security and purity versus rich functionality are difficult to achieve simultaneously within a single system framework, creating a fundamental contradiction. Existing technologies cannot enable a single device to meet these two distinctly different and highly demanding system requirements at the same time. Summary of the Invention

[0005] The technical problem this invention aims to solve is to provide a secure environment implementation method and electronic device based on AVF and the open-source HarmonyOS, enabling a single mobile computing device to simultaneously meet the dual requirements of system security and purity as well as rich application ecosystem functionality. This solution is based on the Android AVF virtualization framework, running OpenHarmony as a dedicated financial payment system within pVM (protected virtual machine), and achieving a secure payment environment through hardware-level isolation and dual-system collaboration.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for implementing a secure environment based on AVF and the open-source HarmonyOS, applied to electronic devices, includes: Running the open-source HarmonyOS system in a secure virtual machine within the Android system; An inter-process communication link between the Android system and the open-source HarmonyOS system is established based on the virtualization framework of the Android system. The inter-process communication link enables interaction between the application on the open-source HarmonyOS system side and the application on the open-source HarmonyOS system side in the secure virtual machine.

[0007] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the various steps in the above-described method for implementing a security environment based on AVF and open-source HarmonyOS.

[0008] The beneficial effects of this invention are as follows: This method constructs a dual-system collaborative architecture that combines rich functionality and security by running the open-source HarmonyOS system in a secure virtual machine of the Android system; the inter-process communication link established based on the Android system virtualization framework realizes efficient and reliable interaction between the two systems; and finally, application layer service calls are completed through this link, enabling the device to maintain the integrity of the Android application ecosystem while providing a hardware-level isolation environment for the security-sensitive businesses of the open-source HarmonyOS system, effectively solving the industry problem that a single mobile operating system cannot simultaneously take into account the richness of the ecosystem and the security of the system. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the steps of a method for implementing a secure environment based on AVF and open-source HarmonyOS, as provided in this embodiment of the invention; Figure 2 The first part of the framework diagram of a security environment implementation method based on AVF and open-source HarmonyOS provided in the embodiments of the present invention; Figure 3 The second part of the framework diagram of a security environment implementation method based on AVF and open-source HarmonyOS provided for embodiments of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] The following explains the definitions of terms used in this application.

[0015] AVF: Android Virtualization Framework, is the underlying virtualization solution provided by the Android system for creating and managing secure virtual machines.

[0016] pvmfw: Protected VM Firmware, is the initial root of trust when a secure virtual machine starts up in the AVF architecture, and is responsible for establishing the secure execution environment of the virtual machine.

[0017] TEE: Trusted Execution Environment, a secure zone provided by hardware isolation technology for processing sensitive data and performing security-critical operations.

[0018] SE: Secure Element, is a tamper-proof hardware security chip that provides the highest level of protection for data storage and cryptographic operations.

[0019] HAP: Harmony Ability Package, an open-source HarmonyOS application installation package format that includes application code, resources, and configuration files.

[0020] Binder: A unique inter-process communication mechanism in the Android system that supports remote procedure calls and service management.

[0021] vSock: Virtual Socket, is a socket communication mechanism provided by the Linux kernel between a virtual machine and the host machine.

[0022] zipfuse: A module developed based on FUSE (Userspace File System) for mounting ZIP format installation packages as virtual directories.

[0023] microDroid_manager: The resource management module of the MicroDroid operating system, responsible for the scheduling and allocation of virtual machine resources.

[0024] pKVM: Protected Kernel Virtual Machine, is an enhanced virtualization solution based on Linux KVM (Kernel-based Virtual Machine). It runs as a protected domain in the ARM CCA architecture, providing a hardware-isolated execution environment for secure virtual machines.

[0025] Hypervisor: A virtual machine monitor is system software that runs between a physical server and an operating system. It allows multiple virtual machines to share the same hardware resources and is responsible for managing the lifecycle, resource allocation, and isolation protection of virtual machines.

[0026] Foundation process: The core system service process in the open-source HarmonyOS system architecture. In the native single-system environment, it is responsible for unified resource scheduling, system service management, and application lifecycle management. In the dual-system collaborative adaptation, it was removed because its resource scheduling mode was incompatible with the virtualization environment.

[0027] Init process: The first user-space process of the open-source HarmonyOS system, with process ID 1, is responsible for parsing initialization configuration files, mounting file systems, starting critical system services, and undertaking system security hardening configuration responsibilities in this solution, including setting read-only partitions and filtering device hot-plug events.

[0028] In related technologies, mobile operating systems typically employ a single system architecture to meet the needs of various application scenarios. Android dominates the market thanks to its rich application ecosystem, but in scenarios with extremely high security requirements, such as financial payments and digital certificates, its open nature becomes a security concern. Conversely, while the open-source HarmonyOS, designed specifically for IoT and embedded devices, has advantages in security, its application ecosystem is relatively weak, making it difficult to meet the diverse functional needs of users.

[0029] Currently, the industry is attempting to achieve multi-system coexistence through virtualization technology, but significant technical bottlenecks exist on mobile terminal devices. First, traditional virtualization solutions struggle to achieve efficient collaborative operation of two complete operating systems on resource-constrained mobile terminals, resulting in high inter-system communication overhead and low resource scheduling efficiency. Second, security isolation mechanisms are inadequate, potentially leading to mutual interference and data leakage risks between systems. Particularly in the system startup verification phase, existing solutions lack a complete trust chain construction mechanism, failing to ensure a trustworthy foundation for the operating environment.

[0030] Furthermore, in terms of application ecosystem integration, existing technologies cannot achieve seamless collaboration between Android system applications and open-source HarmonyOS applications on a single device. The application installation and management process is complex, and the lack of a unified security verification mechanism makes it difficult to guarantee overall system security. Especially in sensitive scenarios such as financial payments, existing solutions cannot simultaneously meet the dual requirements of a rich application ecosystem and system security.

[0031] Regarding system communication architecture, existing cross-system communication solutions mostly employ traditional Socket communication methods, which suffer from low communication efficiency and insufficient security. Furthermore, the lack of effective coordination mechanisms for resource management between systems easily leads to resource conflicts and performance degradation. These technical shortcomings limit the practical application of dual-system architectures on mobile terminal devices.

[0032] To address the aforementioned problems, this application provides a method and electronic device for implementing a secure environment based on AVF and the open-source HarmonyOS. The following section details one such method.

[0033] The secure environment implementation method based on AVF and open-source HarmonyOS in this application can be used in financial payment electronic devices. The electronic device described in this application can be a financial payment electronic device that deploys core payment functions such as payment transaction processing, password keyboard driver, and sensitive data storage in a secure virtual machine environment, and needs to run both a general Android system application and a highly secure open-source HarmonyOS system application simultaneously. Examples include dual-ecosystem financial payment terminals that run the core payment module in a secure virtual machine, smart retail devices that ensure transaction security through a secure virtual machine, and industrial control terminals that employ a dual-system architecture to ensure the security of control commands, etc.

[0034] The following details a method for implementing a secure environment based on AVF and the open-source HarmonyOS, as described in this invention. Figure 1 This includes steps 101 to 103.

[0035] Step 101: Run the open-source HarmonyOS system in a secure virtual machine within the Android system. This step establishes the basic execution environment for dual-system coexistence, with the open-source HarmonyOS system running as the client system within a protected trusted execution environment.

[0036] Step 102: Establish an inter-process communication link between the Android system and the open-source HarmonyOS system based on the Android system's virtualization framework. In specific implementation, this virtualization framework is the Android Virtualization Framework (AVF), which builds a cross-system communication channel through the virtualization capabilities provided by the hypervisor layer.

[0037] Step 103: Enable interaction between Android system-side applications and open-source HarmonyOS system services within the secure virtual machine via an inter-process communication link. During implementation, security-sensitive function call requests issued by Android system-side applications are routed through this link to the corresponding services on the open-source HarmonyOS side for processing.

[0038] This embodiment constructs a complete dual-system collaborative architecture through steps 101 to 103 described above. This method organically combines the rich application ecosystem of the Android system with the high-security environment of the open-source HarmonyOS system, enabling a single electronic device to simultaneously meet both general functional requirements and security-sensitive business needs. It provides a hardware-level security isolation solution for scenarios such as financial payments and digital certificates.

[0039] In one embodiment of this application, the startup process of the open-source HarmonyOS system is further described in detail, including steps 201 to 203.

[0040] Step 201: In the secure boot chain of the open-source HarmonyOS system, port the verification function of the original operating system of the secure virtual machine for the secure virtual machine firmware. In specific implementation, the verification logic of MicroDroid for the pvmfw firmware is integrated into the image signature verification area of ​​the secure boot chain of the open-source HarmonyOS system.

[0041] Step 202: Verify the digital signature of the secure virtual machine firmware using the ported verification function. This verification process uses a hardware-fused RSA public key to check the firmware integrity, ensuring the trustworthiness of the underlying virtualization environment.

[0042] Step 203: After successful verification, the bootloader stage of the open-source HarmonyOS system is initiated. This stage uses a Linux kernel that is from the same source as the Android system's general kernel image, ensuring full support for the pKVM virtualization architecture.

[0043] This embodiment establishes a complete trusted boot chain through steps 201 to 203. By reconstructing the boot process, this method transforms the open-source HarmonyOS system from a verified entity into an active verifier, ensuring a complete trust chain from the firmware layer to the system layer, and providing a reliable security foundation for a dual-system collaborative environment.

[0044] In one embodiment of this application, the system legitimacy verification mechanism is described in detail, including steps 301 to 306.

[0045] Step 301: After the open-source HarmonyOS system starts, the system version and firmware identification information are used as query credentials. This credential contains metadata information that can uniquely identify the system instance.

[0046] Step 302: Send the query credentials to the secure element through a secure channel between the secure virtual machine and the secure element. This secure channel is established based on vSock sockets and the Binder communication mechanism.

[0047] Step 303: The secure element queries the internally stored list of legitimate secure virtual machines based on the query credentials. This list is encrypted and stored using the secure element master key at the time of device shipment and can be updated via OTA.

[0048] Step 304: When the query credentials match an entry in the list of legitimate secure virtual machines, the security element generates a verification pass instruction.

[0049] Step 305: The secure element returns the verification pass instruction to the secure virtual machine through the secure channel.

[0050] Step 306: After receiving the verification pass instruction, the secure virtual machine establishes an inter-process communication link between the Android system and the open-source HarmonyOS system.

[0051] This embodiment implements runtime system legitimacy verification through steps 301 to 306. This method establishes a whitelist-based system authorization mechanism by leveraging the hardware-level secure storage and computing capabilities provided by the secure element, preventing unauthorized system instances from accessing sensitive resources and enhancing the security protection capabilities of the dual-system collaborative environment.

[0052] In one embodiment of this application, the specific implementation of the inter-process communication link is described in detail, including steps 401 to 403.

[0053] Step 401: Port the Android Binder communication mechanism to the open-source HarmonyOS system. This porting includes adapting components such as the Binder driver, service manager, and interface definition language to the open-source HarmonyOS environment.

[0054] Step 402: Configure the Linux kernel's vSock virtual socket as the underlying transport channel. vSock utilizes virtualized network devices provided by the hypervisor to achieve cross-system data transfer.

[0055] Step 403: Establish a complete inter-process communication link through the coordinated operation of vSock and Binder communication mechanisms. Binder is responsible for the serialization and deserialization of remote procedure calls, while vSock provides reliable data transmission.

[0056] This embodiment constructs an efficient cross-system communication scheme through steps 401 to 403. This method utilizes the mature Binder IPC mechanism and virtualized network technology to achieve transparent service calls between the Android system and the open-source HarmonyOS system, ensuring both communication performance and maintaining secure isolation between the systems.

[0057] In one embodiment of this application, the security hardening configuration of the open-source HarmonyOS system is described in detail, including steps 501 to 502.

[0058] Step 501: In the Init process of the open-source HarmonyOS system, identify the system image partition that stores the system's core files. This partition typically contains read-only content such as the system framework, core libraries, and pre-installed applications.

[0059] Step 502: Configure the identified system image partition as read-only. Use the mount command to set file system mount parameters to prevent any modification to the system's core files.

[0060] This embodiment implements system-level security protection through steps 501 to 502. By restricting write permissions to critical system areas, this method effectively prevents malicious software from tampering with system files, thereby improving the integrity and reliability of the open-source HarmonyOS system in a virtualized environment.

[0061] In one embodiment of this application, the optimized configuration of resource management is further illustrated, including steps 601 to 606.

[0062] Step 601: In the Init process, identify the types of hardware device hot-plug events managed by the Android system host system. This includes status change notifications from physical peripherals such as USB devices and network devices.

[0063] Step 602: Configure the open-source HarmonyOS system to ignore identified hot-plug events. By modifying the ueventd configuration or registering a filter, related events can be blocked from propagating to user space.

[0064] This embodiment optimizes resource management in the virtualization environment through steps 601 to 602. This method reduces system overhead by streamlining unnecessary device management functions, avoids resource management conflicts between the virtual machine and the host system, and improves the collaborative efficiency of the two systems.

[0065] In one embodiment of this application, the adaptation of the resource scheduling mechanism is described in detail, including steps 701 to 704.

[0066] Step 701: Port the resource management module of the original operating system of the secure virtual machine to the open-source HarmonyOS system. In specific implementation, the microDroid_manager module of MicroDroid will be integrated into the service layer of the open-source HarmonyOS system.

[0067] Step 702: Remove the original foundation process from the open-source HarmonyOS system. This process is responsible for resource scheduling in the native open-source HarmonyOS system, but its functions overlap in the virtualization environment.

[0068] Step 703: The ported management module acts as a proxy to request resources from the Android host system. It requests hardware resource quotas such as CPU and memory from the host through the hypervisor interface.

[0069] Step 704: The management module is responsible for the allocation and scheduling of resources within the secure virtual machine. It performs secondary allocation and management of resources within the virtual machine based on application requirements.

[0070] This embodiment reconstructs the resource scheduling mechanism through steps 701 to 704. By introducing a resource manager specifically for the virtualization environment, this method establishes a resource request and allocation mechanism oriented towards virtualization, improving the efficiency and rationality of resource utilization in a dual-system collaborative environment.

[0071] In one embodiment of this application, the installation mechanism of the open-source HarmonyOS system application is described in detail, including steps 801 to 804.

[0072] Step 801: Prepare the open-source HarmonyOS application installation package using a manager application deployed on the Android system side. This manager application is responsible for the lifecycle management of the secure virtual machine and application deployment.

[0073] Step 802: The manager application imports the open-source HarmonyOS system application installation package into the secure virtual machine. Cross-system file transfer is achieved through the data sharing mechanism provided by the virtualization platform.

[0074] Step 803: On the secure virtual machine side, the installation package is processed using the ported zipfuse module. The zipfuse module mounts HAP format compressed packages as a virtual file system.

[0075] Step 804: Complete the application installation through the file system interface provided by the zipfuse module. The system reads the application files from the virtual file system and completes the installation process.

[0076] This embodiment achieves cross-system application deployment through steps 801 to 804. This method utilizes user-space file system technology to simplify the application installation process, maintains compatibility with the native open-source HarmonyOS application format, and provides a unified application management solution for dual-system collaborative environments.

[0077] In one embodiment of this application, a security verification mechanism for application installation is described in detail, including steps 901 to 904.

[0078] Step 901: Verify the installation permissions of the manager application through the application installation management module on the Android system side. Verify whether the manager application initiating the application installation operation has the corresponding permissions.

[0079] Step 902: After the permission verification is successful, the manager application imports the open-source HarmonyOS system application installation package into the secure virtual machine.

[0080] Step 903: On the secure virtual machine side, perform application signature verification on the imported installation package using the zipfuse module. Verify the application's integrity and authenticity using the developer's digital certificate.

[0081] Step 904: As an alternative or supplementary solution, perform a whitelist check. Verify that the application identifier matches the list of applications allowed to be installed under the device policy.

[0082] This embodiment establishes a multi-layered security verification mechanism through steps 901 to 904. This method, through a combination of access control, signature verification, and whitelist checks, ensures that only legitimate and trusted applications can run in the secure virtual machine, thus maintaining the security of the open-source HarmonyOS environment.

[0083] The following combination Figure 2 and Figure 3 (A framework for implementing a secure environment based on AVF and open-source HarmonyOS) introduces the system architecture and details the specific implementation logic of the invention step by step.

[0084] This architecture diagram fully illustrates the overall structure of the dual-system collaborative financial payment system based on Android AVF. The system adopts a layered design and includes the following three core components: 1. System Overall Layering As can be seen from the architecture diagram, the system is divided into three main worlds: HardWare Secure World: Located at the bottom of the diagram, it includes TEE (Trusted Execution Environment) and SE (Secure Element).

[0085] The TEE side includes the original TA (such as the certificate key management TA) and the newly added pVM-TEE communication TA.

[0086] The SE side includes the original modules and the newly added pVM-SE communication module and pVM system identification module.

[0087] Non-Secure World: The left-hand area runs the Android operating system (REE) as a general business environment.

[0088] Secure World-Protected VM: The right-hand area runs the open-source HarmonyOS (pVM) as a dedicated environment for financial payments.

[0089] 2. REE Android system side (Non-Secure World) Android payment acquiring application (APK): A user application that calls financial payment APIs.

[0090] Android APIs: Native Android APIs used for general functions.

[0091] Android native components: including system services such as the Android system runtime.

[0092] Key new modules: pVM Management Module: Manages the lifecycle of pVM (startup, shutdown).

[0093] Android application installation management module: Connects to zipfuse on the pVM side to verify APK installation permissions (through whitelisting or signing).

[0094] API bridging module: Relays financial payment API requests initiated by Android system applications to the pVM side, and verifies the legitimacy of the pVM system before forwarding.

[0095] pVM-HardWare Secure World secure channel module: handles secure communication between pVM and TEE / SE, with data encrypted on the REE side.

[0096] 3. pVM (Secure World-Protected VM) is an open-source version of the HarmonyOS system. The open-source HarmonyOS acquiring application (HAP) is launched through an Android system container (APK) and runs within the pVM.

[0097] OpenHarmony APIs: Native open-source HarmonyOS system APIs.

[0098] Financial Payment APIs: APIs specifically designed for financial payments, consistent with the financial payment APIs on the Android system side.

[0099] Financial management components include access control, log management, data collection, terminal management, and digital signatures, enabling secure and compliant management of financial terminals.

[0100] Financial payment components: including financial equipment services, EMV modules, financial algorithms, etc., providing payment business functions.

[0101] Financial Equipment Management Module: Manages financial equipment such as magnetic card modules, IC card modules, and contactless card modules, and communicates with the SE through the pVM-SE channel.

[0102] pVM-SE communication module and pVM-TEE communication module: handle secure communication with SE / TEE, with encryption keys negotiated by both parties.

[0103] API bridging component: Receives API requests forwarded from the Android system and calls the corresponding financial components.

[0104] Porting modules include Binder (for IPC communication), zipfuse (for HAP installation), authfs (for file sharing), and OpenHarmony_manager (for resource management), which are adapted from microDroid OS to the open-source HarmonyOS system.

[0105] Based on the above system architecture, the specific implementation logic of this invention is executed in the following steps: Step 1 corresponds to step 101 above: running the open-source HarmonyOS system in the secure virtual machine of the Android system.

[0106] Step 1: System startup and pVM legitimacy verification: Start the open-source HarmonyOS operating system in the Android system's secure virtual machine (pVM).

[0107] In the secure boot chain of the open-source HarmonyOS system, MicroDroid's verification logic for pvmfw is ported to verify the pVM firmware.

[0108] After the open-source HarmonyOS system within pVM starts, it generates fingerprint information containing the system version and firmware identifier.

[0109] The fingerprint information is sent to the pVM system identification module of the SE for query and verification through a secure channel between the pVM and the secure element (SE).

[0110] If the SE verifies that the current pVM system is a legitimate system, it will allow subsequent communication and API calls; otherwise, it will return an error.

[0111] Step 2 corresponds to step 102 above: establishing an inter-process communication link between the Android system and the open-source HarmonyOS system based on the Android system's virtualization framework.

[0112] Step 2: Establish cross-system communication links: Porting the Android Binder communication mechanism within the open-source HarmonyOS system of pVM.

[0113] An inter-process communication (IPC) link is established between the Android system and the open-source HarmonyOS system through the Linux kernel's virtual socket (vSock) and Binder mechanism.

[0114] Steps 3 to 7 correspond to step 103 above: Through inter-process communication links, the interaction between Android system-side applications and open-source HarmonyOS system-side system services in the secure virtual machine is realized.

[0115] Step 3: Android System Application (APK) Installation Management: When the Package Management Service (PMS) on the Android system side installs an APK, the newly added APK installation management module is invoked.

[0116] The APK installation management module sends the package name and signature information of the APK to be installed to the zipfuse module on the pVM side through the communication link established in step 2.

[0117] The zipfuse module verifies the signature based on the financial custom signature or queries the application whitelist to determine whether installation is allowed and returns the result.

[0118] If installation is allowed, PMS will continue with the native installation process.

[0119] Step 4: Install the open-source HarmonyOS application (HAP): Install and run open-source HarmonyOS applications (HAP) through a dedicated Android system container (APK).

[0120] Users install the Android system container APK.

[0121] When the container APK starts, it launches its associated pVM through the AVF mechanism and establishes a communication channel between the REE side and the pVM side.

[0122] The pVM side of the container APK calls the ported zipfuse module to install the HAP installation package.

[0123] The zipfuse module performs signature verification on HAP installation packages and parses and records the permission information in their profiles.

[0124] Step 5: Android system application calls financial payment API: Android acquiring applications (APKs) call financial payment APIs (such as obtaining TUSN MAC).

[0125] The API bridging module on the Android system side captures this request.

[0126] Before forwarding the request, the API bridging module obtains the currently running pVM system information through the pVM management module and requests the SE's pVM system identification module for verification via the SE's secure channel.

[0127] After successful verification, the API bridging module forwards the API request and application package name to the API bridging component on the pVM side through the communication link established in step 2.

[0128] The permission management module on the pVM side queries the application's permissions based on the application package name. If the application has permission to call the application, the API bridging component calls the terminal management module to execute the corresponding function.

[0129] The terminal management module communicates with the SE through the pVM-SE secure channel, performs specific operations (such as calculating the TUSN MAC), and returns the results layer by layer to the Android system application.

[0130] Step 6: Open-source HarmonyOS system applications call financial payment APIs: The open-source HarmonyOS acquiring application (HAP) directly calls the financial payment API on the pVM side.

[0131] The permission management module on the pVM side verifies application permissions.

[0132] Once the verification is successful, the API will be executed directly by the corresponding financial management component or financial payment component (such as the terminal management module).

[0133] The terminal management module communicates with the SE through the pVM-SE secure channel, performs specific operations, and returns the results to the open-source HarmonyOS system application.

[0134] Step 7: Secure Communication Between the System and Hardware Security World When components within the pVM need to communicate with the TEE or SE, they do so through the corresponding secure channels.

[0135] pVM-TEE Communication: Data is transmitted via the pVM-TEE communication module of pVM, the pVM-HardWare SecureWorld secure channel module of REE, and the pVM-TEE communication TA of TEE, and is encrypted on the REE side.

[0136] pVM-SE communication: Data is transmitted via the pVM-SE communication module of pVM, the pVM-HardWare Secure World secure channel module of REE, and the pVM-SE communication module of SE, and is encrypted on the REE side.

[0137] The encryption key is negotiated and generated by the two communicating parties (pVM and TEE, or pVM and SE) when the channel is established.

[0138] Through the collaborative work of the above seven steps, the dual-system collaborative system of this invention achieves secure isolation and efficient collaboration between the Android system and the open-source HarmonyOS system, maintaining the rich application ecosystem of the Android system while providing a financial-grade secure payment environment through the open-source HarmonyOS system.

[0139] Please refer to Figure 4 The present invention also provides an electronic device, including a memory, a processor, and a computer program stored on the memory and running on the processor. When the processor executes the computer program, it implements the various steps in the above-described method for implementing a secure environment based on AVF and open-source HarmonyOS.

[0140] 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.

[0141] In summary, this application provides a method for implementing a secure environment based on AVF and the open-source HarmonyOS. By constructing a dual-system architecture based on a secure virtual machine, it enables mobile terminal devices to maintain the integrity of the Android system application ecosystem while obtaining high security guarantees from the open-source HarmonyOS system. This method establishes a trusted execution environment by reconstructing the secure boot chain of the open-source HarmonyOS system, establishes a cross-system communication mechanism based on the AVF virtualization framework, and adopts a layered security verification strategy, effectively solving the technical challenge of a single mobile operating system being unable to simultaneously achieve rich functionality and reliable security. Compared with existing technologies, this solution significantly improves system isolation, communication efficiency, and security, providing an ideal terminal system solution for sensitive business scenarios such as financial payments and digital certificates.

[0142] 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 implementing a secure environment based on AVF and the open-source HarmonyOS, characterized in that, Applied to electronic devices, the method includes: Running the open-source HarmonyOS system in a secure virtual machine within the Android system; An inter-process communication link between the Android system and the open-source HarmonyOS system is established based on the virtualization framework of the Android system. The inter-process communication link enables interaction between applications on the Android system side and applications on the open-source HarmonyOS system side in the secure virtual machine.

2. The method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 1, characterized in that, Running the open-source HarmonyOS system in a secure virtual machine within the Android system includes: In the secure boot chain of the open-source HarmonyOS system, the verification function of the original operating system of the secure virtual machine for the secure virtual machine firmware is ported, and the secure virtual machine firmware is verified according to the verification function. After successful verification, the bootloader phase of the open-source HarmonyOS system is initiated.

3. The method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 1, characterized in that, The establishment of an inter-process communication link between the Android system and the open-source HarmonyOS based on the virtualization framework of the Android system includes: After the open-source HarmonyOS system is started, the open-source HarmonyOS system version and firmware identification information are used as query credentials, and the query credentials are sent to the secure element through the secure channel between the secure virtual machine and the secure element. The security element queries the internally stored list of legitimate and secure virtual machines based on the query credentials. If the query credential matches an entry in the list of legitimate secure virtual machines, the secure element generates a verification pass instruction and returns the verification pass instruction to the secure virtual machine through the secure channel; After the secure virtual machine receives the verification pass instruction, it establishes an inter-process communication link between the Android system and the open-source HarmonyOS system.

4. The method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 1, characterized in that, The method of establishing an inter-process communication link between the Android system and the open-source HarmonyOS system based on the Android system virtualization framework also includes: Porting the Android Binder communication mechanism into the open-source HarmonyOS system; An inter-process communication link is established using the Linux kernel's virtual sockets and the Binder communication mechanism.

5. The method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 1, characterized in that, The description of running the open-source HarmonyOS system in a secure virtual machine of the Android system also includes: In the Init process of the open-source HarmonyOS system, the system image partition storing the core files of the open-source HarmonyOS system is configured to read-only access mode.

6. A method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 5, characterized in that, Running the open-source HarmonyOS system in a secure virtual machine within the Android system also includes: In the Init process, the open-source HarmonyOS is configured to ignore hot-plug events of hardware devices managed by the Android system.

7. A method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 5, characterized in that, Also includes: The management module of the original operating system of the secure virtual machine was ported to the open-source HarmonyOS system; Remove the original basic service processes of the open-source HarmonyOS system, and have the ported management module act as an agent to request resources from the host system of the Android system and manage the resources in the secure virtual machine.

8. A method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 1, characterized in that, Also includes: The open-source HarmonyOS application installation package is imported into the secure virtual machine by a manager application deployed on the Android system side and used to manage the lifecycle of the secure virtual machine; On the secure virtual machine side, the open-source HarmonyOS application is installed using the ported zipfuse module.

9. A method for implementing a secure environment based on AVF and open-source HarmonyOS according to claim 8, characterized in that, Also includes: The application installation management module on the Android system side verifies the installation permissions of the manager application and performs application signature verification or whitelist check on the open-source HarmonyOS application installation package. After successful verification, the manager application imports the installation package into the secure virtual machine; On the secure virtual machine side, the imported open-source HarmonyOS application installation package is again verified for application signature or checked for whitelist through the zipfuse module. If the signature verification or whitelist check passes, the open-source HarmonyOS application installation package will be installed in the secure virtual machine.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the security environment implementation method based on AVF and open-source HarmonyOS as described in any one of claims 1-9.

Images