A licensing method, apparatus, computer device, and storage medium

Abstract

This application provides an authorization method, apparatus, computer device, and storage medium to address the problem of low authorization efficiency. The method includes: a device to be authorized receiving an authorization file sent by a third-party authorization device; if the signature of a first signature information contained in the authorization file is successfully verified based on a pre-stored root public key, the device to be authorized obtains sub-public key information contained in the authorization file, wherein the sub-public key information includes a sub-public key; if the signature of a second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains authorization information contained in the authorization file, wherein the authorization information includes a specified authorization function; the device to be authorized activates the running permission of a program corresponding to the specified authorization function in a pre-stored firmware program, wherein the firmware program is used to integrate programs corresponding to all developed functions.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a licensed method, apparatus, computer device and storage medium. Background Technology

[0002] With the development of globalization, manufacturers often outsource equipment production to third-party platforms to improve manufacturing efficiency. For example, manufacturers can entrust different third-party platforms to produce devices with different functions. To reduce the development costs of device functions, manufacturers can integrate all the programs corresponding to the developed functions into the firmware. Different third-party platforms can then use the same firmware, granting different levels of licenses to achieve the effect of producing devices with different functions.

[0003] The traditional authorization method involves pre-setting private keys for all functions on a third-party platform and pre-setting public keys for all private keys on the device. The third-party platform extracts the program corresponding to a certain function from the firmware, encrypts it using the private key corresponding to that function, and sends the encrypted program to the device. If the device has a public key that can decrypt the encrypted program, then the authorization is complete, and the decrypted program is written to the device.

[0004] As can be seen, the authorization process requires not only pre-assigning public and private key pairs for all possible functions, but also pre-storing all public keys in the device. After receiving the encrypted program, the device also needs to iterate through each public key to see if it can decrypt the encrypted program. After successful decryption, the decrypted program needs to be written into the device. The authorization process is quite complex and the authorization efficiency is low. Summary of the Invention

[0005] This application provides an authorization method, apparatus, computer device, and storage medium to address the problem of low authorization efficiency.

[0006] Firstly, an authorization method is provided, including:

[0007] The device to be authorized receives the authorization file sent by the third-party authorization device;

[0008] If the signature verification of the first signature information contained in the signature authorization file is successful based on the pre-stored root public key, then the device to be authorized obtains the sub-public key information contained in the signature authorization file, wherein the sub-public key information includes a sub-public key;

[0009] If the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file, wherein the authorization information includes the specified authorization function;

[0010] The device to be authorized will have the permission to run the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate all the programs corresponding to the developed functions.

[0011] Optionally, the execution permissions of the program corresponding to the specified authorized function in the pre-stored firmware program of the device to be authorized include:

[0012] If the sub-public key information also includes an authorizable scope for the device to be authorized, then the device to be authorized determines whether the specified authorized function and the authorizable scope match.

[0013] If the specified authorized function matches the authorized scope, the device to be authorized will enable the running permissions of the program corresponding to the specified authorized function in the pre-stored firmware program.

[0014] Optionally, the execution permissions of the program corresponding to the specified authorized function in the pre-stored firmware program of the device to be authorized include:

[0015] If the authorization information also includes target device information, then the device to be authorized determines whether the target device information is consistent with the device information of the device to be authorized;

[0016] If the target device information is consistent with the device information of the device to be authorized, then the device to be authorized will enable the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program.

[0017] Optionally, before the device to be authorized determines whether the target device information matches the device information of the device to be authorized, the method further includes:

[0018] The device to be authorized receives an information acquisition request sent by the third-party authorized device, wherein the information acquisition request is used to acquire the device attributes of the device to be authorized;

[0019] Based on the information acquisition request, the device to be authorized sends the obtained device attributes to the third-party authorized device, so that after receiving the device attributes sent by the device to be authorized, the third-party authorized device generates the target device information based on the received device attributes.

[0020] Secondly, an authorization method is provided, including:

[0021] Based on the pre-stored sub-public key information, first signature information, authorization information and second signature information, the third-party authorization device generates an authorization file, wherein the sub-public key information includes a sub-public key, and the authorization information includes specified authorization functions for the device to be authorized;

[0022] The third-party authorized device sends an authorization file to the device to be authorized, so that the device to be authorized receives the authorization file sent by the third-party authorized device. If the first signature information contained in the authorization file is successfully verified based on the pre-stored root public key, the device to be authorized obtains the sub-public key information contained in the authorization file. If the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file. The device to be authorized then enables the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate programs corresponding to all functions developed.

[0023] Optionally, before the third-party authorization device generates the authorization file based on the pre-stored sub-public key information, first signature information, authorization information, and second signature information, the following steps are also included:

[0024] The third-party authorized device receives the firmware program sent by the manufacturer's device, wherein the firmware program carries a root public key, which is used to verify the signature of the information after it is signed by the root private key.

[0025] The third-party authorized device sends the firmware program to the device to be authorized, so that the device to be authorized can receive the firmware program sent by the third-party authorized device and obtain the root public key carried in the firmware program.

[0026] Optionally, before the third-party authorization device generates the authorization file based on the pre-stored sub-public key information, first signature information, authorization information, and second signature information, the following steps are also included:

[0027] The third-party authorized device receives the sub-public key information, sub-private key and first signature information sent by the manufacturer device. The sub-public key information contains the sub-public key used to verify the signature of the information after it is signed by the sub-private key. The first signature information is obtained by the manufacturer device by signing the sub-public key information based on the pre-stored root private key.

[0028] Based on the sub-private key, the pre-stored authorization information is signed to obtain the second signature information.

[0029] Thirdly, a licensing device is provided, comprising:

[0030] Transceiver module: Used to receive authorization files sent by third-party authorized devices;

[0031] Processing module: If the signature verification of the first signature information contained in the signature authorization file is successful based on the pre-stored root public key, then the sub-public key information contained in the signature authorization file is obtained, wherein the sub-public key information includes a sub-public key;

[0032] The processing module is further configured to: if the second signature information contained in the authorization file is successfully verified based on the sub-public key, then obtain the authorization information contained in the authorization file, wherein the authorization information includes a specified authorization function;

[0033] The processing module is further configured to: enable the running permissions of the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate the programs corresponding to all the functions developed.

[0034] Optionally, the processing module is specifically used for:

[0035] If the sub-public key information also includes an authorizable scope for the device to be authorized, then determine whether the specified authorization function and the authorizable scope match;

[0036] If the specified authorized function matches the authorized scope, then the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program is enabled.

[0037] Optionally, the processing module is specifically used for:

[0038] If the authorization information also includes target device information, then it is determined whether the target device information is consistent with the device information of the device to be authorized;

[0039] If the target device information matches the device information of the device to be authorized, then the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program is enabled.

[0040] Optionally, the transceiver module is further configured to:

[0041] Before determining whether the target device information is consistent with the device information of the device to be authorized, an information acquisition request sent by the third-party authorized device is received, wherein the information acquisition request is used to acquire the device attributes of the device to be authorized;

[0042] The processing module is further configured to: based on the information acquisition request, send back the obtained device attributes to the third-party authorized device, so that after receiving the device attributes sent by the device to be authorized, the third-party authorized device generates the target device information based on the received device attributes.

[0043] Fourthly, a licensing device is provided, comprising:

[0044] Processing module: used to generate an authorization file based on pre-stored sub-public key information, first signature information, authorization information and second signature information, wherein the sub-public key information includes a sub-public key and the authorization information includes specified authorization functions for the device to be authorized;

[0045] Transceiver module: Used to send an authorization file to the device to be authorized, so that the device to be authorized can receive the authorization file; and, if the first signature information contained in the authorization file is successfully verified based on the pre-stored root public key, the device to be authorized obtains the sub-public key information contained in the authorization file; and, if the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file; and, the device to be authorized enables the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate programs corresponding to all functions developed.

[0046] Optionally, the transceiver module is further configured to:

[0047] Before generating the authorization file based on the pre-stored sub-public key information, first signature information, authorization information and second signature information, the firmware program sent by the manufacturer's device is received. The firmware program carries a root public key, which is used to verify the signature of the information after it is signed by the root private key.

[0048] The firmware program is sent to the device to be authorized, so that the device to be authorized receives the firmware program and obtains the root public key carried by the firmware program.

[0049] Optionally, the transceiver module is further configured to:

[0050] Before generating an authorization file based on pre-stored sub-public key information, first signature information, authorization information, and second signature information, the system receives the sub-public key information, sub-private key, and first signature information sent by the manufacturer's device. The sub-public key information contains the sub-public key used to verify the signature of the information after it is signed by the sub-private key. The first signature information is obtained by the manufacturer's device signing the sub-public key information based on the pre-stored root private key.

[0051] The processing module is also used for:

[0052] Based on the sub-private key, the pre-stored authorization information is signed to obtain the second signature information.

[0053] Fifthly, an authorization system is provided, including the authorization device as described in the third aspect and the authorization device as described in the fourth aspect.

[0054] Sixthly, a computer device is provided, comprising:

[0055] Memory, used to store program instructions;

[0056] A processor is configured to invoke program instructions stored in the memory and execute the method as described in the first aspect or the second aspect according to the obtained program instructions.

[0057] A seventh aspect provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the method as described in the first aspect or the second aspect.

[0058] In this embodiment, the device to be authorized may pre-store only one root public key. After receiving the authorization file sent by the third-party authorization device, the sub-public key contained in the authorization file can be obtained based on the root public key. By using a key chain, the public and private key pairs that need to be stored in the device to be authorized are simplified. The key is only used as a tool for signing or verifying signatures. The specified authorization function is sent to the device to be authorized when the third-party authorization device authorizes the device to be authorized. It is not necessary to pre-allocate public and private key pairs for all possible functions, nor is it necessary to pre-store all public keys in the device to be authorized, thereby reducing the authorization complexity and improving the authorization efficiency.

[0059] Furthermore, based on the designated authorization function set by the third-party authorization device, the device to be authorized can enable the execution permission of the program corresponding to the designated authorization function in the pre-stored firmware program. All devices to be authorized can pre-store firmware programs including all functions. By authorizing different programs, the devices to be authorized can have different functions. The designated authorization function is only used to indicate the programs in the firmware program that need authorization. It does not need to carry the program encrypted with the key. The device to be authorized does not need to traverse each public key to see if it can decrypt the encrypted program. The device to be authorized does not need to write the decrypted program to the device to be authorized after successful decryption. This reduces the authorization complexity and improves the authorization efficiency. Attached Figure Description

[0060] Figure 1 A schematic diagram of the authorization method provided in the embodiments of this application. Figure 1 ;

[0061] Figure 2 This is one application scenario of the authorization method provided in the embodiments of this application;

[0062] Figure 3 A flowchart illustrating the authorization method provided in this application embodiment. Figure 1 ;

[0063] Figure 4 A flowchart illustrating the authorization method provided in this application embodiment. Figure 2 ;

[0064] Figure 5a A schematic diagram of the authorization method provided in the embodiments of this application. Figure 2 ;

[0065] Figure 5b A schematic diagram of the authorization method provided in the embodiments of this application. Figure 3 ;

[0066] Figure 6 A schematic diagram of the structure of the authorized device provided in the embodiments of this application. Figure 1 ;

[0067] Figure 7 A schematic diagram of the structure of the authorized device provided in the embodiments of this application. Figure 2 ;

[0068] Figure 8 A schematic diagram of the structure of the authorized device provided in the embodiments of this application. Figure 3 . Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0070] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0071] (1) Signature:

[0072] A signature (also known as a digital signature) is a string of numbers generated by the sender of a message that cannot be forged by others. This string of numbers also serves as valid proof of the authenticity of the message sent by the sender. A signature typically defines two complementary operations: one for signing and the other for verification.

[0073] (2) Verification of signature:

[0074] Signature verification (also known as digital signature verification) is the process of verifying a digital signature. After receiving a message signed by the sender, the recipient verifies the digital signature and the message to determine its authenticity and integrity.

[0075] The application areas of the authorized methods provided in the embodiments of this application will be briefly introduced below.

[0076] With the development of globalization, manufacturers often outsource equipment production to third-party platforms to improve manufacturing efficiency. For example, manufacturers can entrust different third-party platforms to produce devices with different functions; alternatively, they can entrust the same third-party platform to produce devices with the same set of functions. To reduce the development costs of device functions, manufacturers can integrate the programs corresponding to all developed functions into the firmware. Different third-party platforms, based on the same firmware, can then license it to varying degrees, achieving the effect of producing devices with different functions.

[0077] The traditional authorization method involves pre-setting private keys for all functions on a third-party platform and pre-setting public keys for all private keys on the device. The third-party platform extracts the program corresponding to a certain function from the firmware, encrypts it using the private key corresponding to that function, and sends the encrypted program to the device. If the device has a public key that can decrypt the encrypted program, then the authorization is complete, and the decrypted program is written to the device.

[0078] As can be seen, the authorization process requires not only pre-assigning public and private key pairs for all possible functions, but also pre-storing all public keys in the device. After receiving the encrypted program, the device also needs to iterate through each public key to see if it can decrypt the encrypted program. After successful decryption, the decrypted program needs to be written into the device. The authorization process is quite complex and the authorization efficiency is low.

[0079] To address the issue of inefficient text authorization, this application proposes an authorization method. Please refer to... Figure 1 In this method, after receiving an authorization file from a third-party authorization device, if the device to be authorized successfully verifies the first signature information contained in the authorization file based on the pre-stored root public key, then the device to be authorized obtains the sub-public key information contained in the authorization file, wherein the sub-public key information includes a sub-public key. If the device to be authorized successfully verifies the second signature information contained in the authorization file based on the sub-public key, then the device to be authorized obtains the authorization information contained in the authorization file, wherein the authorization information includes the specified authorized function. The device to be authorized then enables the execution permission of the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate programs corresponding to all functions developed.

[0080] In this embodiment, the device to be authorized may pre-store only one root public key. After receiving the authorization file sent by the third-party authorization device, the sub-public key contained in the authorization file can be obtained based on the root public key. By using a key chain, the public and private key pairs that need to be stored in the device to be authorized are simplified. The key is only used as a tool for signing or verifying signatures. The specified authorization function is sent to the device to be authorized when the third-party authorization device authorizes the device to be authorized. It is not necessary to pre-allocate public and private key pairs for all possible functions, nor is it necessary to pre-store all public keys in the device to be authorized, thereby reducing the authorization complexity and improving the authorization efficiency.

[0081] Furthermore, based on the designated authorization function set by the third-party authorization device, the device to be authorized can enable the execution permission of the program corresponding to the designated authorization function in the pre-stored firmware program. All devices to be authorized can pre-store firmware programs including all functions. By authorizing different programs, the devices to be authorized can have different functions. The designated authorization function is only used to indicate the programs in the firmware program that need authorization. It does not need to carry the program encrypted with the key. The device to be authorized does not need to traverse each public key to see if it can decrypt the encrypted program. The device to be authorized does not need to write the decrypted program to the device to be authorized after successful decryption. This reduces the authorization complexity and improves the authorization efficiency.

[0082] The application scenarios of the authorization method provided in this application are described below.

[0083] Please refer to Figure 2 This is an application scenario of the authorization method provided in the embodiments of this application. The application scenario includes a manufacturer's device 101, a third-party authorized device 102, and a device to be authorized 103. The manufacturer's device 101 and the third-party authorized device 102 can communicate with each other, and the third-party authorized device 102 and the device to be authorized 103 can communicate with each other. The communication method can be wired communication technology, such as communicating through a network cable or serial cable; or it can be wireless communication technology, such as communicating through Bluetooth or Wireless Fidelity (WIFI), etc., without any specific limitation.

[0084] The term "vendor device 101" broadly refers to devices capable of developing firmware programs, such as servers, terminal devices, third-party applications accessible to the terminal devices, or web pages accessible to the terminal devices. For example, servers include cloud servers or local servers. Terminal devices include, but are not limited to, mobile phones, computers, or tablets. The term "third-party authorized device 102" broadly refers to devices capable of authorizing devices to be authorized, such as servers, terminal devices, third-party applications accessible to the terminal devices, or web pages accessible to the terminal devices. The term "device to be authorized 103" broadly refers to devices capable of performing corresponding functions based on programs with running permissions enabled, such as servers, terminal devices, third-party applications accessible to the terminal devices, or web pages accessible to the terminal devices. Vendor device 101, third-party authorized device 102, and device to be authorized 103 can all utilize cloud computing to reduce the consumption of local computing resources; similarly, they can also utilize cloud storage to reduce the consumption of local storage resources.

[0085] As one embodiment, the manufacturer's device 101 and the third-party authorized device 102 can be the same device, and the third-party authorized device 102 and the device to be authorized 103 can be the same device. The manufacturer's device 101, the third-party authorized device 102, and the device to be authorized 103 can all be the same device; no specific limitation is imposed. In this embodiment, the manufacturer's device 101, the third-party authorized device 102, and the device to be authorized 103 are described as different devices.

[0086] The following is based on Figure 2 The authorization method provided in this application embodiment will be specifically introduced from the perspective of the device to be authorized, taking the device to be authorized as device to be authorized terminal 103, the third-party authorization device as third-party authorization terminal 102, and the manufacturer's device as manufacturer's device terminal 101 as an example.

[0087] Please refer to Figure 3 This is a flowchart illustrating the authorization method provided in the embodiments of this application.

[0088] S301, The device to be authorized receives the authorization file sent by the third-party authorization device.

[0089] The device to be authorized can pre-store firmware, which is used to integrate all the programs corresponding to the developed functions. When the device is not authorized, it cannot start the firmware. Only after the device has authorized the corresponding programs in the firmware based on the authorization file can it run based on the authorized programs. Therefore, it is unnecessary to develop different programs for different third-party authorized devices, nor for different devices, reducing development costs and maintenance costs for different programs.

[0090] For example, after the manufacturer completes the firmware program, it can send the firmware program to each third-party authorized device. After receiving the firmware program, the third-party authorized device will write the firmware program into each manufactured device to be authorized. The following text will introduce the specific situation from the perspective of the third-party authorized device, and will not be elaborated here.

[0091] When a third-party authorized device authorizes a device to be authorized, the third-party authorized device can send an authorization file to the device to be authorized. The device to be authorized can receive the authorization file sent by the third-party authorized device, and thus, the device to be authorized can perform authorization based on the authorization file.

[0092] S302, if the signature verification of the first signature information contained in the signed authorization file is successful based on the pre-stored root public key, then the device to be authorized obtains the sub-public key information contained in the signed authorization file.

[0093] After receiving the authorization file, the device to be authorized can verify the first signature information contained in the authorization file based on the pre-stored root public key. There are several ways for the device to pre-store the root public key. For example, the root public key can be carried in the firmware program pre-stored by the device, allowing the device to obtain the root public key when it acquires the firmware program. Alternatively, a third-party authorizing device can obtain the root public key from the manufacturer's device when authorizing the device to be authorized, and then send the root public key to the device to be authorized after receiving it from the manufacturer's device, thus pre-stored the root public key. There are no specific restrictions on the method used by the device to pre-store the root public key.

[0094] The device to be authorized verifies the first signature information contained in the authorization document based on the pre-stored root public key. The first signature information is obtained by the manufacturer's device signing the sub-public key information based on the preset root private key, where the sub-public key information includes the sub-public key. After obtaining the sub-private key, sub-public key information, and first signature information, the manufacturer's device sends the sub-private key, sub-public key information, and first signature information to the third-party authorization device. The third-party authorization device receives the sub-private key, sub-public key information, and first signature information sent by the manufacturer's device and proceeds with the subsequent processing steps for obtaining the authorization document.

[0095] After obtaining the authorization document, the device to be authorized can verify the first signature information contained in the authorization document using the pre-stored root public key corresponding to the root private key. If the verification is successful, it indicates the authenticity and integrity of the sub-public key information contained in the authorization document, and the device to be authorized obtains the sub-public key information contained in the authorization document. After obtaining the sub-public key information, the device to be authorized has obtained the sub-public key. If the verification fails, it indicates a problem with the authenticity and integrity of the sub-public key information contained in the authorization document. The device to be authorized can then send a message to the manufacturer's device, or forward the message through a third-party authorization device, instructing the manufacturer's device to resend the sub-public key information and the first signature information, etc.; the device to be authorized can also send a message to a third-party authorization device, instructing the third-party authorization device to resend the authorization document, etc., without specific restrictions.

[0096] As one embodiment, the sub-public key information may further include an authorizable scope, which represents all functions that a third-party authorizing device receiving the sub-public key information can authorize for the device to be authorized. Therefore, the third-party authorizing device can configure specific authorized functions for the device to be authorized based on the authorizable scope contained in the sub-public key information sent by the manufacturer's device.

[0097] S303, if the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file.

[0098] After obtaining the sub-public key, the device to be authorized can verify the second signature information contained in the authorization file based on the sub-private key sent by the manufacturer's device. The second signature information is obtained by the third-party authorization device signing the authorization information set by the third-party authorization device based on the sub-private key sent by the manufacturer's device. The authorization information includes the specified authorization functions.

[0099] If the device to be authorized successfully verifies the second signature information based on the sub-public key, it indicates the authenticity and completeness of the authorization information contained in the authorization file, and the device to be authorized then obtains the authorization information contained in the authorization file. After obtaining the authorization information contained in the authorization file, the device to be authorized gains the specified authorized function. If the device to be authorized fails to verify the second signature information based on the sub-public key, it indicates a problem with the authenticity and completeness of the authorization information contained in the authorization file. In this case, the device to be authorized can send a message to a third-party authorization device, instructing the third-party authorization device to resend the authorization file to the device to be authorized; alternatively, the device to be authorized can send a verification result file to the third-party authorization device, allowing the third-party authorization device to determine the reason for the verification failure based on the verification result file, thereby identifying whether there is an unauthorized device that has illegally tampered with the authorization file, thus improving authorization security.

[0100] As one embodiment, the authorization information may further include target device information, used to indicate that the specified authorized function is for the device to be authorized corresponding to the target device information. The target device information may include one or more of the following: the media access control address (MAC) address, the central processing unit (CPU) number, or the device serial number of the device to be authorized. The target device information may also be other information used to uniquely identify the device to be authorized, and no specific limitations are made in this embodiment.

[0101] As one example, if the authorization information may also include target device information, then the third-party authorization device can obtain the target device information in advance. There are various methods to obtain the target device information in advance. For example, when setting up a specified authorization function, the third-party authorization device can determine the target device information based on the pre-stored device information of each device to be authorized.

[0102] For example, when determining to authorize a device, an information retrieval request is sent to the device to be authorized. The information retrieval request is used to obtain the device attributes of the device to be authorized, such as MAC address or CPU number.

[0103] The device to be authorized receives an information retrieval request from a third-party authorized device and retrieves its own device attributes based on the request. The information retrieval request can specify the device attributes to be retrieved, allowing the device to obtain the corresponding attribute values ​​after receiving the request. Alternatively, the information retrieval request can be left unspecified; in this case, the device to be authorized can retrieve all available device attributes, without any specific restrictions.

[0104] The device to be authorized sends its acquired device attributes to the third-party authorizing device. Upon receiving these attributes, the third-party authorizing device generates target device information. This allows the third-party authorizing device to determine, using the target device information, whether the device receiving the authorization file is the same as the device that received the information request, thus preventing incorrect authorization file transmission.

[0105] S304, The device to be authorized has the permission to run the program corresponding to the specified authorized function in the pre-stored firmware program.

[0106] After obtaining the specified authorized function, the device to be authorized can enable the execution permission of the program corresponding to the specified authorized function in the pre-stored firmware program, thereby enabling the device to possess the specified authorized function. The specified authorized function can be a single function or a collection of multiple functions, without any specific restrictions. The representation of the specified authorized function can be in various forms, such as descriptive information of the function, a function number used to uniquely identify each function, or the location of the corresponding program in the firmware program, etc., without any specific restrictions.

[0107] As one embodiment, if the sub-public key information also includes the scope of authorizable permissions for the device to be authorized, then after obtaining the specified authorized function, the device to be authorized can determine whether the specified authorized function and the scope of authorizable permissions match. This allows it to determine whether the specified authorized function set by the third-party authorizing device for the device to be authorized is a function that the manufacturer's device allows the third-party authorizing device to authorize, avoiding authorization errors caused by misoperation of the third-party authorizing device and improving the accuracy of authorization to a certain extent. It also prevents unauthorized third-party devices from maliciously authorizing the authorized device, thus improving the security of authorization.

[0108] There are various methods for a device to determine whether a specified authorized function matches the licensure scope, and this application does not impose specific limitations. For example, if the licensure scope is a set of multiple functions, the device to be authorized can determine whether the specified authorized function belongs to the set corresponding to the licensure scope. If the specified authorized function belongs to the set corresponding to the licensure scope, the device to be authorized determines that the specified authorized function matches the licensure scope. If the specified authorized function does not belong to the set corresponding to the licensure scope, the device to be authorized determines that the specified authorized function does not match the licensure scope.

[0109] For example, if the scope of authorization is the description information of a function, then the device to be authorized can determine the similarity between the description information of the specified authorized function and the description information corresponding to the scope of authorization. If the similarity is greater than a preset threshold, then the device to be authorized determines that the specified authorized function and the scope of authorization match. If the similarity is less than or equal to the preset threshold, then the device to be authorized determines that the specified authorized function and the scope of authorization do not match.

[0110] If the device to be authorized determines that the specified authorized function and the scope of authorization match, then the device to be authorized can enable the execution permission of the program corresponding to the specified authorized function in the pre-stored firmware program to complete the authorization of the device to be authorized. If the device to be authorized determines that the specified authorized function and the scope of authorization do not match, then the device to be authorized can provide feedback to the third-party authorization device so that the third-party authorization device can re-authorize the device to be authorized, or it can output a prompt message to indicate that the authorization failed.

[0111] As one embodiment, if the authorization information also includes target device information, the device to be authorized can determine whether the target device information matches its own device information after receiving the authorization information. This allows it to determine whether the device to be authorized for the specified authorization function in the authorization information is the same device that received the authorization information. This avoids authorization errors caused by network latency or transmission channel congestion when the same third-party authorization device authorizes different functions to different devices, thus improving the accuracy of authorization to some extent.

[0112] There are multiple methods for a device to determine whether the target device information matches its own device information, and this application embodiment does not impose specific limitations. For example, if the target device information includes multiple device attributes, such as MAC address and CPU number, the device to be authorized can determine whether there are any device attributes in the target device information that are the same as its own device information. If there are device attributes in the target device information that are the same as its own device information, such as a MAC address that is the same as its own, then the device to be authorized can determine that the target device information is consistent with its own device information. If the device to be authorized determines that there are no device attributes in the target device information that are the same as its own device information, then the device to be authorized can determine that the target device information is inconsistent with its own device information.

[0113] For example, the device to be authorized can determine the similarity between the target device information and its own device information. If the similarity is greater than a preset threshold, the device to be authorized can determine that the target device information is consistent with its own device information. If the similarity is less than or equal to the preset threshold, the device to be authorized can determine that the target device information is inconsistent with its own device information.

[0114] If the device to be authorized determines that the target device information matches its own, it can grant the program corresponding to the specified authorized function execution permission in the pre-stored firmware to complete the authorization process. If the device to be authorized determines that the target device information does not match its own, it can either send feedback to a third-party authorizing device so that the third-party authorizing device can re-authorize the device, or output a prompt message to indicate authorization failure.

[0115] The following is based on Figure 2 From the perspective of a third-party authorized device, the authorization method provided in the embodiments of this application will be described in detail.

[0116] Please refer to Figure 4 This is a flowchart illustrating the authorization method provided in the embodiments of this application.

[0117] S401, Generate an authorization file based on the pre-stored sub-public key information, first signature information, authorization information and second signature information.

[0118] Third-party authorization devices can generate authorization files based on pre-stored sub-public key information, first signature information, authorization information, and second signature information. For example, please refer to [reference needed]. Figure 5a This is a schematic diagram of the structure of an authorization file. The sub-public key information may include the sub-public key and the scope of authorization, while the authorization information may include the specified authorized functions and target device information. The following examples illustrate the processes for obtaining the sub-public key information, the first signature information, the authorization information, and the second signature information; specific implementations are not limited.

[0119] Manufacturer devices can pre-configure a root public-private key pair. The manufacturer device can integrate the root public key into the developed firmware program. Therefore, when the manufacturer device sends the firmware program to a third-party authorized device, it can also send the root public key to the third-party authorized device. In turn, when the third-party authorized device sends the firmware program to the device to be authorized, it can also send the root public key to the device to be authorized, so that the device to be authorized can receive the firmware program sent by the third-party authorized device and obtain the firmware program and the root public key carried by the firmware program.

[0120] Manufacturer-manufactured devices can also pre-configure corresponding sub-public / private key pairs for each third-party authorized device. The root private key can then be used to sign the sub-public key, and the sub-private key can be used to sign the authorization information. The authorization information includes the specified authorized functions for the device to be authorized. Therefore, the device to be authorized only needs to pre-store the root public key to obtain the sub-public key through signature verification. After obtaining the sub-public key, it can then obtain the authorization information, i.e., the specified authorized functions, through signature verification.

[0121] The authorization information can be generated by a third-party authorized device. For example, a third-party authorized device can set specific authorization functions for the device to be authorized. Thus, the third-party authorized device can generate authorization information based on the specific authorization functions for the device to be authorized. Alternatively, the third-party authorized device can generate authorization information based on the specific authorization functions for the device to be authorized and the target device information of the device to be authorized. There are no specific restrictions.

[0122] The process by which a third-party authorized device obtains information about a target device can be described as follows: the third-party authorized device sends an information acquisition request to the device to be authorized; the device to be authorized returns device attributes based on the received information acquisition request; and the third-party authorized device generates target device information based on the received device attributes.

[0123] For example, please refer to Figure 5bThe manufacturer's equipment pre-configures a root public-private key pair and sets up three sub-public-private key pairs for three third-party authorized devices: third-party authorized device A, third-party authorized device B, and third-party authorized device C. These sub-public key pairs are sub-private key A, sub-public key B, and sub-private key C. Therefore, the manufacturer's equipment can integrate the root public key into the developed firmware and send the sub-public keys to the corresponding third-party authorized devices.

[0124] Manufacturer devices can set an authorized scope for each third-party authorized device, representing the maximum number of functions that the third-party authorized device can configure on the device to be authorized. The manufacturer device can use a sub-public key and the authorized scope as sub-public key information, or only the sub-public key. The manufacturer device uses its root private key to sign the sub-public key information to obtain the first signature. Therefore, when the manufacturer device needs to modify the authorized scope for a specific third-party authorized device, it can modify only the authorized scope without needing to allocate a new public-private key pair for the new authorized scope, nor pre-store a new public key in the device to be authorized. This simplifies the process of modifying the authorized scope during re-authorization and improves the efficiency of re-authorization.

[0125] The manufacturer's device can send the sub-private key, sub-public key information, and first signature information to a third-party authorized device. The third-party authorized device receives the sub-private key, sub-public key information, and first signature information sent by the manufacturer's device. After obtaining the sub-private key, sub-public key information, and first signature information, the third-party authorized device can use the sub-private key to sign the authorization information to obtain the second signature information.

[0126] From the perspective of the third-party authorized device, the sub-private key, sub-public key information, and first signature information are pre-set by the manufacturer's device. The manufacturer's device defines the sub-private key and sub-public key, as well as the scope of authorization, for the third-party authorized device. The third-party authorized device can use the same sub-private key and sub-public key to authorize different devices within the authorized scope, without needing to pre-allocate corresponding public-private key pairs for all possible functions, nor pre-store all public keys in the devices to be authorized, simplifying the authorization process and improving authorization efficiency. Furthermore, when the third-party authorized device needs to modify the authorized function of a device to be authorized, it can directly modify the authorization information and re-authorize the device to be authorized using the authorization file, without needing to re-allocate public-private key pairs for the new function, nor pre-store the newly allocated public key in the device to be authorized, simplifying the process of modifying authorized functions during re-authorization and improving authorization efficiency during re-authorization.

[0127] S402, send the authorization document to the device to be authorized.

[0128] After obtaining the authorization document, the third-party authorized device can send the authorization document to the device to be authorized, so that the device to be authorized can receive the authorization document and perform authorization based on the authorization document. The authorization process of the device to be authorized can be referred to the previous introduction, and will not be repeated here.

[0129] Based on the same inventive concept, embodiments of this application provide an authorization device, which is equivalent to the authorization device discussed above and can realize the functions corresponding to the aforementioned authorization method. Please refer to... Figure 6 The device includes a transceiver module 601 and a processing module 602, wherein:

[0130] Transceiver module 601: Used to receive authorization files sent by third-party authorized devices;

[0131] Processing module 602: If the signature verification of the first signature information contained in the signature authorization file is successful based on the pre-stored root public key, then the sub-public key information contained in the signature authorization file is obtained, wherein the sub-public key information includes the sub-public key;

[0132] The processing module 602 is also used to: if the second signature information contained in the authorization file is successfully verified based on the sub-public key, then obtain the authorization information contained in the authorization file, wherein the authorization information includes the specified authorization function;

[0133] The processing module 602 is also used to: enable the running permissions of the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate the programs corresponding to all the functions developed.

[0134] In one possible embodiment, the processing module 602 is specifically used for:

[0135] If the sub-public key information also includes the scope of authorization for the device to be authorized, then determine whether the specified authorization function and the scope of authorization match;

[0136] If the specified authorized function and the scope of authorized functions match, then the running permissions of the program corresponding to the specified authorized function in the pre-stored firmware program will be enabled.

[0137] In one possible embodiment, the processing module 602 is specifically used for:

[0138] If the authorization information also includes target device information, then determine whether the target device information is consistent with the device information of the device to be authorized;

[0139] If the target device information matches the device information of the device to be authorized, then the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program will be enabled.

[0140] In one possible embodiment, the transceiver module 601 is further configured to:

[0141] Before determining whether the target device information is consistent with the device information of the device to be authorized, an information acquisition request sent by a third-party authorized device is received. The information acquisition request is used to obtain the device attributes of the device to be authorized.

[0142] The processing module 602 is also used to: based on the information acquisition request, send back the obtained device attributes to the third-party authorized device, so that after receiving the device attributes sent by the device to be authorized, the third-party authorized device generates target device information based on the received device attributes.

[0143] Based on the same inventive concept, embodiments of this application provide an authorization device, which is equivalent to the third-party authorization device discussed above and can realize the functions corresponding to the aforementioned authorization method. Please refer to... Figure 7 The device includes a processing module 701 and a transceiver module 702, wherein:

[0144] Processing module 701: is used to generate an authorization file based on pre-stored sub-public key information, first signature information, authorization information and second signature information, wherein the sub-public key information includes a sub-public key and the authorization information includes specified authorization functions for the device to be authorized;

[0145] Transceiver module 702: Used to send an authorization file to the device to be authorized, so that the device to be authorized can receive the authorization file; and, if the first signature information contained in the authorization file is successfully verified based on the pre-stored root public key, the device to be authorized obtains the sub-public key information contained in the authorization file; and, if the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file; and, the device to be authorized enables the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program, wherein the firmware program is used to integrate the programs corresponding to all functions developed.

[0146] In one possible embodiment, the transceiver module 702 is further configured to:

[0147] Before generating the authorization file based on the pre-stored sub-public key information, first signature information, authorization information and second signature information, the firmware program sent by the manufacturer's device is received. The firmware program carries the root public key, which is used to verify the signature of the information after it is signed by the root private key.

[0148] Send the firmware program to the device to be authorized so that the device to be authorized can receive the firmware program and obtain the root public key carried by the firmware program.

[0149] In one possible embodiment, the transceiver module 702 is further configured to:

[0150] Before generating the authorization file based on the pre-stored sub-public key information, first signature information, authorization information and second signature information, the system receives the sub-public key information, sub-private key and first signature information sent by the manufacturer's device. The sub-public key information contains the sub-public key used to verify the signature of the information after the sub-private key is signed. The first signature information is obtained by the manufacturer's device signing the sub-public key information based on the pre-stored root private key.

[0151] Processing module 701 is also used for:

[0152] Based on the sub-private key, the pre-stored authorization information is signed to obtain the second signature information.

[0153] Based on the same inventive concept, embodiments of this application provide an authorization system, including an authorization device equivalent to the device to be authorized as described above and an authorization device equivalent to the third-party authorization device described above.

[0154] Based on the same inventive concept, this application provides a computer device, which is described below.

[0155] Please refer to Figure 8 The aforementioned authorized device can run on computer device 800. The current and historical versions of the data storage program and the application software corresponding to the data storage program can be installed on computer device 800. Computer device 800 includes display unit 840, processor 880 and memory 820. Display unit 840 includes display panel 841 for displaying user interactive operation interface, etc.

[0156] In one possible embodiment, the display panel 841 may be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED).

[0157] The processor 880 is used to read a computer program and then execute the methods defined by the computer program. For example, the processor 880 reads a data storage program or file, thereby running the data storage program on the computer device 800 and displaying the corresponding interface on the display unit 840. The processor 880 may include one or more general-purpose processors, and may also include one or more DSPs (Digital Signal Processors) for performing related operations to implement the technical solutions provided in the embodiments of this application.

[0158] The memory 820 generally includes main memory and secondary storage. Main memory can be random access memory (RAM), read-only memory (ROM), and cache, etc. Secondary storage can be a hard disk, optical disk, USB flash drive, floppy disk, or tape drive, etc. The memory 820 is used to store computer programs and other data. The computer programs include applications corresponding to each client, and other data may include data generated after the operating system or applications are run, including system data (e.g., operating system configuration parameters) and user data. In this embodiment, program instructions are stored in the memory 820, and the processor 880 executes the program instructions stored in 820 to implement any of the authorized methods described in the preceding figures.

[0159] The aforementioned display unit 840 is used to receive input digital information, character information, or contact touch operations / non-contact gestures, and to generate signal inputs related to user settings and function control of the computer device 800. Specifically, in this embodiment, the display unit 840 may include a display panel 841. The display panel 841, for example, is a touch screen, which can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or on the display panel 841), and drive corresponding connection devices according to a pre-set program.

[0160] In one possible embodiment, the display panel 841 may include two parts: a touch detection device and a touch controller. The touch detection device detects the player's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 880. It can also receive and execute commands from the processor 880.

[0161] The display panel 841 can be implemented using various methods such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the display unit 840, the computer device 800 may also include an input unit 830, which may include a graphics input device 831 and other input devices 832. These other input devices may include, but are not limited to, one or more of the following: a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick.

[0162] In addition to the above, the computer device 800 may also include a power supply 890 for powering other modules, an audio circuit 860, a near-field communication module 870, and an RF circuit 810. The computer device 800 may also include one or more sensors 850, such as an accelerometer, a light sensor, and a pressure sensor. The audio circuit 860 specifically includes a speaker 861 and a microphone 862, for example, the computer device 800 can use the microphone 862 to collect the user's voice and perform corresponding operations.

[0163] As one embodiment, the number of processors 880 can be one or more, and the processors 880 and the memory 820 can be coupled together or relatively independent.

[0164] As one example, Figure 8 The processor 880 in the middle can be used to implement, for example Figure 6 The functions of the transceiver module 601 and the processing module 602 in the above can also be used to implement, for example... Figure 7 The functions of the processing module 701 and the transceiver module 702.

[0165] As one example, Figure 8 The processor 880 in the document can be used to implement the functions corresponding to the unlicensed device or the third-party licensed device as discussed above.

[0166] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0168] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An authorization method, characterized in that, include: The device to be authorized receives the authorization file sent by the third-party authorization device; The scope of authorization for each third-party authorized device is set or modified by the manufacturer; the scope of authorization includes: the functions that the corresponding third-party authorized device is authorized to authorize for the device to be authorized; If the first signature information contained in the authorization file is successfully verified based on the root public key carried in the firmware program pre-stored in the device to be authorized, then the device to be authorized obtains the sub-public key information contained in the authorization file, wherein the sub-public key information includes a sub-public key and an authorized scope; the first signature information is obtained by the manufacturer's device that developed the firmware program signing the sub-public key information set for the third-party authorized device based on a preset root private key; If the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file, wherein the authorization information includes a specified authorization function; the second signature information is obtained by the third-party authorization device signing the authorization information set by the third-party authorization device based on the sub-private key set by the manufacturer's device for the third-party authorization device; If the specified authorized function matches the authorized scope, the device to be authorized will enable the running permission of the program corresponding to the specified authorized function in the firmware program, wherein the firmware program is used to integrate programs corresponding to all functions developed.

2. The method according to claim 1, characterized in that, The execution permissions of the program corresponding to the specified authorized function in the pre-stored firmware program of the device to be authorized include: If the authorization information also includes target device information, then the device to be authorized determines whether the target device information is consistent with the device information of the device to be authorized; If the target device information is consistent with the device information of the device to be authorized, then the device to be authorized will enable the running permission of the program corresponding to the specified authorized function in the pre-stored firmware program.

3. The method according to claim 2, characterized in that, Before the device to be authorized determines whether the target device information matches the device information of the device to be authorized, the method further includes: The device to be authorized receives an information acquisition request sent by the third-party authorized device, wherein the information acquisition request is used to acquire the device attributes of the device to be authorized; Based on the information acquisition request, the device to be authorized sends the obtained device attributes to the third-party authorized device, so that after receiving the device attributes sent by the device to be authorized, the third-party authorized device generates the target device information based on the received device attributes.

4. An authorization method, characterized in that, include: Based on pre-stored sub-public key information, first signature information, authorization information, and second signature information, a third-party authorization device generates an authorization file. The sub-public key information includes a sub-public key and an authorized scope for the device to be authorized. The authorization information includes specified authorized functions for the device to be authorized. The authorized scope for each third-party authorization device is set or modified by the manufacturer's device. The authorized scope includes the functions that the corresponding third-party authorization device is authorized to authorize for the device to be authorized. The first signature information is obtained by the manufacturer's device, which develops the firmware program, signing the sub-public key information set for the third-party authorization device based on a preset root private key. The second signature information is obtained by the third-party authorization device, which signs the authorization information set by the third-party authorization device based on the sub-private key set by the manufacturer's device for the third-party authorization device. The third-party authorized device sends an authorization file to the device to be authorized, so that the device to be authorized can receive the authorization file sent by the third-party authorized device. If the first signature information contained in the authorization file is successfully verified based on the root public key carried in the firmware program pre-stored in the device to be authorized, the device to be authorized obtains the sub-public key information contained in the authorization file. If the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file. If the specified authorized function and the authorized scope match, the device to be authorized enables the running permission of the program corresponding to the specified authorized function in the firmware program. The firmware program is used to integrate programs corresponding to all functions developed.

5. The method according to claim 4, characterized in that, Before the third-party authorization device generates the authorization file based on the pre-stored sub-public key information, first signature information, authorization information, and second signature information, it also includes: The third-party authorized device receives the firmware program sent by the manufacturer's device, wherein the firmware program carries a root public key, which is used to verify the signature of the information after it is signed by the root private key. The third-party authorized device sends the firmware program to the device to be authorized, so that the device to be authorized can receive the firmware program sent by the third-party authorized device and obtain the root public key carried in the firmware program.

6. The method according to claim 4 or 5, characterized in that, Before the third-party authorization device generates the authorization file based on the pre-stored sub-public key information, first signature information, authorization information, and second signature information, it also includes: The third-party authorized device receives the sub-public key information, sub-private key and first signature information sent by the manufacturer device. The sub-public key information contains the sub-public key used to verify the signature of the information after it is signed by the sub-private key. The first signature information is obtained by the manufacturer device by signing the sub-public key information based on the pre-stored root private key. Based on the sub-private key, the pre-stored authorization information is signed to obtain the second signature information.

7. An authorization device, characterized in that, include: Transceiver module: Used to receive authorization files sent by third-party authorized devices; The scope of authorization for each third-party authorized device is set or modified by the manufacturer; the scope of authorization includes: the functions that the corresponding third-party authorized device is authorized to authorize for the device to be authorized; Processing module: If the first signature information contained in the authorization file is successfully verified based on the root public key carried in the firmware program pre-stored in the device to be authorized, then the sub-public key information contained in the authorization file is obtained, wherein the sub-public key information includes a sub-public key and an authorized scope for the authorization device; wherein the first signature information is obtained by the manufacturer's device that developed the firmware program signing the sub-public key information set for the third-party authorization device based on a preset root private key; The processing module is further configured to: if the second signature information contained in the authorization file is successfully verified based on the sub-public key, then obtain the authorization information contained in the authorization file, wherein the authorization information includes a specified authorization function; the second signature information is obtained by the third-party authorization device signing the authorization information set by the third-party authorization device based on the sub-private key set by the manufacturer's device for the third-party authorization device; The processing module is further configured to: if the specified authorized function matches the authorized scope, then enable the running permission of the program corresponding to the specified authorized function in the firmware program, wherein the firmware program is used to integrate programs corresponding to all functions developed.

8. An authorization device, characterized in that, include: Processing module: Used to generate an authorization file based on pre-stored sub-public key information, first signature information, authorization information, and second signature information. The sub-public key information includes a sub-public key and an authorized scope for the device to be authorized. The authorization information includes specified authorized functions for the device to be authorized. The authorized scope for each third-party authorized device is set or modified by the manufacturer's device. The authorized scope includes the functions that the corresponding third-party authorized device is authorized to grant to the device to be authorized. The first signature information is obtained by the manufacturer's device, which develops the firmware program, signing the sub-public key information set for the third-party authorized device based on a preset root private key. The second signature information is obtained by the third-party authorized device, which signs the authorization information set by the third-party authorized device based on the sub-private key set by the manufacturer's device for the third-party authorized device. Transceiver module: Used to send an authorization file to the device to be authorized, so that the device to be authorized can receive the authorization file; and, if the first signature information contained in the authorization file is successfully verified based on the root public key carried in the firmware program pre-stored in the device to be authorized, the device to be authorized obtains the sub-public key information contained in the authorization file; and, if the second signature information contained in the authorization file is successfully verified based on the sub-public key, the device to be authorized obtains the authorization information contained in the authorization file; and, if the specified authorization function matches the authorized scope, the device to be authorized enables the running permission of the program corresponding to the specified authorization function in the firmware program, wherein the firmware program is used to integrate programs corresponding to all functions developed.

9. An authorization system, characterized in that, Includes the authorized device as described in claim 7 and the device as described in claim 8.

10. A computer device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method as described in any one of claims 1 to 6 according to the obtained program instructions.

11. A computer-readable storage medium, characterized in that, The storage medium stores computer-executable instructions for causing a computer to perform the method as described in any one of claims 1 to 6.

Images