CN118819603A

CN118819603A - Application updating method, communication system and electronic device

Info

Publication number: CN118819603A
Application number: CN202310440674.2A
Authority: CN
Inventors: 梁永峰; 李林锋
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2023-04-20
Filing date: 2023-04-20
Publication date: 2024-10-22

Abstract

The present application discloses an application update method, a communication system and an electronic device, which relate to the field of terminal technology, and can solve the problem that the application cannot be updated normally after the developer certificate is replaced, without the need for the user to manually uninstall the old version of the application before the developer certificate is replaced. In this scheme, after the server puts the new version of the first application on the shelf, the terminal device can download the new version of the first application from the server. Among them, the new version of the first application includes a first certificate and certificate change information, and the first certificate is the developer certificate of the new version of the first application. After the terminal device completes the download of the new version of the first application, it determines whether the developer certificate of the old version of the first application installed locally is consistent with the first certificate. If not, the terminal device determines whether to allow the old version of the first application to be updated to the new version of the first application based on the certificate change information. If consistent, the terminal device performs a normal update from the first version to the second version of the first application.

Description

Application updating method, communication system and electronic equipment

Technical Field

The present application relates to the field of terminal technologies, and in particular, to an application update method, a communication system, and an electronic device.

Background

Currently, in some operating systems, the package name (packagername) of an application is used as a unique identifier of the application, and when the application is installed, upgraded, and run, the application with the same package name is identified as the same application. There are also systems currently supporting the installation of applications from multiple markets/channels (e.g., browser, in-application installation) based on open considerations. However, the package name cannot be guaranteed to be globally unique for different applications distributed by different developers in different channels, which can induce a plurality of package name conflict problems, influence the normal work of the applications in the system, and have poor experience for the developers. For this reason, the unique identification of the current application is commonly in the form of "package name+developer attestation", wherein the developer attestation is used to uniquely identify the developer identity that developed the application.

However, when the developer of the application proves to change, the unique identification of the application will also change. When the new version application after the developer certification is changed needs to be installed on the system, the new version application after the developer certification is changed needs to be installed after the old version application before the developer certification is changed is manually unloaded by a user, and the user experience is poor.

Disclosure of Invention

The application provides an application updating method, a communication system and electronic equipment, wherein when a user terminal downloads a new version of application after a developer proves change from an application market, verification of normal updating can be performed by utilizing the evidence replacement information carried in the new version of application. Therefore, the new version application can be directly installed after verification is successful, and the old version application before the local installed developer proves the change is covered, so that the old version application does not need to be manually unloaded by a user.

In order to achieve the above purpose, the application adopts the following technical scheme:

In a first aspect, an application update method is provided, applied to a communication system including a first terminal device and a server, where the server establishes a communication connection with the first terminal device. In the method, the server sends a first application of a second version to the first terminal device, wherein the first application of the second version comprises a first certificate and certificate change information. Wherein the first attestation is a developer attestation of the second version of the first application. After the first terminal device obtains the first application of the second version from the server, it may be determined whether the developer certification of the first application of the first version installed locally is consistent with the first certification. If not, the developer demonstrates that the second version of the first application has changed as compared to the first version of the first application. The existing first terminal equipment can regard the two as different applications developed by different developers, can not recognize the two as different versions of the same application, can not be normally installed because of package name conflict, and can normally install the first application of the second version only after the user manually uninstalls the first application of the first version.

In the scheme provided by the application, since the first terminal equipment acquires the first application of the second version and comprises the certification change information, if the developer certification of the first application of the first version is detected to be inconsistent with the first certification, the first terminal equipment can judge whether to allow the first application of the first version to be updated to the first application of the second version according to the certification change information.

Of course, if it is detected that the developer certification of the first application of the first version is consistent with the first certification, the first terminal device can identify the first application of the second version and the first application of the first version as different versions of the same application, and the first terminal device can perform normal update, that is, at this time, the first terminal device can perform update installation from the first version to the second version on the first application.

Alternatively, the developer attestation may be a developer certificate, a developer public key or derivative thereof, or other credentials that may be used to attest to the identity of the developer, or the like. The first application may be any application program that may be installed in a local operating system of the terminal device, such as a video application, a chat application, or a game application. Taking the first application as game application a as an example, the first application of the first version may be version 1.0 of game application a, the developer proof of the version application may be a test public key used in the application development phase, the first application of the second version may be version 2.0 of game application a, and the developer proof of the version application may be a commercial public key used in the application online phase.

In the solution provided in the first aspect, when the new version application released by the developer adopts the modified new developer certificate, the new version application released by the server (or called application market or application store) carries certificate modification information. Therefore, after the first terminal device (or called user device, user terminal) obtains the new version application from the server, the verification of normal update can be performed by using the replacement information carried in the new version application. Thus, after the verification is successful, the first terminal device can normally update the old version application before the local installed developer proves the change, namely, the new version application is directly installed and the old version application is covered. Instead of directly reminding the user to manually uninstall the locally installed developer to prove the old version application before the change, and then install the new version application.

In one possible implementation, the attestation change information includes a developer attestation list including developer attestations of the first application that are allowed to be updated to the second version. For example, using a developer attestation as a developer public key as an example, the developer attestation list may be a developer public key list that includes one or more historically used developer public keys that allow updating of the first application as the second version. For another example, taking a developer attestation as a developer credential, the developer attestation list may be a developer credential list that includes one or more historically used developer credentials that allow updating the first application as the second version. When the new version application released by the developer needs to adopt the changed new developer certification, all the historical developer certificates which are allowed to be updated into the new version application are written in the certification change information, so that all the developer certificates in the developer certification list can be normally updated into the new version application.

In one possible implementation manner, if the first terminal device detects that the developer certification of the first application of the first version is inconsistent with the first certification, the first terminal device obtains the developer certification list from the certification changing information at this time, so as to determine whether the developer certification list includes the developer certification of the first application of the first version. That is, the verification of the normal update performed by the first terminal device may be by verifying whether the developer certification of the locally installed legacy application is in the developer certification list certifying the change information.

In one possible implementation manner, if the first terminal device detects that the developer certification of the first application including the first version in the developer certification list corresponds to that the first application accurately declaring the first version in the certification change information allows the first application to be updated into the second version, the verification of the normal update can be considered to be passed at this time, and the first terminal device directly installs the new version application and covers the old version application.

For example, taking the developer proof of the first application of the second version as the developer public key E, the developer public key list records the developer public key A, B, C as an example, if the developer proof of the first application of the first version is the developer public key a, after the first terminal device downloads the first application of the second version, the verification of the verification change information may pass (the developer public key list includes a), and the first terminal device executes the normal coverage update of the first application of the second version.

If the developer of the first application of the first version proves to be the developer public key D, after the first terminal device downloads the first application of the second version, the verification of the verification change information will not pass (the developer public key list does not contain D), and the first terminal device will not execute the normal coverage update of the first application of the second version. At the moment, the first terminal equipment can remind the user to manually uninstall the old version application before the local installed developer proves the change, and then the new version application is installed.

In one possible implementation, the attestation change information includes an update path including update rules between at least two developer attestations of the first application. For example, taking the developer proof as the developer public key as an example, the update path may be developer public key a- > developer public key B- > developer public key C, which is equivalent to stating that only the version application corresponding to developer public key a is allowed to be updated to the version application corresponding to developer public key B, and that the version application corresponding to developer public key B is not allowed to be updated to the version application corresponding to developer public key C in a jumping manner.

When the new version application released by the developer needs to adopt the changed new developer certification, the update path rule among the developer certificates of the application is written in the certification change information, so that the first terminal equipment is accurately declared which developer in the certification change information certifies that the corresponding version application can be normally updated to the new version application, and which developer in the certification change information certifies that the corresponding version application cannot be normally updated to the new version application. That is, there may be some developer in the attestation change information that attests to the corresponding version application, which is not allowed to be normally updated to the currently downloaded new version application. The method is suitable for a scene with compatible version application update and incompatible version application update.

In one possible implementation manner, if the first terminal device detects that the developer certification of the first application of the first version is inconsistent with the first certification, the first terminal device may acquire the update path from the certification change information at this time to determine whether an update rule of the update path is satisfied between the first application of the first version and the first application of the second version. That is, the verification of the normal update performed by the first terminal device may be by verifying whether the developer certification of the new and old version application meets the update path rule described in the certification change information.

In one possible implementation manner, if the first terminal device detects that the update rule of the update path is satisfied between the first application of the first version and the first application of the second version, which is equivalent to proving that the first application of the first version accurately declares in the change information that the first application of the first version allows the update to be the first application of the second version, the verification of the normal update may be considered to be passed at this time, and the first terminal device directly installs the new version application and covers the old version application.

For example, taking the developer certification of the first application of the second version as the developer public key B, the update path of the developer public key a- > developer public key B- > developer public key C and the update path of the developer public key D- > developer public key E- > developer public key C are recorded in the certification change information. If the developer of the first application of the first version proves to be the developer public key A, after the first terminal device downloads the first application of the second version, the verification of the verification change information can pass (the update path rule of the developer public key A- > the developer public key B exists), and the first terminal device executes normal coverage update of the first application of the second version.

If the developer of the first application of the first version proves to be the developer public key D, after downloading the first application of the second version, the first terminal device may not pass the verification of the verification change information (there is no update path rule of the developer public key D- > the developer public key B), and the first terminal device may not execute the normal coverage update of the first application of the second version.

In one possible embodiment, the attestation change information includes signature information of other developer attestations to the first attestation, the other developer attestations being developer attestations of the first application that allow updating to the second version. As such, when a new version of an application that a developer issues needs to employ a changed new developer attestation, the new developer attestation may be signed with the developer attestation of the old version of the application that is allowed to be updated. The signature information can be written in the proving change information, so that all the version applications corresponding to the old developer proving signed for the new developer proving can be correctly updated into the new version applications.

Optionally, the developer attestation is a developer signing key, the developer signing key comprising a developer private key and a developer public key. The signature information of the first proof by the other developer proof may be a signature of the first developer private key (i.e., the first proof) by the other developer private key. It will be appreciated that since the developer private keys are both privately owned by the developer, the developer public keys are both public. Therefore, if the developer signs the new private key by using the old private key, it is proved that both private keys are held by the developer, and it can be explained that the developer allows the version application corresponding to the old private key to be updated to the version application corresponding to the new private key. It should be noted that if the developer does not have the old private key (the private key is lost), the new key cannot be signed. Thus, this embodiment is applicable to a scenario where the developer still holds the old private key.

In one possible implementation manner, if the first terminal device detects that the developer certification of the first application of the first version is inconsistent with the first certification, the first terminal device obtains the signature information from the certification changing information at this time, so as to determine whether the signature information includes signature information of the developer certification of the first application of the first version on the first certification. That is, the verification of the normal update performed by the first terminal device may be a signature of the first certificate by verifying whether there is a developer certificate of the locally installed old version application in the certificate change information.

Alternatively, the private key signed content in the signing key may be decrypted by the public key. Thus, the first terminal device may decrypt the signature information in the authentication change information using the developer public key of the locally installed legacy application. If the first certificate in the signature information is successfully decrypted, the first terminal device can consider that the verification of the normal update is passed. The first terminal device directly installs the new version application and overrides the old version application. If the signature information is not decrypted or the decrypted developer proof is not the first proof, the first terminal device can consider that the verification of the normal update is not passed, and the first terminal device cannot execute the normal coverage update of the first application of the second version.

In one possible implementation, the attestation change information includes signature information between at least two developer attestations of the first application. The signature information may include signature information of the first proof by the other developer proof. For example, taking the developer attestation as the developer signing key, the attestation change information includes developer key A signing developer key B- > developer key B signing developer key C- > developer key C signing developer key D.

When the first proof is the developer key D, as an implementation manner, since once the current signature information in the signature information is successfully decrypted, the subsequent signature information is decrypted, which is equivalent to declaring that the version application corresponding to the decrypted signature information can be updated to the new version application. In another embodiment, once the current signature information is successfully decrypted, the subsequent signature information is decrypted, which is equivalent to declaring the update path of the version application corresponding to the decrypted signature information, so that it can be determined whether the update to the new version application is possible according to the verification manner of the previous update path. This signing way to declare whether to allow the developer of the application updated to the new version proves that it can have a stronger security.

In one possible embodiment, the server sends the first application of the first version to the first terminal device before the server sends the first application of the second version to the first terminal device, wherein the first application of the first version comprises a second attestation, the second attestation being a developer attestation of the first application of the first version. That is, at this time, since the developer of the first application proves that the change has not occurred, the first application issued by the server does not carry the information of the change of the proof. After the first terminal device obtains the first application of the first version from the server, the first terminal device can normally install the first application of the first version.

Alternatively, the server may be an application distribution server for managing and distributing the application program, such as a cloud server that provides an application market service, or other application distribution channels through which the end user can download the application.

In one possible implementation, the communication system further includes a second terminal device, before the server sends the first application of the second version to the first terminal device, the second terminal device sends a request for a change of certification to the server, when the server receives the request for the change of certification from the second terminal device, the server generates certification change information according to the request for the change of certification, and the server sends the certification change information to the second terminal device. In this way, when the developer needs to change the developer certification of the first application, the certification change may be applied to the server through the second terminal device, so that the server may issue, to the developer, certification change information for certifying that the version application corresponding to the old developer certification is legally updated to the version application corresponding to the new developer certification. Therefore, the change of the developer certification is uniformly managed and controlled through the server, and abuse, embezzlement and tampering of the developer certification can be effectively prevented.

Alternatively, the server may be a certificate server for unified issuing and managing of developer certificates. Alternatively, the certificate server and the application distribution server may be two independent servers, or may be two different functional modules in the same server.

In one possible embodiment, the second terminal device sends the second version of the first application to the server before the server sends the second version of the first application to the first terminal device, the second version of the first application including the first attestation and the attestation change information. In this way, after the developer obtains legal proof change information issued by the server through the second terminal device, if the new version application issued adopts the new developer proof after the change, the proof update information can be added into the new version application and uploaded to the server for the first terminal device to download. After the first terminal equipment downloads the new version application from the server, normal updating verification can be carried out on the application by utilizing legal proof change information carried in the new version application, and after the verification is passed, the new version application can be allowed to be directly updated normally on the old version application.

In one possible embodiment, the communication system further comprises a second terminal device, the second terminal device sending the first application of the first version to the server before the server sending the first application of the first version to the first terminal device, the first application of the first version comprising the second attestation. That is, since the developer certification of the old version application issued by the developer has not changed, the certification update information is not added to the old version application and is directly uploaded to the server.

In one possible implementation manner, after the first terminal device obtains the first application of the second version from the server, the first terminal device obtains the first application of the first version corresponding to the package name according to the package name of the first application of the second version. To determine whether the first terminal device has previously installed other versions of the application by determining whether there is an application of the same package name locally.

In a second aspect, an application updating method is provided and applied to a first terminal device in a communication system, where the communication system includes the first terminal device and a server, and the server establishes a communication connection with the first terminal device. In the method, the first terminal device can acquire a first application of a second version from the server, wherein the first application of the second version comprises a first certificate and certificate change information. Wherein the first attestation is a developer attestation of the second version of the first application. The first terminal device may then determine whether the developer attestation of the locally installed first version of the first application is consistent with the first attestation. If the first application is inconsistent with the second application, the first terminal equipment can judge whether to allow the first application of the first version to be updated to the first application of the second version according to the proving change information. If so, the first terminal device performs update installation from the first version to the second version on the first application.

In one possible implementation, the attestation change information includes a developer attestation list including developer attestations of the first application that are allowed to be updated to the second version.

In one possible implementation manner, after the first terminal device obtains the developer certification list from the certification changing information, it may be determined whether the developer certification list includes the developer certification of the first application of the first version.

In one possible implementation, if the first terminal device detects that the developer attestation list includes a developer attestation of the first application of the first version, the first terminal device performs an update installation of the first version to the second version on the first application.

In one possible implementation, the attestation change information includes an update path including update rules between at least two developer attestations of the first application.

In one possible implementation manner, after the first terminal device obtains the update path from the certificate change information, it may be determined whether an update rule of the update path is satisfied between the first application of the first version and the first application of the second version.

In one possible implementation, if the first terminal device detects that an update rule of an update path is satisfied between the first application of the first version and the first application of the second version, the first terminal device performs update installation from the first version to the second version on the first application.

In one possible embodiment, the attestation change information includes signature information of other developer attestations to the first attestation, the other developer attestations being developer attestations of the first application that allow updating to the second version.

In one possible implementation, before the first terminal device obtains the second version of the first application from the server, the first terminal device obtains the first version of the first application from the server, wherein the first version of the first application includes a second proof, the second proof is a developer proof of the first version of the first application, and then the first terminal device can normally install the first version of the first application.

In one possible implementation manner, after the first terminal device obtains the first application of the second version from the server, the first terminal device obtains the first application of the first version corresponding to the package name according to the package name of the first application of the second version.

In a third aspect, an application update method is provided, applied to a server in a communication system, where the communication system includes a first terminal device and a server, and the server establishes a communication connection with the first terminal device. In the method, a server sends a first application of a second version to a first terminal device, wherein the first application of the second version comprises a first certificate and certificate change information, and the first certificate is a developer certificate of the first application of the second version. When the first terminal equipment detects that the developer of the first application of the first version installed locally is inconsistent with the first certificate, judging whether to allow the first application of the first version to be updated to the first application of the second version according to the certificate change information; the second version of the first application is further used for the first terminal device to execute update installation from the first version to the second version of the first application when detecting that the developer certification of the first application of the first version locally installed by the first terminal device is consistent with the first certification.

In one possible embodiment, the server sends the first application of the first version to the first terminal device before the server sends the first application of the second version to the first terminal device, wherein the first application of the first version comprises a second attestation, the second attestation being a developer attestation of the first application of the first version. The first application of the first version is used for the first terminal equipment to be installed in the local system.

In one possible embodiment, the communication system further comprises a second terminal device, and the server may receive a request for a change in attestation for the first application from the second terminal device before the server sends the first application of the second version to the first terminal device. The server may then generate attestation change information based on the attestation change request. The server then transmits the attestation-change information to the second terminal device.

In one possible implementation, before the server sends the first application of the second version to the first terminal device, the server may receive the first application of the second version sent by the second terminal device, where the first application of the second version includes the first attestation and attestation change information.

In one possible implementation, the communication system further includes a second terminal device, and the server may receive the first application of the first version including the second attestation from the second terminal device before the server transmits the first application of the first version to the first terminal device.

In a fourth aspect, a communication system is provided, including a first terminal device and a server, the server establishing a communication connection with the first terminal device. Wherein:

The server is used for sending a first application of a second version to the first terminal equipment, wherein the first application of the second version comprises a first certificate and certificate change information, and the first certificate is a developer certificate of the first application of the second version;

and the first terminal equipment is used for acquiring the first application of the second version from the server. And the first terminal equipment is also used for judging whether to allow the first application of the first version to be updated to the first application of the second version according to the proving change information if the developer proving of the first application of the first version is detected to be inconsistent with the first proving, wherein the first application of the first version is an application installed locally by the first terminal equipment. The first terminal device is further configured to execute update installation from the first version to the second version on the first application if it is detected that the developer certification of the first application of the first version is consistent with the first certification.

In a fifth aspect, an electronic device is provided that includes a memory, one or more processors; the memory is coupled with the processor; wherein the memory has stored therein computer program code comprising computer instructions which, when executed by the processor, cause the electronic device to perform the application updating method as in the second aspect and any of its implementations, or to perform the application updating method as in the third aspect and any of its implementations.

In a sixth aspect, a computer readable storage medium is provided, comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the application update method as in the second aspect and any of its implementations, or to perform the application update method as in the third aspect and any of its implementations.

In a seventh aspect, a computer program product is provided which, when run on a computer, causes the computer to perform the application update method as in the second aspect and any of its implementations, or to perform the application update method as in the third aspect and any of its implementations.

It may be appreciated that the advantages achieved by the application updating method according to the second aspect, the application updating method according to the third aspect, the communication system according to the fourth aspect, the electronic device according to the fifth aspect, the computer readable storage medium according to the sixth aspect, and the computer program product according to the seventh aspect may refer to the advantages in any one of the possible designs of the first aspect and the advantages will not be described herein.

Drawings

Fig. 1 is a schematic diagram of installation failure after key replacement according to an embodiment of the present application;

FIG. 2 is a schematic diagram of an application update method in a general technology according to an embodiment of the present application;

fig. 3 is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 4 is a schematic system diagram of an application update method according to an embodiment of the present application;

Fig. 5 is a flowchart of an application update method according to an embodiment of the present application;

FIG. 6 is a schematic diagram I of a certificate exchange file according to an embodiment of the present application;

FIG. 7 is a second schematic diagram of a certificate exchange file according to an embodiment of the present application;

FIG. 8 is a third schematic diagram of a certificate exchange file according to an embodiment of the present application;

FIG. 9 is a schematic diagram of an interface during application update according to an embodiment of the present application;

FIG. 10 is a flowchart illustrating another method for updating applications according to an embodiment of the present application;

FIG. 11 is a schematic diagram of successful update of an application according to an embodiment of the present application;

fig. 12 is an overall flowchart of an application updating method according to an embodiment of the present application.

Detailed Description

In the description of the present application, unless otherwise indicated, "/" means that the objects associated in tandem are in a "or" relationship, e.g., A/B may represent A or B; the "and/or" in the present application is merely an association relationship describing the association object, and indicates that three relationships may exist, for example, a and/or B may indicate: there are three cases, a alone, a and B together, and B alone, wherein a, B may be singular or plural.

In the description of the present application, unless otherwise indicated, "a plurality" means two or more than two. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a and b, a and c, b and c, a and b and c, wherein a, b and c can be single or multiple.

In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", etc. are used to distinguish the same item or similar items having substantially the same function and effect. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion that may be readily understood.

The particular features, structures, or characteristics of the application may be combined in any suitable manner in one or more embodiments. In various embodiments of the present application, the sequence number of each process does not mean the sequence of execution sequence, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Some optional features of the embodiments of the present application may be implemented independently without depending on other features in some scenarios, so as to solve corresponding technical problems, achieve corresponding effects, and may also be combined with other features according to requirements in some scenarios.

In the present application, the same or similar parts between the embodiments may be referred to each other unless specifically stated otherwise. In the various embodiments of the application, if there is no specific description or logical conflict, terms and/or descriptions between the various embodiments will be consistent and will reference each other. The embodiments of the present application do not limit the scope of the present application.

In addition, the service scenario described in the embodiment of the present application is for more clearly describing the technical solution of the embodiment of the present application, and does not constitute a limitation on the technical solution provided in the embodiment of the present application, and as a person of ordinary skill in the art can know that, with the evolution of the network architecture and the appearance of a new service scenario, the technical solution provided in the embodiment of the present application is applicable to similar technical problems.

First, for ease of understanding, related terms and concepts that may be related to embodiments of the present application are described below.

1. Key(s)

The key may be used to encrypt or decrypt information. Keys can be classified into asymmetric keys, which means that keys used for encryption and decryption are identical, and symmetric keys, which means that keys used for encryption and decryption are different.

The asymmetric key may comprise both public and private keys, i.e., a public-private key pair. The public key is public and can be known by the owner or related personnel, the private key is private, and only the owner of the public-private key pair can obtain the private key. The public key and the private key correspond to each other, and the information encrypted by the public key can be decrypted by the corresponding private key. Similarly, information encrypted using a private key may be decrypted using a corresponding public key.

In some application scenarios, the owner of a public-private key pair may sign some information (which is encrypted in nature) with the private key, generating signature information. Then, a person who knows the public key can utilize the public key to carry out security verification on the signature information, can determine whether the signature information is generated by a private key (only owned by an owner), further realize identity verification on the party providing the signature information, and can confirm the integrity of the signed information.

In the embodiment of the present application, an asymmetric key is described as an example of a key for signing an application. In this case, the application owner, i.e., the developer, does not send the private key for signing the application to the receiver, but sends the public key corresponding to the private key to the receiver, which own private and securely stores the private key for signing the application.

2. Bag name

The package name is used to identify the application identity, and may be PACKAGENAME, BUNDLEID, APPID, etc., the names of packages for different markets/channels are different. For example, the package name of application 1 may be "com.123".

3. Developer attestation

The developer attestation is used to identify the application owner, i.e., the developer unique identity. The developer attestation may be a developer certificate, a developer signing key or derivative thereof, other credentials that may be used to attest to the identity of the developer, and the like. The embodiments of the present application are not limited to developer certification.

4. Developer signing key

A developer signing key may refer to a public-private key pair generated and held by the developer itself, which may include a developer private key for signing, and a developer public key for verification.

A developer may sign an application by its private key when developing the application. In some embodiments, the "package name+developer public key" may be used as a unique identification of the application after the application is signed by the developer private key. In some scenarios, a developer may issue a developer public key corresponding to the developer private key along with the application when issuing the application, so that an installer may perform security verification on the signed application through the developer public key when installing the application.

Alternatively, the developer signing key may be another key derived from the developer public key, such as a key obtained by further encrypting the developer public key. Embodiments of the present application are not limited to signing keys that may be used to prove the identity of a developer.

5. Developer certificate

A developer certificate may refer to a type of certificate file issued by a certificate authority (CERTIFICATE AUTHORITY, CA) for identifying developer identity information, also referred to as a digital certificate, public key certificate, or the like. The CA is the authority responsible for issuing and managing developer certificates. The CA, as a trusted third party in the network, may verify the identity of the developer applying for the developer certificate, manage and update the developer certificate, etc.

For example, when a developer applies a legitimate developer certificate to a CA using a developer public key a generated by the developer, the CA may issue a developer certificate to the developer based on the developer public key a after passing the validity check of the application. Alternatively, the developer certificate may include public key information of the developer, identity information of the developer, signature information of the CA (i.e., a certificate signature generated when the CA signs the developer certificate), and the like. The validity of the public key in the developer certificate can be determined through verification of the developer certificate.

In some embodiments, the "package name+developer certificate" may be used as a unique identification of the application after the application is signed by the developer private key.

5. Root certificate

The root certificate is the basis for establishing trust relationship between the CA and other devices, is the digital certificate of the CA, and is the starting point of a trust chain. Verifying the authenticity of a developer certificate (i.e., verifying whether the signature of the developer certificate information by the CA is valid) requires verification with the public key of the CA, which is present in the certificate signing the developer certificate, i.e., the public key of the CA is present in the root certificate of the CA, so if the device needs to verify the authenticity of a developer certificate, a root certificate needs to be preset in the device.

Currently, in some operating systems, the unique identification of an application includes both a package name and a developer certificate. I.e. the same "package name + developer proof" can only prove a certain application. However, in some scenarios, there may be situations where the package name is unchanged and the developer proves that the change has occurred. And when the developer of the application proves to change, the unique identification of the application will also change. The current operating system does not support the switching of developer certification, the new application after the switching of developer certification cannot be updated from the old application before the switching of developer certification, and the end-side user experience is poor.

For example, referring to fig. 1, when a developer generates a signing key a (including a private key a and a public key a), after applying for a legal developer certificate a from an application market (including a CA issuing module) through the public key a, the developer may sign an unsigned application 1.0 version (old version) using the private key a, write the developer certificate a in the application 1.0 signed by the developer, and upload the application certificate a to the application market. The application market can put the application 1.0 signed by the developer on shelf, and the application 1.0 after putting on shelf can be used for inquiring and downloading of various user equipment (such as mobile phones, tablet computers and the like). Wherein the application 1.0 on the application market may carry the package name of the application 1.0 and the developer certificate a.

The user device may download and install the application 1.0 into the local system through the application marketplace. As a specific implementation, when the user equipment installs the application 1.0 on the local system, it is necessary to check the unique identifier of the application. That is, the user device may extract the "package name+developer certificate a" of the application 1.0 to be installed and compare with the "package name+developer certificate" of the application installed in the local system. The user equipment can detect that the package names are different, can identify the application 1.0 to be installed as a brand new application, can independently install the application, does not conflict with the installed application, and can exist simultaneously.

Later, when the developer needs to put the application 2.0 version (new version) on the shelf, it is found that the storage medium of the signature key a is damaged and cannot be repaired (or other cases where the key must be replaced), and the signature of the application 2.0 cannot be performed using the private key a. At this point, the developer may generate a new signing key B (including private key B and public key B). After the developer applies from the application market to the legal developer certificate B through the public key B, the developer can sign the unsigned application version 2.0 (new version) using the private key B, write the developer certificate B in the application 2.0 signed by the developer, and upload the application certificate B to the application market.

When the user equipment downloads and installs the application 1.0 into the local system through the application market, the package name and the developer certificate A of the application 2.0 to be installed are extracted and compared with the package name and the developer certificate B of the application installed in the local system. At this time, the user equipment may detect that the package name of the application 2.0 to be installed is the same as the package name of the application 1.0 installed in the local system, but the developer certificate is inconsistent, that is, it is verified that the unique identifier of the application changes. Applications do not allow installation/updating (upgrading), and new versions of applications must be installed behind old version applications.

Among them, developer-proven replacement is more common. Taking the example of a developer proving to sign a key for a developer, the following replacement scenarios may be generally included:

Developer signing key loss: the developer switches the development environment to cause the key loss, or the key preservation medium is damaged, etc., and the key must be replaced;

developer signing key leakage: the private key of the developer is revealed, or the complexity of the key is too low, and the private key of the developer is replaced for safety;

Application transfer/vending: the application is transferred/sold by developer a to developer B, who needs to rekey after transfer/sale.

It can be understood that in the current Android operating system, the unique identifier of the application adopts a mode of "package name+certificate signature (or certificate fingerprint)", and after the certificate signature is changed, the unique identifier of the application is also changed. The problem that the application cannot be updated (upgraded) normally and the old version application needs to be uninstalled and then the new version application needs to be installed is faced.

As a possible solution, as shown in fig. 2, an intermediate version application may be added between the new version application and the old version application. The developer may first upgrade from an old version application (signing key a) to an intermediate version application carrying the key a signature and the key a to key B signature. To prove that the old version application (key a) can be upgraded to the new version application (key B). The developer can then upgrade the intermediate version application to the new version application (key B), and the key replacement is complete.

The above scheme then has to hold the old key a by the developer. If the old key a is lost, the above scheme cannot be implemented. And the developer needs to pass through the intermediate version to complete the rekeying of the application. In addition, due to the openness of android ecology, the certificate signature of the application is self-verified by a developer, and a unified certificate CA authentication mechanism does not exist. Thus, the above solution essentially requires the developer to "certify the legitimacy of the key exchange by itself" by specification, and is not applicable to other systems with uniform certificate management.

It can be appreciated that in the apple iOS operating system, the iOS applications can only be distributed through an application Store (App Store) which holds all the application information on shelf, due to the ecological total closeness, so that the globally unique package name (BundleId) of the application can be ensured. Thus, in the iOS operating system, the package name (BundleId) of the application is directly used as the unique identification of the application, which, while verifying the validity of the developer certificate, does not count into the unique identification of the application. Therefore, after the key is switched, the new key application can be updated (upgraded) normally as long as the certificate of the developer based on the new key application is legal. Therefore, the current iOS operating system does not have the problem that the application cannot be updated (upgraded) normally after the key replacement.

However, for other application ecology which is not totally enclosed and uniformly manages the developer certificate, since a plurality of distribution platforms (such as a browser and an application market) are allowed to coexist, the global uniqueness of the package name of the application cannot be guaranteed, and therefore the developer certification information (developer certificate, developer public key or other information for identifying the uniqueness of the developer) is added into the application uniqueness identification. This results in the problem that when the developer proves that the change occurs, the current operating system cannot update (upgrade) the application normally, and the old version application needs to be uninstalled before the new version application is installed. Thus, there is a need for a method that can be used to address the inability of developers to properly upgrade applications after replacement.

In order to solve the above problems, an embodiment of the present application provides an application update method, which is uniformly controlled by a server, and distributes a certificate replacement file for proving that a new and old developer is legal to be replaced to a developer when the developer needs to replace the developer certificate. The certification change is then added to the application by the developer and uploaded to the application marketplace. When the user equipment downloads the application from the application market and installs the application, the application can be checked by using the certificate change file carried in the application, and after the verification is passed, the application can be allowed to be normally updated (upgraded), namely, the old version application before the developer certificate is changed is directly covered, and the new version application after the developer certificate is changed is directly installed. The problem that the application cannot be updated (upgraded) normally after the developer proves to be replaced is solved.

It should be noted that, the application updating method provided by the embodiment of the application is suitable for non-totally-enclosed application ecology for uniformly managing and controlling the certificates of the developer. For example, the method can be applied to a hong Harmony system, a computer application market and the like, can be applied to three-party application ecology built based on OpenHarmony in the future, and can also be applied to application ecology possibly built in the future of an android system. It will be appreciated that there are systems in existence today that mandate developers to host keys and certificates to the system to achieve uniform management of the developer's certificates. After the certificate management capability reaches a certain stage, the application updating method provided by the embodiment of the application is also applicable to the systems.

The method provided by the embodiment of the application is described in detail below with reference to the accompanying drawings.

Referring to fig. 3, fig. 3 is a schematic diagram of an application scenario provided in an embodiment of the present application. The application scenario includes a terminal device 310 and a server 320.

The terminal device 310 may be an electronic device such as a mobile phone, a tablet computer, a notebook computer, an ultra mobile personal computer, a Personal Digital Assistant (PDA), a television, a smart watch, and an Augmented Reality (AR)/Virtual Reality (VR) device. The device type of the terminal device in the present application is not particularly limited.

Server 320 may be a local or remote server cluster, or a single server, as the application is not limited in this regard. Optionally, the server of the present application may be a server built specifically for implementing the application update method provided by the present application, or may be an application update service provided by the present application added to an existing server.

Optionally, the terminal device 310 includes an application developer device and a user device. The application developer device is a terminal device where the application developer is located, and the user device is any terminal device which needs to download and install the application. Optionally, an application developer device is provided with a developer platform provided for a developer, and the application developer can develop the application on the developer platform.

Optionally, the server 320 includes an application distribution server for managing and distributing application programs. For example, the application distribution server may be a cloud server that provides an application market service, or other application distribution channels that may be used by an end user to download an application, which is not limited in this embodiment of the present application. Alternatively, the user device may be a terminal device where a general user accessing the application market is located.

Taking the application distribution server as a cloud server supporting the application market service as an example, the application developer device sends the target application to the application distribution server, so that the target application can be put on shelf in the application market, and other users can download the target application from the application market.

Optionally, the server 320 includes a certificate server for uniformly issuing and managing the developer certificates, so that uniform management and control of the developer certificates can be realized, and the developer certificates are prevented from being forged and tampered. In this way, the terminal device side can trust the key information conveyed by the developer certificate.

In the embodiment of the application, the certificate server provides a unified certificate issuing and managing system for the developer, and also provides a unified certificate replacement file issuing and managing system. Wherein the certificate change file is a certificate credential for proving whether the developer of the application is permitted to legally change. The developer attestation may be, among other things, a developer certificate, a developer signing key or derivative thereof, other credentials that may be used to attest to the identity of the developer, and the like.

It will be appreciated that the certificate change is issued and signed by a certificate server that uniformly manages the developer's certificates, preventing the certificate change from being counterfeited and tampered with. In this way, the terminal device side can trust the certificate exchange information conveyed by the certificate exchange file.

In an embodiment of the present application, referring to fig. 4, the certificate server may include a CA issuing module, a certificate management module, and a replacement certification module.

The CA issuing module is responsible for unifying signature developer certificates, proving replacement files and the like. The CA issuing module signs the developer certificate, proves the validity of the developer certificate issued by the certificate server, the certificate of replacement file, and the like. I.e. to prove the validity of the developer certificate, to prove the source of the issuing of the replacement document, etc.

Alternatively, only developers who acquire legitimate developer certificates are allowed to put on-shelf to the application market, thereby enabling secure management of application ecology.

The certificate management module is responsible for unified issuance and management of developer certificates. The developer certificate includes a signing key of the developer for the developer to sign his application. In the embodiment of the application, the certificate management module can record all the historical certificate information applied by the developer, can provide historical data support for the replacement proven by the developer, and can also provide support for the validity judgment of the replacement proven by the developer.

In some scenarios, the application developer device, after generating the signing key a (including the developer public key a and the developer private key a), the developer private key a is only owned by the application developer device for decryption and signing. The developer public key a may be externally disclosed for encrypting and verifying the signature.

As shown in fig. 4 (a), the application developer device may send the developer public key a to the certificate server to apply for issuing the developer certificate. After the certificate server receives the developer public key A, a certificate management module of the certificate server can verify the legitimacy of the identity of the developer, and after the verification is passed, the certificate management module can sign the developer public key A through a CA issuing module to obtain a signature file (profile) containing the developer certificate A. The certificate management module may then return the signature file to the application developer device. While the certificate management module may store the developer certificate a. So that the application developer device can acquire the developer certificate a issued by the CA and the signature file.

In some scenarios, after acquiring the developer certificate a and the signature file issued by the CA, the application developer device may sign the application using the developer private key a, and write the signature file (profile) containing the developer certificate a into the signed application. Then put on shelf to the application market for any terminal device to query and download.

The change proof module may be responsible for receiving a proof change request from an application developer device, verifying the validity of the developer proof change, and issuing a proof change file in unison. Wherein the certification replacement request is used to apply for replacement of developer certification. The certificate change file is a certificate credential for proving whether the developer of the application proves that the legal change is allowed.

For example, taking a developer attestation as a developer signing key, an attestation change request may be for applying for a change to the developer signing key. The certificate change may be a certificate credential that certifies whether the developer signing key of the application allows legal change. As a way, the old list of compatible keys may be included in the certificate change to prove that all old keys present in the list are allowed to be updated (upgraded).

In some scenarios, after an application has been signed using signing key a and put on shelf to the application marketplace, if a new version of the application needs to be put on shelf and it is found that the storage medium of signing key a is damaged and cannot be repaired (or other situations requiring rekeying), the application developer device may generate a new signing key B (including developer public key B and developer private key B). And applies for the replacement of signing key a with signing key B to the certificate server. For convenience of explanation, the application that is put on shelf before is referred to as application 1.0 version, and the application that is put on shelf is currently required to be referred to as application 2.0 version.

As shown in fig. 4 (B), the application developer device may send the developer public key B to the certificate server to apply for the use of the signing key B instead of the signing key a. After receiving the replacement request of the public key B of the developer, the certificate server replacement proof module of the certificate server can check the validity of the replacement request, for example, the identity validity of the developer, the replacement validity, the frequency limit, the key validity and the like. After verification is passed, the public key B of the developer can be signed by the CA issuing module to obtain a signature file (profile) containing the certificate B of the developer and the proof change file. The replacement certification module may then return the signature file to the application developer device. While the certificate management module may store the developer certificate B. The application developer device can acquire the signature file which is issued by the CA and contains the developer certificate B and the certificate replacement file.

In some scenarios, after the application developer device obtains the signature file including the developer certificate B and the certificate replacement file issued by the CA, the application developer device may use the developer private key B to sign the unsigned application 2.0 version, and write the signature file (profile) including the developer certificate B and the certificate replacement file into the signed application 2.0. Then put on shelf to the application market for any terminal device to query and download.

In some scenarios, after the terminal device downloads the application 2.0 from the application market, it may be determined whether to perform the replacement of the signing key by proving the replacement file. Thereby determining whether to allow application 1.0 to update (upgrade) normally to application 2.0.

Optionally, the replacement proof module may also record historical proof replacement information applied by the developer, which may provide a historical data support for the replacement that the developer proves, and may also provide a support for the validity judgment of the replacement that the developer proves.

In some embodiments, the certificate server and the application distribution server may be two independent servers, or may be two different functional modules in the same server, which is not limited to the embodiment of the present application. For example, the server 320 may be a cloud server supporting an application marketplace service, and the motion server may include a CA issuing module, a certificate management module, and a replacement certification module.

Referring to fig. 5, fig. 5 is a schematic diagram of an application update method applied to a certificate server or an application distribution server according to an embodiment of the present application. As shown in fig. 5, the application updating method provided by the embodiment of the present application includes:

S510, the certificate server receives a certificate replacement request from the application developer device.

It will be appreciated that the same developer may generate multiple signing keys. For example, for the developer a, in the development stage of the target application, it is necessary to generate the debug signature key a of the target application; in the target application online stage, a commercial signature key B of the target application needs to be generated. For another example, the developer a needs to generate a new signing key B even when the old signing key a is lost or leaked.

Alternatively, since the signing key is typically held by the developer alone, the signing key may uniquely identify the developer's identity. The developer's signing key or its derivative, other credentials that can be used to prove the developer's identity, such as a developer certificate, a new key that encrypts the developer's signing key, etc., can be used as a developer's proof, along with the package name of the application as the unique identification of the application. It will be appreciated that when a developer's signing key changes, the corresponding developer's proof also changes.

Alternatively, when the application developer device needs to change the developer certificate, a certificate change request may be sent to the certificate server. Wherein the certification replacement request may include a new developer certification after replacement.

In one scenario, when an application developer device needs to change a signing key, the application developer device may apply for a developer certificate to a certificate server using the new signing key after the change. The certificate server may then receive the application request of the application developer device and the replaced new signing key. If the signing key of the application developer device is recorded in the certificate server, the certificate server can use the received certificate application request as the received certificate replacement request from the application developer device.

Optionally, if the signing key of the application developer device is not recorded in the certificate server, the certificate server may consider that the application developer device is a brand new developer device, and after verifying that the identity of the application developer device passes, the signing key applied by the application developer device may be signed, and a legal developer certificate may be generated.

In an embodiment of the application, evidence that allows the old developer to prove the change is recorded in the proof change request.

In some scenarios, the proof change request has recorded therein an old developer proof that allows the change and a new developer proof after the change.

Optionally, the new developer attestation is included in the attestation replacement request to attest to the old developer attestation to be replaced so that the credential server can know which old developer attestation allows legal replacement.

Optionally, the change request includes a change path for the old and new developer certificates, so that the certificate server can know the legal change paths allowed by each old developer certificate in the historical developer certificates. For example, the change path required for old developer attestation A in attestation change request is: old developer attestation A— old developer attestation B- > new developer attestation C, the old developer attestation A is not allowed to update (upgrade) directly to the new developer attestation C.

Optionally, the certificate exchange request includes mutual sign authentication of the certificate of the new and old developers. For example, taking a developer attestation as a developer signing key, the old signing key a may be used to sign the new signing key B in the attestation change request, which may prove that both the new and old signing keys are held by the developer, because if the developer does not have the old signing key, the signing cannot be performed for the new signing key.

In some scenarios, the developer attestation is generated based on the developer signing key, and thus, evidence that the developer signing key is allowed to change may also be used as evidence that the corresponding developer attestation is allowed to change. Therefore, the old developer signing key that allows the change may be directly recorded in the certificate exchange request.

Optionally, the attestation change request includes an old developer signing key to be replaced by the new developer signing key. Or prove the change path of the signing key of the new and old developer is included in the change request. Or proving that the replacement request comprises mutual sign authentication of signing keys of new and old developers.

Alternatively, after the application developer device sends the credential replacement request, the credential server may receive the credential replacement request sent from the application developer. The certificate server may then process the request for a certificate exchange.

Alternatively, where the certificate server and the application distribution server are two different functional modules in the same server, it may be that the same server receives and processes the credential replacement request from the application developer device. For example, taking a cloud server supporting an application marketplace service as an example, the cloud server may receive a credential replacement request from an application developer device and process the credential replacement request.

S520, the certificate server verifies the replacement request.

According to the embodiment of the application, the certificate server can verify the validity of the replacement request, and can avoid misuse of the replacement proof of a developer.

Alternatively, the certificate server may verify the validity of the developer's identity. For example, the identity of the developer sending the request for proving replacement may be verified by mailbox verification, fingerprint verification, identity card, etc. When the verification finds that the identity of the developer is not the identity of the developer, the identity of the developer is illegal, and the legitimacy verification of the replacement request is proved to be not passed.

Optionally, when the validity of the identity of the developer is checked, the certificate server may determine that the validity check of the replacement request is checked, or may further check other validity, and when the other validity is checked, the certificate server may determine that the validity check of the replacement request is checked.

Alternatively, the certificate server may verify the validity of the replacement action. For example, if the developer has not previously proven by the old developer, the credential server may determine that a credential change cannot be performed, that the replacement behavior is illegal, and that the validity check of the replacement request is not passed. For another example, when the historical developer certificates of the developer are relatively large, if the allowable legal replacement of the old and new developer certificates is not explicitly indicated in the certificate replacement request, the certificate server can judge that the certificate replacement cannot be performed, the certificate replacement behavior is illegal, and the legitimacy verification of the certificate replacement request is not passed. For another example, the certificate server pays for replacing the certification service, where the certificate server may detect whether the developer paid for successfully, and if not, the certificate server may determine that the replacement behavior is illegal, and that the validity check of the replacement request is not passed.

Optionally, when the validity of the replacement proving behavior is verified, the certificate server may determine that the validity of the replacement proving request is verified, or may further verify other validity, and when the other validity is all passed, the certificate server may determine that the validity of the replacement proving request is verified.

Alternatively, it may be that the certificate server verifies the frequency of the certificate exchange. For example, if the time that the certificate server receives the request for proving replacement this time is less than the preset time threshold from the last time the request for proving replacement was received, the certificate server may determine that the frequency of proving replacement is too high, that the frequency of proving replacement is illegal, and that the validity check of the request for replacement is not passed. For another example, if the number of times the certificate server receives the request for verifying replacement is greater than the preset number of times within the preset time period, the certificate server may determine that the number of times the replacement is verified exceeds the limit, the frequency of the replacement is verified to be illegal, and the validity check of the request for replacing is verified to be failed. The preset time threshold, the frequency of replacement proof and the preset times can be reasonably set according to actual application scenes, and the embodiment of the application is not limited to the above.

Optionally, when the validity of the frequency of the proof replacement passes, the certificate server may determine that the validity of the proof replacement request passes, or may continue to check other validity, and when the other validity passes, the certificate server may determine that the validity of the proof replacement request passes.

Alternatively, the certificate server may verify the normalization of the replaced developer certification. For example, if the replaced developer certificate exceeds the first length threshold, or a special character exists, or is smaller than the second length threshold, the certificate server may determine that the replaced developer certificate is out of specification, and prove that the validity check of the replacement request is not passed.

Optionally, when the validity of the normalization proved by the developer after the replacement passes the verification, the certificate server may determine that the validity of the replacement request passes the verification, and may further verify other legalities, and when the other legalities pass the verification, the certificate server may determine that the validity of the replacement request passes the verification.

The embodiment of the application is not limited to a specific verification process for verifying the validity of the replacement request, and may be a combination of at least two possible embodiments, or may be other validity verification.

Alternatively, when the certificate server and the application distribution server are two different functional modules in the same server, the same server may verify the certificate replacement request. For example, taking a cloud server supporting an application marketplace service as an example, the cloud server may verify a credential replacement request after receiving the credential replacement request from an application developer device.

And S530, after the verification is passed, the certificate server sends the certificate replacement file to the application developer device.

In the embodiment of the application, when the validity check of the certificate replacement request is passed by the certificate server, the certificate server can generate the certificate replacement file and send the certificate replacement file to the application developer device. So that the application developer device can write the certificate change into the application to be updated and put on the shelf to the application market. So that when the user device downloads the updated application from the application market, it can identify from the certificate change file whether the developer of the application proves that the legal change is allowed. And after identifying that legal replacement is allowed, replacing the developer proof of the application and allowing normal updating of the application.

Optionally, the application to be updated is an application different from the previous application version content. In this way, the update (upgrade) installation of the application can be quickly realized by uniformly managing the certificate replacement file issued by the server, and the user does not need to manually uninstall the previous application version.

Alternatively, the application to be updated is the same application as the previous application version content, and only the developer of the application proves that the application is changed. Therefore, the application developer certification switching can be rapidly realized through the certification replacement file issued by the uniformly managed server, and the user does not need to manually uninstall the previous application version. Alternatively, since only the developer of the application is involved to prove the change, the relevant information may be directly changed without reinstalling the application.

In some embodiments, the certificate server generated certificate changes may be issued via a CA, resulting in a signature file (profile) containing the certificate changes. The certificate server may then return the signature file to the application developer device. Wherein, since CA is an authentication center trusted by the application developer device and the user device. Therefore, the CA signature information generated when the CA issues the certificate exchange can be used for proving the legitimacy of the certificate exchange issued by the certificate server, namely proving the legitimacy of the source of issuing the certificate exchange. When the validity check of the source of issuing the certificate change passes, the application developer device and the user device trust the developer certificate change information conveyed by the certificate change.

Optionally, the signature file further includes a new developer certificate of the application, so that the subsequent user equipment can directly replace the new developer certificate when recognizing that the developer certificate of the application allows legal replacement according to the certificate replacement file.

Optionally, since the developer certificate is generated based on the developer signing key, the signature file may further include a developer certificate generated by signing the new developer signing key by the CA, so that when the subsequent user device recognizes that the application developer certificate allows legal replacement according to the certificate replacement file, the new developer certificate may also be generated directly according to the new developer signing key in the new developer certificate.

In the embodiment of the application, the certificate replacement file generated by the certificate server can be recorded with a certificate allowing the old developer to prove the change. The user equipment can download the updated application from the application market after the application developer equipment writes the evidence replacement file into the application to be updated and puts the application on the application market, and can identify whether the developer of the application installed by the user equipment is permitted to be legally replaced according to the evidence replacement file. And after identifying that legal replacement is allowed, replacing with a new developer proof of the application and allowing normal updating of the application.

It can be appreciated that, due to the unified management of the certificate server, the certificate server can generate the certificate change file by extracting the historical developer certification information applied by the developer based on the historical developer certification information applied by the developer. In this way, the user device can trust the developer credential change information conveyed by the credential change when the validity check of the source of the issuance of the credential change passes.

Alternatively, the manifest change may include a new developer manifest for the application.

Optionally, the above-described certification replacement file includes a historical developer certification list to certify that all old developer certificates present in the list are allowed to be changed to new developer certificates. When updating the application, the user equipment can judge whether the developer certification of the self-installed application exists in the historical developer certification list for certifying the replacement file, and if so, the original developer certification of the self-installed application is replaced by the new developer certification of the application, and the self-installed application is allowed to be normally updated.

For example, taking a developer certificate as an example of a developer signing key, as shown in fig. 6, a certificate exchange file 610 written with an old compatible key list, and a new signing key X620 may be included in a signing file issued via CA. All old signing keys 1,2, 3 etc. present in the list are allowed to change to the new signing key X.

It can be understood that, since the private key of the developer in the signing key of the developer is private to the developer and is not externally developed, in the embodiment of the application, the content related to the signing key of the developer in the certificate of the developer and the certificate of the developer refers to the public key of the developer. For example, the proof change file 610 shown in FIG. 6 may be a historical public key list of the developer.

Optionally, the certification change file includes a change path of the new and old developer certification to certify that the old developer certification meets the change path rules, and allows the change to the new developer certification. For example, the change path required for old developer attestation A in attestation change request is: when the old developer attestation A < - > the old developer attestation B < - > the new developer attestation C, the old developer attestation A is not allowed to be directly upgraded to the new developer attestation C. When updating the application, the user equipment can match the developer certification of the application installed by itself with the change path of the new and old developer certification to judge whether the developer certification of the application installed by itself meets the change path rule, if so, the original developer certification of the application installed by itself is replaced with the new developer certification C of the application, and the application installed by itself is allowed to be updated normally.

For example, taking a developer certificate as a developer signing key, as shown in fig. 7, a certificate replacement file 710 in which upgrade paths of new and old signatures are written, and a signing key 720 used by the current application may be included in a signing file issued via CA. If the signing key used by the current application in the signing file issued by the CA is the signing key B, only the old application of the signing key A is allowed to be changed into the signing key B. If the signing key used by the current application is signing key E, only the old application of signing key D is allowed to change to signing key E. If the signing key used by the current application is signing key F, only the old application of signing key D is allowed to change to signing key F. If the signing key used by the current application is signing key C, only the old applications of signing key B, signing key E and signing key F are allowed to change to signing key C.

In some scenarios, the content of the new version application update may not be compatible with some developer proof corresponding version applications, so it is necessary to design a change path of some new and old developer proof, and thus accurately declare to the user device which old developer proof corresponding version applications allow update and which old developer proof corresponding version applications do not allow update.

Optionally, the certificate change includes mutual sign authentication of new and old developer certificates. For example, a new developer attestation B is signed with an old developer attestation A to attest to allow the old developer attestation A to switch to the new developer attestation B. It will be appreciated that this approach is applicable to scenarios where a developer holds old developer credentials, which can be used by the developer to sign new developer credentials because both new and old developer credentials are held by the present developer. If the developer does not have the old developer attestation, then signing cannot be performed for the new developer attestation.

For example, taking a developer certificate as a developer signing key, as shown in fig. 8 (a), a certificate exchange file 810 in which a mutual signature of a new signature and an old signature is written may be included in a signature file issued via CA. Where signing a signing key B pair with the oldest signing key a may prove to allow the developer to switch signing keys from the oldest signing key a to signing key B. When the latest signing key D820 is signed using signing key C, it may prove that the developer signing key is allowed to switch from signing key C to the latest signing key D820.

As an embodiment, as shown in fig. 8 (a), when the changed developer signing key is the developer signing key D, since the signing keys A, B, C, D are mutually signed, the version application corresponding to the signing key A, B, C allows updating to the version application corresponding to the signing key D. As another embodiment, as shown in (b) in fig. 8, a signature 830 written with the signature key a to the signature key D and a signature 840 written with the signature key C to the signature key D may be included in the signature file issued via the CA. When the changed developer signing key is the developer signing key D, the signing key a signs the signing key D, and the signing key C signs the signing key D, and there is no mutual signature between the signing key a and the signing key C, so that at this time, a legal signing key change path can be determined according to the directionality of the signature, and thus legal update of the version application corresponding to the change path can be verified. For example, if the developer signing key of the application of the old version installed locally on the user equipment is signing key a, since there is signature of signing key D by signing key a in the signing file, it is possible to prove that the old version application installed locally on the user equipment is allowed to be updated as the new version application corresponding to signing key D.

In some scenarios, when an application developer device needs to exchange a signing key, the application developer device may apply for issuing a new developer certificate to the certificate server using the exchanged new signing key. The certificate server may then verify the validity of the replacement new signing key, and after the verification passes, the new signing key may be signed by the CA issuing module to generate a signature file (profile) including the new developer certificate, the certificate replacement file, and the like. The certificate server may then send the CA signed signature file (profile) to the application developer device.

In some scenarios, when an application developer device develops an upgraded version of an application and desires to update the application to the application marketplace, the application of the upgraded version may be signed using the new replaced signing key, and then a signature file (profile) obtained from a certificate server and containing new developer certificates, certificate changes, and the like may be written in a software package of the application of the upgraded version. And put on shelf to the application market.

The user device may perform installation after downloading the updated upgraded version of the application from the application marketplace, and may obtain a certificate replacement file from the signature file of the upgraded version of the application to identify whether the application is correctly declared in the certificate replacement file to allow switching from the previous signature key to the new signature key. And upon identifying that the switch is allowed, the executing application is allowed to switch from the previous signing key to the new signing key. After the switching, the user can recognize that the old version of application can be normally upgraded to the application with the upgraded version. After the application is updated and installed, only the application with the updated version is stored on the user equipment, the application is successfully updated, and the signature key is successfully switched.

In some scenarios, when the certificate server and the application distribution server are two different functional modules in the same server, the same server may send the certificate replacement file to the application developer device after the verification of the certificate replacement request is passed. For example, taking a cloud server supporting an application market service as an example, the cloud server may send the certificate replacement file to the application developer device after the verification of the certificate replacement request is passed.

According to the application updating method provided by the embodiment of the application, the certificate server can support the application developer equipment to submit the developer evidence replacement application, support the verification of the validity of the developer evidence replacement, support the issuing of the evidence replacement document, and verify that the source of the issued evidence replacement document is legal by signing the evidence replacement document through the CA issuing module, and the application developer equipment and the user equipment can trust the developer evidence replacement information in the evidence replacement document. In this way, the certificate server or the application distribution server can prevent the developer certificate and the developer certificate from being forged and tampered by uniformly managing and verifying the developer certificate and the developer certificate replacement.

With continued reference to fig. 5, the application updating method provided by the embodiment of the present application further includes:

s540, the application developer device acquires the certificate change file from the certificate server.

Optionally, the certificate change is uniformly signed by a CA issuing module in the certificate server. Since CA is an authentication center trusted by application developer devices and user devices. The signature information generated when the CA issues the certificate change can be used to prove the legitimacy of the certificate change issued by the certificate server, i.e. the legitimacy of the source from which the certificate change was issued.

Alternatively, the application developer device may obtain the certificate change file from the certificate server when the application developer device applies for the change developer certificate to the certificate server.

Optionally, when the application developer device applies for the developer certificate from the certificate server using the developer signing key, the certificate server may determine whether the application developer device has a replacement requirement of the developer certificate according to whether the application developer device has a historical developer certificate.

Alternatively, when the credential server detects that the application developer device does not have a historical developer credential, the credential server may consider the application developer device to be a newly registered developer device. After verifying the validity of the identity of the application developer device, the certificate server can issue a developer certificate according to the applied developer signing key. In some scenarios, when a credential server issues a developer credential, a signature file (profile) may be generated that contains the developer credential. The certificate server may then send the signature file (profile) to the application developer device. So that the application developer device can receive the developer certificate from the certificate server.

Alternatively, when the credential server detects that the application developer device has a historical developer credential, the credential server may consider that the application developer device is not a newly registered developer device, and the credential server may consider that the application developer device is a signing key that requests replacement of its applied signing key by the historical signing key, i.e., there is a change in the signing key. In this case, the certificate server may assume that the developer certificate generated based on the signing key is changed when the signing key is changed. Thus, the credential server may determine that the application developer device has a developer-proven replacement requirement. After verifying the replacement and legitimacy of the developer certificate, the certificate server can issue a new developer certificate and a certificate replacement file according to the applied developer signing key.

In some scenarios, when a certificate server issues a new developer certificate and a certificate replacement file, a signature file (profile) may be generated that contains the new developer certificate and the certificate replacement file. The certificate server may then send the signature file (profile) to the application developer device. So that the application developer device can receive the certificate change from the certificate server.

Alternatively, the application developer device, upon acquiring the certificate change, may verify the integrity of the certificate change, preventing the certificate change from being destroyed or tampered with. As one way, since the certificate change is uniformly signed by the CA issuing module in the certificate server, when the application developer device acquires the certificate change, the application developer device also acquires the signature information of the certificate change. The application developer device can prevent the certificate change file from being tampered by checking the integrity of the certificate change file through the signature information of the certificate change file.

Optionally, when the application developer device acquires the certificate replacement file, the validity of the certificate replacement file may also be checked to determine whether the source of the certificate replacement file is legal. As one way, the application developer device may parse the source of the signature (root certificate) from the signature information certifying the change file. When the signature source is consistent with the signature source trusted by the application developer device, the certification is determined to be valid. For example, when the signature source trusted by the application developer device includes a CA issuing authority of the certificate server, if the signature source parsed from the signature information of the certificate change is from the CA, the application developer device may determine that the certificate change source is legal.

Alternatively, the application developer device may be pre-set with a trusted signature source list. The signature source list may include the root CA certificate of the certificate server of the present application or other trusted root certificates.

Alternatively, the application developer device may trust the developer attestation change information conveyed by the attestation change file when both of the validity checks of the attestation change file pass.

Similarly, the application developer device may also verify the integrity and legitimacy of the new developer certificate issued by the certificate server.

In some scenarios, when the certificate server and the application distribution server are two different functional modules in the same server, it may be that the application developer device obtains the certificate change from the same server. For example, taking a cloud server supporting an application marketplace service as an example, an application developer device may obtain a proof change file from the cloud server.

S550, the application developer device adds the replacement certificate to the target application.

In the embodiment of the application, after receiving the certificate replacement file, the application developer device can sign the target application by using the developer signing key and package the replacement certificate file into a software package of the target application.

Optionally, when the application developer device obtains a signature file (profile) containing a new developer certificate and a certificate replacement file from the certificate server, the application developer device may also package the signature file (profile) into a software package of the target application. Wherein the target application may be a first application requiring modification of the developer's proof.

Alternatively, the application developer device may set up the first application to the application marketplace after signing the first application using the developer signing key before the developer attestation changes. The application developer device adds a package name and a developer certificate before modification in the first application, so as to uniquely identify the first application in a mode of package name and developer certificate, and writes a signature file (profile) containing a developer certificate in the first application. The user device may then download the first application from the application marketplace and install it in the local system.

When the application developer device needs to replace the developer certificate because of leakage, loss and the like of the developer certificate, the application developer device can generate a new developer certificate, and can acquire a certificate replacement file from the certificate server when the application developer device applies for the certificate replacement based on the new developer certificate. The application developer device may then use the new developer attestation to re-launch the first application into the application marketplace after signing the first application using the developer signing key. The first application that needs to be changed to be brought up again by the developer certification may be referred to herein as the target application. The application developer device may add a package name and a modified developer certificate to the target application, and package a signature file (profile) containing the developer certificate and the certificate replacement file into the target application. The user device may then download the target application from the application marketplace and perform the installation.

For example, taking a developer attestation as a developer signing key as an example, the target application may be a first application that requires modification of the developer signing key. For convenience of explanation, the developer signing key before modification may be referred to as a signing key a, and the developer signing key after modification may be referred to as a signing key B.

The application developer device may put the first application on the application marketplace after signing the first application using the signing key a. The application developer device adds a package name and a signature key A in the first application, and writes a signature file (profile) containing a developer certificate A in the first application. The user device may then download the first application from the application marketplace and install it in the local system.

When the application developer device needs to replace the developer signing key due to the conditions of leakage, loss and the like of the developer signing key, the application developer device can generate a new developer signing key B, and can acquire a certificate replacement file and a developer certificate B from the certificate server when applying for key replacement to the certificate server based on the new signing key A. Then, the application developer device re-puts the first application on the application market after signing the first application by using the replaced signing key B. The first application that needs to be changed to be re-shelved by the developer signing key may be referred to herein as the target application. The application developer device may add a package name and a signature key B to the target application, and package a signature file (profile) including the developer certificate B and the certificate replacement file into the target application. The user device may then download the target application from the application marketplace and perform the installation.

S560, the application developer device sends the target application to the application distribution server.

In the embodiment of the present application, the application distribution server is used for managing and distributing the application program, for example, the application distribution server may be a cloud server that provides an application market service, or other application distribution channels that may be used for the end user to download the application, which is not limited to the embodiment of the present application. Taking the application distribution server as a cloud server supporting the application market service as an example, the application developer device sends the target application to the application distribution server, so that the target application can be put on shelf in the application market, and other users can download the target application from the application market.

The application distribution server may be a server representing one of the application markets. As a specific implementation, there may also be a plurality of application distribution servers, where each server corresponds to a different application market or application distribution channel, where a specific working manner of each server may be the same as that of the application distribution server, so that the embodiments of the present application are not described again.

In some scenarios, the credential server and the application distribution server may be two different functional modules in the same server, i.e. the application developer device sends the target application to the same server. For example, taking a cloud server supporting an application market service as an example, the application developer device may obtain the certificate change file from the cloud server, and then package the certificate change file into a target application and upload the target application to the cloud server for other users to download the target application.

According to the application updating method provided by the embodiment of the application, the certificate server or the application distribution server can enable the application developer device to package the signature file (profile) carrying the developer certificate and the developer certificate replacement file into the application together when uploading the application through unified verification, issuing and management of the developer certificate and the developer certificate replacement file. So that when these applications are uploaded to the application distribution server, the application distribution server can distribute these applications to the respective user devices. In this way, the developer certificate and the signature file (profile) issued by the server for uniformly managing and controlling the developer certificate and the developer certificate replacement file are used for carrying the developer certificate replacement file, so that the developer certificate replacement file can be prevented from being tampered and counterfeited when reaching the user equipment side.

In some embodiments, after the application distribution server puts the target application on shelf, the user device may obtain the target application from the server. Taking the cloud server providing the application market service as an example, the application distribution server may be provided with an application market application on the user equipment. After the cloud server puts the target application on shelf, the installation option (or the downloading option) or the updating option of the target application can be displayed in the display interface of the application market application on the user equipment. Optionally, if the user device has previously installed an old version of an application, the cloud server may display an update option of the application in a display interface of an application market application on the user device after putting the new version of the application on shelf.

Optionally, if any version of an application is not installed locally in the user device, after the cloud server puts the new version of the application on shelf, an installation option (or a download option) of the new version of the application may be displayed in a display interface of the application in the "application market" on the user device.

For example, as shown in fig. 9, taking the 2.0 version of "XX music" as the target application and the 1.0 version of "XX music" as the first application, if the 1.0 version of "XX music" has been installed before the user equipment, after the cloud server puts the 2.0 version of "XX music" on shelf, an update option of "XX music" may be displayed in a display interface of the "application market" application on the user equipment, so as to prompt the user that a new version of "XX music" is currently available.

The user can choose whether to update (or upgrade) the "XX music" according to his own needs. If the user selects update "XX music", the update option of "XX music" may be triggered on the user device by clicking, touching, etc., as shown in FIG. 9. So that the user device can obtain the software package of version 2.0 of the "XX music" from the cloud server.

Alternatively, the user device may also automatically trigger the update of "XX music" without manual operation by the user.

Referring to fig. 10, fig. 10 is a schematic diagram of an application updating method applied to a ue according to an embodiment of the present application. As shown in fig. 10, the application updating method provided by the embodiment of the application includes.

S1000, the user equipment acquires a first application from an application distribution server.

Wherein the first application may be downloaded by the user device from the application marketplace (application distribution server) to the user device locally in the form of a software package (installation package) comprising the package name and developer attestation of the first application.

Alternatively, the first application may be version 1.0 of the above "XX music".

Optionally, the user device, upon detecting a first operation of the user on the first application, downloads the software package of the first application from the distribution server in response to the first operation. The first operation may be a touch operation such as a single click, a double click, a long press, etc., which is not limited in the embodiment of the present application.

In the embodiment of the present application, the software package of the first application carries a signature file (profile) issued by the private key of the CA, where the signature file includes a developer certificate issued by the CA.

In some embodiments, after the user device downloads the obtained software package of the first application from the application distribution server, the developer certificate may be obtained from the signature information of the software package of the first application, so as to verify the validity of the developer certificate.

In some scenarios, the user device may include a preset issuing CA module, storing CA certificates trusted by the user device, which may be used to verify that the signature source of the developer certificate is legitimate.

Alternatively, the user device may obtain the issuing CA certificate from the signature information of the developer certificate to parse the signature source. Then judging whether the issuing source of the developer certificate, namely the issuing CA certificate, is consistent with a preset trusted CA certificate, and if so, the user equipment judges that the first application is from a legal developer and a legal application market (application distribution server) and allows installation. When the first application is inconsistent, the user equipment judges that the first application is from an illegal developer and an illegal application market (application distribution server), and installation is not allowed.

As one way, the preset trusted CA certificate can be the complete CA certificate content, or part of the CA certificate information, such as information of an issuing authority, a theme of the certificate, a public key of the CA certificate and the like. The embodiment of the application does not limit the form of the preset trusted CA certificate.

Optionally, after verifying the validity of the developer certificate, the user device may extract the package name and developer certificate of the first application from the software package to perform installation verification prior to installation of the first application.

S1010, the user equipment judges that the package name of the first application is inconsistent with the package name of the local application.

In the embodiment of the application, the user equipment can compare the extracted package name of the first application with the package names of all applications installed in the local system to determine whether the first application is a brand new application or an updated version application corresponding to the local application.

Alternatively, the user device may determine whether the package name of the first application is consistent with the package name of the local application. If the packet names of the first application and the local application are inconsistent, the first application can be judged to be a brand new application. If there is a local application whose package name is consistent with that of the first application, it may be determined that the first application may be an updated version application corresponding to the local application.

S1020, the user equipment installs the first application.

In the embodiment of the application, when the user equipment judges that the package name of the first application is inconsistent with the package name of the local application, the first application can be considered to be independently installed, does not conflict with the installed application, and can exist simultaneously. Thus, the user device may install the first application into the local system.

S1030, the user equipment acquires the target application from the application distribution server.

The target application may also be downloaded by the user device from the application market (application distribution server) to the user device locally in the form of a software package (installation package), which includes the package name and developer certification of the target application.

Optionally, the user device, upon detecting a first operation of the user acting on the target application, downloads the software package of the target application from the distribution server in response to the first operation. The first operation may be a touch operation such as a single click, a double click, a long press, etc., which is not limited in the embodiment of the present application.

Alternatively, the target application may be an updated version of the first application. The user device may automatically obtain the target application from the application distribution server to enable automatic updating of the application. For example, when the first application is version 1.0 of the above "XX music", the target application may be version 2.0 of the above "XX music".

As one approach, the target application may be an upgrade package whose package name and developer prove consistent with the first application, but whose version contents are different. As another approach, the target application may be a package name and version content consistent with the first application, but a developer attestation update package whose developer attestation is inconsistent with the first application. As yet another approach, the target application may also be an upgrade package whose package name is consistent with the first application, but whose developer attests and version content are inconsistent with the first application.

In some scenarios, when the target application is a developer of the first application to prove the changed application, the software package of the target application carries a signature file (profile) issued by the CA, where the signature file may include a developer certificate and a proof change file issued by the CA.

In some embodiments, after the user device downloads the obtained software package of the target application from the application distribution server, similar to the first application, the user device may also obtain a developer certificate from the signature information of the software package of the target application, determine whether the source of issuing the developer certificate, that is, the CA certificate issued, is consistent with a preset trusted CA certificate, and if so, the user device determines that the target application is from a legal developer and a legal application market (application distribution server), and allows installation. If the target application is inconsistent, the user equipment judges that the target application is from an illegal developer and an illegal application market (application distribution server), and the target application is not allowed to be installed.

Alternatively, the target application may be an application unrelated to the first application.

Optionally, after verifying the validity of the developer certificate, the user device may extract the package name and developer certificate of the target application from the software package to perform installation verification prior to installation of the target application.

S1040, the user equipment judges that the package name of the target application is consistent with the package name of the local first application.

In the embodiment of the application, the user equipment can compare the extracted package name of the target application with the package names of all applications installed in the local system to determine whether the target application is a brand new application or an updated version application corresponding to the locally installed application.

Alternatively, the user device may determine whether the package name of the target application is consistent with the package name of the locally installed application. If the packet names of the applications are inconsistent with the packet names of the locally installed applications, the target application can be judged to be a brand new application. If there is a local installation application with a package name consistent with the package name of the target application, it may be determined that the target application may be an updated version application corresponding to the local installation application.

In the embodiment of the application, if the user equipment judges that the package name of the locally installed application is consistent with the package name of the target application, the user equipment can execute the following application updating step, namely, checking the consistency of the evidence of the developer, and checking the validity of the evidence of the replacement file when the inconsistency is identified. Here, for convenience of explanation, the local application set to coincide with the package name of the target application may be the first application installed as described above.

S1050, the user equipment judges that the developer certification of the target application is inconsistent with the developer certification of the first application.

In the embodiment of the application, when the user equipment detects that the packet name of the target application is consistent with the packet name of the local first application, the application updating method for the first application can be executed. The user equipment may first determine whether the developer proof of the target application is consistent with the developer proof of the first application.

It can be appreciated that if the developer proof of the target application is consistent with the developer proof of the first application, the user device may identify that the target application and the first application are different versions of the same application, and the user device may perform normal upgrade on the first application to directly overlay upgrade to the target application without requiring the user to manually uninstall the first application.

If the developer certification of the target application is inconsistent with the developer certification of the first application, in the prior art, the user equipment can identify different applications of the target application and the first application developed for different developers, the user equipment cannot normally upgrade the first application, and the user needs to manually uninstall the first application to install the target application. In the embodiment of the application, the user equipment can execute the following application updating step, namely, the normal upgrading of the first application is realized by checking the validity of the evidence replacement file of the target application, and the user is not required to manually uninstall the first application.

Illustratively, taking a developer certificate as an example, if the developer public key in the developer certificate of the target application is inconsistent with the developer public key in the developer certificate of the first application, the validity of the certificate change file of the target application is checked.

S1060, the user equipment acquires the evidence replacement file of the target application.

Wherein the proof change file is the change proof credential added to the target application in the foregoing embodiment. This is not described in detail.

In the embodiment of the application, when the user equipment detects that the developer certification of the target application is inconsistent with the developer certification of the first application, a certification replacement file can be obtained from the signature file (profile) of the software package of the target application, so that whether the developer certification switching for the first application is legal or not is checked according to the certification replacement file.

Optionally, after the user device obtains the signature file (profile) from the software package of the target application, the integrity of the signature file may be checked. As one way, the user may extract the public key information of the CA from the signature information of the signature file to verify the integrity of the signature file according to the public key information of the CA, preventing the signature file from being destroyed or tampered.

Alternatively, the software package of the first application may be written with the original data content of the signature file, and the user device may generate the first digest information according to the original data content of the signature file. The first summary information may be a hash value generated according to the original data content of the signature file, and the change of the original data content of the signature file may cause the change of the hash value, so that the first summary information may accurately represent the original data content of the current signature file. And then the user equipment decrypts the signature file through the public key of the CA to obtain second abstract information of the signature file, and when the second abstract information is consistent with the first abstract information, the integrity of the signature file can be considered to pass through. When the second summary information is inconsistent with the first summary information, the integrity of the verification signature file can be considered to be failed, and the application updating method provided by the embodiment of the application is not allowed to be executed.

Optionally, the software package of the first application may also directly write the first summary information of the original data content of the signature file, after the user device decrypts the signature file through the public key of the CA, the second summary information of the signature file may be obtained, and when the second summary information is consistent with the first summary information, it may be considered that the integrity of the signature file is checked. When the second summary information is inconsistent with the first summary information, the integrity of the verification signature file can be considered to be failed, and the application updating method provided by the embodiment of the application is not allowed to be executed.

Optionally, after the user device obtains the signature file (profile) from the software package of the target application, the validity of the signature file may also be checked. As one way, the user device may parse the signature source, i.e. issue the CA certificate, from the signature information of the signature file. The user equipment can judge whether the signature source is consistent with a preset trusted CA certificate, and when the signature source is consistent with the preset trusted CA certificate, the user equipment judges that the source of the signature file is legal. And when the signature file is inconsistent, the user equipment judges that the source of the signature file is illegal, and the application updating method provided by the embodiment of the application is not allowed to be executed.

S1070, the user equipment verifies the certificate replacement file.

In the embodiment of the application, the user equipment can read the certificate which is recorded in the certificate change file and allows the old developer to prove the change, and judge whether the developer certificate of the first application is the old developer certificate which can allow the change.

That is, the user device can determine whether the developer certification of the first application is correctly declared by certifying the contents recorded in the change file, and can switch to the developer certification of the target application.

If the proof change file correctly declares that the developer proof of the first application can be switched to the developer proof of the target application, the user equipment verifies that the proof change file passes, and recognizes that the developer proof switching behavior of the first application is legal, and allows the developer proof of the first application to be switched to the developer proof of the target application.

If the proof change file does not correctly state that the developer proof of the first application can be switched to the developer proof of the target application, the user equipment verifies that the proof change file does not pass, and can recognize that the developer proof switching behavior of the first application is illegal and does not allow the developer proof of the first application to be switched to the developer proof of the target application. Alternatively, at this point, the user may manually uninstall the first application and install the second application.

Taking the developer certificate as the developer signing key as an example, for example, as shown in fig. 6, in the certificate exchange file 610, if the signing key of the first application is the old signing key 3 and the signing key of the target application is the new signing key X, it may be determined whether the signing key of the first application is included in the history key list of the certificate exchange file 610. As shown in fig. 6, the certificate exchange file 610 includes the signing key of the first application, and the user device may determine that the application is explicitly stated to be switchable from the old signing key 3 to the new signing key X in the certificate exchange file 610. The user equipment verifies that the replacement file passes, recognizes that the signature key switching behavior of the first application is legal, and allows the old signature key 3 of the first application to be executed to be switched to the new signature key X of the target application.

Illustratively, as shown in fig. 7, in the proof change file 710, if the signing key of the first application is the old signing key B and the signing key of the target application is the signing key E, it is not stated in the proof change file 710 that the application can be switched from the old signing key B to the signing key E. The user equipment checks to prove that the replacement file does not pass, recognizes that the signature key switching behavior of the first application is illegal, and does not allow the old signature key B of the first application to be executed to be switched to the signature key E of the target application.

Illustratively, as in the proof change file 810 shown in fig. 8 (a), if the signing key of the first application is the oldest signing key a and the signing key of the target application is the signing key B, it is explicitly stated in the proof change file 810 that the application can be switched from the oldest signing key a to the signing key B. The user equipment verifies that the replacement file passes, recognizes that the signing key switching behavior of the first application is legal, and allows the oldest signing key A of the first application to be executed to be switched to the signing key B of the target application.

And S1080, after the verification is passed, the user equipment performs coverage installation on the first application according to the target application.

In the embodiment of the application, after the user equipment verifies that the file replacement is passed, the user equipment can identify that the target application can be normally upgraded by the first application, and execute application coverage installation without manually unloading the first application by a user. After the user equipment is installed, only the target application is stored, the first application is successfully upgraded, and a developer proves that the switching is successful.

Taking the developer proof as the developer signing key as an example, as shown in fig. 11, for example, if the signing key of the first application is the developer public key a and the signing key of the target application is the developer public key B, and if the proof change file explicitly states that the application can be switched from the developer public key a to the developer public key B, the user equipment verifies that the proof change file passes, and recognizes that the signing key switching behavior of the first application is legal, and allows the developer public key a executing the first application to be switched to the developer public key B of the target application. Then the user equipment can recognize that the target application can be normally upgraded by the first application, so that the user equipment directly covers the first application and directly installs the target application. As shown in fig. 11, after the user equipment is installed, only the target application is stored, the first application is successfully upgraded, and the key switching of the developer is successful.

For example, taking the example that the first application is version 1.0 of "XX music" and the target application is version 2.0 of "XX music", please refer to fig. 12, fig. 12 shows an overall flow chart of the application update method provided by the embodiment of the present application.

The developer uses the application developer device to first upload version 1.0 of "XX music" to the application distribution server, which version 1.0 of "XX music" is signed using signing key a, and uses signing key a as a developer proof of the "XX music" application. The user device then downloads version 1.0 of "XX music" from the application distribution server and successfully installs into the local operating system.

Thereafter, the developer wishes to put on the 2.0 version of "XX music", but at this time the developer finds that the storage medium of signing key a is damaged and cannot be repaired (or other cases where the key must be replaced), cannot perform signing of the 2.0 version of "XX music" using signing key a, the developer generates a new signing key B, and applies to the application distribution server to replace signing key a with signing key B. After the application distribution server verifies the validity of the application, the application distribution server can issue a signature file signed by the CA to the developer, wherein the signature file comprises a certificate replacement file.

Then, the developer subsequently develops version 2.0 of "XX music" and wishes to update the on-shelf, needs to sign version 2.0 of "XX music" using a new signing key B, and writes a signature file acquired from the application distribution server in the software package of version 2.0 of "XX music", the signature file containing the certificate replacement file.

The developer then uses the application developer device to upload version 2.0 of "XX music" to the application distribution server and uses the signing key B as a developer attestation for the "XX music" application. The user device then downloads version 2.0 of "XX music" from the application distribution server and upon execution of the installation, detects that version 1.0 of "XX music" is locally present (as judged by the same package name), executes the application update logic, verifies the developer attestation consistency of version 1.0 of "XX music" and version 2.0 of "XX music".

At this time, the user equipment may detect that the developer of version 1.0 of "XX music" and the developer of version 2.0 of "XX music" prove inconsistent, and the user equipment may obtain the signature file from the software package of version 2.0 of "XX music" and obtain the proof change file from the signature file after checking the integrity and legitimacy of the signature file. The user device then verifies the certificate exchange file to determine if the certificate exchange file correctly declares that the developer of "XX music" has certified the switch from signing key A to signing key B. If the verification is successful, the user equipment can identify that the key replacement is legal, and allows the 1.0 version of the XX music corresponding to the signature key A to be updated normally to the 2.0 version of the XX music corresponding to the signature key B. At this time, the user equipment may directly perform the overlay installation of the 2.0 version of "XX music", and after the installation, only the 2.0 version of "XX music" is stored on the user equipment. The user does not need to manually uninstall the 1.0 version of "XX music" and then install the 2.0 version of "XX music".

Thus, the problem that the application cannot be normally upgraded after the developer proves to be replaced in some existing operating systems is solved. The application updating method provided by the embodiment of the application is suitable for the scene that the developer proof is lost, and can be implemented even if the developer does not hold the old developer proof. In addition, the cloud profile file carries the evidence replacement file, and the evidence replacement file is issued and signed by a legal application market (application distribution server) or a certificate server, so that the problems of abuse, embezzlement, tampering and the like can be effectively prevented. In addition, the certificate change is issued via the CA, so that when the user device installs the application, the certificate change issued by the cloud server is trusted. And the developer proving behaviors are uniformly controlled by the cloud server, so that the misuse of the developer proving replacement can be prevented.

It should be noted that, the developer certification replacement method provided by the embodiment of the application is also applicable to a key replacement scenario in secure communication between any two electronic devices.

Illustratively, when the electronic device 1 has a public key a and a private key a, the electronic device may send the public key a to a certificate server, which may issue a digital certificate a based on the public key a. The electronic device 1 may then send the digital certificate a to the electronic device 2, and the electronic device 2 may obtain public key a information of the electronic device 1 after verifying the validity of the digital certificate a. Thus, after the electronic device 1 encrypts the message to be transmitted by using the private key a, the message can be sent to the electronic device 2, and the electronic device 2 can decrypt the encrypted message by using the public key a, thereby realizing secure communication.

When the electronic device 1 loses, leaks or otherwise needs to change the key because of the private key a, the electronic device may generate a new public-private key pair, i.e., the public key B and the private key B. The electronic device may then send the public key B to the certificate server to apply for replacing the key, and the certificate server may issue the digital certificate B and the key replacement certificate based on the public key B after verifying that the key replacement request passes. The electronic device may then send the digital certificate B and the key change certificate to the electronic device 2. After verifying the validity of the digital certificate B and the key change certificate, the electronic device 2 may switch the key in communication with the electronic device 1 from the public key a to the public key B. Therefore, after the electronic equipment 1 encrypts the message to be transmitted by using the private key B, the message can be sent to the electronic equipment 2, and the electronic equipment 2 can decrypt the encrypted message by using the public key B, so that the key replacement in the secure communication is realized, and the problem that the key change evidence file is tampered and forged can be effectively prevented.

It will be appreciated that the electronic device, in order to achieve the above-described functions, includes corresponding hardware and/or software modules that perform the respective functions. The present application can be implemented in hardware or a combination of hardware and computer software, in conjunction with the example algorithm steps described in connection with the embodiments disclosed herein. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application in conjunction with the embodiments, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The present embodiment may divide the functional modules of the electronic device according to the above method example, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated modules described above may be implemented in hardware. It should be noted that, in this embodiment, the division of the modules is schematic, only one logic function is divided, and another division manner may be implemented in actual implementation.

The embodiment of the application also provides electronic equipment, which comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, wherein when the processor executes the computer program, the electronic equipment realizes the functions or steps executed by the certificate server, the application distribution server, the application developer equipment or the user equipment in the method embodiments. The electronic device may be a certificate server, an application distribution server, or a cloud server supporting an application market service, where the certificate server and the application distribution server are two different functional modules in the cloud server, and may be an application developer device or a user device.

The embodiment of the application also provides an application updating device which can be applied to the electronic equipment. The apparatus is configured to perform the functions or steps performed by the certificate server, the application distribution server, the application developer device, or the user device in the above-described method embodiments.

The embodiment of the application also provides a chip system which comprises at least one processor and at least one interface circuit. The processors and interface circuits may be interconnected by wires. The interface circuit may read the instructions stored in the memory and send the instructions to the processor. The instructions, when executed by the processor, may cause the electronic device to perform the various functions or steps described above as being performed by the vehicle in the method embodiments. Of course, the system-on-chip may also include other discrete devices, which are not particularly limited in accordance with embodiments of the present application.

The embodiment of the application also provides a computer storage medium, which comprises computer instructions, when the computer instructions are run on the electronic device, the electronic device is caused to execute the functions or steps executed by the certificate server, the application distribution server, the application developer device or the user device in the embodiment of the method.

Embodiments of the present application also provide a computer program product which, when run on an electronic device, causes the electronic device to perform the functions or steps performed by the certificate server, the application distribution server, the application developer device, or the user device in the above-described method embodiments.

The electronic device, the application updating device, the computer storage medium, the computer program product, or the chip provided in this embodiment are all configured to execute the corresponding method provided above, so that the beneficial effects achieved by the electronic device, the application updating device, the computer storage medium, the computer program product, or the chip can refer to the beneficial effects in the corresponding method provided above, and are not described herein.

It will be apparent to those skilled in the art from this description that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely illustrative of specific embodiments of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present application should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An application update method, characterized in that it is applied to a communication system including a first terminal device and a server, and the method comprises:

The server sends a second version of the first application to the first terminal device, wherein the second version of the first application includes a first certificate and certificate change information, and the first certificate is a developer certificate of the second version of the first application;

The first terminal device obtains the second version of the first application from the server;

If the first terminal device detects that the developer certificate of the first version of the first application is inconsistent with the first certificate, the first terminal device determines whether to allow the first version of the first application to be updated to the second version of the first application according to the certificate change information, wherein the first version of the first application is an application locally installed on the first terminal device;

If the first terminal device detects that the developer certificate of the first version of the first application is consistent with the first certificate, the first terminal device performs an update installation from the first version to the second version of the first application.

2 . The method according to claim 1 , wherein the certification change information comprises a developer certification list, wherein the developer certification list comprises developer certifications of the first application that are allowed to be updated to the second version.

3. The method according to claim 2 is characterized in that the first terminal device determines whether to allow the first version of the first application to be updated to the second version of the first application according to the certification change information, comprising:

The first terminal device obtains the developer certification list from the certification change information;

The first terminal device determines whether the developer certification list includes the developer certification of the first version of the first application.

4. The method according to claim 3, characterized in that the method further comprises:

If the first terminal device detects that the developer certification list includes the developer certification of the first version of the first application, the first terminal device performs an update installation from the first version to the second version of the first application.

5. The method according to claim 1 is characterized in that the certification change information includes an update path, and the update path includes an update rule between at least two developer certifications of the first application.

6. The method according to claim 5, wherein the first terminal device determines whether to allow the first application of the first version to be updated to the first application of the second version according to the certification change information, comprising:

The first terminal device obtains the update path from the certification change information;

The first terminal device determines whether the update rule of the update path is satisfied between the first application of the first version and the first application of the second version.

7. The method according to claim 6, characterized in that the method further comprises:

If the first terminal device detects that the first application of the first version and the first application of the second version satisfy the update rule of the update path, the first terminal device performs an update installation from the first version to the second version of the first application.

8. The method according to claim 1 is characterized in that the certification change information includes signature information of other developer certifications on the first certification, and the other developer certifications are developer certifications of the first application that are allowed to be updated to the second version.

9. The method according to any one of claims 1 to 8, characterized in that before the server sends the second version of the first application to the first terminal device, the method further comprises:

The server sends the first version of the first application to the first terminal device, wherein the first version of the first application includes a second certificate, and the second certificate is a developer certificate of the first version of the first application;

The first terminal device obtains the first version of the first application from the server;

The first terminal device installs the first version of the first application.

10. The method according to any one of claims 1 to 9, characterized in that the communication system further comprises a second terminal device, and before the server sends the second version of the first application to the first terminal device, the method further comprises:

The second terminal device sends a certification change request for the first application to the server;

When the server receives the certificate change request from the second terminal device, generating certificate change information according to the certificate change request;

The server sends the certification change information to the second terminal device.

11. The method according to claim 10, characterized in that before the server sends the second version of the first application to the first terminal device, the method further comprises:

The second terminal device sends the second version of the first application to the server, where the second version of the first application includes the first certificate and the certificate change information.

12. The method according to claim 9, wherein the communication system further comprises a second terminal device, and before the server sends the first version of the first application to the first terminal device, the method further comprises:

The second terminal device sends the first version of the first application to the server, where the first version of the first application includes the second certificate.

13. The method according to any one of claims 1 to 12, characterized in that after the first terminal device obtains the second version of the first application from the server, the method further comprises:

The first terminal device obtains the first application of the first version corresponding to the package name according to the package name of the first application of the second version.

14. An application update method, characterized in that it is applied to a first terminal device in a communication system, and the method comprises:

Acquire a second version of the first application from the server, wherein the second version of the first application includes a first certificate and certificate change information, and the first certificate is a developer certificate of the second version of the first application;

If it is detected that the developer certificate of the first version of the first application is inconsistent with the first certificate, judging whether to allow the first version of the first application to be updated to the second version of the first application according to the certificate change information, wherein the first version of the first application is an application locally installed on the first terminal device;

If it is detected that the developer certificate of the first version of the first application is consistent with the first certificate, an update installation from the first version to the second version is performed on the first application.

15 . The method according to claim 14 , wherein the certification change information comprises a developer certification list, wherein the developer certification list comprises developer certifications of the first application that are allowed to be updated to the second version.

16. The method according to claim 15, wherein judging whether to allow updating the first application of the first version to the first application of the second version according to the certification change information comprises:

Acquire the developer certification list from the certification change information;

It is determined whether the developer certification list includes the developer certification of the first version of the first application.

17. The method according to claim 16, characterized in that the method further comprises:

If it is detected that the developer certification list includes the developer certification of the first version of the first application, an update installation from the first version to the second version is performed on the first application.

18. The method according to claim 14, characterized in that the certification change information includes an update path, and the update path includes an update rule between at least two developer certifications of the first application.

19. The method according to claim 18, wherein judging whether to allow the first application of the first version to be updated to the first application of the second version according to the certification change information comprises:

Acquire the update path from the certification change information;

It is determined whether the update rule of the update path is satisfied between the first application of the first version and the first application of the second version.

20. The method according to claim 19, characterized in that the method further comprises:

If it is detected that the update rule of the update path is satisfied between the first application of the first version and the first application of the second version, an update installation from the first version to the second version is performed on the first application.

21. The method according to claim 14 is characterized in that the certification change information includes signature information of other developer certifications on the first certification, and the other developer certifications are developer certifications of the first application that are allowed to be updated to the second version.

22. The method according to any one of claims 14 to 21, characterized in that before obtaining the second version of the first application from the server, the method further comprises:

Acquire the first version of the first application from the server, wherein the first version of the first application includes a second certificate, and the second certificate is a developer certificate of the first version of the first application;

Install the first version of the first application.

23. The method according to any one of claims 14 to 22, characterized in that after obtaining the second version of the first application from the server, the method further comprises:

According to the package name of the first application of the second version, the first application of the first version corresponding to the package name is obtained.

24. An electronic device, characterized in that the electronic device comprises a memory and one or more processors; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code comprises computer instructions, and when the processor executes the computer instructions, the electronic device executes the method as described in any one of claims 14-23.

25. A computer-readable storage medium, characterized in that it comprises computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the method as claimed in any one of claims 14 to 23.