Locking method, terminal device and computer program product

Abstract

The embodiment of the invention discloses a locking method, terminal equipment and a computer program product, and belongs to the technical field of terminals. The method comprises the steps that n-tuple information is acquired, the n-tuple information at least comprises a device identifier and an authorization code, the authorization code is distributed by a locking server, both the device identifier and the authorization code have uniqueness, and n is larger than or equal to 2; sending a contract state query request containing n-tuple information; receiving a contract state query result sent by the locking server, wherein the contract state query result is obtained based on the n-tuple information; and under the condition that the contract state query result indicates that the n-tuple information does not pass verification, carrying out machine locking operation.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of terminal technology, and in particular to a locking method, a terminal device, and a computer program product. Background Art

[0002] For terminal devices purchased by installment payment, a locking client is usually installed in the terminal device. When the user violates the contract, the locking client will lock the terminal device to limit the available functions of the terminal device.

[0003] In the related art, the locking client implements the locking function based on the International Mobile Equipment Identity (IMEI) of the terminal device. Summary of the invention

[0004] The embodiments of the present application provide a method for locking a mobile phone, a terminal device and a computer program product. The technical solution is as follows:

[0005] On the one hand, an embodiment of the present application provides a method for locking a device, the method being executed by a terminal device, the method comprising:

[0006] Obtaining n-tuple information, wherein the n-tuple information includes at least a device identification and an authorization code, wherein the authorization code is assigned by the locking server, the device identification and the authorization code are both unique, and n is greater than or equal to 2;

[0007] Sending a contract status query request containing the n-tuple information;

[0008] receiving a contract status query result, wherein the contract status query result is obtained based on the n-tuple information;

[0009] When the contract status query result indicates that the n-tuple information has not passed the verification, the device is locked.

[0010] On the other hand, an embodiment of the present application provides a method for locking a device, the method being executed by a locking server, the method comprising:

[0011] Receive a contract status query request, the contract status query request includes n-tuple information, the n-tuple information includes at least a device identification and an authorization code, the authorization code is assigned by the lock server, the device identification and the authorization code are both unique, and n is greater than or equal to 2;

[0012] Determine a contract status query result based on the n-tuple information;

[0013] The contract status query result is sent, wherein when the contract status query result indicates that the n-tuple information has not passed the verification, the terminal device performs a locking operation.

[0014] On the other hand, an embodiment of the present application provides a locking device, the device comprising:

[0015] An acquisition module, used for acquiring n-tuple information, wherein the n-tuple information includes at least a device identification and an authorization code, wherein the authorization code is assigned by a locking server, and both the device identification and the authorization code are unique, and n is greater than or equal to 2;

[0016] A sending module, used for sending a contract status query request containing the n-tuple information;

[0017] A receiving module, used to receive a contract status query result, wherein the contract status query result is obtained based on the n-tuple information;

[0018] The locking module is used to lock the device when the contract status query result indicates that the n-tuple information has not passed the verification.

[0019] On the other hand, an embodiment of the present application provides a locking device, the device comprising:

[0020] A receiving module, used to receive a sent contract status query request, wherein the contract status query request includes n-tuple information, wherein the n-tuple information includes at least a device identification and an authorization code, wherein the authorization code is assigned by a locking server, and both the device identification and the authorization code are unique, and n is greater than or equal to 2;

[0021] A processing module, used to determine a contract status query result based on the n-tuple information;

[0022] A sending module is used to send the contract status query result, wherein when the contract status query result indicates that the n-tuple information has not passed the verification, the terminal device performs a locking operation.

[0023] On the other hand, an embodiment of the present application provides a terminal device, which includes a processor and a memory, wherein the memory stores at least one computer instruction, and the at least one computer instruction is loaded and executed by the processor to implement the locking method as described in the above aspects.

[0024] On the other hand, an embodiment of the present application provides a server, which includes a processor and a memory, wherein the memory stores at least one computer instruction, and the at least one computer instruction is loaded and executed by the processor to implement the locking method as described in the above aspect.

[0025] On the other hand, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores at least one computer instruction, and the at least one computer instruction is used to be executed by a processor to implement the locking method as described in the above aspects.

[0026] On the other hand, an embodiment of the present application provides a computer program product, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; a processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the locking method described in the above aspects.

[0027] In the embodiment of the present application, when the terminal device requests to obtain the contract status, the request sent contains n-tuple information, which contains not only the device identification of the terminal device itself, but also the authorization code assigned by the locking server, so that when the contract status is subsequently queried based on the n-tuple information, it can be determined whether the terminal device has been tampered with and cracked by verifying the n-tuple information, and then instruct the terminal device to perform a locking operation when the n-tuple information fails to pass the verification. Compared with the related art that only implements the locking function based on IMEI, the locking can be circumvented by tampering with the IMEI of the terminal device. Since the n-tuple information integrates the device identification of the terminal device itself and the authorization code assigned by the server, the tampering behavior of the device identification can be identified based on the authorization code, and then the locking operation is performed for the tampering behavior, which improves the availability of the locking function and the security of the contract. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a system architecture diagram of a computer system shown in an exemplary embodiment of the present application;

[0029] Figure 2 A flowchart of a locking method provided by an exemplary embodiment of the present application is shown;

[0030] Figure 3 It is a schematic diagram of an implementation of a sub-information partition encryption storage process shown in an exemplary embodiment of the present application;

[0031] Figure 4 is a flowchart of an authorization code acquisition storage process shown in an exemplary embodiment of the present application;

[0032] Figure 5 It is a schematic diagram of an implementation of a text message content generation process shown in an exemplary embodiment of the present application;

[0033] Figure 6 is a flowchart of an authorization code acquisition process shown in an exemplary embodiment of the present application;

[0034] Figure 7is a flowchart of a process of generating and sending a text message by a terminal device, shown in an exemplary embodiment of the present application;

[0035] Figure 8 is a flowchart of a process of allocating authorization codes by a lock server, shown in an exemplary embodiment of the present application;

[0036] Fig. 9 is a schematic diagram of an implementation of a device sub-information decryption process shown in an exemplary embodiment of the present application;

[0037] Fig.10 is a flowchart of a process for determining a contract status query result shown in an exemplary embodiment of the present application;

[0038] Fig.11 It is a schematic diagram of prompt information displayed by a terminal device under different reasons for failure of verification, shown in an exemplary embodiment of the present application;

[0039] Fig.12 is a timing diagram of a contract creation and status query process shown in an exemplary embodiment of the present application;

[0040] Fig.13 A structural block diagram of a locking device provided by an exemplary embodiment of the present application is shown;

[0041] Fig.14 A structural block diagram of a locking device provided by another exemplary embodiment of the present application is shown;

[0042] Fig.15 A structural block diagram of a computer device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0043] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0044] The term "multiple" as used herein refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0045] Please refer to Figure 1 , which shows an architecture diagram of a computer system provided by an exemplary embodiment of the present application. The computer system includes a terminal device 110 and a locking server 120.

[0046] The terminal device 110 is an electronic device installed with a locking client 111. The locking client 111 is used to detect the contract status, and when the contract status is detected to be in breach, the terminal device 110 is locked. In some embodiments, the locking client 111 cannot be manually uninstalled by the user.

[0047] The electronic device may be a smart phone, a tablet computer, a smart wearable device, or other device with a network access function, which is not limited in the embodiments of the present application.

[0048] The terminal device 110 is connected to the locking server 120 via a wired network or a wireless network.

[0049] The locking server 120 is a server with a contract status query function. In some embodiments, the locking server 120 is a backend server of the locking client 111.

[0050] When the locking client 111 has a contract status query requirement, it sends a contract status query request to the locking server 120. The locking server 120 feeds back the contract status query result to the locking client 111 according to the contract status query request for subsequent processing by the locking client 111.

[0051] In the related art, the contract of the terminal device in the locking server is bound to the IMEI of the terminal device. When the locking client queries the contract status, it sends a contract status query request containing the IMEI to the locking server, and the locking server queries the corresponding contract according to the IMEI and feeds back the contract status to the locking client.

[0052] However, the lock can be circumvented by tampering with the IMEI of the terminal device. For example, after the IMEI of the terminal device that has not fulfilled the contract is tampered with to the IMEI of the terminal that has fulfilled the contract, the lock client sends a contract status query request containing the IMEI to the lock server. The lock server obtains the contract status of fulfillment based on the IMEI. Correspondingly, the lock client will not lock the terminal device based on the contract status query result fed back by the lock server.

[0053] In an embodiment of the present application, during the contract creation phase, the locking server 120 assigns a unique authorization code to the terminal device 110. When the contract status is subsequently queried, the locking client 111 sends an n-tuple of information including a device identifier and an authorization code to the locking server 120. By verifying the n-tuple information, the locking server 120 can determine whether the terminal device 110 has been tampered with, and inform the verification result of the n-tuple information through the contract status query result. In the case where it is determined to have been tampered with based on the contract status query result (i.e., the n-tuple information has not passed the verification), the locking client 111 can lock the terminal device 110.

[0054] With the help of the information provided by the client and the server (device identification and authorization code respectively), criminals cannot circumvent the lock by tampering with the IMEI of the terminal device (the tampered device identification does not match the authorization code and cannot pass the verification), which improves the availability of the lock function and the security of the contract.

[0055] Please refer to Figure 2 , which shows a flowchart of a locking method provided by an exemplary embodiment of the present application. This embodiment uses the method for Figure 1 Taking the terminal device 110 and the locking server 120 as an example, the method may include the following steps:

[0056] Step 201: The terminal device obtains n-tuple information, which includes at least a device identification and an authorization code. The authorization code is allocated by the locking server. Both the device identification and the authorization code are unique, and n is greater than or equal to 2.

[0057] Optionally, when the contract status acquisition condition is met, the terminal device acquires the n-tuple information. The contract status acquisition condition may be a timing condition, such as acquiring the contract status once a day, acquiring the contract status at the beginning of each month, or the contract status acquisition condition may be a terminal status condition, such as acquiring the contract status when the terminal is turned on. The embodiment of the present application does not limit the specific contract status acquisition condition.

[0058] In a possible implementation, a locking client is installed and running on the terminal device, and when a contract status acquisition condition is met, the locking client acquires n-tuple information.

[0059] In some embodiments, the device identifier is a unique identifier configured when the terminal device leaves the factory, for example, the device identifier is the IMEI of the terminal device.

[0060] Since the device identification of the terminal device may be illegally tampered with to avoid being locked in case of breach of contract, in order to improve the availability of the locking function, in the embodiment of the present application, the locking server allocates a unique authorization code to the terminal device. The terminal device needs to query the contract status from the locking server based on the n-tuple information consisting of the device identification and the authorization code.

[0061] Optionally, the authorization code is assigned by the lock server during the contract creation phase.

[0062] In some embodiments, when the n-tuple information includes three or more sub-information items, the sub-information other than the device identification and the authorization code is the component identification of the component in the terminal device.

[0063] Optionally, the component is a component in the terminal device that is not easily replaced. For example, the component identifier can be a MAC (Media Access Control) address of a network card in the terminal device, a Bluetooth address of a Bluetooth component, etc., which is not limited in the embodiments of the present application.

[0064] Illustratively, the n-tuple information is (IMEI, MAC address, authorization code).

[0065] In some embodiments, each sub-information item in the n-tuple information obtained by the terminal device is ciphertext information, that is, each sub-information item is encrypted.

[0066] Step 202: The terminal device sends a contract status query request containing n-tuple information.

[0067] In some embodiments, the terminal device sends a contract status query request to the locking server.

[0068] In a possible implementation, in order to ensure the security of the request, the n-tuple information is encrypted. It should be noted that if the acquired n-tuple information has been encrypted, the terminal device further encrypts the encrypted n-tuple information.

[0069] Step 203: The locking server receives a contract status query request.

[0070] In some embodiments, the locking server receives a contract status query request sent by the terminal device.

[0071] After receiving the contract status request, the locking server obtains the n-tuple information carried in the request.

[0072] In some embodiments, when the n-tuple information in the request is transmitted after being encrypted, the locking server first decrypts the n-tuple information.

[0073] Step 204, the locking server determines the contract status query result based on the n-tuple information.

[0074] In some embodiments, the contract of the terminal device in the locking server is bound to the n-tuple information of the terminal device. The n-tuple information stored in the locking server can be referred to as the server-side n-tuple information, which is generated based on the device identification and the authorization code (or other sub-information) of the terminal device after the authorization code is assigned to the terminal device during the contract creation phase.

[0075] Correspondingly, the n-tuple information provided by the terminal device can be referred to as the client n-tuple information. Unlike the server n-tuple information which cannot be tampered with at will, the client n-tuple information has the risk of being tampered with.

[0076] In a possible implementation, before the locking server performs a contract status query on the n-tuple information, the n-tuple information is first verified. The verification process is used to determine whether the terminal device has been tampered with.

[0077] Among them, when the n-tuple information fails to pass the verification, the locking server determines that the terminal device has been tampered with; when the n-tuple information passes the verification, the locking server determines that the terminal device has not been tampered with.

[0078] In a possible implementation, the locking server verifies the client n-tuple information based on the server n-tuple information. The verification process of the n-tuple information will be described in detail in the following embodiments.

[0079] In some embodiments, when the n-tuple information is encrypted, the locking server needs to decrypt each sub-information in the n-tuple information, and then perform verification based on the decrypted n-tuple information.

[0080] Optionally, the contract status query result includes an n-tuple information verification result.

[0081] Optionally, when the n-tuple information verification result indicates that the n-tuple information has passed the verification, the contract status query result also includes the current contract status.

[0082] In a possible implementation, the current contract status is obtained based on a verified n-tuple information query.

[0083] Step 205: The locking server sends the contract status query result.

[0084] In some embodiments, the locking server sends the contract status query result to the terminal device.

[0085] Optionally, when the n-tuple information passes the verification, the contract status query result sent by the locking server includes the n-tuple information verification result (indicating that the verification passed) and the current contract status; when the n-tuple information fails the verification, the contract status query result sent by the locking server includes the n-tuple information verification result (indicating that the verification failed).

[0086] Step 206: The terminal device receives the contract status query result.

[0087] In some embodiments, the terminal device receives a contract status query result sent by the locking server, and the contract status query result is obtained based on n-tuple information.

[0088] Step 207: When the contract status query result indicates that the n-tuple information has not passed the verification, the terminal device performs a locking operation.

[0089] In a possible implementation, when the contract status query result includes an n-tuple information verification result and the n-tuple information verification result indicates that the n-tuple information has failed the verification, it indicates that the terminal device has been tampered with, and the locking client locks the terminal device.

[0090] Optionally, the functions of the terminal device are restricted after the locking operation. For example, after the locking operation, the terminal device can only answer or dial numbers in the whitelist (such as emergency call numbers).

[0091] In some embodiments, when the terminal device is locked, a lock prompt will be displayed to inform the user how to unlock the device.

[0092] It should be noted that, when the contract status query result indicates that the n-tuple information has passed the verification, the terminal device further determines what operation to perform based on the current contract status indicated by the contract status query result.

[0093] Optionally, when the current contract status is that the current installment has been fulfilled, the terminal device will not lock the device to ensure normal use of the function. When the current contract status is that the current installment has not been fulfilled, the terminal device locks the device and prompts the user to fulfill the contract to unlock it.

[0094] In summary, in the embodiment of the present application, when the terminal device requests to obtain the contract status, the request sent contains n-tuple information, which contains not only the device identification of the terminal device itself, but also the authorization code assigned by the locking server, so that when the contract status is subsequently queried based on the n-tuple information, it can be determined whether the terminal device has been tampered with and cracked by verifying the n-tuple information, and then instruct the terminal device to perform a locking operation when the n-tuple information fails to pass the verification. Compared with the related art that only implements the locking function based on IMEI, the locking can be circumvented by tampering with the IMEI of the terminal device. Since the n-tuple information integrates the device identification of the terminal device itself and the authorization code assigned by the server, the tampering behavior of the device identification can be identified based on the authorization code, and then the locking operation is performed for the tampering behavior, which improves the availability of the locking function and the security of the contract.

[0095] Sub-information partition storage in n-tuple information

[0096] Usually, criminals tamper with the data of mobile devices by intercepting APIs (Application Programming Interface). For example, by intercepting the underlying API for obtaining IMEI, the locking client obtains the tampered IMEI, and then uses the tampered IMEI to query the contract status, thereby avoiding locking caused by breach of contract.

[0097] In order to increase the difficulty of tampering with the terminal device data, the lock client does not use the API call method to obtain the n-tuple information, but obtains the n-tuple information from the local storage to avoid API interception. In addition, in order to further increase the difficulty of breaking, the sub-information in the n-tuple information is stored in different storage partitions in the local storage.

[0098] Since terminal device data tampering usually occurs after non-first startup, in order to ensure the reliability of locally stored sub-information, in one possible implementation, for the device sub-information in the n-tuple information, that is, the sub-information other than the authorization code in the n-tuple information, when the device is started for the first time, the terminal device obtains the device sub-information by calling an interface, thereby encrypting the device sub-information and storing it in local storage.

[0099] In some embodiments, when the terminal device is powered on, the installed lock client starts automatically. When the lock client starts for the first time, the device sub-information is obtained by calling the underlying interface.

[0100] The device sub-information at least includes a device identifier, such as IMEI. Optionally, the device sub-information may further include component identifiers of other components in the terminal device, such as a MAC address of a network card, a Bluetooth address of a Bluetooth component, and the like.

[0101] In some embodiments, the terminal device encrypts each item of sub-information in the device sub-information separately, and stores the encrypted sub-information in different storage partitions of the local storage.

[0102] Optionally, the terminal device uses a public key to encrypt the sub-information, and the private key paired with the public key is stored in the lock server, thereby improving the security of the encrypted sub-information and reducing the probability of being cracked.

[0103] In an illustrative example, when the device is turned on for the first time, the locking client obtains the IMEI and MAC address of the terminal device by calling the underlying interface for obtaining the IMEI and the underlying interface for obtaining the MAC address, and encrypts the IMEI using the first public key and the MAC address using the second public key. The encrypted IMEI is stored in the first storage partition, and the encrypted MAC address is stored in the second storage partition.

[0104] Sub-information is split and stored in encrypted partitions

[0105] In order to further improve the security of locally stored device sub-information, in a possible implementation, for any item of device sub-information, the terminal device splits the sub-information to obtain multiple sub-information fragments, and encrypts and stores the multiple sub-information fragments in different storage partitions of the local storage.

[0106] Optionally, the terminal device splits the sub-information into at least two sub-information segments, and the number of sub-information segments into which different sub-information in the device sub-information is split can be the same or different. It should be noted that the terminal device splits the sub-information in a manner pre-agreed with the locking server to ensure that the locking server can subsequently correctly decrypt and restore each sub-information.

[0107] Optionally, different sub-information fragments are encrypted with different keys, which further increases the difficulty of completely cracking the encrypted sub-information and improves the security of the locally stored device sub-information.

[0108] In some embodiments, the sub-information segment is encrypted using a public key, and the private key corresponding to the public key is stored in the lock server. Even if the encrypted sub-information segment in the local storage is extracted, the plaintext sub-information segment cannot be decrypted.

[0109] It should be noted that the terminal device encrypts the sub-information fragment based on the correspondence between the sub-information fragment and the public key used for encryption. The lock machine server is also aware of the correspondence so that it can subsequently use the private key corresponding to the public key to decrypt the encrypted sub-information fragment to ensure that the sub-information fragment can be correctly decrypted.

[0110] In an illustrative example, Figure 3 As shown, when the terminal device is turned on for the first time, the locking client obtains the IMEI and MAC address of the terminal device through an interface call. The locking client divides the IMEI in half to obtain the first IMEI fragment and the second IMEI fragment, and divides the MAC address in half to obtain the first MAC address fragment and the second MAC address fragment. Furthermore, the locking client encrypts the first IMEI fragment using the first public key, and stores the encrypted ciphertext of the first IMEI fragment in the first storage partition of local storage; encrypts the second IMEI fragment using the second public key, and stores the encrypted ciphertext of the second IMEI fragment in the second storage partition of local storage; encrypts the first MAC address fragment using the third public key, and stores the encrypted ciphertext of the first MAC address fragment in the first storage partition of local storage; encrypts the second MAC address fragment using the fourth public key, and stores the encrypted ciphertext of the second MAC address fragment in the second storage partition of local storage.

[0111] In this embodiment, when the terminal device is powered on for the first time, the device sub-information in the n-tuple information is obtained and encrypted and stored in the local storage by means of an interface call, thereby ensuring the reliability of the locally stored device sub-information; and, when the contract status is subsequently queried, the device sub-information is directly read from the local storage, thereby avoiding the interface interception problem and improving the reliability of the device sub-information in the sent n-tuple information.

[0112] In addition, each item of sub-information in the device sub-information is split and encrypted and stored in different storage partitions of local storage, which further increases the difficulty of illegally obtaining the device sub-information and the threshold for cracking and modifying it after obtaining it, thereby improving the security of the locally stored device sub-information.

[0113] Get the authorization code

[0114] In the above embodiment, the terminal device completes the local storage of the device sub-information after the first power-on. In the subsequent contract creation process, the terminal device can request the lock server to allocate an authorization code based on the device sub-information stored this time.

[0115] Please refer to Figure 4 , which shows a flowchart of the authorization code acquisition process provided by an exemplary embodiment of the present application. This embodiment uses this method for Figure 1 Taking the terminal device 110 as an example, the method may include the following steps:

[0116] Step 401, obtaining device sub-information from local storage, where the device sub-information is the sub-information other than the authorization code in the n-tuple information.

[0117] In some embodiments, in response to the contract creation instruction, the terminal device obtains the device sub-information from the local storage.

[0118] Optionally, the contract creation instruction is triggered by a contract client installed in the terminal device, indicating that a contract needs to be created for the current terminal device. The contract may be a contract for purchasing the terminal device by installment payment.

[0119] In this embodiment, since reliable device sub-information is stored in the local storage, when the locking client receives the contract creation instruction, it does not obtain the device sub-information by interface call, but directly extracts the device sub-information from the local storage.

[0120] In some embodiments, when the sub-information in the device sub-information is stored in different storage partitions, the lock client obtains each sub-information of the device sub-information from the different storage partitions stored locally.

[0121] In some embodiments, when the sub-information in the device sub-information is divided into sub-information fragments and encrypted and stored in different storage partitions, the lock client obtains the encrypted sub-information fragments from different storage partitions of local storage, and the encrypted sub-information fragments are obtained by dividing and encrypting the sub-information in the device sub-information.

[0122] It should be noted that when the sub-information (or sub-information fragment) in the device sub-information is encrypted and stored locally, the sub-information (or sub-information fragment) obtained by the lock client is all ciphertext information, and the lock client will not decrypt it, that is, the obtained sub-information (or sub-information fragment) will be kept in the ciphertext state.

[0123] In an illustrative example, Figure 3 On the basis of Figure 5 As shown, when the device sub-information includes IMEI and MAC address, the locking client obtains the first IMEI fragment ciphertext and the first MAC address fragment ciphertext from the first storage partition stored locally, and obtains the second IMEI fragment ciphertext and the second MAC address fragment ciphertext from the second storage partition stored locally.

[0124] Step 402: Obtain an authorization code based on the device sub-information.

[0125] In some embodiments, the terminal device obtains an authorization code from the locking server based on the device sub-information.

[0126] In some embodiments, after the terminal device obtains the encrypted sub-information fragments from different storage partitions stored locally (the encrypted sub-information fragments are obtained by dividing and encrypting the sub-information in the device sub-information), the encrypted sub-information fragments corresponding to the same sub-information in the device sub-information are merged to obtain the encrypted sub-information, and the encrypted sub-information is concatenated based on the target format to obtain the encrypted device sub-information, thereby obtaining the authorization code based on the encrypted device sub-information. The target format is the format agreed upon with the lock server.

[0127] In a possible implementation, the terminal device sends an authorization code acquisition request to the locking server based on the encrypted device sub-information obtained, requesting the locking server to allocate and feedback the authorization code based on the device sub-information.

[0128] When a single channel is used to transmit key data between the terminal device and the lock server, the risk of the key data being consistently cracked is high. Therefore, in order to reduce the risk of the key data being consistently cracked and improve the security of the key data, in another possible implementation, the terminal device requests the allocation of an authorization code and the terminal device requests the issuance of an authorization code using different channels.

[0129] Since the SMS channel has higher reliability and security than the network channel, in some embodiments, the terminal device can request allocation of an authorization code through the SMS channel and request issuance of the authorization code through the network channel.

[0130] Optionally, the process of the terminal device obtaining the authorization code based on the device sub-information is as follows Figure 6 shown.

[0131] Step 601: The terminal device sends a text message containing device sub-information.

[0132] Optionally, the terminal device generates a text message based on the acquired device sub-information, and sends the text message to the SMS service provider.

[0133] In some embodiments, when the sub-information in the device sub-information is split and encrypted and stored in different storage partitions of the local storage, the terminal device will obtain the ciphertext sub-information fragments corresponding to the different sub-information instead of the plaintext sub-information. Figure 7 As shown, the terminal device sending a text message based on the ciphertext sub-information fragment may include the following steps:

[0134] Step 601A, merging the encrypted sub-information fragments corresponding to the same sub-information in the device sub-information to obtain the encrypted sub-information.

[0135] For each encrypted sub-information fragment obtained, the locking client merges the encrypted sub-information fragments corresponding to the same sub-information to obtain the encrypted sub-information corresponding to each sub-information in the device sub-information.

[0136] Optionally, the locking client merges the encrypted sub-information fragments based on the positional relationship of the sub-information fragments in the sub-information to obtain the encrypted sub-information. For example, when the sub-information is divided into two halves, the locking client merges the encrypted sub-information fragments corresponding to the second half of the sub-information fragments with the encrypted sub-information fragments corresponding to the first half of the sub-information fragments to obtain the encrypted sub-information.

[0137] Indicatively, Figure 5 As shown, the locking client merges the second IMEI fragment ciphertext into the first IMEI fragment ciphertext to obtain the IMEI ciphertext; and merges the second MAC address fragment ciphertext into the first MAC address fragment ciphertext to obtain the MAC address ciphertext.

[0138] Step 601B, based on the target format, concatenate the encrypted sub-information to obtain the encrypted device sub-information, and the target format is the format agreed upon with the lock server.

[0139] In order to further increase the difficulty of decrypting the data in the SMS, in a possible implementation, the terminal device concatenates the encrypted sub-information in a target format to obtain the encrypted device sub-information (i.e., the device sub-information ciphertext). The target format is a concatenation format agreed upon in advance with the lock server (e.g., pre-set when the terminal device leaves the factory), that is, the lock server can only perform correct decryption based on the target format.

[0140] In some embodiments, the target format is used to indicate the serial connection order of different encrypted sub-information. Accordingly, the terminal device serially connects the different encrypted sub-information based on the serial connection order indicated by the target format.

[0141] In a possible implementation manner, when the device sub-information includes m items of sub-information, the target format is expressed as (first sub-information, ..., mth sub-information), where m is an integer greater than or equal to 2.

[0142] Illustratively, when the device sub-information includes IMEI and MAC address, and the target format is (MAC address, IMEI), the locking client concatenates the MAC address ciphertext and the IMEI ciphertext based on the target format to obtain the device sub-information ciphertext.

[0143] Step 601C, sending a text message containing encrypted device sub-information.

[0144] In a possible implementation, after obtaining the encrypted device sub-information, the terminal device may further perform secondary encryption on the encrypted device sub-information to further improve information security.

[0145] Optionally, the terminal device encodes the encrypted device sub-information (for example, using base64 encoding), and uses the encoded data as the SMS content to send the SMS to the SMS service provider.

[0146] Of course, in addition to the above method of combining the encrypted sub-information fragments first and then concatenating the encrypted sub-information, in another possible implementation, the lock client can directly concatenate the encrypted sub-information fragments based on the target concatenation format of the sub-information fragments. Since the number of encrypted sub-information fragments is larger, this concatenation method can further increase the difficulty of cracking.

[0147] Indicatively, after obtaining Figure 5 After the fragment ciphertext shown, the locking client can concatenate the second MAC address fragment ciphertext, the first IMEI fragment ciphertext, the first MAC address fragment ciphertext and the second IMEI fragment ciphertext in sequence based on the target concatenation format.

[0148] Step 602: The locking server synchronizes SMS messages from the SMS service provider.

[0149] In a possible implementation, after receiving the text message sent by the terminal device, the text message service provider synchronizes the text message to the lock server based on a pre-selected synchronization strategy.

[0150] Step 603: The locking server allocates an authorization code based on the device sub-information, and generates server-side n-tuple information based on the device sub-information and the authorization code.

[0151] In some embodiments, the locking server assigns a unique authorization code based on the device sub-information contained in the SMS, and generates a server n-tuple consisting of the device sub-information and the authorization code. Since the reliability of the server n-tuple is higher than that of the client n-tuple, the server n-tuple will be used to verify the client n-tuple later.

[0152] In some embodiments, since the device sub-information contained in the text message is encrypted information, the locking server candidate needs to decrypt the encrypted device sub-information to obtain the plaintext device sub-information in order to construct an n-tuple information based on the plaintext device sub-information and the authorization code.

[0153] In some embodiments, when the text message contains encrypted sub-information concatenated in the target format, such as Figure 8 As shown, the process of the locking server decrypting the device sub-information and allocating the authorization code may include the following steps:

[0154] Step 603A, extract the encrypted device sub-information in the SMS.

[0155] Indicatively, Fig. 9 As shown, the locking server extracts the encrypted device sub-information from the text message, and the encrypted device sub-information includes the encrypted MAC address and the encrypted IMEI.

[0156] It should be noted that when the SMS content is encrypted or encoded twice, the locking server needs to first decrypt or decode the SMS content, which is not elaborated in this embodiment.

[0157] Step 603B, extracting the encrypted sub-information from the encrypted device sub-information based on the target format, the target format is the format agreed upon with the terminal device, and the encrypted sub-information is obtained by merging the encrypted sub-information fragments corresponding to the same sub-information.

[0158] The locking server provides each encrypted sub-information based on the target format agreed with the terminal device. At this time, although the extracted sub-information is still in ciphertext, the locking server can determine the type of the sub-information based on the target format.

[0159] Indicatively, Fig. 9 As shown, when the target format is (MAC address, IMEI), the locking server determines that the first part of the encrypted sub-information extracted is the ciphertext MAC address, and determines that the second part of the encrypted sub-information extracted is the ciphertext IMEI.

[0160] Step 603C: when the encrypted sub-information is correctly decrypted, an authorization code is allocated based on the decrypted device sub-information.

[0161] In a possible implementation, the sub-information (or sub-information fragment) in the device sub-information is encrypted with a public key, and the corresponding private key is stored in the lock server. For the extracted encrypted sub-information, the lock server obtains the private key corresponding to the sub-information type according to the sub-information type of the encrypted sub-information, and then uses the private key to decrypt it.

[0162] In some embodiments, when different sub-information fragments in the sub-information are encrypted using different public keys, the lock server uses the private keys corresponding to the different sub-information fragments to decrypt the encrypted sub-information fragments.

[0163] When the terminal device uses the target format to concatenate the encrypted sub-information, the locking server can correctly decrypt the sub-information using the private key; however, when the terminal device does not use the target format to concatenate the encrypted sub-information (it may be intercepted through the interface and a forged text message is sent, but because the target format is not known, the concatenation method of the encrypted sub-information is incorrect), the locking server will not be able to correctly decrypt the sub-information using the private key.

[0164] Therefore, when the encrypted sub-information is correctly decrypted, it indicates that the data in the SMS is not forged, and the locking server allocates an authorization code for decrypting the device sub-information.

[0165] Indicatively, Fig. 9 As shown, the lock server determines that the extracted first part of the encrypted sub-information is a ciphertext MAC address based on the target format, and then uses the third private key (corresponding to the third public key) to decrypt the first MAC address fragment ciphertext in the ciphertext MAC address, and uses the fourth private key (corresponding to the fourth public key) to decrypt the second MAC address fragment ciphertext, and merges the decrypted first MAC address fragment and the second MAC address fragment to obtain the MAC address.

[0166] Based on the target format, the locking server determines that the extracted second part of the encrypted sub-information is the ciphertext IMEI, and then uses the first private key (corresponding to the first public key) to decrypt the first IMEI fragment ciphertext in the ciphertext IMEI, and uses the second private key (corresponding to the second public key) to decrypt the second IMEI fragment ciphertext, and merges the decrypted first IMEI fragment and the second IMEI fragment to obtain the IMEI.

[0167] Of course, in addition to decryption in the above manner, in another possible implementation, when the lock machine client directly concatenates the encrypted sub-information fragments based on the target concatenation format of the sub-information fragments, the lock machine server can directly extract the encrypted sub-information fragments from the encrypted device sub-information according to the target concatenation format, and decrypt based on the private keys corresponding to different sub-information fragments. When each sub-information fragment is correctly decrypted, the lock machine server distributes the authorization code.

[0168] Step 604: The terminal device sends an authorization code acquisition request including device sub-information.

[0169] In a possible implementation, since SMS sending, synchronization, authentication and allocation of authorization codes require a certain amount of time, when the SMS sending duration reaches a duration threshold, the terminal device sends an authorization code acquisition request to the lock server to request the allocated authorization code.

[0170] In some embodiments, the terminal device extracts device sub-information from local storage and generates an authorization code acquisition request based on the device sub-information.

[0171] Among them, the process of the terminal device extracting the device sub-information can refer to the above steps. The device sub-information in the authorization code acquisition request is also in ciphertext form, which is not repeated in this embodiment.

[0172] Step 605: The locking server receives the authorization code acquisition request sent by the terminal device, and the authorization code acquisition request includes device sub-information.

[0173] Step 606: The locking server sends an authorization code based on the device sub-information.

[0174] In a possible implementation, the locking server decrypts the encrypted device sub-information in the authorization acquisition request to obtain the plaintext device sub-information. The process of the locking server decrypting the encrypted device sub-information can refer to the process of decrypting the device sub-information in the text message, which will not be described in detail in this embodiment.

[0175] Optionally, the locking server detects whether the device sub-information matches the server n-tuple information, that is, detects whether the device sub-information contained in the server n-tuple information is consistent with the device sub-information in the request. If the device sub-information matches the server n-tuple information, the locking server sends the authorization code in the server n-tuple information to the terminal device.

[0176] Step 607: The terminal device receives the authorization code.

[0177] Optionally, the authorization code sent by the locking server may be a plain text authorization code, or the authorization code may be an encrypted cipher text authorization code.

[0178] Step 403: encrypt the authorization code and store it in local storage, wherein the authorization code and the device sub-information are stored in different storage partitions in the local storage.

[0179] In order to increase the difficulty of cracking, the terminal device encrypts and stores the authorization code in a local storage that is different from the storage partition where the device sub-information is located.

[0180] Optionally, the terminal device may encrypt the authorization code as a whole and then store it in local storage.

[0181] Optionally, the terminal device may split the authorization code and store the split authorization code fragments in different storage partitions.

[0182] In some embodiments, the terminal device uses a public key to encrypt the authorization code or the authorization code fragment, and the private key corresponding to the public key is stored in the lock server.

[0183] In this embodiment, in the process of obtaining the authorization code, the terminal device uses two channels, SMS and Internet, to request the allocation of the authorization code and request the issuance of the authorization code, which can reduce the risk of key data being consistently cracked (requiring cracking both SMS and Internet channels) and improve the security of the authorization code acquisition process.

[0184] In addition, the terminal device uses the target format agreed with the lock server to concatenate the sub-information in the device sub-information, and the lock server subsequently decrypts the sub-information based on the target format. That is, an additional level of concatenation format detection is added during the decryption process to identify the modified SMS (the concatenation method between sub-information does not conform to the target format), further improving the security of the SMS sending device sub-information process.

[0185] Through the authorization code allocation process of the above embodiment, the locking server completes the construction of the server-side n-tuple information, and when it subsequently receives a contract status query request from the terminal device, it uses the server-side n-tuple information to verify the n-tuple information in the request.

[0186] like Fig.10 As shown, the contract status query process of the locking server may include the following steps.

[0187] Step 1001, verifying n-tuple information.

[0188] In a possible implementation, the locking server matches the client n-tuple information in the contract status query request with the server n-tuple information. If there is server n-tuple information that matches the client n-tuple information, the locking server determines that the n-tuple information has been verified. If there is no server n-tuple information that matches the client n-tuple information, the locking server determines that the n-tuple information has not been verified.

[0189] Optionally, the client n-tuple information matches the server n-tuple information, which means that each item of sub-information in the client n-tuple information is consistent with each item of sub-information in the server n-tuple information.

[0190] For example, when the IMEI in the client n-tuple information is consistent with the IMEI in the server n-tuple information, and the MAC address in the client n-tuple information is consistent with the MAC address in the server n-tuple information, and the authorization code in the client n-tuple information is consistent with the authorization code in the server n-tuple information, it is determined that the client n-tuple information has passed the verification.

[0191] Optionally, when the n-tuple information includes not only the device identification, which is device sub-information that cannot be changed under normal circumstances, but also other device sub-information that may be changed, such as the component identification of a replaceable component in a terminal device, the client n-tuple information matches the server n-tuple information, which means that: the device identification in the client n-tuple information is consistent with the device identification in the server n-tuple information, and the authorization code in the client n-tuple information is consistent with the authorization code in the server n-tuple information.

[0192] For example, when the n-tuple information contains IMEI, the MAC address of the network card and the authorization code, since the MAC address of the terminal device may change due to changing the grid, when the IMEI in the client n-tuple information is consistent with the IMEI in the server n-tuple information, and the authorization code in the client n-tuple information is consistent with the authorization code in the server n-tuple information, it is determined that the client n-tuple information has passed the verification.

[0193] In some embodiments, when sub-information other than the device identification and authorization code is inconsistent, the locking server can carry prompt information in the contract status query result, prompting the user to go to a qualified outlet to update the information, that is, to update the inconsistent sub-information in the server-side n-tuple information.

[0194] For example, when the MAC address in the client n-tuple information is inconsistent with the MAC address in the server n-tuple information, the contract status query result sent by the locking server carries a prompt message to prompt the user to go to the outlet to update the MAC address of the terminal device. After the user goes to the outlet according to the prompt message, the staff can update the MAC address in the server n-tuple information corresponding to the terminal device in the locking server.

[0195] Step 1002, when the n-tuple information fails to pass the verification, the reason for the failure to pass the verification is determined as the contract status query result, wherein the locking operation performed by the terminal device is different for different reasons for the failure to pass the verification.

[0196] When the n-tuple information fails to pass the verification, in order to let the locking client know the reason for the failure to pass the verification and then take the corresponding locking operation, the locking server will determine the reason for the failure to pass the verification as the contract status query result and feedback it to the terminal device.

[0197] In some embodiments, the reasons for the failed verification may include that the device identification is tampered with, and both the device identification and the authorization code are tampered with.

[0198] The device identification is tampered when the locking server queries the server n-tuple information with the same authorization code as the client n-tuple information, but the device identification contained in the two is inconsistent. This usually happens when the user wants to tamper with the device identification to avoid default locking.

[0199] The device identification and authorization code are tampered with, which means that the lock server cannot query the device identification and authorization code that are consistent with the client n-tuple information from the server n-tuple information. This situation usually occurs during the cracking of the terminal device.

[0200] Step 1003, when the n-tuple information passes the verification, query the current contract status based on the n-tuple information, and determine the current contract status as the contract status query result.

[0201] In some embodiments, the n-tuple information of the terminal device in the locking server is bound to the contract. When the n-tuple information passes the verification, the locking server obtains the current contract status of the contract bound to the n-tuple information, and feeds back the current contract status to the terminal device as the contract status query result.

[0202] Correspondingly, when the contract status query result indicates that the n-tuple information has not passed the verification, the terminal device performs a lock operation based on the reason for the failure to pass the verification, wherein the lock operations performed for different reasons for the failure to pass the verification are different.

[0203] The more sub-information that has been tampered with in the n-tuple device, the more severely the terminal device has been cracked. Accordingly, the success rate of the subsequent default avoidance lock of the terminal device is also higher. Therefore, in some embodiments, when the reason for failure to pass the verification is that the device identification has been tampered with, the first locking operation is performed; when the reason for failure to pass the verification is that both the device identification and the authorization code have been tampered with, the second locking operation is performed, wherein the available functions after the second locking operation are less than the available functions after the first locking operation, that is, different locking strengths are set for different tampering degrees to increase the difficulty of completely cracking the terminal device.

[0204] Illustratively, under the first lock operation, the available functions of the terminal device include making and receiving calls in the whitelist; under the second lock operation, the terminal device automatically powers off after a predetermined period of time.

[0205] In some embodiments, when the n-tuple information fails to pass the verification, the terminal device displays prompt information corresponding to the reason for the failure to pass the verification.

[0206] Optionally, the prompt information corresponding to different reasons for failure to pass verification has different information content, and / or the prompt method is different (such as text, picture, animation, etc.), and / or the prompt intensity is different (such as non-screen dominating prompt, screen dominating prompt, etc.).

[0207] Indicatively, Fig.11 As shown, when the reason for verification failure is that the device identification has been tampered with, the terminal device displays a first lock prompt 1101. When the reason for verification failure is that both the device identification and the authorization code have been tampered with, the terminal device displays a second lock prompt 1102.

[0208] In this embodiment, the locking server feeds back the reason why the n-tuple information fails the verification to the terminal device as part of the contract status query result, so that the terminal device can perform locking operations of different intensities based on the reason. For example, the more sub-information in the n-tuple information is tampered with, the higher the intensity of the locking operation performed, which helps to increase the difficulty of cracking the terminal device.

[0209] Please refer to Fig.12 , which shows a timing diagram of a contract creation and status query process shown in an exemplary embodiment of the present application.

[0210] Step 1201, when the device is turned on for the first time, the locking client obtains the IMEI and MAC address by calling the interface, divides the IMEI and MAC address, and stores them in encrypted partitions.

[0211] Step 1202, the installment client triggers the creation of a contract.

[0212] Step 1203: The locking client extracts the IMEI and MAC address from different storage partitions of the local storage, and sends them to the SMS service provider via SMS.

[0213] Step 1204, the SMS service provider synchronizes SMS messages with the direction lock server.

[0214] Step 1205, the locking server decrypts the IMEI and MAC address in the SMS and assigns an authorization code.

[0215] Step 1206: The locking client extracts the combined encrypted IMEI and MAC address from different storage partitions of local storage, and sends an authorization code acquisition request.

[0216] Step 1207, the locking server decrypts the IMEI and MAC address in the authorization code acquisition request, and obtains the corresponding authorization code.

[0217] Step 1208: The locking server feeds back an authorization code to the locking client.

[0218] Step 1209: The locking client encrypts and stores the authorization code.

[0219] Step 1210, the installment client activates the contract.

[0220] Step 1211, the locking client extracts the IMEI, MAC address and authorization code from different storage partitions of local storage, obtains n-tuple information, and sends a contract status query request containing the n-tuple information to the locking server.

[0221] Step 1212: When the n-tuple information fails to pass the verification, the locking server feeds back the reason for the failure to pass the verification to the locking client.

[0222] Step 1213: The locking client performs a locking operation based on the reason for failing the verification.

[0223] Step 1214, when the n-tuple information passes the verification, the locking server feeds back the current contract status to the locking client.

[0224] It should be noted that in the above embodiment, the steps with the terminal device as the execution subject can be independently implemented as an embodiment of the locking method on the terminal device side, and the steps with the locking server as the execution subject can be independently implemented as an embodiment of the locking method on the locking server side, which will not be elaborated in this embodiment.

[0225] Please refer to Fig.13 , which shows a structural block diagram of a locking device provided by an exemplary embodiment of the present application. The device includes:

[0226] The acquisition module 1301 is used to acquire n-tuple information, wherein the n-tuple information includes at least a device identification and an authorization code, wherein the authorization code is assigned by the locking server, and both the device identification and the authorization code are unique, and n is greater than or equal to 2;

[0227] A sending module 1302, configured to send a contract status query request including the n-tuple information;

[0228] A receiving module 1303 is used to receive a contract status query result, where the contract status query result is obtained based on the n-tuple information;

[0229] The locking module 1304 is used to lock the device when the contract status query result indicates that the n-tuple information has not passed the verification.

[0230] Optionally, the acquisition module 1301 is used to:

[0231] The n-tuple information is obtained from a local storage, wherein sub-information in the n-tuple information is stored in different storage partitions in the local storage.

[0232] Optionally, the device further comprises:

[0233] The storage module is used to obtain device sub-information by calling an interface when the device is turned on for the first time, wherein the device sub-information is sub-information other than the authorization code in the n-tuple information; and encrypt and store the device sub-information in the local storage.

[0234] Optional, storage module for:

[0235] For any item of sub-information in the device sub-information, split the sub-information to obtain multiple sub-information fragments;

[0236] The multiple sub-information fragments are encrypted and stored in different storage partitions of the local storage, wherein different sub-information fragments are encrypted using different keys.

[0237] Optionally, the acquisition module 1301 is further configured to acquire device sub-information from the local storage, where the device sub-information is sub-information other than the authorization code in the n-tuple information;

[0238] The sending module 1302 and the receiving module 1303 are used to obtain the authorization code based on the device sub-information;

[0239] A storage module is used to encrypt and store the authorization code in the local storage, wherein the authorization code and the device sub-information are stored in different storage partitions in the local storage.

[0240] Optionally, the acquisition module 1301 is used to:

[0241] Acquire encrypted sub-information segments from different storage partitions of the local storage, wherein the encrypted sub-information segments are obtained by dividing and encrypting sub-information in the device sub-information;

[0242] The sending module 1302 is used to:

[0243] Merging the encrypted sub-information fragments corresponding to the same sub-information in the device sub-information to obtain encrypted sub-information;

[0244] Concatenate the encrypted sub-information based on a target format to obtain encrypted device sub-information, wherein the target format is a format agreed upon with the lock server;

[0245] Based on the encrypted device sub-information, the authorization code is obtained.

[0246] Optionally, the locking module 1304 is used to:

[0247] When the contract status query result indicates that the n-tuple information has not passed the verification, a locking operation is performed based on the reason for the failure to pass the verification, wherein different locking operations are performed for different reasons for the failure to pass the verification.

[0248] Optionally, the locking module 1304 is used to:

[0249] When the reason for the failure of verification is that the device identification has been tampered with, performing a first locking operation;

[0250] When the reason for the failure of verification is that both the device identification and the authorization code are tampered with, a second locking operation is performed, and the available functions after the second locking operation are less than the available functions after the first locking operation.

[0251] Please refer to Fig.14 , which shows a structural block diagram of a locking device provided by another exemplary embodiment of the present application. The device includes:

[0252] The receiving module 1401 is used to receive a contract status query request, wherein the contract status query request includes n-tuple information, wherein the n-tuple information includes at least a device identification and an authorization code, wherein the authorization code is assigned by the locking server, and both the device identification and the authorization code are unique, and n is greater than or equal to 2;

[0253] A processing module 1402 is used to determine a contract status query result based on the n-tuple information;

[0254] The sending module 1403 is used to send the contract status query result, wherein when the contract status query result indicates that the n-tuple information has not passed the verification, the terminal device performs a locking operation.

[0255] Optionally, the receiving module 1401 is used to:

[0256] Synchronize a text message from a text message service provider, the text message is sent by the terminal device, the text message includes device sub-information, and the device sub-information is sub-information other than the authorization code in the n-tuple information;

[0257] Processing module 1402, configured to allocate the authorization code based on the device sub-information, and generate server-side n-tuple information based on the device sub-information and the authorization code;

[0258] The receiving module 1401 is used to receive an authorization code acquisition request sent by the terminal device, wherein the authorization code acquisition request includes the device sub-information;

[0259] The sending module 1403 is used to send the authorization code to the terminal device based on the device sub-information.

[0260] Optionally, the sub-information in the device sub-information is split into sub-information fragments and then encrypted. The processing module 1402 is used to:

[0261] Extracting the encrypted device sub-information in the SMS;

[0262] Extracting encrypted sub-information from the encrypted device sub-information based on a target format, wherein the target format is a format agreed upon with the terminal device, and the encrypted sub-information is obtained by merging encrypted sub-information fragments corresponding to the same sub-information;

[0263] In the case where the encrypted sub-information is correctly decrypted, the authorization code is allocated based on the decrypted device sub-information.

[0264] Optionally, the sending module 1403 is used to:

[0265] In a case where the device sub-information matches the server n-tuple information, the authorization code in the server n-tuple information is sent to the terminal device.

[0266] Optionally, the processing module 1402 is used to:

[0267] Verifying the n-tuple information;

[0268] In the case where the n-tuple information fails to pass the verification, the reason for the failure to pass the verification is determined as the contract status query result, wherein the locking operation performed by the terminal device is different for different reasons for the failure to pass the verification;

[0269] In the case where the n-tuple information passes the verification, the current contract status is queried based on the n-tuple information, and the current contract status is determined as the contract status query result.

[0270] Optionally, when the reason for the failure of verification is that the device identification has been tampered with, the terminal device performs a first locking operation;

[0271] When the reason for the failure of verification is that both the device identification and the authorization code have been tampered with, the terminal device performs a second locking operation, and the available functions after the second locking operation are less than the available functions after the first locking operation.

[0272] See also Fig.15 , Fig.1515 is a schematic diagram of the structure of a computer device provided by an exemplary embodiment of the present application. The computer device can be implemented as a terminal device or a server in the above embodiment. The computer device can also include one or more of the following components: a processor 1510 and a memory 1520.

[0273] Optionally, the processor 1510 uses various interfaces and lines to connect various parts of the entire electronic device, and executes various functions of the electronic device and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 1520, and calling data stored in the memory 1520. Optionally, the processor 1510 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 1510 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), a neural network processor (NPU), and a baseband chip. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing the content that needs to be displayed on the touch display; the NPU is used to implement artificial intelligence (AI) functions; and the baseband chip is used to process wireless communications. It is understandable that the above-mentioned baseband chip may not be integrated into the processor 1510, but may be implemented by a separate chip.

[0274] The memory 1520 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 1520 includes a non-transitory computer-readable storage medium. The memory 1520 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 1520 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function, instructions for implementing the following various method embodiments, etc.; the data storage area may store data created according to the use of the electronic device, etc.

[0275] In addition, those skilled in the art will understand that the structure of the computer device shown in the above figures does not constitute a limitation on the computer device, and the computer device may include more (such as communication components, display components) or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0276] An embodiment of the present application provides a computer-readable storage medium, which stores at least one computer instruction, and the at least one computer instruction is used to be executed by a processor to implement the locking method of the terminal device or the locking server side as described in the above embodiment.

[0277] On the other hand, an embodiment of the present application provides a computer program product, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; a processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the locking method on the terminal device or locking server side as described in the above embodiment.

[0278] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented with hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein the communication media include any media that facilitates the transmission of a computer program from one place to another. The storage medium can be any available medium that a general or special-purpose computer can access.

[0279] The above description is only an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for locking a machine, characterized in that: The method is performed by a terminal device, and the method includes: Obtaining n-tuple information, wherein the n-tuple information includes at least a device identification and an authorization code, wherein the authorization code is assigned by the locking server, the device identification and the authorization code are both unique, and n is greater than or equal to 2; Sending a contract status query request containing the n-tuple information; receiving a contract status query result, wherein the contract status query result is obtained based on the n-tuple information; When the contract status query result indicates that the n-tuple information has not passed the verification, the device is locked.

2. The method according to claim 1, characterized in that The obtaining of n-tuple information includes: The n-tuple information is obtained from a local storage, wherein sub-information in the n-tuple information is stored in different storage partitions in the local storage.

3. The method according to claim 2, characterized in that The method comprises: In the case of first booting, obtaining device sub-information by calling an interface, wherein the device sub-information is sub-information other than the authorization code in the n-tuple information; The device sub-information is encrypted and stored in the local storage.

4. The method according to claim 3, characterized in that The step of encrypting and storing the device sub-information in the local storage includes: For any item of sub-information in the device sub-information, split the sub-information to obtain multiple sub-information fragments; The multiple sub-information fragments are encrypted and stored in different storage partitions of the local storage, wherein different sub-information fragments are encrypted using different keys.

5. The method according to claim 2, characterized in that: The method further comprises: Acquire device sub-information from the local storage, where the device sub-information is sub-information other than the authorization code in the n-tuple information; Based on the device sub-information, obtaining the authorization code; The authorization code is encrypted and stored in the local storage, wherein the authorization code and the device sub-information are stored in different storage partitions in the local storage.

6. The method according to claim 5, characterized in that The acquiring device sub-information from the local storage includes: Acquire encrypted sub-information segments from different storage partitions of the local storage, wherein the encrypted sub-information segments are obtained by dividing and encrypting sub-information in the device sub-information; The obtaining the authorization code based on the device sub-information includes: Merging the encrypted sub-information fragments corresponding to the same sub-information in the device sub-information to obtain encrypted sub-information; Concatenate the encrypted sub-information based on a target format to obtain encrypted device sub-information, wherein the target format is a format agreed upon with the lock server; Based on the encrypted device sub-information, the authorization code is obtained.

7. The method according to any one of claims 1 to 6, characterized in that: When the contract status query result indicates that the n-tuple information has not passed the verification, performing the locking operation includes: When the contract status query result indicates that the n-tuple information has not passed the verification, a locking operation is performed based on the reason for the failure to pass the verification, wherein different locking operations are performed for different reasons for the failure to pass the verification.

8. The method according to claim 7, characterized in that The locking operation based on the reason of failure to pass the verification includes: When the reason for the failure of verification is that the device identification has been tampered with, performing a first locking operation; When the reason for the failure of verification is that both the device identification and the authorization code are tampered with, a second locking operation is performed, and the available functions after the second locking operation are less than the available functions after the first locking operation.

9. A terminal device, characterized in that: The terminal device includes a processor and a memory, wherein the memory stores at least one computer instruction, and the at least one computer instruction is loaded and executed by the processor to implement the locking method as described in any one of claims 1 to 8.

10. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium; a processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the locking method as described in any one of claims 1 to 8.

Images