Application management method based on openharmony system and electronic device

Abstract

The application discloses an application management method based on an OpenHarmony system and electronic equipment. The method comprises the following steps: obtaining a historical package name list, wherein the historical package name list comprises application information of historical installation of the electronic equipment; obtaining an application to be installed; if a purchaser signature does not exist in the application to be installed, it is judged whether a developer signature exists in the application to be installed; if the developer signature exists in the application to be installed, it is judged whether first application information corresponding to the application to be installed exists in the historical package name list; and if the first application information exists, the application to be installed is determined as a safe application. The application can simplify the application signature verification process and improve the development efficiency of the application.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to an application management method based on an OpenHarmony system and an electronic device. BACKGROUND

[0002] The main purchasers of financial terminals are banks, third-party payment service providers, and related Internet companies. When purchasing financial terminals, these purchasers require that the financial terminals can only download and install applications that belong to their own property rights. Therefore, the purchasers need to centrally manage the applications installed on the financial terminals. In order to realize centralized management of applications in the financial terminals, an application digital signature scheme is introduced in the process of installing applications, and the purchaser needs to sign each time the application is updated and installed.

[0003] In related technologies, when developing business applications for financial terminals, manufacturers need to install different business applications on the financial terminals for testing. Due to the existence of the application signature scheme, the manufacturer needs to sign the purchaser each time the application is installed or updated on the financial terminal, which causes the installation process of the application to be cumbersome, the development efficiency of the application to be low, and the financial terminal to be unable to install applications other than the purchaser's applications. SUMMARY

[0004] The technical problem to be solved by the present application is to provide an application management method based on an OpenHarmony system and an electronic device, which can simplify the application signature verification process and improve the development efficiency of the application.

[0005] To solve the above technical problems, one technical solution adopted by the present application is:

[0006] An application management method based on an OpenHarmony system, for an electronic device using an OpenHarmony system, comprising:

[0007] Obtaining a historical package name list, the historical package name list including application information of historical installations of the electronic device;

[0008] Obtaining an application to be installed, and if the application to be installed does not exist a purchaser signature, determining whether the application to be installed exists a developer signature;

[0009]

[0009] If the application to be installed exists a developer signature, determining whether there is first application information corresponding to the application to be installed in the historical package name list;

[0010] If the first application information exists, determining the application to be installed as a safe application.

[0011] Another technical solution adopted by the present application to solve the above technical problems is:

[0012] An electronic device includes a memory, a processor, and a computer program stored on the memory and running on the processor, and the processor implements each step of the above application management method based on the OpenHarmony system when the computer program is executed.

[0013] The application has the beneficial effect that the historical package name list records the historical installation application information of the electronic device, and the application obtains the historical package name list and the to-be-installed application, judges whether the to-be-installed application contains a developer signature when the to-be-installed application does not contain a purchaser signature, judges whether the first application information corresponding to the to-be-installed application exists in the historical package name list when the to-be-installed application contains the developer signature, and determines the to-be-installed application as a safe application when the first application information exists. Therefore, the method of the application can directly determine the to-be-installed application as a safe application through the developer signature when the first application information corresponding to the to-be-installed application exists in the historical package name list, thereby realizing application installation. The application does not need to verify the purchaser signature when performing secondary installation of the application that has been historically installed, simplifies the verification process of the secondary installation application, and therefore the manufacturer does not need to repeatedly sign the application with the purchaser when developing the application, thereby effectively improving the development efficiency of the application. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 The flowchart of the application management method based on the OpenHarmony system is provided for the embodiments of the application.

[0015] Figure 2 The schematic diagram of the secondary installation of the application containing only the developer signature is provided for the embodiments of the application.

[0016] Figure 3 The schematic diagram of the first installation of the application containing only the developer signature is provided for the embodiments of the application.

[0017] Figure 4 The schematic diagram of the secondary installation of the application containing only the purchaser signature is provided for the embodiments of the application.

[0018] Figure 5 The schematic diagram of the first installation of the application containing only the purchaser signature is provided for the embodiments of the application.

[0019] Figure 6 The schematic diagram of the first installation of the application containing the developer signature and the purchaser signature is provided for the embodiments of the application.

[0020] Figure 7Another flowchart of the application management method based on the OpenHarmony system provided by the embodiment of the present application is provided.

[0021] Figure 8 An application package schematic diagram of an application to be installed app1 provided by the embodiment of the present application is provided.

[0022] Figure 9 An application package schematic diagram of an application to be installed app2 provided by the embodiment of the present application is provided.

[0023] Figure 10 An application package schematic diagram of an application to be installed app3 provided by the embodiment of the present application is provided.

[0024] Figure 11 An application package schematic diagram of an application to be installed app4 provided by the embodiment of the present application is provided.

[0025] Figure 12 A structural schematic diagram of an electronic device provided by the embodiment of the present application is provided.

[0026] Label explanation:

[0027] 100, an electronic device; 101, a memory; 102, a processor. DETAILED DESCRIPTION

[0028] In order to make the technical problems, technical solutions and beneficial effects to be solved in the present application clearer, the present application will be further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0029] In the following description, specific details such as specific system structures, techniques, etc. are presented in order to facilitate a thorough understanding of the embodiments of the present application for the purpose of explanation rather than for the purpose of limitation. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits and methods are omitted in order not to obscure the description of the present application with unnecessary details.

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

[0031] Reference within the specification of this application to "one embodiment" or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" or "in some embodiments" in various places within specified descriptions are not necessarily all referring to the same embodiment, however, but can refer to one or more but not all embodiments. The terms "including," "comprising," "carrying," "having," "containing," and variations thereof are meant to encompass the item listed thereafter but do not exclude additional, unrecited items. The terms "a" or "an," as used herein in the specification, mean "one or more."

[0032] The main purchasers of the financial terminal are banks, third-party payment service providers, and related Internet companies. When purchasing the financial terminal, these purchasers require that the financial terminal can only download and install applications that belong to the own property of the purchaser. Therefore, the purchaser needs to centrally manage the applications installed on the financial terminal. In order to realize the centralized management of the applications in the financial terminal, an application digital signature scheme is introduced in the process of installing the application, and the purchaser needs to sign every time the application is updated and installed.

[0033] In the related art, when developing business applications of the financial terminal, the manufacturer needs to install different business applications on the financial terminal for testing. Due to the existence of the application signature scheme, the manufacturer needs to sign the purchaser every time the application is installed or updated on the financial terminal, which causes the installation process of the application to be cumbersome, the development efficiency of the application to be low, and the financial terminal to be unable to install other applications except the applications of the purchaser.

[0034] In the related art, the manufacturer needs to pre-embed the root public key certificate provided by the purchaser in the financial terminal. For the financial terminal, any application to be installed must be signed by the private key corresponding to the working public key certificate derived from the root public key certificate to obtain installation permission. This means that whether it is the first installation or subsequent upgrade, the application on the financial terminal needs to pass through the signature verification process of the purchaser. However, when developing business applications of the financial terminal, the manufacturer needs to install different business applications on the financial terminal for testing. However, this application digital signature scheme needs to be re-signed to the purchaser when the application only makes minor changes, such as version number update. This frequent signature requirement greatly reduces the development efficiency of the manufacturer on the business, and also prolongs the cycle of application version update and upgrade.

[0035] To solve the above problems, the application embodiment provides an application management method based on an OpenHarmony system, which is used for an electronic device using the OpenHarmony system.

[0036] Please refer to Figure 1, the method includes steps S110 - S140.

[0037] Step S110: Obtain a list of historical package names, where the list of historical package names includes application information installed on the electronic device historically.

[0038] Step S120: Obtain the application to be installed. If the application to be installed does not have a purchaser signature, determine whether the application to be installed has a developer signature.

[0039] Step S130: If the application to be installed has a developer signature, determine whether there is first application information corresponding to the application to be installed in the list of historical package names.

[0040] Step S140: If there is first application information, determine the application to be installed as a safe application.

[0041] In a specific scenario, such as Figure 2 shown, if the application to be installed is historical application 1 that has been successfully installed on the electronic device, and i in the figure is the set of all integers satisfying 2 < i < N, that is, the application information of the application to be installed is recorded in the list of historical package names of the electronic device, then the installation process of this application to be installed belongs to a secondary installation. For a secondary installation application, the application package only contains a developer signature. As long as it is determined that there is first application information of the application to be installed in the list of historical package names, it can be determined as a safe application.

[0042] As can be seen from the above embodiments, for an application that has been installed historically, when performing a secondary installation, there is no need to verify the purchaser signature, which simplifies the signature verification process when installing the application for the second time. Therefore, when a manufacturer develops an application update, there is no need to repeatedly sign the application with the purchaser, effectively improving the development efficiency of the application.

[0043] In an embodiment of the present application, the method further includes step S210.

[0044] Step S210: If there is no first application information, determine the application to be installed as a normal application. The permission level of a safe application is higher than that of a normal application.

[0045] In a specific scenario, such as Figure 3As shown, if the application to be installed is not one of the historical applications 1 to historical applications N that have been successfully installed on the electronic device, where i in the figure is the set of all integers satisfying 2 < i < N, that is, the application information of the application to be installed is not recorded in the historical package name list of the electronic device, then the installation process of this application to be installed belongs to the first installation. For applications installed for the first time, the application package only contains the developer signature. Since the application does not contain the purchaser signature, it is impossible to determine whether the application is a secure application allowed by the purchaser, so it is determined as a general application. Among them, the permission level of the secure application includes the permission level of the general application, enabling the secure application to execute all functions of the general application on the electronic device.

[0046] As can be seen from the above embodiments, if the first application information does not exist in the historical package name list, it means that the application to be installed has not been installed on the electronic device, and the application to be installed only has a developer signature, then the application to be installed can be determined as a general application and is not allowed to be installed on the device. In this way, applications that have not been processed with the purchaser signature are not allowed to be installed on the device, realizing the centralized management of applications on the electronic device and avoiding the installation of other applications other than the purchaser.

[0047] In an embodiment of the present application, the method further includes steps S310 - step S320.

[0048] Step S310: If the application to be installed has a purchaser signature, then determine whether there is second application information corresponding to the application to be installed in the historical package name list.

[0049] Step S320: If the second application information exists, then determine the application to be installed as a secure application.

[0050] In a specific scenario, such as Figure 4 As shown, if the application to be installed is the historical application 1 that has been successfully installed on the electronic device, where i in the figure is the set of all integers satisfying 2 < i < N, that is, the application information of the application to be installed is recorded in the historical package name list of the electronic device, then the installation process of this application to be installed belongs to the second installation. For applications installed for the second time, the application package only contains the purchaser signature. As long as it is determined that the second application information of the application to be installed exists in the historical package name list, it can be determined as a secure application.

[0051] As can be seen from the above embodiments, if the second application information exists in the historical package name list, it means that the application to be installed has been installed on the electronic device. At this time, regardless of whether the application to be installed has a developer signature, it can be determined as a secure application for installation. In this way, for applications installed for the second time, the installation can be achieved without verifying the developer signature, effectively simplifying the signature verification steps and improving the installation efficiency of the application.

[0052] In an embodiment of the present application, the method further includes steps S410 - S420.

[0053] Step S410: If there is no second application information, perform signature verification on the purchaser signature.

[0054] Step S420: If the purchaser signature verification passes, determine the to-be-installed application as a safe application.

[0055] In a specific scenario, as Figure 5 shown, if the to-be-installed application is not the historical application 1 to historical application N that has been successfully installed on the electronic device, where i in the figure is the set of all integers satisfying 2 < i < N, that is, the application information of the to-be-installed application is not recorded in the historical package name list of the electronic device, then the installation process of this to-be-installed application belongs to the first installation. For the first-installed application, the application package only contains the purchaser signature. As long as the purchaser signature verification passes, it can be determined as a safe application.

[0056] As can be seen from the above embodiment, if there is no second application information in the historical package name list, it means that the to-be-installed application has never been installed on the electronic device. At this time, as long as the purchaser signature verification of the to-be-installed application passes, regardless of whether there is a developer signature for the to-be-installed application, it can be determined as a safe application for installation. In this way, for the first-installed application, as long as the purchaser signature is verified, verification can be achieved. While realizing the centralized management of applications on the electronic device (that is, avoiding the installation of other applications other than the purchaser), the signature verification steps are effectively simplified and the installation efficiency of the application is improved.

[0057] In an embodiment of the present application, the method further includes steps S510 - S530.

[0058] Step S510: If there is no second application information, determine whether the to-be-installed application has a developer signature.

[0059] Step S520: If the to-be-installed application has a developer signature, perform signature verification on the purchaser signature and the developer signature respectively.

[0060] Step S530: If both the purchaser signature and the developer signature verification pass, determine the to-be-installed application as a safe application, and update the historical package name list according to the purchaser signature and the developer signature.

[0061] In a specific scenario, as Figure 6As shown, if the to-be-installed application is not the historical application 1 to the historical application N that has been successfully installed on the electronic device, i is a set of all integers satisfying 2 < i < N, i.e., the application information of the to-be-installed application is not recorded in the historical package name list of the electronic device, then the installation process of the to-be-installed application is the first installation. For the first installed application, the application package contains the developer signature and the purchaser signature. As long as the developer signature and the purchaser signature are verified, the application is determined to be a safe application, and the historical package name list is updated.

[0062] From the above embodiments, it can be seen that if the to-be-installed application contains both the purchaser signature and the developer signature, and both the signatures are verified, the application is determined to be a safe application for installation, and the historical package name list is updated. In this way, for the first installed application, the relevant historical installation record can be retained to facilitate the secondary installation of the application, avoid the problem that the purchaser signature is required when the application is slightly modified, and effectively improve the development efficiency of the application.

[0063] From the above five embodiments, it can be seen that for the first installed application, the application must contain the purchaser signature and the signature verification must be passed to determine the application to be a safe application; and the application must contain both the purchaser signature and the developer signature, and the signature verification of both must be passed to be updated to the historical package name list. For the second installed application, the application can be determined to be a safe application as long as the application contains the purchaser signature or the developer signature and the signature verification is passed. In this way, if the manufacturer needs to update and test the application, the application needs to request the signature from the purchaser when the application is first installed, so that the application information can be recorded in the historical package name list, so that the application does not need to request the signature from the purchaser when the application is secondly installed, effectively simplifies the signature verification process when the application is secondly installed, and improves the installation efficiency of the application.

[0064] In an embodiment of the present application, the method further includes steps S610-S620.

[0065] Step S610: If the to-be-installed application is a safe application, the to-be-installed application is allowed to be installed.

[0066] Step S620: If the to-be-installed application is not a safe application, the to-be-installed application is not allowed to be installed.

[0067] In an embodiment of the present application, as Figure 7As shown, the application management method based on the OpenHarmony system specifically includes: obtaining a historical package name list, and determining whether application information of a to-be-installed application exists in the historical package name list. If the application information exists, it is determined that the to-be-installed application is a secondary installation, and if the application information does not exist, it is determined that the to-be-installed application is a first installation. After it is determined that the to-be-installed application is a secondary installation, a developer signature or a purchaser signature of the to-be-installed application is obtained, and signature verification is performed according to the application information in the historical package name list, and after the signature verification passes, the application is allowed to be installed. After it is determined that the to-be-installed application is a first installation, it is detected whether the to-be-installed application exists a purchaser signature. If the purchaser signature does not exist, the application is not allowed to be installed, and if the purchaser signature exists, the purchaser signature is subjected to signature verification, and after the signature verification passes, the application is allowed to be installed, and it is detected whether the to-be-installed application exists a developer signature. If the developer signature does not exist, the historical package name list is not updated, and if the developer signature exists, the developer signature is subjected to signature verification, and after the signature verification passes, the historical package name list is updated.

[0068] In an embodiment of the present application, the application of the present application adds a purchaser signature on the basis of retaining the original developer signature, wherein the signature ID of the purchaser signature is a custom ID assigned to the purchaser by the manufacturer. For an application developed based on the OpenHarmony system, a profile file (configuration file) of the purchaser can be added in the application package, the custom ID is written in the profile file, and a root certificate of the purchaser is added in the application package, so as to obtain an application package containing the purchaser signature. At the same time, the custom ID and the root certificate of the purchaser signature of the electronic device are pre-stored in the TEE (Trusted Execution Environment, Trusted Execution Environment) security area when the electronic device is produced, and the custom ID is a read-only variable and cannot be modified when the electronic device is started. In this way, the purchaser signature is distinguished from the original developer signature, so as to realize the signature verification process of the purchaser signature.

[0069] In an embodiment of the present application, the program and file to be signed (i.e., the application package to be signed), the profile file, and the application signature are packaged to form a to-be-installed application package. The profile file includes a signature certificate for the developer signature and / or a signature certificate for the purchaser signature, and the application signature includes an application signature certificate.

[0070] As Figure 8As shown in the figure, in a specific scenario, the to-be-installed application package app1-signed.hap is packaged by the program and file to be signed, the profile file containing the signature certificate for the developer signature, and the developer signature, where the program and file are specifically named app1-unsigned.hap, the profile file can be specifically named app1-profile.p7b, and the developer signature is specifically a pkcs7 structure, that is, the to-be-installed application package app1-signed.hap is only signed by the developer, and the final application signature is embodied as the developer signature.

[0071] As shown in the figure, Figure 9 As shown in the figure, in a specific scenario, the to-be-installed application package app2-signed.hap is packaged by the program and file to be signed, the profile file containing the signature certificate for the purchaser signature, and the purchaser signature, where the program and file are specifically named app2-unsigned.hap, the profile file is specifically named app2-profile.p7b, and the purchaser signature is specifically a pkcs7 structure, that is, the to-be-installed application package app2-signed.hap is only signed by the purchaser, and the final application signature is embodied as the purchaser signature.

[0072] As shown in the figure, Figure 10 As shown in the figure, in a specific scenario, the to-be-installed application package app3-signed.hap is packaged by the program and file to be signed, the profile1 file containing the signature certificate for the purchaser signature, the profile2 file containing the signature certificate for the developer signature, and the developer signature, where the program and file are specifically named app3-unsigned.hap, the profile1 file is specifically named app3-profile1.p7b, the profile2 file is specifically named app3-profile2.p7b, and the developer signature is specifically a pkcs7 structure, that is, the to-be-installed application package app3-signed.hap is first signed by the purchaser and then signed by the developer, and the final application signature is embodied as the developer signature.

[0073] As shown in the figure, Figure 11As shown, in a specific scenario, the to-be-installed application package app4-signed.hap is generated by a program and a file to be signed, a profile1 file containing a signature certificate for a developer signature, a profile2 file containing a signature certificate for a purchaser signature, and a purchaser signature package, wherein the program and the file are specifically named as app4-unsigned.hap, the profile1 file is specifically named as app4-profile1.p7b, the profile4 file is specifically named as app4-profile2.p7b, and the purchaser signature is specifically a pkcs7 structure, that is, the to-be-installed application package app4-signed.hap is first signed by the developer and then signed by the purchaser, and finally the application signature is embodied as the purchaser signature.

[0074] Based on the above embodiment, it can be known that the application signatures corresponding to the four different packaged forms of the to-be-installed application are different. Based on the application management method, if the above four to-be-installed application packages are all installed for the first time, the to-be-installed application package app1-signed.hap is determined as a normal application and is not allowed to be installed, and the to-be-installed application packages app2-signed.hap, app3-signed.hap, and app4-signed.hap are determined as secure applications and are allowed to be installed. For the to-be-installed application package app3-signed.hap, the purchaser signature is performed first, which has actually completed the application installation step, but in order to ensure that the to-be-installed application package can be installed for the second time, the developer signature needs to be performed again. That is, the to-be-installed application packages app3-signed.hap and app4-signed.hap can update the history package name list.

[0075] In an embodiment of the present application, the method for performing signature verification on the purchaser signature in step S410 or step S520 includes the following steps: first, the preset purchaser root certificate is obtained from the TEE secure area, and the purchaser root certificate in the to-be-installed application is compared and verified with the preset purchaser root certificate to determine whether they are consistent, so as to determine the legality of the signature source. Then, the preset signer ID is obtained from the TEE secure area, and the signer ID read from the profile file of the to-be-installed application is compared and verified with the preset signer ID to determine whether they are consistent, and if they are consistent, it is determined that the purchaser signature verification is passed.

[0076] In addition, the root certificate of the developer signature is preset by the OpenHarmony system, and the method for performing verification on the developer signature in step S520 is consistent with the method for performing signature verification on the purchaser signature, which will not be described herein again.

[0077] In an embodiment of the present application, the method of updating the historical package name list according to the purchaser signature and the developer signature in step S530 includes steps S710-S730.

[0078] Step S710: extracting the developer public key and the developer certificate in the developer signature, and generating first application information according to the developer public key and the developer certificate.

[0079] Step S720: extracting the purchaser public key and the purchaser certificate in the purchaser signature, and generating second application information according to the purchaser public key and the purchaser certificate.

[0080] Step S730: adding the first application information and the second application information to the historical package name list according to the application package name of the application to be installed.

[0081] In step S730, the electronic device can add the first application information, the second application information, and the application package name to the historical package name list through the HAP centralized manager. The HAP centralized manager is a basic unit for managing application installation and running in the OpenHarmony system.

[0082] From the above embodiments, for the first installation of the application, if the purchaser signature and the developer signature are both verified, the second application information and the first application information are generated based on the information of the purchaser signature and the information of the developer signature respectively, to ensure that the application can only pass one signature to complete the installation verification when installed for the second time, and to simplify the signature verification process of the application while realizing the centralized management of the application.

[0083] In an embodiment of the present application, the method of determining whether the first application information corresponding to the application to be installed exists in the historical package name list in step S130 includes steps S810-S840.

[0084] Step S810: detecting whether a historical application package name identical to the application name to be installed exists in the historical package name list.

[0085] Step S820: if the historical application package name exists, obtaining the first application information of the historical application package name, and verifying the developer signature according to the first application information.

[0086] Step S830: if the verification is successful, confirming that the first application information corresponding to the application to be installed exists in the historical package name list.

[0087] Step S840: if the verification fails, confirming that the first application information corresponding to the application to be installed does not exist in the historical package name list.

[0088] From the above embodiments, it can be seen that by detecting the application name, it can be quickly determined whether the to-be-installed application has been installed on the electronic device. If the first application information exists in the historical package name list, the developer signature is verified based on the first application information, and the installation can be performed only after the verification is passed, thereby ensuring the security of the application package.

[0089] In an embodiment of the present application, the method of verifying the developer signature based on the first application information in step S820 includes steps S910-S940.

[0090] Step S910: Obtain the historical developer public key in the first application information.

[0091] Step S920: Extract the to-be-verified developer public key in the developer signature, and compare the historical developer public key with the to-be-verified developer public key.

[0092] Step S930: If the comparison is consistent, the verification is successful.

[0093] Step S940: If the comparison is inconsistent, the verification fails.

[0094] From the above embodiments, it can be seen that the developer signature is verified based on the public key information, and the detection accuracy and efficiency are high.

[0095] In an embodiment of the present application, the method of determining whether the second application information corresponding to the to-be-installed application exists in the historical package name list in step S310 includes the following steps: detecting whether a historical application package name identical to the to-be-installed application name exists in the historical package name list; if the historical application package name exists, obtaining the second application information of the historical application package name, obtaining the historical vendor public key in the second application information, extracting the to-be-verified vendor public key in the vendor signature, comparing the historical vendor public key with the to-be-verified vendor public key, and if the comparison is consistent, confirming that the second application information corresponding to the to-be-installed application exists in the historical package name list; if the comparison is inconsistent, confirming that the second application information corresponding to the to-be-installed application does not exist in the historical package name list.

[0096] Please refer to Figure 12 In another embodiment of the present application, an electronic device 100 is provided, which includes a memory 101, a processor 102, and a computer program stored in the memory 101 and running on the processor 102, and the processor 102 implements each step of the application management method based on the OpenHarmony system in the above embodiments when executing the computer program.

[0097] The application management method based on the OpenHarmony system has been disclosed in the above part, and will not be repeated here.

[0098] In summary, the application provides an application management method based on an OpenHarmony system and an electronic device. For a first-installed application, the application must contain a purchaser signature and pass signature verification to be determined as a secure application, thereby achieving installation management of the application program and ensuring that only applications authorized by the purchaser can be installed and downloaded in the terminal. At the same time, an application that passes the verification of both the developer signature and the purchaser signature is determined as a secure application, and the application information of the application is recorded in the history package name list of the electronic device, so that when the application is installed for the second time, the application only needs to contain a purchaser signature or a developer signature and pass the signature verification to be determined as a secure application, thereby ensuring that the application does not need to request a signature from the purchaser when installed for the second time, effectively simplifying the signature verification process when the application is installed for the second time, and improving the application installation efficiency.

[0099] The above description is only an embodiment of the present application, and does not limit the patent scope of the present application. Any equivalent transformation or direct or indirect application in the related technical field based on the content of the specification and drawings is also included in the patent protection scope of the present application.

Claims

1. An application management method based on an OpenHarmony system, characterized in that, An electronic device for using an OpenHarmony system, comprising: obtaining a historical package name list, the historical package name list comprising application information of historical installation of the electronic device; obtaining an application to be installed, and if the application to be installed does not exist a purchaser signature, judging whether the application to be installed exists a developer signature; the purchaser signature comprises a private key corresponding to a working public key certificate derived by using a root public key certificate provided by a purchaser and pre-embedded in the electronic device to sign; if the application to be installed exists the developer signature, judging whether first application information corresponding to the application to be installed exists in the historical package name list; if the first application information exists, determining the application to be installed as a safe application; for the first installation of the application, if the purchaser signature and the developer signature are both verified, generating the first application information based on information of the developer signature.

2. The method of claim 1, wherein, Further comprising: if the application to be installed exists the purchaser signature, judging whether second application information corresponding to the application to be installed exists in the historical package name list; if the second application information exists, determining the application to be installed as a safe application.

3. The method of claim 2, wherein, Further comprising: if the second application information does not exist, performing signature verification on the purchaser signature; if the purchaser signature is verified, determining the application to be installed as a safe application.

4. The method of claim 2, wherein, Further comprising: if the second application information does not exist, judging whether the application to be installed exists the developer signature; if the application to be installed exists the developer signature, performing signature verification on the purchaser signature and the developer signature respectively; if the purchaser signature and the developer signature are both verified, determining the application to be installed as a safe application, and updating the historical package name list according to the purchaser signature and the developer signature.

5. The method of claim 1, wherein, Further comprising: if the first application information does not exist, determining the application to be installed as a common application; the permission level of the safe application is higher than that of the common application.

6. The method of claim 4, wherein, updating the historical package name list according to the purchaser signature and the developer signature comprises: extracting a developer public key and a developer certificate in the developer signature, and generating first application information according to the developer public key and the developer certificate; extracting a purchaser public key and a purchaser certificate in the purchaser signature, and generating second application information according to the purchaser public key and the purchaser certificate; adding the first application information and the second application information to the historical package name list according to an application package name of the application to be installed.

7. The method of claim 1, wherein, judging whether first application information corresponding to the application to be installed exists in the historical package name list comprises: detecting whether a historical application package name same as an application name of the application to be installed exists in the historical package name list; if the historical application package name exists, obtaining first application information of the historical application package name, and verifying the developer signature according to the first application information; if the verification is successful, confirming that the first application information corresponding to the application to be installed exists in the historical package name list; If the verification fails, it is confirmed that the first application information corresponding to the to-be-installed application does not exist in the historical package name list.

8. The method of claim 7, wherein, The verification of the developer signature according to the first application information comprises: obtaining a historical developer public key in the first application information; extracting a to-be-verified developer public key in the developer signature, and comparing the historical developer public key with the to-be-verified developer public key; if the comparison is consistent, the verification is successful; if the comparison is inconsistent, the verification fails.

9. The method according to any one of claims 1-5, characterized in that, Further comprising: if the to-be-installed application is a secure application, the to-be-installed application is allowed to be installed; if the to-be-installed application is not a secure application, the to-be-installed application is not allowed to be installed.

10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor implements each step in the application management method based on the OpenHarmony system according to any one of claims 1-9 when executing the computer program.

Images