Function opening method, electronic device and computer program product

Abstract

The invention provides a function opening method, electronic equipment and a computer program product, which can be used in the technical field of software. The method is applied to a client, and comprises the following steps: generating a first information body based on a device identifier and an anti-replay identifier in response to an obtained opening instruction for a target function; generating a first message authentication code corresponding to the first information body based on a preset symmetric key, and generating opening request information based on the first message authentication code and the first information body; sending opening request information to a server; receiving opening response information sent by the server; the opening response information comprises a license corresponding to the target function; verifying the license to obtain an opening verification result; and storing the license under the condition that the opening verification result is that the verification is passed. According to the invention, data tampering and replay attacks are effectively prevented, and the security and integrity of data transmission are ensured, so that the secure opening of the target function is ensured.

Description

Technical Field

[0001] This application relates to the field of software technology, and more particularly to a method for enabling functions, electronic devices, and computer program products. Background Technology

[0002] Some software currently offers advanced or customized features, which can be activated according to the customer's actual needs to provide corresponding services.

[0003] In related technologies, enabling functionality involves the client requesting a license from the server, which involves data transmission between the client and server. In complex network topologies, multiple intermediate network nodes exist between the client and server. The client's request information to the server may be tampered with by malicious attackers during transmission. Furthermore, the license returned by the server after receiving the request may be stolen by malicious attackers, causing the client's activation to fail. Summary of the Invention

[0004] This application provides a function activation method, an electronic device, and a computer program product to ensure the secure activation of the target function.

[0005] Firstly, this application provides a method for enabling functionality, applied to a client, including:

[0006] In response to receiving an activation command for the target function, a first information body is generated based on the device identifier and the anti-replay identifier;

[0007] Based on a preset symmetric key, a first message authentication code corresponding to the first information body is generated, and an activation request message is generated based on the first message authentication code and the first information body.

[0008] Send the activation request information to the server; the activation request information is used to instruct the server to verify the first message authentication code in the activation request information based on a preset symmetric key, and if the verification passes, to verify the anti-replay identifier in the activation request information, and if the verification passes, to generate activation response information.

[0009] Receive activation response information sent by the server; the activation response information includes the license corresponding to the target function;

[0010] The license is verified to obtain the activation verification result;

[0011] If the activation verification result is successful, the license is stored.

[0012] In some embodiments, the license includes a device identifier and a replay protection identifier; the verification of the license to obtain an activation verification result includes:

[0013] The license is verified using a public key to obtain the license verification result.

[0014] If the license verification result is successful, the device identifier in the license is compared with the device identifier stored locally, and the anti-replay identifier in the license is compared with the anti-replay identifier stored locally to obtain a first comparison result;

[0015] If the first comparison result indicates that the device identifier in the license is the same as the device identifier stored locally, and the anti-replay identifier in the license is the same as the anti-replay identifier stored locally, then the activation verification result is determined to be successful.

[0016] In some embodiments, after storing the license, the method further includes:

[0017] In response to receiving a verification command for the target function, the stored license is read;

[0018] The license is verified to obtain a local verification result;

[0019] A second information body is generated based on the device identifier and the license, and a second message authentication code corresponding to the second information body is generated based on the symmetric key. Verification request information is generated based on the second message authentication code and the second information body.

[0020] The verification request information is sent to the server; the verification request information is used to instruct the server to verify the second message authentication code in the verification request information based on a preset symmetric key and generate verification response information if the verification is successful.

[0021] Receive verification response information sent by the server; the verification response information includes the cloud verification result;

[0022] Based on the local verification result and the cloud verification result, the target verification result is determined.

[0023] In some embodiments, the verification response information further includes a third message authentication code; determining the target verification result based on the local verification result and the cloud verification result includes:

[0024] The third message authentication code is verified based on the symmetric key to obtain the authentication code verification result.

[0025] If the verification code verification result is successful, the target verification result is determined based on the local verification result and the cloud verification result.

[0026] In some embodiments, generating a second information body based on the device identifier and the license includes:

[0027] The second information body is generated based on the device identifier, the random number, and the license; the verification response information also includes the device identifier and the random number.

[0028] The determination of the target verification result based on the local verification result and the cloud verification result includes:

[0029] The device identifier in the verification response information is compared with the device identifier stored locally, and the random number in the verification response information is compared with the random number stored locally to obtain a second comparison result;

[0030] If the second comparison result indicates that the device identifier in the verification response information is the same as the device identifier stored locally, and the random number in the verification response information is the same as the random number stored locally, then the target verification result is determined based on the local verification result and the cloud verification result.

[0031] Secondly, this application provides a method for enabling functionality, applied on the server side, including:

[0032] The system receives an activation request from a client to request the activation of a target function; the activation request includes a first information body and a corresponding first message authentication code; the first information body is generated by the client based on a device identifier and an anti-replay identifier;

[0033] The first message authentication code is verified based on a preset symmetric key to obtain the authentication code verification result;

[0034] If the authentication code verification result is successful, the anti-replay identifier is verified to obtain the anti-replay verification result.

[0035] If the anti-replay verification result is successful, a license corresponding to the client is generated for the target function to enable the target function;

[0036] Generate activation response information and send the activation response information to the client; the activation response information includes the license.

[0037] In some embodiments, generating the license corresponding to the client for the target function includes:

[0038] The license is generated based on the device identifier, the anti-replay identifier, and the activation information corresponding to the target function;

[0039] The license is signed using a private key.

[0040] In some embodiments, after sending the activation response information to the client, the method further includes:

[0041] The system receives a verification request message sent by the client; the verification request message includes a second information body and a corresponding second message authentication code; the second information body is generated by the client based on the device identifier and the license.

[0042] The second message authentication code is verified based on the symmetric key to obtain the authentication code verification result;

[0043] If the authentication code verification result is successful, the license is verified to obtain the cloud verification result;

[0044] Generate verification response information and send the verification response information to the client; the verification response information includes the cloud verification result.

[0045] In some embodiments, verifying the license to obtain a cloud verification result includes:

[0046] The license is verified using a public key to obtain the license verification result.

[0047] If the license verification result is successful, the activation record information corresponding to the device identifier is compared with the activation-related information in the license to obtain a third comparison result;

[0048] If the third comparison result indicates that the activation record information matches the activation-related information in the license, the cloud verification result is determined to be successful.

[0049] In some embodiments, the second information body further includes a random number; the generation of verification response information includes:

[0050] A response information body is generated based on the device identifier, the random number, and the cloud verification result;

[0051] Based on the symmetric key, a third message authentication code corresponding to the response information body is generated, and the verification response information is generated based on the third message authentication code and the response information body.

[0052] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0053] The memory stores computer-executed instructions;

[0054] The processor executes computer execution instructions stored in the memory to implement the function activation method as described in any of the first or second aspects.

[0055] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the first aspects or the function activation methods described in any of the second aspects.

[0056] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements any of the methods described in the first aspect or the function activation method described in any of the second aspects.

[0057] The function activation method, electronic device, and computer program product provided in this application pre-set a symmetric key on the client and server. When the client receives an activation command triggered by the user for the target function, it first generates a first information body based on the device identifier and the anti-replay identifier. Then, based on the preset symmetric key, it generates a first message authentication code corresponding to the first information body. On this basis, it generates activation request information based on the first message authentication code and the first information body and sends the activation request information to the server. In this way, the server can verify the first message authentication code in the activation request information through the symmetric key. If the verification passes, it further verifies the anti-replay identifier in the activation request information. Only if the verification passes will it return activation response information. On the one hand, by generating the first message authentication code on the device side and verifying it on the server side, it is ensured that the activation request information is not tampered with during transmission. Any tampering will cause the first message authentication code verification to fail, and the server will not return activation response information, thus ensuring the integrity and authenticity of the data. On the other hand, the first information body is generated using the device identifier and the anti-replay identifier, and the anti-replay identifier is verified on the server side. The anti-replay identifier is one-time use to ensure that each request is unique. This way, even if an attacker intercepts the activation request information, they cannot obtain a license later by replaying the request because the anti-replay identifier contained in the request is repeated and cannot pass the server's verification, thus effectively preventing replay attacks. Furthermore, since symmetric keys are used for message authentication... The generation and verification of the key are known only to the device and server sides, preventing attackers from forging valid activation request information. This enhances system security and prevents unauthorized activation of functions. Furthermore, this mechanism ensures that only legitimate user requests can successfully activate the target function, preventing malicious attackers from obtaining unauthorized function activation through data theft or tampering, thus protecting user privacy and data security. Therefore, this scheme, through multi-layered security measures (such as symmetric keys, message authentication codes, and anti-replay identifiers), effectively prevents data tampering and replay attacks, ensuring the security and integrity of data transmission, the reliability and stability of the system, and reducing the risk of function activation failure due to data tampering or attacks, thereby guaranteeing the secure activation of the target function. Attached Figure Description

[0058] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0059] Figure 1 This is a schematic diagram illustrating an application scenario according to an exemplary embodiment;

[0060] Figure 2This is a flowchart illustrating a function activation method according to an exemplary embodiment;

[0061] Figure 3 This is a flowchart illustrating a function activation method according to another exemplary embodiment;

[0062] Figure 4 This is a flowchart illustrating a method for enabling a function according to yet another exemplary embodiment;

[0063] Figure 5 This is a schematic diagram illustrating a function activation process according to an exemplary embodiment;

[0064] Figure 6 This is a flowchart illustrating an authorization verification process according to an exemplary embodiment;

[0065] Figure 7 This is a schematic diagram illustrating a local verification process according to an exemplary embodiment;

[0066] Figure 8 This is a schematic diagram illustrating a cloud verification process according to an exemplary embodiment;

[0067] Figure 9 This is a schematic diagram of the structure of a function activation device according to an exemplary embodiment;

[0068] Figure 10 This is a schematic diagram of the structure of a function activation device according to another exemplary embodiment;

[0069] Figure 11 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment.

[0070] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0071] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0072] The terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. In the following descriptions of embodiments, "a plurality of" means two or more, unless otherwise explicitly defined.

[0073] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0074] As mentioned in the background section, some software currently offers advanced or customized features that can be activated according to the customer's actual needs to provide corresponding services. In related technologies, activation of these features is achieved by the client requesting a license from the server, which involves data transmission between the client and server. In complex network topologies, multiple intermediate network nodes exist between the client and server. The request information sent by the client to the server may be tampered with by malicious attackers during transmission. Furthermore, the license returned by the server after receiving the request information may be stolen by malicious attackers, causing the client's activation to fail.

[0075] In response to the technical problems existing in related technologies, the inventors of this application discovered in their research that, since request information may be tampered with during transmission, the server can verify the request information after receiving it. If the verification passes, a license is returned, ensuring that only legitimate user requests can successfully activate the function. Based on this, to provide a basis for the server's verification operation, the client can perform some calculation on the data contained in the request information to obtain reference information, and send this reference information to the server. This allows the server to use the reference information to verify the integrity and authenticity of the data in the request information, thereby effectively preventing data tampering, ensuring the security and integrity of data transmission, reducing the risk of function activation failure due to data tampering, and thus ensuring the secure activation of the function.

[0076] Specifically, this application pre-sets a symmetric key on the client and server. When the client receives an activation command triggered by the user for the target function, it first generates a first information body based on the device identifier and the anti-replay identifier. Then, based on the preset symmetric key, it generates a first message authentication code corresponding to the first information body. On this basis, it generates activation request information based on the first message authentication code and the first information body and sends the activation request information to the server. In this way, the server can verify the first message authentication code in the activation request information and verify the anti-replay identifier through the symmetric key. Only when the verification is successful will the server return activation response information.

[0077] Figure 1 This is a schematic diagram illustrating an application scenario according to an exemplary embodiment. For example... Figure 1 As shown, this application scenario includes: client 1, server 2, and one or more intermediate network nodes. Client 1 connects through one or more intermediate network nodes (…). Figure 1 (Two examples) Communicate with server 2. For instance, the devices are connected via a wireless or wired network.

[0078] In this context, Client 1 is the terminal device used by the user. Client 1 has a target application installed that provides advanced or customized functions. For example, this target application can be a system application or a third-party application; in terms of type, it can be an in-vehicle application, a game application, or a social application, but is not limited to these. For example, the terminal device can be a smartphone, tablet, laptop, desktop computer, smart home device (such as a smart speaker, smart home appliance, etc.), wearable device (such as a smartwatch), smart voice interaction device, and in-vehicle terminal (vehicle infotainment system), but is not limited to these.

[0079] Server 2 provides backend services to client 1, which has the target application installed. For example, in one scenario, client 1 is an in-vehicle terminal, and server 2 is a server of a service provider offering advanced intelligent driving functions. Exemplarily, server 2 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0080] In the application scenarios applicable to this application, multiple intermediate network nodes are included between client 1 and server 2, and the number and purpose of these intermediate network nodes can be determined according to the actual application scenario. For example, in one scenario, client 1 is an in-vehicle terminal, and the intermediate network nodes are used to provide vehicle manufacturer services and forward activation request information sent by the in-vehicle terminal to server 2; for example, the intermediate network node is a vehicle manufacturer server. This method of forwarding by the vehicle manufacturer server enables vehicle manufacturers to manage vehicle data, meeting their vehicle management requirements. It also meets the needs of intelligent driving service providers to obtain vehicle function usage data for facilitating the activation of related functions, and allows intelligent driving service providers to directly obtain and statistically manage user intelligent driving function data. In another scenario, intermediate network nodes are used to provide communication services; for example, the intermediate network node is a server of a communication service provider, specifically providing functions such as network routing and bandwidth management. In yet another scenario, intermediate network nodes are used for data processing and analysis; for example, the intermediate network node is an edge computing node used for real-time data processing such as video streams and sensor data to reduce latency and bandwidth requirements, and improve response speed and reliability.

[0081] In one application scenario, a user uses the functions provided by the target application through client 1. When the user wants the target application to enable advanced or customized functions, the user can trigger an activation command for the target function. The client then sends an activation request to the server by executing the function activation method provided in this application. The server, by executing the function activation method provided in this application, activates the target function for the client if the verification is successful, and returns activation response information. Subsequently, the client stores the license if the verification is successful, thus realizing the activation of the target function.

[0082] Those skilled in the art will understand that the number of clients 1 can be greater. For example, there may be only one client 1, or dozens or hundreds, or more. There may be no intermediate network nodes, or there may be one or more. This application does not limit the number of clients 1 or intermediate network nodes.

[0083] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0084] Figure 2 This is a flowchart illustrating a function activation method according to an exemplary embodiment. The function activation method provided in this application is executed by a function activation device, which is integrated into an electronic device, and the electronic device is provided as follows: Figure 1Client 1 is shown. (Example) Figure 2 As shown, the function activation method provided in this embodiment includes the following steps:

[0085] Step S101: In response to receiving the activation command for the target function, a first information body is generated based on the device identifier and the anti-replay identifier.

[0086] The client application contains a target application that provides advanced or customized features. This target application offers various functions, including the target feature and other features. The target feature is either advanced or customized. In some scenarios, the target feature is typically a paid feature.

[0087] In this embodiment, if the target application is for enabling a target function, and the user wants to enable that target function, an activation command for the target function can be triggered. The client then executes the function activation method provided in this application to activate the target function, enabling the user to use it. For example, the client displays an activation control for the target function in the target application. The user triggers this activation control, thereby triggering the client to generate an activation command for the target function. For example, the activation control can be a button or other styles; this embodiment does not limit this.

[0088] The device identifier is a unique identifier for the client, which can be the device's serial number (SN), media access control address (MAC address), or other unique identifier. The anti-replay identifier is an identifier used to prevent replay attacks; it can be a timestamp, a random number, or other identifier capable of preventing replay attacks, ensuring that each request is unique. A replay attack refers to an attacker capturing and replaying the communication data of a legitimate user to deceive the system.

[0089] Optionally, generating the first information body based on the device identifier and the anti-replay identifier is specifically implemented as follows: obtaining the device identifier from the client's local machine; generating an anti-replay identifier; collecting other necessary data for forming the request body; and combining the device identifier, the anti-replay identifier, and other necessary data into the first information body according to the communication protocol specifications agreed upon in advance between the client and the server.

[0090] If the client has pre-stored the device identifier locally, it can directly retrieve the stored device identifier. When generating the anti-replay identifier, the random number output by the anti-replay counter can be used as the anti-replay identifier, or a timestamp can be generated based on the current time and used as the anti-replay identifier. Other necessary data includes, but is not limited to, the specific parameters of the request, user information, and the type of function requested. The communication protocol specification can be the Hypertext Transfer Protocol (HTTP) specification or other protocol specifications. When combining the data into the first message body, it is necessary to ensure that the data is arranged and encapsulated according to the format of the request message specification. For example, it may be necessary to convert the data into JSON format (a lightweight data interchange format), XML format (an extensible markup language), or other protocol-specified formats.

[0091] Step S102: Based on the preset symmetric key, generate a first message authentication code corresponding to the first information body, and generate an activation request message based on the first message authentication code and the first information body.

[0092] The first message authentication code is used to verify the integrity and authenticity of the message. It is calculated together with the symmetric key and the message (here, the first information body) to ensure that the first information body has not been tampered with during transmission. In one optional implementation, a key-based hash-based message authentication code (HMAC) algorithm is used to encrypt the first information body based on the symmetric key to obtain the first message authentication code. The client and server each have a pre-set symmetric key and hash function, which are identical between the communicating parties. Specifically, the key is padded or compressed to make its length equal to the length of the block inside the hash function. The processed key is concatenated with the first information body, and the hash function is used to hash the concatenated data to obtain a hash value. This hash value is then hashed again with the processed key to obtain the first message authentication code. In another optional implementation, other symmetric encryption algorithms besides HMAC can be used to encrypt the first information body based on the symmetric key to obtain the first message authentication code. For example, the symmetric encryption algorithm can be the Advanced Encryption Standard (AES) algorithm, or the Blowfish algorithm (a symmetric encryption algorithm), etc.

[0093] The activation request information is the final generated request information, containing a first information body and a first message authentication code. This activation request information is used to request the activation of the target function. For example, generating the activation request information based on the first message authentication code and the first information body specifically involves combining the first message authentication code and the first information body to form a complete activation request information. Specific formats or protocols can be used to combine this information so that the recipient can correctly parse it.

[0094] Step S103: Send an activation request message to the server. The activation request message is used to instruct the server to verify the first message authentication code in the activation request message based on the preset symmetric key. If the verification is successful, the server will verify the anti-replay flag in the activation request message. If the verification is successful, the server will generate an activation response message.

[0095] The process involves the server verifying the first message authentication code in the activation request information based on a preset symmetric key. If the verification passes, it then verifies the anti-replay flag in the activation request information. If the verification passes, the server generates the activation response information. See below for details on this process. Figure 3 The illustrated embodiment will not be described in detail here. After generating the activation response information, the server sends the activation response information to the client.

[0096] Step S104: Receive activation response information sent by the server; the activation response information includes the license corresponding to the target function.

[0097] The license, also known as a copyright license, is generally used to grant access permission to software users who pay for the software. For example, the license contains data such as device identification, anti-replay identifiers, and information related to the activation of the target function. This activation information includes a description of the target function, the validity period, or the number of valid uses.

[0098] Step S105: Verify the license to obtain the activation verification result.

[0099] For example, the device identifier and the anti-replay identifier in the license are verified to obtain the activation verification result. There are two possibilities for the activation verification result: verification passes or verification fails.

[0100] Step S106: If the activation verification result is successful, store the license.

[0101] If the verification result is successful, it indicates that the license is trustworthy and the target function has been successfully activated. In this case, the license can be stored so that when a user needs to use the target function, the license can be used for verification. If the verification is successful, the target function will be provided. See below for details of this verification process.Figure 5 The illustrated embodiment will not be described in detail here. Exemplarily, the storage license is stored persistently.

[0102] Conversely, if the activation verification result is "verification failed," it indicates that the license is untrusted, and the activation response information may have been tampered with by an attacker during transmission. In this case, an activation failure message can be directly displayed to inform the user that the target function has failed to activate. Alternatively, a retry can be performed first. If the retry also fails, an activation failure message should be displayed. The retry process is implemented as follows: the client regenerates the activation request information and sends it to the server to allow the server to reactivate the target function and return a new activation response information. Accordingly, the client verifies the activation response information. If the verification passes, the license is stored; if the verification fails, it indicates that the retry has failed.

[0103] In this embodiment, on the one hand, by generating a first message authentication code on the device side, the server can verify the information, ensuring that the activation request information is not tampered with during transmission. Any tampering will cause the first message authentication code verification to fail, and the server will not return activation response information, thus ensuring the integrity and authenticity of the data. On the other hand, a first information body is generated using the device identifier and the anti-replay identifier, and the anti-replay identifier is verified on the server side. The anti-replay identifier is one-time use to ensure that each request is unique. This way, even if an attacker intercepts the activation request information, they cannot obtain a license later by replaying the request because the anti-replay identifier contained in the request is repeated and cannot pass the server's verification, thus effectively preventing replay attacks. Furthermore, since a symmetric key is used for... The generation and verification of the message authentication code are known only to the device and server sides. Attackers cannot forge valid activation request information, which enhances system security and prevents unauthorized activation of functions. Furthermore, this mechanism ensures that only legitimate user requests can successfully activate the target function, preventing malicious attackers from obtaining unauthorized function activation by stealing or tampering with data, thus protecting user privacy and data security. Therefore, this scheme, through multi-layered security measures (such as symmetric keys, message authentication codes, and anti-replay identifiers), effectively prevents data tampering and replay attacks, ensuring the security and integrity of data transmission, the reliability and stability of the system, and reducing the risk of function activation failure due to data tampering or attacks, thereby guaranteeing the secure activation of the target function.

[0104] The above Figure 2 The illustrated embodiment describes the function activation method provided by this application from the client's perspective. The following describes the function activation method provided by this application from the server's perspective.

[0105] Figure 3This is a flowchart illustrating a function activation method according to an exemplary embodiment. The function activation method provided in this application is executed by a function activation device, which is integrated into an electronic device, and the electronic device is provided as follows: Figure 1 Server 2 is shown. (Example) Figure 3 As shown, the function activation method provided in this embodiment includes the following steps:

[0106] Step S201: Receive the activation request information sent by the client for requesting to activate the target function; the activation request information includes a first information body and a corresponding first message authentication code; the first information body is generated by the client based on the device identifier and the anti-replay identifier.

[0107] See the implementation method for the client to generate and send activation request information. Figure 2 The embodiments shown are not described in detail here.

[0108] Step S202: Verify the first message authentication code based on the preset symmetric key to obtain the authentication code verification result.

[0109] The algorithm used for server-side verification corresponds to the algorithm used by the client to generate the first message authentication code. In one optional implementation, the HMAC algorithm is used to verify the first message authentication code. The client and server each have a pre-set symmetric key and hash function, which are identical between the communicating parties. Specifically, using the HMAC algorithm, a message authentication code corresponding to the first information body is generated based on the symmetric key and the first information body contained in the activation request information. This message authentication code is compared with the first message authentication code contained in the activation request information. If they are the same, the authentication code verification result is considered successful; otherwise, if they are different, the authentication code verification result is considered unsuccessful. The implementation method of using the HMAC algorithm to generate the message authentication code corresponding to the first information body based on the symmetric key and the first information body contained in the activation request information is described in step S102 and will not be repeated here.

[0110] In another alternative implementation, a symmetric encryption algorithm other than HMAC can be used to verify the first message authentication code. The specific verification method is the same as that using HMAC, and will not be repeated here. For example, the symmetric encryption algorithm can be Advanced Encryption Standard (AES), Blowfish (a symmetric encryption algorithm), etc.

[0111] If the authentication code verification passes, it indicates that the first information body in the activation request information is complete. Step S203 is then executed to further verify the anti-replay identifier. If the authentication code verification fails, it means that the first information body in the activation request information has likely been tampered with by an attacker during transmission. In this case, since the device identifier in the first information body may also have been tampered with, it is impossible to determine which is the real client. Therefore, no response can be made to prevent further theft by attackers.

[0112] Step S203: If the authentication code verification result is successful, the anti-replay identifier is verified to obtain the anti-replay verification result.

[0113] In one scenario, the anti-replay flag is a timestamp. After receiving the activation request, the server generates a receiving timestamp based on the current time. During verification, the request is judged based on the difference between the anti-replay flag and the receiving timestamp. If the difference is greater than a specified threshold, it indicates that a long time has passed between sending and receiving the activation request, and the first data packet may have been tampered with by an attacker during transmission; in this case, the anti-replay verification result is determined to be a failure. Conversely, if the difference is less than or equal to the specified threshold, it indicates that a short time has passed between sending and receiving the activation request, and in this case, the anti-replay verification result is determined to be a success. The threshold can be adjusted appropriately based on the interface's response speed, for example, a threshold of 30 seconds, 60 seconds, etc.

[0114] In another scenario, the anti-replay flag is a random number. During verification, the server checks if this random number exists in the cache set. If it does, the anti-replay verification result is considered failed; otherwise, if it doesn't exist, the random number is added to the cache set, and the anti-replay verification result is considered passed. The cache set stores the anti-replay flag carried in each activation request. It's worth noting that as the request volume increases, the number of random numbers in the cache set can become very large, consuming a significant amount of memory. Therefore, older data in the cache set can be periodically cleared to save memory.

[0115] In another scenario, the anti-replay flag includes a timestamp and a random number. If the difference between the timestamp and the received timestamp is less than or equal to a specified threshold and the random number is not present in the cache set, the anti-replay verification result is determined to be successful; conversely, if the difference between the timestamp and the received timestamp is greater than the specified threshold or the random number is present in the cache set, the anti-replay verification result is determined to be unsuccessful.

[0116] If the anti-replay verification passes, it means the first information body in the activation request information is trustworthy. In this case, step S204 is executed to generate a corresponding license for the client to activate the target function. If the anti-replay verification fails, it means the activation request information is likely a replayed message or the first information body in the activation request information may have been tampered with by an attacker during transmission. In this case, a verification failure response can be generated and returned to the client. Alternatively, since the device identifier in the first information body may also have been tampered with, it is impossible to know which client is the real one. Therefore, no response can be given to prevent theft by an attacker.

[0117] Step S204: If the anti-replay verification result is successful, generate a license corresponding to the client for the target function to enable the target function.

[0118] For example, the license includes data such as device identifier, anti-replay identifier and activation-related information of the target function in the activation request information. The activation-related information includes description information of the target function, activation validity period or number of valid uses.

[0119] Step S205: Generate activation response information and send the activation response information to the client; the activation response information includes the license.

[0120] For example, according to the communication protocol specifications agreed upon in advance between the client and the server, the license and other necessary data used to form the response body are combined into an activation response message. For example, other necessary data includes, but is not limited to, status codes, error messages, request identifiers, and server identifiers. Status codes indicate the result status of the request processing, such as success, failure, or other statuses. If the request processing fails, detailed error information is provided. The request identifier is used to uniquely identify the activation request message; it is a unique string or number sequence, usually generated by the client when sending the request and included in the activation request message, so that the client knows which activation request message the response message is made to. The server identifier is used to uniquely identify the server; for example, the server identifier can be a combination of an IP (Internet Protocol Address) address and port number, or it can be a custom identifier.

[0121] After receiving the activation response, the client executes steps S105-S106, as detailed below. Figure 2 The embodiments shown are not described in detail here.

[0122] On the one hand, by generating the first message authentication code on the device side and verifying it on the server side, it is ensured that the activation request information is not tampered with during transmission. Any tampering will cause the first message authentication code verification to fail, and the server will not return activation response information, thus ensuring the integrity and authenticity of the data. On the other hand, the first information body is generated using the device identifier and the anti-replay identifier, and the anti-replay identifier is verified on the server side. The anti-replay identifier is one-time use to ensure that each request is unique. This way, even if an attacker intercepts the activation request information, they cannot obtain a license later by replaying the request because the anti-replay identifier contained in the request is repeated and cannot pass the server's verification, thus effectively preventing replay attacks. Furthermore, since symmetric keys are used for message authentication... The generation and verification of the key are known only to the device and server sides, preventing attackers from forging valid activation request information. This enhances system security and prevents unauthorized activation of functions. Furthermore, this mechanism ensures that only legitimate user requests can successfully activate the target function, preventing malicious attackers from obtaining unauthorized function activation through data theft or tampering, thus protecting user privacy and data security. Therefore, this scheme, through multi-layered security measures (such as symmetric keys, message authentication codes, and anti-replay identifiers), effectively prevents data tampering and replay attacks, ensuring the security and integrity of data transmission, the reliability and stability of the system, and reducing the risk of function activation failure due to data tampering or attacks, thereby guaranteeing the secure activation of the target function.

[0123] The above Figure 2 as well as Figure 3 The embodiments shown illustrate the function activation method provided by this application from the perspectives of the client and the server. The following describes the function activation method provided by this application from the perspective of interaction between the two ends.

[0124] Figure 4 This is a flowchart illustrating a function activation method according to yet another exemplary embodiment, such as... Figure 4 As shown, the function activation method provided in this embodiment includes the following steps:

[0125] In step S301, the client responds to receiving the activation command for the target function and generates a first information body based on the device identifier and the anti-replay identifier.

[0126] In step S302, the client generates a first message authentication code corresponding to the first information body based on a preset symmetric key, and generates an activation request information based on the first message authentication code and the first information body.

[0127] Step S303: The client sends an activation request to the server.

[0128] Accordingly, the server receives the activation request information sent by the client.

[0129] In step S304, the server verifies the first message authentication code based on a preset symmetric key to obtain the authentication code verification result.

[0130] Step S305: If the authentication code verification result is successful, the server verifies the anti-replay flag to obtain the anti-replay verification result.

[0131] In step S306, if the anti-replay verification result is successful, the server generates a license corresponding to the client for the target function to enable the target function.

[0132] In this embodiment, the implementation method of steps S301-S303 is the same as... Figure 2 The implementation methods of steps S101-S103 in the illustrated embodiment are similar and will not be repeated here. The implementation methods of steps S304-S306 are the same as those in the illustrated embodiment. Figure 3 The implementation of steps S202-S204 in the illustrated embodiment is similar and will not be repeated here.

[0133] In one optional embodiment, the method for generating a license corresponding to the client for the target function includes: generating a license based on the device identifier, the anti-replay identifier, and the activation information corresponding to the target function; and signing the license using a private key.

[0134] For example, the device identifier, anti-replay identifier, and activation-related information corresponding to the target function in the activation request information are serialized to obtain license data. The license data is a data structure, usually a JSON object or other serialization format. The license is signed with a private key to ensure the integrity of the data and the trustworthiness of the source. The signature is added to the license data and serialized to obtain the final license.

[0135] By introducing a replay protection flag, replay attacks can be effectively prevented. This flag ensures that each license request is unique, preventing attackers from exploiting old license requests. Signing the license with a private key ensures its authenticity and integrity; only the authorized party with the corresponding private key can generate a valid signature, preventing license tampering or forgery. Using a device identifier ensures that the license is generated for a specific device, meaning it cannot be shared or copied between different devices, thus enhancing its uniqueness and security. Generating licenses based on activation information for the target function allows for customized authorization. A rigorous license generation and signing process prevents unauthorized devices or users from gaining access to the target function, helping to prevent its abuse or illegal use. In summary, this implementation, through multiple security measures and a flexible function authorization mechanism, not only improves system security and performance but also enhances user experience and system maintainability.

[0136] Step S307: The server generates activation response information.

[0137] Step S308: The server sends an activation response to the client; the activation response includes the license.

[0138] In this embodiment, the implementation method of steps S307-S308 is the same as... Figure 3 The implementation of step S205 in the illustrated embodiment is similar and will not be repeated here.

[0139] Accordingly, the client receives the activation response information sent by the server.

[0140] Step S309: The client verifies the license to obtain the activation verification result.

[0141] In one optional embodiment, the license includes a device identifier and a replay protection identifier; correspondingly, step S308 is implemented by steps S3091-S3093:

[0142] Step S3091: Use the public key to verify the license to obtain the license verification result.

[0143] The license is obtained by signing with a private key, and then verified using a public key. This signing and verification mechanism ensures the security and uniqueness of the license. There are two possibilities for the license verification result: verification successful or verification failed.

[0144] Step S3092: If the license verification result is successful, compare the device identifier in the license with the device identifier stored locally, and compare the anti-replay identifier in the license with the anti-replay identifier stored locally to obtain the first comparison result.

[0145] If the license verification result is successful, it indicates that the license's origin is credible, and the device identification and anti-replay markings in the license can then be further compared. Conversely, if the license verification result is unsuccessful, it indicates that the license's origin is unreliable, and the activation verification result is determined to be unsuccessful.

[0146] Step S3093: If the first comparison result indicates that the device identifier in the license is the same as the device identifier stored locally, and the anti-replay identifier in the license is the same as the anti-replay identifier stored locally, then the activation verification result is determined to be successful.

[0147] If the first comparison result shows that the device identifier and the anti-replay identifier are the same, it means that the data in the license is reliable, and the activation verification result is determined to be successful. Conversely, if the first comparison result shows that the device identifier in the license is different from the device identifier stored locally, or the anti-replay identifier in the license is different from the anti-replay identifier stored locally, it means that the data in the license is unreliable, and the activation verification result is determined to be unsuccessful.

[0148] Using a public key to verify the license ensures that it is signed by the legitimate private key holder, thus verifying its authenticity and integrity. Public key verification is an asymmetric encryption technique; only the corresponding private key can generate a valid signature that can be correctly decrypted by the public key, preventing license tampering or forgery. Comparing the anti-replay identifier effectively prevents replay attacks. A replay attack occurs when an attacker intercepts and repeatedly sends legitimate communication data packets. The anti-replay identifier ensures that each license request is unique, preventing attackers from using old license requests. Comparing the device identifier in the license with locally stored device identifiers ensures that the license is generated for a specific device. This means the license cannot be shared or copied between different devices, enhancing its uniqueness and security. This multi-layered verification process—public key verification, device identifier comparison, and anti-replay identifier comparison—prevents unauthorized devices or users from gaining access to system functions, helping to prevent abuse or illegal use of features. Through this multi-layered verification mechanism, users can be confident that their authorized functions are legitimate and secure. This not only improves user experience but also allows for rapid adjustments and releases of new features based on market demands. In summary, this implementation method, through a multi-factor authentication process involving public key verification, device identification comparison, and anti-replay identification comparison, not only improves the security and reliability of the system but also enhances its performance and user experience. The rigorous authentication mechanism effectively prevents unauthorized access and abuse, ensuring the rational allocation and use of system resources.

[0149] Step S310: If the activation verification result is successful, the client stores the license.

[0150] In this embodiment, the implementation method of step S310 is the same as... Figure 1 The implementation of step S106 in the illustrated embodiment is similar and will not be repeated here.

[0151] For example, Figure 5 This demonstrates a function activation process where a symmetric key (key) and a public key (public_key) are stored in the secure operating environment on the device side, and a symmetric key (key) and a private key (private_key) are stored on the server side.

[0152] The activation process for this feature includes:

[0153] 1. The client generates the first information body based on the device identifier and the anti-replay identifier;

[0154] 2. The client generates a first message authentication code (HMAC authentication code) based on the symmetric key and the first information body;

[0155] 3. The client generates an activation request (license request) based on the first information body and the first message authentication code;

[0156] 4. The activation request information passes through multiple intermediate network nodes ( Figure 5 Send two examples to the server;

[0157] 5. The server uses a symmetric key to verify the authentication code in the first message of the activation request information;

[0158] 6. If the server verifies the information, it will issue a license and sign it using its private key;

[0159] 7. The server issues the license, which is then sent to the client through multiple intermediate network nodes;

[0160] 8. The client uses a public key to verify the license signature. If the signature verification is successful, the device identifier and anti-replay identifier are used to further verify the license.

[0161] 9. If the verification passes, the license will be stored in the storage medium.

[0162] Based on the above embodiments, in practical applications, the client performs both local and cloud verification simultaneously when the target application starts or when the operating system on the client is powered on. Local verification refers to client-side verification, and cloud verification refers to server-side verification. The verification results are then used to determine whether the target function is currently authorized for use. The authorization verification process is described below.

[0163] Figure 6 This is a flowchart illustrating an authorization verification process according to an exemplary embodiment, such as... Figure 6 As shown, the process includes the following steps:

[0164] In step S401, the client responds to receiving the verification instruction for the target function and reads the stored license.

[0165] In one alternative embodiment, the client generates a verification command when the target application starts or when the operating system powers on, thereby enabling the target function to be quickly launched when the user needs to use it, without waiting for verification. Accordingly, the client responds to the verification command by reading the stored license.

[0166] In another alternative embodiment, the client generates verification instructions only when the user needs to use the target function. This reduces meaningless verification operations and saves resources. For example, the client displays a function control corresponding to the target function in the target application. If the user wants to use the target function, they can trigger the function control, thereby triggering the client to generate a verification instruction for that target function. For example, the function control can be a button or other style; this embodiment does not limit this.

[0167] In step S402, the client verifies the license to obtain the local verification result.

[0168] For example, step S402 is implemented by including the following steps S4021-S4023:

[0169] Step S4021: Verify the license using the public key to obtain the license verification result.

[0170] The implementation method of this step is the same as that of step S3081, and will not be repeated here.

[0171] If the license verification result is successful, it indicates that the source of the license is credible, and step S4022 is executed to further compare the equipment identification in the license. Conversely, if the license verification result is unsuccessful, it indicates that the source of the license is unreliable, and the local verification result is determined to be unsuccessful.

[0172] Step S4022: If the license verification result is successful, compare the device identifier in the license with the device identifier stored locally to obtain the local comparison result.

[0173] There are two possibilities for the local comparison results: one is that the device identifier in the license is the same as the device identifier stored locally, and the other is that the device identifier in the license is different from the device identifier stored locally.

[0174] If the local comparison result indicates that the device identifier in the license is the same as the device identifier stored locally, then step S4023 is executed to further verify the activation-related information in the license and obtain the information verification result. If the local comparison result indicates that the device identifier in the license is different from the device identifier stored locally, it means that the license may have been tampered with, and the local verification result is determined to be verification failure.

[0175] Step S4023: If the local comparison result indicates that the device identifier in the license is the same as the device identifier stored locally, the activation-related information in the license is verified to obtain the information verification result.

[0176] For example, the activation-related information includes the activation validity period. It is determined whether the current date and time are within the activation validity period. If they are within the activation validity period, it means that the information has not expired, and the information verification result is determined to be verification passed; otherwise, if the information is not within the activation validity period, it means that the information has expired, and the information verification result is determined to be verification failed.

[0177] Alternatively, the activation information includes the number of valid uses. It determines whether the number of times the target function has been used has reached the valid usage limit. If it hasn't, the verification result is considered passed; otherwise, if it has, the verification result is considered failed. The client records the number of times the target function has been used, and updates the usage count each time the target function is used to ensure accuracy.

[0178] Alternatively, the activation information includes the activation validity period and the number of valid uses. It determines whether the current date and time are within the activation validity period, and whether the number of uses of the target function has reached the valid usage limit. If the current date and time are within the activation validity period and the number of uses of the target function has not reached the valid usage limit, then the information verification result is determined to be verification passed; otherwise, if the current date and time are not within the activation validity period or the number of uses of the target function has reached the valid usage limit, then the information verification result is determined to be verification failed.

[0179] Step S4024: If the information verification result is successful, determine that the local verification result is successful.

[0180] If the information verification result is "verification passed", it means that the target function is currently usable, and the local verification result is determined to be "verification passed"; if the information verification result is "verification failed", it means that the target function is currently unusable, and the local verification result is determined to be "verification failed".

[0181] For example, Figure 7 A local verification process is shown, which includes:

[0182] 1. Read the license from the local persistent storage medium;

[0183] 2. Verify the license using the public key (public_key);

[0184] 3. If the verification passes, the device identifier and the activation validity period (time) are compared to obtain the local verification result.

[0185] In addition to local verification, the client also utilizes the server to perform cloud verification. It should be noted that the client can perform cloud verification using the server after local verification is complete, in which case step S403 is executed after step S402; alternatively, the client can perform cloud verification using the server simultaneously with local verification, in which case step S403 is executed after step S401. This embodiment does not limit this approach, and... Figure 6 An example is given by executing step S403 after step S401.

[0186] In step S403, the client generates a second information body based on the device identifier and license, generates a second message authentication code corresponding to the second information body based on the symmetric key, and generates verification request information based on the second message authentication code and the second information body.

[0187] In one optional embodiment, the method for generating the second information body based on the device identifier and license includes: generating the second information body based on the device identifier, a random number, and the license. The random number is randomly generated, and a different random number is used for each cloud verification. The generation method of the second information body is the same as that of the first information body, as detailed in step S101, and will not be repeated here. Through this implementation, a unique and secure second information body can be generated based on the device identifier, a random number, and the license for subsequent cloud verification.

[0188] The method for generating the second message authentication code is the same as that for generating the first message authentication code. The method for generating the verification request information is the same as that for generating the activation request information. For details, please refer to step S102, which will not be repeated here.

[0189] Step S404: The client sends a verification request to the server.

[0190] The verification request information is used to instruct the server to verify the second message authentication code in the verification request information based on the preset symmetric key and generate verification response information if the verification is successful.

[0191] Accordingly, the server receives the verification request information sent by the client. This verification request information includes a second information body and a corresponding second message authentication code; the second information body is generated by the client based on the device identifier and license.

[0192] In step S405, the server verifies the second message authentication code based on the symmetric key to obtain the authentication code verification result.

[0193] The implementation method of this step is the same as that of step S202, and will not be repeated here.

[0194] Step S406: If the authentication code verification result is successful, the server verifies the license to obtain the cloud verification result.

[0195] In one optional embodiment, the license verification to obtain the cloud verification result is implemented by steps S4061-S4063:

[0196] Step S4061: Verify the license using the public key to obtain the license verification result.

[0197] The implementation method of this step is the same as that of step S3081, and will not be repeated here.

[0198] Step S4062: If the license verification result is successful, compare the activation record information corresponding to the device identifier with the activation-related information in the license to obtain a third comparison result.

[0199] The server stores activation record information for each client, including activation information for each activated function. Accordingly, the server retrieves the client's activation information for the target function from the activation record information, compares this information with the activation information in the license, and obtains a third comparison result.

[0200] Step S4063: If the third comparison result indicates that the activation record information matches the activation-related information in the license, the cloud verification result is determined to be verified as passed.

[0201] If the third comparison result indicates that the activation record information matches the activation information in the license, then the license is genuine and valid, and the cloud verification result is determined to be verification passed; conversely, if the third comparison result indicates that the activation record information does not match the activation information in the license, then the license is invalid, and the cloud verification result is determined to be verification failed.

[0202] By using public keys to verify licenses, the authenticity and integrity of licenses are ensured. Only signed licenses can pass verification, effectively preventing license tampering or forgery. In addition to verifying the license signature, device identification and activation record information are also compared, further enhancing system security. This dual verification mechanism effectively prevents the use of unauthorized devices or licenses. By comparing device identification and activation record information, the binding relationship between the license and the device is ensured. This prevents license misuse or use on unauthorized devices, ensuring system reliability. Through multiple verification steps, the possibility of false positives is reduced, improving the accuracy and reliability of verification results.

[0203] Step S407: The server generates verification response information; the verification response information includes the cloud verification result.

[0204] Step S408: The server sends a verification response to the client.

[0205] The method for generating the verification response information is the same as the method for generating the activation response information. Please refer to step S204 for details, which will not be repeated here.

[0206] In one optional embodiment, the second information body further includes a random number; correspondingly, the method for generating the verification response information includes: generating a response information body based on the device identifier, the random number and the cloud verification result; generating a third message authentication code corresponding to the response information body based on the symmetric key, and generating the verification response information based on the third message authentication code and the response information body.

[0207] The method for generating the response information body is the same as the method for generating the request information body, which is also the first information body. See step S101 for details, which will not be repeated here.

[0208] The method for generating the third message authentication code is the same as that for generating the first message authentication code, and the method for generating the verification response information is the same as that for generating the activation request information. See step S102 for details, which will not be repeated here.

[0209] Accordingly, the client receives the verification response information sent by the server.

[0210] In step S409, the client determines the target verification result based on the local verification result and the cloud verification result.

[0211] In an optional embodiment, the verification response information further includes a third message authentication code; correspondingly, step S409 is implemented by steps S4091-S4092:

[0212] Step S4091: Verify the third message authentication code based on the symmetric key to obtain the authentication code verification result.

[0213] The implementation method of this step is the same as that of step S202, and will not be repeated here.

[0214] If the authentication code verification fails, it indicates that the response body in the verification response information may have been tampered with by an attacker during transmission. In this case, the cloud verification result is unreliable, and the local verification result is used to determine whether the target function is currently authorized: if the local verification result is successful, the target function is currently authorized and can be used directly when the user wants to use it; if the local verification result fails, the target function is currently unauthorized and the user will be prompted that the function cannot be used and needs to be reactivated when trying to use it.

[0215] Step S4092: If the authentication code verification result is successful, determine the target verification result based on the local verification result and the cloud verification result.

[0216] If the authentication code passes verification, it means that the response information body in the verification response is complete and authentic, and then it can be further determined whether the cloud verification result in the verification response is reliable.

[0217] Optionally, the method for determining the target verification result based on the local verification result and the cloud verification result includes: comparing the device identifier in the verification response information with the device identifier stored locally, and comparing the random number in the verification response information with the random number stored locally to obtain a second comparison result; if the second comparison result indicates that the device identifier in the verification response information is the same as the device identifier stored locally, and the random number in the verification response information is the same as the random number stored locally, then the target verification result is determined based on the local verification result and the cloud verification result.

[0218] If the second comparison result indicates that both the device identifier and the random number are the same, it means that the cloud verification result is reliable. Based on the local and cloud verification results, the target verification result is determined. Specifically, if both the local and cloud verification results are successful, or if the local and cloud verification results are inconsistent but the cloud verification result is successful, the target verification result is determined to be successful, and the user is currently authorized to use the target function. The user can then directly use the target function when desired. If the local and cloud verification results are inconsistent and the cloud verification result is unsuccessful, the target verification result is determined to be unsuccessful, and the user will be prompted that the function is unavailable and needs to be reactivated when attempting to use it.

[0219] If the second comparison result indicates that the device identifier or random number is different, it means that the cloud verification result is unreliable. In this case, the local verification result will be used to determine whether the target function is currently authorized. If the local verification result is successful, the target function is currently authorized and can be used directly when the user wants to use it. If the local verification result is unsuccessful, the target function is currently not authorized and the user will be prompted that the function cannot be used and needs to be reactivated when trying to use it.

[0220] This embodiment combines local and cloud-based verification to ensure the authenticity and integrity of the license. Even if local verification passes, cloud verification is still required, further enhancing system security. A symmetric key is used to generate a message authentication code, ensuring the integrity and authenticity of the verification request information and preventing data tampering during transmission. Sensitive information is protected through symmetric key encryption to prevent unauthorized access and data leakage. The multi-layered verification mechanism, combining local and cloud verification, reduces the possibility of false positives and improves the accuracy and reliability of verification results. Comparison of device identifiers and licenses ensures consistency between the device and license, preventing license abuse or use on unauthorized devices. The system has good scalability, allowing for the addition of new verification rules or support for more types of devices and licenses as needed. The cloud system is easy to update and maintain, enabling rapid response to security threats and vulnerabilities, and timely updates to verification algorithms and policies. The redundant verification mechanism, combining local and cloud verification, allows for reliance on the result of another verification if one fails, ensuring system continuity and reliability.

[0221] For example, Figure 8 This illustrates a cloud-based verification process. The cloud-based verification process includes:

[0222] 1. The client reads the stored license;

[0223] 2. The client generates a second information body based on the device identifier, a random number, and the license;

[0224] 3. The client generates a second message authentication code based on the symmetric key and the second information body;

[0225] 4. The client generates a verification request based on the second information body and the second message authentication code (HMAC authentication code);

[0226] 5. The verification request information passes through multiple intermediate network nodes ( Figure 5 Send two examples to the server;

[0227] 6. The server uses a symmetric key to verify the second information body in the verification request information;

[0228] 7. If the server verifies the information, it will use the stored public key to verify the license in the second information body.

[0229] 8. After the server-side verification is successful, the activation record information is compared with the activation-related information in the license to obtain the cloud verification result;

[0230] 9. The server generates a response information body based on the device identifier, random number, and cloud verification result;

[0231] 10. The server generates a third-party authentication code (HMAC) based on the symmetric key and the response message body;

[0232] 11. The server generates a verification response based on the response body and the third-party authentication code;

[0233] 12. Verification response information is sent to the client through multiple intermediate network nodes;

[0234] 13. The client uses a symmetric key to verify the third message authentication code;

[0235] 14. If the verification passes, the device identifier and the random number will be compared.

[0236] 15. If the comparison passes, the target verification result is determined by combining the local verification result and the cloud verification result.

[0237] Figure 9 This is a schematic diagram illustrating the structure of a function activation device according to an exemplary embodiment, such as... Figure 9 As shown, in this embodiment, the function activation device 50 can be installed in an electronic device, which serves as a client. The function activation device 50 includes:

[0238] The first generation module 501 is used to generate a first information body based on the device identifier and the anti-replay identifier in response to receiving an activation command for the target function;

[0239] The second generation module 502 is used to generate a first message authentication code corresponding to the first information body based on a preset symmetric key, and to generate an activation request information based on the first message authentication code and the first information body.

[0240] The sending module 503 is used to send an activation request information to the server. The activation request information is used to instruct the server to verify the first message authentication code in the activation request information based on a preset symmetric key. If the verification is successful, the server will verify the anti-replay flag in the activation request information and generate an activation response information if the verification is successful.

[0241] The receiving module 504 is used to receive the activation response information sent by the server; the activation response information includes the license corresponding to the target function.

[0242] The verification module 505 is used to verify the license in order to obtain the activation verification result;

[0243] Storage module 506 is used to store the license when the activation verification result is successful.

[0244] In some embodiments, the license includes a device identifier and an anti-replay identifier; the verification module 505 is specifically configured to: verify the license using a public key to obtain a license verification result; if the license verification result is successful, compare the device identifier in the license with the device identifier stored locally, and compare the anti-replay identifier in the license with the anti-replay identifier stored locally to obtain a first comparison result; if the first comparison result indicates that the device identifier in the license is the same as the device identifier stored locally, and the anti-replay identifier in the license is the same as the anti-replay identifier stored locally, determine that the activation verification result is successful.

[0245] In some embodiments, an authorization verification module is further included, configured to: in response to receiving a verification instruction for a target function, read the stored license; verify the license to obtain a local verification result; generate a second information body based on the device identifier and the license, and generate a second message authentication code corresponding to the second information body based on a symmetric key, and generate verification request information based on the second message authentication code and the second information body; send the verification request information to the server; the verification request information is used to instruct the server to verify the second message authentication code in the verification request information based on a preset symmetric key and generate verification response information if the verification passes; receive the verification response information sent by the server; the verification response information includes a cloud verification result; and determine the target verification result based on the local verification result and the cloud verification result.

[0246] In some embodiments, the verification response information further includes a third message authentication code; the authorization verification module is specifically used to: verify the third message authentication code based on the symmetric key to obtain the authentication code verification result; and if the authentication code verification result is successful, determine the target verification result based on the local verification result and the cloud verification result.

[0247] In some embodiments, the authorization verification module is specifically used to: generate a second information body based on the device identifier, a random number, and a license; the verification response information further includes the device identifier and a random number.

[0248] Based on the local verification result and the cloud verification result, the target verification result is determined, including: comparing the device identifier in the verification response information with the device identifier stored locally, and comparing the random number in the verification response information with the random number stored locally to obtain a second comparison result; if the second comparison result indicates that the device identifier in the verification response information is the same as the device identifier stored locally, and the random number in the verification response information is the same as the random number stored locally, then the target verification result is determined based on the local verification result and the cloud verification result.

[0249] The function activation device provided in this embodiment can execute the technical solution of the corresponding method embodiment. Its implementation principle and technical effect are similar to those of the corresponding method embodiment, and will not be described in detail here.

[0250] Figure 10 This is a schematic diagram of the structure of a function activation device according to another exemplary embodiment, such as... Figure 10 As shown, in this embodiment, the function activation device 60 can be installed in an electronic device, which serves as a server. The function activation device 60 includes:

[0251] The receiving module 601 is used to receive the activation request information sent by the client for requesting the activation of the target function; the activation request information includes a first information body and a corresponding first message authentication code; the first information body is generated by the client based on the device identifier and the anti-replay identifier;

[0252] The verification module 602 is used to verify the first message authentication code based on a preset symmetric key to obtain the authentication code verification result;

[0253] The verification module 602 is also used to verify the anti-replay identifier when the authentication code verification result is successful, so as to obtain the anti-replay verification result;

[0254] The activation module 603 is used to generate a license corresponding to the client for the target function in order to activate the target function if the anti-replay verification result is successful.

[0255] The sending module 604 is used to generate activation response information and send the activation response information to the client; the activation response information includes the license.

[0256] In some embodiments, the activation module 603 is specifically used to: generate a license based on the device identifier, the anti-replay identifier, and activation-related information corresponding to the target function; and sign the license using a private key.

[0257] In some embodiments, a cloud verification module is further included, configured to: receive verification request information sent by a client; the verification request information includes a second information body and a corresponding second message authentication code; the second information body is generated by the client based on the device identifier and the license; verify the second message authentication code based on a symmetric key to obtain an authentication code verification result; if the authentication code verification result is successful, verify the license to obtain a cloud verification result; generate verification response information and send the verification response information to the client; the verification response information includes the cloud verification result.

[0258] In some embodiments, the cloud verification module is specifically used to: verify the license using a public key to obtain a license verification result; if the license verification result is successful, compare the activation record information corresponding to the device identifier with the activation-related information in the license to obtain a third comparison result; if the third comparison result indicates that the activation record information matches the activation-related information in the license, determine that the cloud verification result is successful.

[0259] In some embodiments, the second information body further includes a random number; a cloud verification module is specifically used to: generate a response information body based on the device identifier, the random number and the cloud verification result; generate a third message authentication code corresponding to the response information body based on the symmetric key, and generate verification response information based on the third message authentication code and the response information body.

[0260] The function activation device provided in this embodiment can execute the technical solution of the corresponding method embodiment. Its implementation principle and technical effect are similar to those of the corresponding method embodiment, and will not be described in detail here.

[0261] This application also provides an electronic device. This electronic device can be provided as a client or a server.

[0262] Figure 11 This is a schematic diagram illustrating the structure of an electronic device according to an exemplary embodiment. For example... Figure 11 As shown, the electronic device 70 includes a processor 701 and a memory 702 communicatively connected to the processor 701.

[0263] The memory 702 stores computer-executable instructions; the processor 701 executes the computer-executable instructions stored in the memory 702 to implement the function activation method provided in this application.

[0264] In this embodiment, the memory 702 and the processor 701 are connected via a bus. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be categorized as an address bus, a data bus, a control bus, etc.

[0265] The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise as required.

[0266] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores computer-executable instructions that, when executed by a processor, are used to implement the function activation method provided in this application.

[0267] In an exemplary embodiment, a computer program product is also provided, including a computer program, which, when executed by a processor, is used to implement the function activation method provided in this application.

[0268] In an exemplary embodiment, a mobile platform is also provided, including an electronic device that can serve as a client, such as a vehicle domain controller, to implement the function activation method provided in this application. The mobile platform can be a vehicle, drone, mobile phone, computer, or other device.

[0269] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0270] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0271] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for activating a function, characterized in that, Applied to the client side, including: In response to receiving an activation command for the target function, a first information body is generated based on the device identifier and the anti-replay identifier; Based on a preset symmetric key, a first message authentication code corresponding to the first information body is generated, and an activation request message is generated based on the first message authentication code and the first information body. Send the activation request information to the server; the activation request information is used to instruct the server to verify the first message authentication code in the activation request information based on a preset symmetric key, and if the verification passes, to verify the anti-replay identifier in the activation request information, and if the verification passes, to generate activation response information. Receive activation response information sent by the server; the activation response information includes the license corresponding to the target function; The license is verified to obtain the activation verification result; If the activation verification result is successful, the license is stored.

2. The method according to claim 1, characterized in that, The license includes a device identifier and a replay protection identifier; the verification of the license to obtain an activation verification result includes: The license is verified using a public key to obtain the license verification result. If the license verification result is successful, the device identifier in the license is compared with the device identifier stored locally, and the anti-replay identifier in the license is compared with the anti-replay identifier stored locally to obtain a first comparison result; If the first comparison result indicates that the device identifier in the license is the same as the device identifier stored locally, and the anti-replay identifier in the license is the same as the anti-replay identifier stored locally, then the activation verification result is determined to be successful.

3. The method according to claim 1, characterized in that, Following the storage of the license, the following is also included: In response to receiving a verification command for the target function, the stored license is read; The license is verified to obtain a local verification result; A second information body is generated based on the device identifier and the license, and a second message authentication code corresponding to the second information body is generated based on the symmetric key. Verification request information is generated based on the second message authentication code and the second information body. The verification request information is sent to the server; the verification request information is used to instruct the server to verify the second message authentication code in the verification request information based on a preset symmetric key and generate verification response information if the verification is successful. Receive verification response information sent by the server; the verification response information includes the cloud verification result; Based on the local verification result and the cloud verification result, the target verification result is determined.

4. The method according to claim 3, characterized in that, The verification response information also includes a third message authentication code; determining the target verification result based on the local verification result and the cloud verification result includes: The third message authentication code is verified based on the symmetric key to obtain the authentication code verification result. If the verification code verification result is successful, the target verification result is determined based on the local verification result and the cloud verification result. And / or, The generation of the second information body based on the device identifier and the license includes: The second information body is generated based on the device identifier, the random number, and the license; the verification response information also includes the device identifier and the random number. The determination of the target verification result based on the local verification result and the cloud verification result includes: The device identifier in the verification response information is compared with the device identifier stored locally, and the random number in the verification response information is compared with the random number stored locally to obtain a second comparison result; If the second comparison result indicates that the device identifier in the verification response information is the same as the device identifier stored locally, and the random number in the verification response information is the same as the random number stored locally, then the target verification result is determined based on the local verification result and the cloud verification result.

5. A method for activating a function, characterized in that, Applied to the server side, including: The system receives an activation request from a client to request the activation of a target function; the activation request includes a first information body and a corresponding first message authentication code; the first information body is generated by the client based on a device identifier and an anti-replay identifier; The first message authentication code is verified based on a preset symmetric key to obtain the authentication code verification result; If the authentication code verification result is successful, the anti-replay identifier is verified to obtain the anti-replay verification result. If the anti-replay verification result is successful, a license corresponding to the client is generated for the target function to enable the target function; Generate activation response information and send the activation response information to the client; the activation response information includes the license.

6. The method according to claim 5, characterized in that, The process of generating the license corresponding to the client for the target function includes: The license is generated based on the device identifier, the anti-replay identifier, and the activation information corresponding to the target function; The license is signed using a private key.

7. The method according to claim 5, characterized in that, After sending the activation response information to the client, the method further includes: The system receives a verification request message sent by the client; the verification request message includes a second information body and a corresponding second message authentication code; the second information body is generated by the client based on the device identifier and the license. The second message authentication code is verified based on the symmetric key to obtain the authentication code verification result; If the authentication code verification result is successful, the license is verified to obtain the cloud verification result; Generate verification response information and send the verification response information to the client; the verification response information includes the cloud verification result.

8. The method according to claim 7, characterized in that, The process of verifying the license to obtain a cloud verification result includes: The license is verified using a public key to obtain the license verification result. If the license verification result is successful, the activation record information corresponding to the device identifier is compared with the activation-related information in the license to obtain a third comparison result; If the third comparison result indicates that the activation record information matches the activation-related information in the license, the cloud verification result is determined to be verification passed. And / or, The second information body also includes a random number; the generation of verification response information includes: A response information body is generated based on the device identifier, the random number, and the cloud verification result; Based on the symmetric key, a third message authentication code corresponding to the response information body is generated, and the verification response information is generated based on the third message authentication code and the response information body.

9. An electronic device, characterized in that, include: A processor and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the function activation method as described in any one of claims 1 to 4 or any one of claims 5 to 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the function activation method as described in any one of claims 1 to 4 or any one of claims 5 to 8.

Images