Application program authentication method and authentication device

Abstract

The present application provides an authentication method and an authentication device for an application, the method comprising: obtaining an aggregated public key and an aggregated signature (S110); verifying the aggregated signature through the aggregated public key to obtain an authentication result for a target program; wherein the aggregated public key is aggregated from N public keys corresponding to N applications on a first terminal, the N applications include a target program and N‑1 auxiliary programs, and the aggregated signature is aggregated from N signature data obtained by N applications signing the target program, where N is an integer greater than or equal to 2 (S120); and the public keys of applications configured on different terminals belong to different Abelian groups, and the public keys of applications configured on the same terminal belong to the same Abelian group. According to the authentication method provided by the present application, the authentication of the application can be decoupled from the hardware attributes, avoiding the problem that the application cannot be normally enabled due to hardware damage or replacement.

Description

Application authentication method and authentication device Technical Field

[0001] The present application relates to the field of security authentication technology, and in particular to an application authentication method and authentication device. Background Art

[0002] Embedded Linux operating systems (ELinux) are widely used in various fields, including automotive, due to their open source, powerful functionality, high security, and ease of expansion. As the primary form of application storage in Linux systems, ELF executable files run directly at the operating system's application layer, making them susceptible to tampering by viruses and Trojans.

[0003] Related technologies can encrypt the .Text section of an ELF file using algorithms such as RSA, DSA, and ECC, and bind the program to specific hardware attributes such as the terminal device's MAC address. During the loading phase, the program is first decrypted and then physically authenticated, ensuring application security.

[0004] The above authentication method strongly binds the program to specific hardware attributes. This strong binding relationship usually makes the bound application unable to be activated normally after the hardware is damaged or replaced, thereby reducing the user experience.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide an application authentication method and an authentication device, which can decouple the authentication of the application from the hardware properties, avoiding the problem of the application being unable to be normally activated due to hardware damage or replacement, thereby improving the user experience.

[0007] In a first aspect, a method for authenticating an application is provided, comprising: obtaining an aggregated public key and an aggregated signature; verifying the aggregated signature through the aggregated public key to obtain an authentication result for a target program; wherein the aggregated public key is aggregated from N public keys corresponding to N applications on a first terminal, the N applications including the target program and N-1 auxiliary programs, and the aggregated signature is aggregated from N signature data obtained by each of the N applications signing the target program, where N is an integer greater than or equal to 2; and, the public keys of applications configured on different terminals belong to different Abelian groups, the public keys of applications configured on the same terminal belong to the same Abelian group, and the N-1 public keys corresponding to the N-1 auxiliary programs belong to the first Abelian group.

[0008] According to the authentication method provided by this application, the public keys of applications configured on different terminals belong to different Abelian groups, and the public keys of applications configured on the same terminal belong to the same Abelian group (identical groups can be aggregated for authentication). For example, the public keys of applications configured on the first terminal all belong to the first Abelian group, that is, the N-1 public keys corresponding to the N-1 auxiliary applications all belong to the first Abelian group.

[0009] Under this premise, when the target program is launched on the authentication device, it needs to be authenticated. The authentication device can first obtain an aggregated public key and an aggregated signature. The aggregated public key is obtained by aggregating N public keys corresponding to N applications, including the target program and N-1 auxiliary applications on the first terminal. The aggregated signature is obtained by aggregating N signature data obtained by each of the N applications using its own private key to sign the target program. The aggregated signature is then verified using the aggregated public key to obtain the authentication result for the target program.

[0010] The authentication method for the application provided in the embodiment of the present application draws on the blockchain security encryption and decryption method, treating the first terminal (system) as a complete block, pre-generating multiple sets of secret keys for the first terminal, and the target program has different secret keys in different terminals (environments), and the secret keys belong to different Abelian groups (the same group can be aggregated for authentication). Therefore, the target program can be authenticated by using the aggregated public key to verify the aggregated signature. This application does not need to strongly bind the application to the hardware properties, so that the authentication of the application by the first terminal can be decoupled from the hardware properties, avoiding the problem of the application not being able to be activated normally due to hardware damage or replacement, thereby improving the user experience.

[0011] In a possible implementation, before obtaining the aggregated public key and the aggregated signature, the method further includes: obtaining the N public keys and the N signature data; and aggregating the N public keys and the N signature data respectively to generate the aggregated public key and the aggregated signature.

[0012] In a possible implementation, before verifying the aggregate signature using the aggregate public key, the method further includes: determining whether the value of N-1 is greater than or equal to a preset first threshold.

[0013] In a possible implementation, if the value of N-1 is less than the first threshold, the method further includes: determining that the authentication result of the target program is failed.

[0014] In a possible implementation, the aggregating the N public keys and the N signature data separately includes: aggregating the N public keys and the N signature data separately based on a BLS signature algorithm.

[0015] In a possible implementation, the target program includes an ELF executable file, and obtaining the N public keys and the N signature data includes: obtaining the N signature data from a .Sign field of the ELF executable file.

[0016] In a possible implementation, obtaining the N public keys and the N signature data includes: receiving the N public keys from a cloud server.

[0017] In a possible implementation, the obtaining the N public keys and the N signature data includes: obtaining the N public keys through an agent program configured on the first terminal.

[0018] In a possible implementation, before verifying the aggregate signature by using the aggregate public key, the method further includes: decrypting the encrypted program package by using the public key of the target program to obtain the target program.

[0019] In a possible implementation, obtaining the N public keys and the N signature data includes: receiving an authentication request message from the first terminal, the authentication request message including the N signature data;

[0020] The authentication method further includes: sending an authentication result of the target program to the first terminal.

[0021] In a second aspect, an authentication device for an application is provided, comprising: an acquisition unit for acquiring an aggregated public key and an aggregated signature; an authentication unit for verifying the aggregated signature through the aggregated public key to obtain an authentication result for a target program; wherein the aggregated public key is aggregated from N public keys corresponding to N applications on a first terminal, the N applications include the target program and N-1 auxiliary programs, the aggregated signature is aggregated from N signature data obtained by each of the N applications signing the target program, and N is an integer greater than or equal to 2; and the public keys of applications configured on different terminals belong to different Abelian groups, the public keys of applications configured on the same terminal belong to the same Abelian group, and the N-1 public keys corresponding to the N-1 auxiliary programs belong to the first Abelian group.

[0022] In one possible implementation, the acquisition unit is further used to: acquire the N public keys and the N signature data; the authentication device also includes: an aggregation unit, used to aggregate the N public keys and the N signature data respectively to generate the aggregated public key and the aggregated signature.

[0023] In a possible implementation, the authentication device further includes: a determination unit, configured to determine whether the value of N-1 is greater than or equal to a preset first threshold.

[0024] In a possible implementation, if the value of N-1 is smaller than the first threshold, the authentication unit is specifically configured to determine that the authentication result of the target program is failed.

[0025] In a possible implementation, the aggregation unit is specifically configured to aggregate the N public keys and the N signature data based on a BLS signature algorithm.

[0026] In a possible implementation, the target program includes an ELF executable file, and the obtaining unit is specifically configured to obtain the N signature data from a .Sign field of the ELF executable file.

[0027] In a possible implementation, the acquisition unit is specifically configured to receive the N public keys from a cloud server.

[0028] In a possible implementation manner, the obtaining unit is specifically configured to obtain the N public keys through an agent program configured on the first terminal.

[0029] In a possible implementation, the authentication device further includes: a decryption unit, configured to decrypt the encrypted program package using a public key of the target program to obtain the target program.

[0030] In one possible implementation, the acquisition unit is specifically used to: receive an authentication request message from the first terminal, the authentication request message including the N signature data; the authentication device also includes: a sending unit, used to send the authentication result of the target program to the first terminal.

[0031] In a third aspect, an authentication device for an application is provided, comprising at least one processor, wherein the at least one processor is used to couple with a memory, read and execute instructions in the memory, so as to implement the authentication method provided by any possible implementation method in the first aspect.

[0032] Optionally, the authentication device also includes the memory.

[0033] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is run on a computer, the authentication method provided by any possible implementation method of the first aspect is implemented.

[0034] In a fifth aspect, a chip system is provided, comprising a processor for calling and running a computer program from a memory, so that a computer equipped with the chip system executes the authentication method provided by any possible implementation of the first aspect.

[0035] In a sixth aspect, a computer program product is provided, comprising: a computer program code, which, when executed on a computer, enables the computer to execute the authentication method provided by any one of the implementations in the first aspect.

[0036] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately from the processor, and this application does not make any specific restrictions on this.

[0037] It can be understood that the authentication device for the application provided in the second and third aspects, the computer-readable storage medium provided in the fourth aspect, the chip system provided in the fifth aspect, and the computer program product provided in the sixth aspect are all used to execute the authentication method provided in the first aspect. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] FIG1 is a schematic diagram of an application scenario of an authentication method for an application program provided in an embodiment of the present application.

[0039] FIG2 is a schematic flowchart of an example of an application authentication method provided in an embodiment of the present application.

[0040] FIG3 is a flowchart of an example of an authentication method for an application provided in an embodiment of the present application.

[0041] FIG4 is a flowchart of another example of an application authentication method provided in an embodiment of the present application.

[0042] FIG5 is a schematic flowchart of another example of an application authentication method provided in an embodiment of the present application.

[0043] FIG6 is a flowchart of another example of an application authentication method provided in an embodiment of the present application.

[0044] FIG7 is a schematic block diagram of an authentication device for an application provided in an embodiment of the present application.

[0045] FIG8 is a structural diagram of an authentication device for an application provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solutions of this application will be described below in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of this application, rather than all the embodiments.

[0047] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0048] The term "comprising" herein indicates the presence of the described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or collections thereof. The terms "comprising", "including", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized. In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, unless otherwise stated, "multiple" means two or more.

[0049] The term "and / or" in this document simply describes a relationship between related objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. Additionally, the character " / " in this document generally indicates that the related objects are in an "or" relationship.

[0050] The following first introduces the explanations of the relevant names involved in the embodiments of this application.

[0051] Asymmetric encryption refers to an encryption method consisting of a pair of unique keys (i.e., a public key and a private key). Unlike traditional symmetric encryption algorithms, asymmetric encryption leverages the asymmetry in computational complexity during encryption and decryption to ensure information security. In an asymmetric encryption system, the encrypting party generates a private and public key pair. The private key is retained by the encrypting party, while the public key can be shared with the other party. One of the private and public keys is used to encrypt files, while the other is used to decrypt them.

[0052] Digital Signature: A digital signature authenticates the origin and integrity of a message based on asymmetric encryption and message digest algorithms, and also provides a guarantee of non-repudiation by the signer. Generally, a digital signature system consists of two roles: the message signer and the message authenticator. The message signer uses their private key to sign the message digest, while the message authenticator verifies the message digest using their public key. If verification succeeds, it proves that the message originated with the signer, the message digests are identical, and the signer cannot deny their identity.

[0053] Aggregate signatures: Aggregate signatures are a type of digital signature with additional properties. In addition to conventional digital signatures, aggregate signatures require that signatures from different users on the same message be aggregated. The aggregated signature size should be smaller than the sum of all the different user signatures before aggregation. Verifying the aggregated signature assures the verifier that the group of signers has signed. In an aggregate signature system, there are three roles: signer, aggregator, and verifier. Signers include multiple users, each with their own public key, who sign a shared message. The aggregator, often a single user, collects signatures from the signers and aggregates them. The verifier only needs to verify the aggregated signature once to confirm that all participating signers have signed the message, significantly improving signature verification and transmission efficiency. Typically, the verifier verifies the aggregated signature using the aggregated public key.

[0054] Embedded Linux operating systems, due to their open source, powerful functionality, high security, and ease of expansion, are often used as the foundation for secondary development of domestic operating systems. They have been widely adopted in various fields, including automotive applications. As application scenarios become increasingly diverse, attacks against embedded Linux are emerging, and the security of embedded Linux systems is facing increasing challenges. Common attacks on Linux systems include attacks against loadable kernel modules (LKMs) and executable files in the Linux Executable and Linkable Format (ELF). ELF executable files, because they run directly in the operating system's application layer, are highly susceptible to tampering by viruses or Trojans.

[0055] The ELF format, developed and released by Unix Labs as an application binary interface, is the default executable file format for Linux systems. As the primary form of application code in Linux, ELF files are subject to a variety of attacks. Viruses or Trojans can insert their own code by modifying the ELF header and program header table. For example, a virus can modify the ELF file, redirecting the program's entry point to the virus's execution address. After the virus program completes execution, the original ELF file's contents are executed, completing the virus program's injection.

[0056] In related technologies, the .Text section of an ELF file (i.e., an application) can be encrypted using algorithms such as RSA, DSA, and ECC, and the program can be bound to specific hardware attributes such as the terminal device's MAC address. During the loading phase, the program is first decrypted and then physically authenticated, ensuring the security of the application.

[0057] The above authentication method is performed by matching the program with specific hardware attributes. This strong binding relationship usually makes the bound application unable to start normally after the hardware is damaged or replaced. For example, a certain application can be bound to the network card (i.e., MAC address) of the terminal device. When the network card of the terminal device is damaged or replaced, the user will not be able to start the program normally. Combined with the above analysis, it can be seen that the above authentication method provided in the relevant technology is not flexible enough, which may cause the application in the secure state to be unable to be normally activated by the user, thereby reducing the user experience.

[0058] To address the above issues, an embodiment of the present application provides an application authentication method that can decouple application authentication from hardware properties, avoiding the problem of application failure due to hardware damage or replacement, thereby improving the user experience.

[0059] According to the application authentication method provided in the embodiment of the present application, the public keys of the applications configured on different terminals belong to different Abelian groups, and the public keys of the applications configured on the same terminal belong to the same Abelian group (the same group can be aggregated for authentication). For example, the public keys of the applications configured on the first terminal all belong to the first Abelian group, while the public keys of the applications configured on the second terminal all belong to the second Abelian group. The same application has different public keys when it is configured on different terminals. For example, when it is configured on the first terminal, the public key of the application belongs to the first Abelian group, and when it is configured on the second terminal, the public key of the application belongs to the second Abelian group.

[0060] Under this premise, when a new application (referred to as the target program) needs to be authenticated on the first terminal, the N public keys corresponding to the N applications including the target program and N-1 auxiliary programs on the first terminal can be obtained. The auxiliary program can be, for example, a system program legally configured on the first terminal. At the same time, it is also necessary to obtain the N signature data obtained by the N applications signing the target program. Secondly, the N public keys are aggregated to obtain an aggregated public key, and the N signature data are aggregated to obtain an aggregated signature. Finally, the aggregated signature is verified by the aggregated public key to obtain the authentication result of the target program. For example, when the authentication result is passed (authentication is successful), it means that the public key of the target program belongs to the first Abelian group. At this time, it can be determined that the target program is an authorized and legal program and can be allowed to run on the first terminal. When the authentication result is failure (authentication failed), it means that the public key of the target program does not belong to the first Abelian group. At this time, it can be determined that the target program is an unauthorized illegal program, which may have been stolen from other terminals (such as the second terminal). At this time, the target program is not allowed to run on the first terminal, thereby preventing the target program from being spread arbitrarily without authorization.

[0061] FIG1 is a schematic diagram of an application scenario for the authentication method for an application provided in an embodiment of the present application. As shown in FIG1 , the scenario includes a first terminal, which can be, for example, any terminal device such as a vehicle, a mobile phone, a laptop computer, a tablet computer, a desktop computer, a server, a smart wearable device, or an in-vehicle device. The first terminal can be a vehicle, which can specifically be an internal combustion engine vehicle, a smart electric vehicle, or a hybrid vehicle. Alternatively, the vehicle can be a vehicle of other power types, etc., and the embodiments of the present application do not limit this.

[0062] Optionally, the vehicle can be a car, truck, train, construction vehicle, motorcycle, bus, ship, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, and cart, etc., and the embodiments of the present application do not make special limitations.

[0063] Optionally, the vehicle may be an autonomous vehicle, which may be a vehicle with partial autonomous driving capabilities or a vehicle with full autonomous driving capabilities. That is, the level of autonomous driving of the vehicle may be divided into no automation (L0), driving support (L1), partial automation (L2), conditional automation (L3), high automation (L4) or full automation (L5) with reference to the classification standards of the Society of Automotive Engineers (SAE). A vehicle or other device (such as a cloud server, a mobile phone terminal, etc.) may implement the authentication method of the application provided in the embodiment of the present application through the components (including hardware and software) contained therein.

[0064] In one possible implementation, the authentication method provided in the embodiment of the present application can be executed by the first terminal (eg, a car) in Figure 1. Figure 2 is a schematic flow chart of the authentication method for an application provided in the embodiment of the present application.

[0065] As shown in Figures 1 and 2, when program #5 (i.e., the target program) is launched (loaded) on the first terminal, program #5 needs to be authenticated. First, the first terminal can obtain the public keys corresponding to program #5 and five other applications on the first terminal, including programs #1 through #4 (i.e., auxiliary programs) (i.e., public keys #1 through #5 in Figure 1). Programs #1 through #4 can be, for example, system programs legally configured on the first terminal, or other programs currently running normally. The public keys corresponding to programs #1 through #4 all belong to the first Abelian group, meaning that the secret keys (both public and private) of the applications legally configured on the first terminal all belong to this first Abelian group. The first terminal also needs to obtain the five signatures (i.e., signatures #1 through #5 in Figure 1) obtained by each of these five programs signing program #5 using its own private key.

[0066] Secondly, an aggregate operation is performed on the five public keys to obtain an aggregate public key, and an aggregate operation is performed on the five signature data to obtain an aggregate signature. Finally, the aggregate signature is verified by the aggregate public key to obtain the authentication result of the target program. For example, when the authentication result is passed (authentication successful), it means that the public key of program #5 belongs to the first Abelian group. At this time, it can be determined that program #5 is an authorized legal program and can be allowed to run on the first terminal. When the authentication result is not passed (authentication failed), it means that the public key of program #5 does not belong to the first Abelian group. At this time, it can be determined that program #5 is an unauthorized illegal program, which may have been stolen from other terminals (such as the second terminal). At this time, program #5 is not allowed to run on the first terminal, thereby preventing program #5 from being spread arbitrarily without authorization.

[0067] In another possible implementation, the scenario shown in FIG1 also includes a cloud server that is wirelessly connected to the first terminal. For example, the first terminal and the cloud server can be wirelessly connected via Over-the-Air (OTA) technology. In this case, the cloud server in FIG1 can execute the authentication method of the application provided in the embodiment of the present application. The first terminal can send an authentication request to the cloud server. After the cloud server completes the authentication, the authentication result is sent to the first terminal. The specific authentication steps of the cloud server are roughly the same as those of the first terminal and will not be repeated here.

[0068] Based on the application scenario shown in Figure 1 and the schematic flowchart shown in Figure 2, combined with the application authentication method provided in the embodiment of the present application, the technical problems raised in this application will be specifically analyzed and solved.

[0069] FIG3 is a flow chart of an authentication method 100 for an application provided in an embodiment of the present application. The authentication method 100 can be applied to the first terminal shown in FIG1 above. For example, the execution subject of the authentication method 100 can be the first terminal or a processor or chip within the first terminal. The authentication method 100 can also be applied to other devices that can assist the first terminal in remote authentication (such as the cloud server or mobile terminal in FIG1 ). For example, the execution subject of the authentication method 100 can be a cloud server or a processor or chip within the cloud server. The authentication method 100 can include the following steps 110-120.

[0070] Step 110: The authentication device obtains the aggregated public key and the aggregated signature;

[0071] Step 120: The authentication device verifies the aggregate signature using the aggregate public key to obtain an authentication result for the target program.

[0072] Among them, the aggregated public key is aggregated from N public keys corresponding to N applications on the first terminal, and the N applications include the target program to be authenticated and N-1 auxiliary programs. The aggregated signature is aggregated from N signature data obtained by the N applications each signing the target program, where N is an integer greater than or equal to 2, for example, N is 2, 3, 4, 5, 6 or 8, etc.

[0073] Moreover, the public keys of applications configured on different terminals belong to different Abelian groups, and the public keys of applications configured on the same terminal belong to the same Abelian group. The N-1 public keys corresponding to the N-1 auxiliary programs belong to the first Abelian group.

[0074] Specifically, in an embodiment of the present application, the public keys of applications configured on different terminals belong to different Abelian groups, and the public keys of applications configured on the same terminal belong to the same Abelian group (the same group can be aggregated for authentication). For example, the public keys of applications configured on the first terminal all belong to the first Abelian group, that is, the N-1 public keys corresponding to the N-1 auxiliary programs all belong to the first Abelian group. The auxiliary program here can be, for example, a system program that is legally configured on the first terminal, or it can be other programs that are currently running normally.

[0075] Abelian groups, also known as commutative groups, are an important class of groups. Abelian groups are groups that have the commutative property of group operations, meaning that for any a, b∈G, ab=ba. Therefore, Abelian groups are also called commutative groups. Commutative group operations are often represented by addition, and Abelian groups are also called additive groups or additive groups. They consist of their set G and the binary operation *. In addition to satisfying the general group axioms—namely, the associative property of operations, the identity of G, and the inverse of all elements of G—they also satisfy the commutative property. Because Abelian group operations are commutative and associative, the value of the product of group elements is independent of the order of the multiplications. Elements in an Abelian group can be strings, coordinate values, or curve formulas.

[0076] Under this premise, when the target program is started (e.g., loaded by a recorder) on an authentication device (e.g., the first terminal or cloud server in FIG1 ), the target program needs to be authenticated. The authentication device can first obtain an aggregate public key and an aggregate signature. The aggregate public key is obtained by aggregating N public keys corresponding to N applications, including the target program and N-1 auxiliary applications on the first terminal. The aggregate signature is obtained by aggregating N signature data obtained by each of the N applications using its own private key to sign the target program.

[0077] The aggregate signature is then verified using the aggregate public key to obtain an authentication result for the target program. Specifically, verifying the aggregate signature using the aggregate public key verifies the legitimacy of the target program. If the verification passes, the authentication result for the target program is "authentication passed" or "authentication successful." If the verification fails, the authentication result for the target program is "authentication failed" or "authentication failed." Public key signature verification is a well-known technique and will not be further described here.

[0078] For example, if the authentication result is "pass" (authentication successful), it means that the public key of the target program belongs to the first Abelian group. In this case, it can be determined that the target program is an authorized and legal program and can be allowed to run on the first terminal. If the authentication result is "failed" (authentication failed), it means that the public key of the target program does not belong to the first Abelian group. In this case, it can be determined that the target program is an unauthorized and illegal program, which may have been stolen from another terminal (such as the second terminal). In this case, the target program is not allowed to run on the first terminal, thereby preventing the target program from being spread without authorization.

[0079] Optionally, the authentication device itself may perform an aggregation operation on the N public keys to obtain an aggregated public key, or another device may perform an aggregation operation on the N public keys to obtain an aggregated public key, and send the aggregated public key to the authentication device.

[0080] Optionally, the authentication device itself may perform an aggregation operation on the N signature data to obtain an aggregate signature, or another device may perform an aggregation operation on the N signature data to obtain an aggregate signature, and send the aggregate signature to the authentication device.

[0081] The application authentication method 100 provided in the embodiment of the present application draws on the blockchain security encryption and decryption method, treating the first terminal (system) as a complete block, pre-generating multiple sets of secret keys for the first terminal, and the target program has different secret keys in different terminals (environments), and the secret keys belong to different Abelian groups (the same group can be aggregated for authentication). Therefore, the target program can be authenticated by using the aggregated public key to verify the aggregated signature. This application does not need to strongly bind the application to the hardware properties, so that the authentication of the application by the first terminal can be decoupled from the hardware properties, avoiding the problem of the application not being able to be normally activated due to hardware damage or replacement, thereby improving the user experience.

[0082] Figure 4 is a flow chart illustrating an application authentication method 200 provided in an embodiment of the present application. Authentication method 200 can be applied to the first terminal shown in Figure 1 . For example, the execution entity of authentication method 200 can be the first terminal or a processor or chip within the first terminal. Authentication method 200 can be considered a more specific implementation of the aforementioned authentication method 100. Authentication method 200 can include the following steps 210 through 270.

[0083] In step 210 , the first terminal decrypts the encrypted program package using the public key of the target program to obtain the target program.

[0084] Specifically, when the first terminal determines that the loader starts the target program, the encrypted program package is first decrypted by the public key of the target program to obtain the target program. During the decryption process, the encrypted program package in the source code class file format can be compiled and converted into a binary class file (i.e., the target program).

[0085] Optionally, the software system configured on the first terminal may be a Linux system, and the target program may include an ELF executable file. The cloud server may use the target program's private key to encrypt the .Text field (section) in the ELF executable file. The Linux loader decrypts the .Text field using the public key during the loading process, and then enters the authentication phase after decryption.

[0086] In step 220, the first terminal obtains N public keys and N signature data. The N public keys include the public key of the target program and the public keys of N-1 auxiliary programs. The N signature data are obtained by each of the N application programs, including the target program and the N-1 auxiliary programs, signing the target program using its own private key. The public keys of the N-1 auxiliary programs all belong to the first Abelian group.

[0087] After decryption is complete, the target program needs to be authenticated. The first terminal can obtain N public keys corresponding to N applications, including the target program and N-1 auxiliary programs on the first terminal. The auxiliary programs can be, for example, legally configured system programs on the first terminal or other currently running programs. The first terminal also needs to obtain N signature data obtained by these N applications signing the target program.

[0088] Optionally, the first terminal may obtain the N public keys from a local loader, which will not affect authentication even when there is no network.

[0089] Optionally, the first terminal may receive the N public keys sent from the cloud server. In this case, the public keys may be stored in the cloud server, which can prevent the application from being stolen, thereby improving the security of the system and facilitating the cloud server to update and replace the secret keys.

[0090] Optionally, the first terminal can obtain the N public keys through an agent program. To address the security risks associated with traditional key storage in local loaders, dynamically managing keys through an agent program not only improves key security but also facilitates key updates and replacements. Public keys can also be uploaded to a cloud server for cloud authentication, if the network allows.

[0091] Optionally, the target program may include (or be) an ELF executable file, and each application program may sign the target program information (e.g., the .Text field) using its own private key, and accordingly add a .Sign field (i.e., the .Sign section) to the target program. In this case, the first terminal may obtain the N signature data from the .Sign field (i.e., the .Sign section) of the ELF executable file.

[0092] Step 230: Aggregate the N public keys and the N signature data to generate an aggregated public key and an aggregated signature.

[0093] After obtaining the N public keys and the N signature data, the first terminal performs an aggregation operation on the N public keys to obtain an aggregated public key, and performs an aggregation operation on the N signature data to obtain an aggregated signature.

[0094] Optionally, the first terminal aggregates the N public keys based on a BLS (Boneh-Lynn-Shacham) signature algorithm to obtain an aggregated public key, and the first terminal aggregates the N signature data based on the BLS signature algorithm to obtain an aggregated signature.

[0095] The BLS signature algorithm was proposed by Dan Boneh, Ben Lynn, and Hovav Shacham from the Department of Computer Science at Stanford University. It does not require a random number generator and can aggregate all signatures in a block into one, making it easy to implement multi-signatures and avoiding unnecessary communication between signers.

[0096] Optionally, in other implementations, the first terminal may also perform aggregation operations based on other algorithms such as the ECDSA signature algorithm and the Schnorr signature algorithm to obtain the aforementioned aggregate public key and / or aggregate signature.

[0097] In step 240 , the first terminal obtains the calculated aggregate public key and aggregate signature.

[0098] In step 250 , the first terminal verifies the aggregate signature using the aggregate public key to obtain an authentication result for the target program.

[0099] For example, if the target program passes authentication, it can be determined that the target program is an authorized and legitimate program and can be allowed to run on the first terminal. Alternatively, if the target program fails authentication, it means that the public key of the target program does not belong to the first Abelian group. In this case, it can be determined that the target program is an unauthorized and illegal program, possibly stolen from another terminal (such as the second terminal). In this case, the target program is not allowed to run on the first terminal, thereby preventing the target program from being spread without authorization.

[0100] It is worth noting that if the target program fails to be authenticated, it means that the public key of the target program does not belong to the first Abelian group. It may also mean that the signature data carried in the .Sign field of the target program at this time may be the signature data obtained by the application on other terminals (such as the second terminal) using its own private key (belonging to the second Abelian group) to sign the target program. In other words, the aforementioned acquisition of N signature data is obtained by the N applications including the target program and N-1 auxiliary programs each using their own private key to sign the target program. Here, if the secret key of the target program (for example, including the public key and the private key) belongs to the first Abelian group, it means that the target program is a legitimate program and can be successfully authenticated. At this time, the N signature data can be obtained by the N applications configured on the first terminal using their own private keys (all belonging to the first Abelian group) to sign the target program.

[0101] Another situation is that the secret key of the target program (for example, including the public key and the private key) does not belong to the first Abelian group, which means that the target program is not a legitimate program and cannot be authenticated successfully. At this time, the N signature data obtained may be obtained by the N applications on other devices (for example, the stolen device) using their own private keys (for example, belonging to the second Abelian group) to sign the target program.

[0102] In other words, in the embodiment of the present application, "the N signature data are obtained by N applications including the target program and N-1 auxiliary programs, each using its own private key to sign the target program", which includes at least the above two situations.

[0103] Optionally, as shown in FIG4 , between step 220 and step 230 , the authentication method 200 provided in the embodiment of the present application further includes:

[0104] In step 260, the first terminal determines whether the number of auxiliary programs is greater than or equal to a preset first threshold, that is, the first terminal determines whether the value of N-1 is greater than or equal to the first threshold (for example, 1, 2, 3, 4, 5 or 8, etc.). When it is determined that the value of N-1 is greater than or equal to the preset first threshold, step 230 is entered, otherwise step 270 is entered.

[0105] Figure 5 is a schematic flow chart of another example of an application authentication method provided in an embodiment of the present application. In conjunction with Figures 4 and 5, in an embodiment of the present application, an authentication cluster can be set up, which includes multiple auxiliary programs. When a target program needs to be authenticated, the first terminal can obtain the public keys of N-1 target programs from the authentication cluster. Only when the number of public keys obtained (i.e., the value of N-1) is greater than or equal to a preset first threshold value, the subsequent authentication steps are performed.

[0106] The above settings provide fault tolerance, ensuring that authentication can continue normally even if problems arise with auxiliary programs and their public keys cannot be retrieved. Specifically, the target program is allowed to run when the number of "agreements" reaches a first threshold. In other words, a "majority agreement" within the authentication cluster during the target program authentication process allows it to start normally.

[0107] As shown in Figure 5, as a specific example, the first threshold is 2, and there are 4 auxiliary programs in the authentication cluster, namely program #1, program #2, program #3 and program #4. When program #5 needs to be authenticated as the target program, the first terminal obtains the public keys of two programs, program #3 and program #4, from the authentication cluster, that is, the value of N-1 is 2, which is equal to the first threshold, so it can enter step 230 and continue with the subsequent authentication steps.

[0108] In the subsequent authentication steps, the first terminal can obtain the public keys of program #3, program #4, and program #5, namely public key #3, public key #4, and public key #5, and obtain the signature data of program #3, program #4, and program #5, namely signature #3, signature #4, and signature #5. Then, the first terminal performs an aggregation operation on public key #3, public key #4, and public key #5 using the BLS signature algorithm to obtain an aggregated public key. The first terminal also performs an aggregation operation on signature #3, signature #4, and signature #5 to obtain an aggregated signature. The aggregated signature is then verified using the aggregated public key to obtain an authentication result for program #5. For example, if the authentication result is passed, program #5 can be allowed to run.

[0109] If the first terminal determines that the value of N-1 is less than the first threshold, the process proceeds to step 270. In step 270, the first terminal determines that the authentication of the target program is unsuccessful, that is, determines that the authentication result of the target program is failed.

[0110] As shown in Figure 5, as a specific example, the first threshold is 3. At this time, since only the public keys of program #3 and program #4 are obtained, that is, the value of N-1 is 2, which is less than the first threshold, the subsequent authentication steps (that is, steps 230 to 260) can no longer be executed, and the authentication result of program #5 is directly determined to be failed, and program #5 is not allowed to run on the first terminal.

[0111] Figure 6 is a flow chart illustrating an application authentication method 300 provided in an embodiment of the present application. Authentication method 300 can be applied to the cloud server shown in Figure 1 . For example, the execution entity of authentication method 300 can be the cloud server or a processor or chip within the cloud server. Authentication method 300 can be considered a more specific implementation of the aforementioned authentication method 100. Authentication method 300 includes the following steps 310 through 340.

[0112] In step 310, the first terminal sends an authentication request message to the cloud server, requesting the cloud server to assist the first terminal in authenticating the target program. The authentication request message includes N signature data, which are the same as the N signature data in the aforementioned authentication methods 100 and 200 and are not further described here.

[0113] Correspondingly, the cloud server receives the authentication request message from the first terminal.

[0114] Optionally, the authentication request message may include the .Sign field (ie, the .Sign section) of the target program, and the N signature data are carried (included) in the .Sign field, or in other words, the .Sign field is the N signature data.

[0115] Optionally, the first terminal sends the authentication request message or the N signature data (eg, the Sign field) to the cloud server through the aforementioned proxy program.

[0116] In step 320, the cloud server performs an aggregation operation on the N public keys and the N signature data to obtain an aggregated public key and an aggregated signature. The N public keys can be stored locally on the cloud server. These N public keys are the same as the N public keys in the aforementioned authentication methods 100 and 200 and are not further described here.

[0117] In step 330 , the cloud server verifies the aggregate signature using the aggregate public key to authenticate the target program.

[0118] In step 340 , the cloud server sends an authentication result to the first terminal, such as authentication passed or failed.

[0119] Correspondingly, the first terminal receives the authentication result sent by the cloud server.

[0120] According to the authentication method 300 of the application provided in the embodiment of the present application, when there is a network, the cloud server can help the first terminal to perform remote authentication. At this time, the first terminal can send an authentication request message to the cloud server, and the request message carries the N signature data. The cloud server aggregates the N signature data to obtain an aggregated signature, and aggregates the N public keys stored locally to obtain an aggregated public key. The aggregated signature is verified by the aggregated public key to authenticate the target program. After the authentication is completed, the authentication result is notified to the first terminal via the wireless network. At this time, since the public key of the application is also stored in the cloud server, the security of the public key and private key of the application can be better guaranteed.

[0121] Optionally, in other implementations, the first terminal may perform an aggregation operation on the N signatures to obtain an aggregate signature, and carry the aggregate signature in the authentication request message in the aforementioned step 310. In this case, the cloud server does not need to perform an aggregation operation on the N signatures.

[0122] The application authentication method provided by the embodiments of the present application is described in detail above with reference to Figures 1 to 6 . The application authentication device provided by the embodiments of the present application is described in detail below with reference to Figures 7 and 8 . It should be understood that the authentication device shown in Figures 7 and 8 is capable of implementing one or more steps of the method flow shown in Figures 2 to 6 . To avoid repetition, detailed description will not be given here.

[0123] FIG7 is a schematic block diagram of an application authentication device 400 according to an embodiment of the present application. As shown in FIG7 , the authentication device 400 includes an acquisition unit 410 and an authentication unit 420 .

[0124] The acquisition unit 410 is configured to acquire an aggregated public key and an aggregated signature.

[0125] The authentication unit 420 is used to verify the aggregate signature through the aggregate public key to obtain an authentication result for the target program; wherein the aggregate public key is aggregated from N public keys corresponding to N applications on the first terminal, the N applications include the target program and N-1 auxiliary programs, and the aggregate signature is aggregated from N signature data obtained by each of the N applications signing the target program, where N is an integer greater than or equal to 2; and the public keys of applications configured on different terminals belong to different Abelian groups, the public keys of applications configured on the same terminal belong to the same Abelian group, and the N-1 public keys corresponding to the N-1 auxiliary programs belong to the first Abelian group.

[0126] Optionally, the acquisition unit 410 is further configured to: acquire the N public keys and the N signature data.

[0127] The authentication device 400 further includes:

[0128] The aggregation unit 430 is configured to aggregate the N public keys and the N signature data respectively to generate the aggregated public key and the aggregated signature.

[0129] Optionally, the authentication device 400 further includes:

[0130] The determining unit 440 is configured to determine whether the value of N-1 is greater than or equal to a preset first threshold.

[0131] Optionally, if the value of N-1 is less than the first threshold, the authentication unit 420 is specifically configured to:

[0132] The authentication result of the target program is determined to be failed.

[0133] Optionally, the aggregation unit 430 is specifically configured to:

[0134] The N public keys and the N signature data are respectively aggregated based on the BLS signature algorithm.

[0135] Optionally, the target program includes an ELF executable file, and the acquiring unit 410 is specifically configured to:

[0136] The N signature data are obtained from the .Sign field of the ELF executable file.

[0137] Optionally, the acquiring unit 410 is specifically configured to:

[0138] Receive the N public keys from the cloud server.

[0139] Optionally, the acquiring unit 410 is specifically configured to:

[0140] The N public keys are obtained through an agent program configured on the first terminal.

[0141] Optionally, the authentication device 400 further includes:

[0142] The decryption unit 450 is configured to decrypt the encrypted program package using the public key of the target program to obtain the target program.

[0143] Optionally, the acquiring unit 410 is specifically configured to:

[0144] An authentication request message is received from the first terminal, where the authentication request message includes the N signature data.

[0145] The authentication device 400 further includes:

[0146] The sending unit 460 is configured to send the authentication result of the target program to the first terminal.

[0147] Specifically, the authentication device 400 may correspond to the first terminal in the method 100, method 200, and method 300 according to the embodiments of the present application, or other devices (such as a cloud server) that can help the first terminal perform remote authentication, or a chip configured in the first terminal or the other device. The authentication device 400 may include various units for executing the methods executed by the authentication device, the first terminal, or the cloud server in Figures 3, 4, and 6. In addition, the various units in the authentication device 400 and the above-mentioned other operations and / or functions are respectively for implementing the corresponding processes of method 100, method 200, and method 300. The specific process of each unit performing the above-mentioned corresponding steps has been described in detail in method 100, method 200, and method 300. For the sake of brevity, they will not be repeated here.

[0148] FIG8 is a schematic structural diagram of an authentication device 500 for an application provided in an embodiment of the present application. The authentication device 500 can be a first terminal or a cloud server, or a chip or circuit disposed within the first terminal or cloud server. As shown in FIG8 , the authentication device 500 includes a processor 510, a memory 520, and a communication interface 530. The memory 520 stores instructions, and the processor 510 is configured to execute the instructions in the memory 520. When the instructions are executed, the processor 510 is configured to execute the method provided in the above-described method embodiment. The processor 510 is also configured to control the communication interface 530 to communicate with the outside world.

[0149] Furthermore, the processor 510 , the memory 520 , and the communication interface 530 may communicate with each other through internal connection paths to transfer control and / or data signals.

[0150] Furthermore, the memory 520 may be integrated into the processor 510 or may be provided separately from the processor 510 .

[0151] Specifically, the authentication device 500 may correspond to the first terminal in method 100, method 200, and method 300 according to the embodiments of the present application, or other devices (such as cloud servers) that can help the first terminal perform remote authentication, or a chip configured in the first terminal or the other device. The authentication device 500 may include various units for executing the methods executed by the authentication device, the first terminal, or the cloud server in Figures 3, 4, and 6. In addition, the various units in the authentication device 500 and the above-mentioned other operations and / or functions are respectively for implementing the corresponding processes of method 100, method 200, and method 300. The specific process of each unit performing the above-mentioned corresponding steps has been described in detail in method 100, method 200, and method 300. For the sake of brevity, they will not be repeated here.

[0152] An embodiment of the present application further provides a computer-readable storage medium, which includes a computer program. When the computer-readable storage medium is run on a computer, the computer is caused to execute the method provided in the above method embodiment.

[0153] An embodiment of the present application further provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method provided in the above method embodiment.

[0154] An embodiment of the present application also provides a chip system, including a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that a network device equipped with the chip system executes the method provided in the above method embodiment.

[0155] Among them, the chip system may include an input circuit or interface for sending information or data, and an output circuit or interface for receiving information or data.

[0156] It should be understood that in the embodiments of the present application, the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0157] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0158] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0159] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0160] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0161] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0162] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0163] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0164] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for authenticating an application, characterized in that: include: Get the aggregate public key and aggregate signature; Verifying the aggregate signature by using the aggregate public key to obtain an authentication result of the target program; The aggregated public key is obtained by aggregating N public keys corresponding to N applications on the first terminal, the N applications include the target program and N-1 auxiliary programs, the aggregated signature is obtained by aggregating N signature data obtained by each of the N applications signing the target program, and N is an integer greater than or equal to 2; Furthermore, the public keys of applications configured on different terminals belong to different Abelian groups, the public keys of applications configured on the same terminal belong to the same Abelian group, and the N-1 public keys corresponding to the N-1 auxiliary programs belong to the first Abelian group.

2. The authentication method according to claim 1, characterized in that: Before obtaining the aggregate public key and the aggregate signature, the method further includes: Obtain the N public keys and the N signature data; The N public keys and the N signature data are aggregated respectively to generate the aggregated public key and the aggregated signature.

3. The authentication method according to claim 2, characterized in that: Before verifying the aggregate signature by using the aggregate public key, the method further includes: Determine whether the value of N-1 is greater than or equal to a preset first threshold.

4. The authentication method according to claim 3, characterized in that: If the value of N-1 is less than the first threshold, the method further includes: The authentication result of the target program is determined to be failed.

5. The authentication method according to any one of claims 2 to 4, characterized in that: The aggregating the N public keys and the N signature data respectively includes: The N public keys and the N signature data are aggregated respectively based on the BLS signature algorithm.

6. The authentication method according to any one of claims 2 to 5, characterized in that: The target program includes an ELF executable file, and the obtaining of the N public keys and the N signature data includes: The N signature data are obtained from the .Sign field of the ELF executable file.

7. The authentication method according to any one of claims 2 to 6, characterized in that: The obtaining of the N public keys and the N signature data includes: Receive the N public keys from the cloud server.

8. The authentication method according to any one of claims 2 to 7, characterized in that: The obtaining of the N public keys and the N signature data includes: The N public keys are obtained through an agent program configured on the first terminal.

9. The authentication method according to any one of claims 1 to 8, characterized in that: Before verifying the aggregate signature by using the aggregate public key, the method further includes: The encrypted program package is decrypted by the public key of the target program to obtain the target program.

10. The authentication method according to any one of claims 2 to 6, characterized in that: The obtaining of the N public keys and the N signature data includes: receiving an authentication request message from the first terminal, wherein the authentication request message includes the N signature data; The authentication method further comprises: Sending an authentication result of the target program to the first terminal.

11. An authentication device for an application, characterized in that: include: An acquisition unit, used to acquire an aggregate public key and an aggregate signature; an authentication unit, configured to verify the aggregate signature by using the aggregate public key to obtain an authentication result for the target program; The aggregated public key is obtained by aggregating N public keys corresponding to N applications on the first terminal, the N applications include the target program and N-1 auxiliary programs, the aggregated signature is obtained by aggregating N signature data obtained by each of the N applications signing the target program, and N is an integer greater than or equal to 2; Furthermore, the public keys of applications configured on different terminals belong to different Abelian groups, the public keys of applications configured on the same terminal belong to the same Abelian group, and the N-1 public keys corresponding to the N-1 auxiliary programs belong to the first Abelian group.

12. The authentication device according to claim 11, characterized in that: The acquisition unit is also used for: Obtain the N public keys and the N signature data; The authentication device also includes: An aggregation unit is used to aggregate the N public keys and the N signature data respectively to generate the aggregated public key and the aggregated signature.

13. The authentication device according to claim 12, characterized in that: The authentication device also includes: A determination unit is used to determine whether the value of N-1 is greater than or equal to a preset first threshold.

14. The authentication device according to claim 13, characterized in that: If the value of N-1 is less than the first threshold, the authentication unit is specifically configured to: The authentication result of the target program is determined to be failed.

15. The authentication device according to any one of claims 12 to 14, characterized in that: The polymeric unit is specifically used for: The N public keys and the N signature data are aggregated respectively based on the BLS signature algorithm.

16. The authentication device according to any one of claims 12 to 15, characterized in that: The target program includes an ELF executable file, and the acquisition unit is specifically used for: The N signature data are obtained from the .Sign field of the ELF executable file.

17. The authentication device according to any one of claims 12 to 16, characterized in that: The acquisition unit is specifically used for: Receive the N public keys from the cloud server.

18. The authentication device according to any one of claims 12 to 17, characterized in that: The acquisition unit is specifically used for: The N public keys are obtained through an agent program configured on the first terminal.

19. The authentication device according to any one of claims 11 to 18, characterized in that: The authentication device also includes: The decryption unit is used to decrypt the encrypted program package by using the public key of the target program to obtain the target program.

20. The authentication device according to any one of claims 12 to 16, characterized in that: The acquisition unit is specifically used for: receiving an authentication request message from the first terminal, wherein the authentication request message includes the N signature data; The authentication device also includes: A sending unit is used to send the authentication result of the target program to the first terminal.

21. An authentication device for an application, characterized in that: The system comprises at least one processor, wherein the at least one processor is used to be coupled with a memory, read and execute instructions in the memory, so as to implement the authentication method according to any one of claims 1 to 10.

22. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed on a computer, the computer is enabled to execute the authentication method according to any one of claims 1 to 10.

23. A chip system, characterized in that: It includes a processor for calling and running a computer program from a memory, so that a computer equipped with the chip system executes the authentication method as described in any one of claims 1 to 10.

Images