A software authorization method and device

Abstract

The application provides a software authorization method and device, the method comprises the following steps: a kernel driver acquires a first product model sent by an application when the application is started for the first time on a target device; first software authorization information in the kernel driver compiled to the target device is restored to first ciphertext by inverse operation of salt encryption technology, and the first ciphertext is decrypted by a public key to obtain the first software authorization information; the first software authorization information comprises a second product model; it is judged whether the first product model and the second product model are consistent; if not, the connection with the application is disconnected; if yes, the first ciphertext is encrypted by a random key and then sent to the application, so that the application is authorized by the first software authorization information. The above method can realize the authorization of the application by the software authorization method compiled into the kernel driver, avoid the software theft of external devices, and reduce the labor cost and error risk.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a software licensing method and target device. Background Technology

[0002] Once installed on an electronic device, the software requires authorization to run; otherwise, it could be used without authorization.

[0003] Currently, there are two common licensing methods. The first is a dongle, a hardware device similar in appearance to a USB flash drive. When plugged into a machine, the software product reads the dongle to obtain licensing information and can then use it within the authorized scope. The second is a license file. The software product obtains the machine information it is running on to generate a machine identification code, and then generates a license file based on the machine identification code and licensing information. The software product reads the license file, verifies its compatibility with the machine, obtains the licensing information, and can then use it within the authorized scope.

[0004] While the above methods are usable, they still have drawbacks. The dongle increases hardware costs. The authorization file increases the workload in the production process, as the production line needs to send the machine code to the authorization manager to generate the authorization file, and then deploy the authorization file to the machine, thus increasing labor costs. Summary of the Invention

[0005] In view of this, the present invention provides a software licensing method and apparatus that can solve the problem of cumbersome software licensing process in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a software licensing method, comprising:

[0007] Obtain the first product model sent when the application is first launched on the target device;

[0008] The first software license information in the kernel driver compiled into the target device is restored to the first ciphertext by inverse operation of salt encryption technology, and the first ciphertext is decrypted using a public key to obtain the first software license information; the first ciphertext is ciphertext including the first software license information; the first software license information includes the second product model;

[0009] Determine whether the first product model and the second product model match;

[0010] If the first product model and the second product model do not match, then disconnect from the application.

[0011] If the first product model and the second product model match, the first ciphertext is encrypted using the random key and then sent to the application, so that the application can decrypt the encrypted first ciphertext to obtain the first software authorization information and authorize the application using the first software authorization information.

[0012] Secondly, embodiments of the present invention provide a software licensing method, including:

[0013] When the application is first launched on the target device, the first product model compiled in the application is restored to the second ciphertext through the inverse operation of salt encryption technology. The second ciphertext is the ciphertext of the second information. The second information is obtained by concatenating the first product model and the hash digest corresponding to the first product model.

[0014] The second ciphertext is encrypted using a random key to obtain an authorization request ciphertext, which is then sent to the kernel driver of the target device. The kernel driver determines whether the first product model in the authorization request ciphertext matches the second product model in the first software license information. If they match, the encrypted first ciphertext is returned; otherwise, the connection with the application is disconnected. The first ciphertext is an ciphertext that includes the first software license information.

[0015] If the returned encrypted first ciphertext is detected, the encrypted first ciphertext is decrypted to obtain the first software authorization information, and the application is authorized using the first software authorization information;

[0016] When a disconnection from the kernel driver is detected, it is determined that the application is not authorized.

[0017] Thirdly, embodiments of the present invention provide a device, wherein the operating system of the device includes a kernel space and a user space; a kernel driver runs in the kernel space and executes the software licensing method described in the first aspect above; and an application runs in the user space and executes the software licensing method described in the second aspect above.

[0018] The beneficial effects of the embodiments of the present invention compared with the prior art are as follows:

[0019] The kernel driver provided in this embodiment of the invention first obtains the first product model sent by the application when it is first launched on the target device; then, it uses the inverse operation of salted encryption technology to restore the first ciphertext of the first software license information compiled into the kernel driver of the target device, and decrypts the first ciphertext using a public key to obtain the first software license information; the first ciphertext is ciphertext including the first software license information; the first software license information includes a second product model; it determines whether the first product model and the second product model match; if the first product model and the second product model do not match, the connection with the application is disconnected; if the first product model and the second product model match, the first ciphertext is encrypted using the random key and sent to the application, so that the application can decrypt the encrypted first ciphertext to obtain the first software license information, and authorize the application using the first software license information. The above method can realize the authorization of the application by compiling the software license program into the kernel driver, avoid the external device from stealing software, and has no additional hardware cost or manual intervention, reducing labor costs and error risks. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the implementation of the software licensing method provided in this embodiment of the invention.

[0022] Figure 2 This is a flowchart illustrating the specific interaction process of the software licensing method provided in this embodiment of the invention.

[0023] Figure 3 This is a schematic diagram of the structure of the software licensing device provided in an embodiment of the present invention;

[0024] Figure 4 This is a schematic diagram of the terminal provided in an embodiment of the present invention. Detailed Implementation

[0025] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the invention. However, those skilled in the art will understand that the invention can be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of the invention with unnecessary detail.

[0026] To make the objectives, technical solutions, and advantages of the present invention clearer, specific embodiments will be described below in conjunction with the accompanying drawings.

[0027] See Figure 1 The document illustrates a flowchart of the software licensing method provided in an embodiment of the present invention, which is described in detail below:

[0028] S101: Obtain the first product model sent when the application is first launched on the target device.

[0029] The software licensing method provided in this embodiment is executed by a device, and the software licensing method is a kernel driver in the kernel space of the device.

[0030] Specifically, to prevent the application from being stolen and run on other devices, this embodiment writes a unique kernel driver in the kernel space of the target device. The application's software licensing information is compiled into the kernel image of the target device as part of the kernel driver. The application runs in user space, establishes a connection with the kernel driver, and interacts with it. The kernel driver is used to verify the trustworthiness of the application and authorizes it when it determines that the application is an authorized application for the target device.

[0031] As can be seen from the above embodiments, the kernel driver in this embodiment is compiled into the kernel image as a whole, rather than compiled into a separate kernel module file. Therefore, it cannot be used independently and has higher security.

[0032] In this embodiment, when the application runs on the target device for the first time, it first needs to establish a connection with the kernel driver and then send the first product model to the kernel driver.

[0033] To improve the communication security between the application and the kernel driver, this embodiment can encrypt the first product model on the application side and send it to the kernel driver. The kernel driver can then decrypt the ciphertext of the first product model using an encryption algorithm agreed upon with the application to obtain the first product model.

[0034] S102: The first software license information in the kernel driver compiled into the target device is restored to the first ciphertext by the inverse operation of salt encryption technology, and the first ciphertext is decrypted using the public key to obtain the first software license information; the first ciphertext is ciphertext including the first software license information; the first software license information includes the second product model.

[0035] In this embodiment, to enhance security, the software license information corresponding to the application is compiled into the kernel driver of the target device to prevent the software license information from being used independently. Furthermore, since the kernel image on the target device is strongly dependent on the hardware, this further ensures that the application is not abused.

[0036] Specifically, salting encryption is an asymmetric encryption technique that inserts a specific string at any fixed position in the data to be encrypted, causing the hash result to differ from the hash result of the original data. The "salt" is a set of random strings called Salt, generated randomly by the system. Salt can be inserted at the beginning, end, or in the middle, and can be inserted separately or in reverse order.

[0037] In this embodiment, the software licensing information is encrypted twice and compiled into the kernel driver before the software licensing process begins. After the kernel driver obtains the first product model, the first software licensing information compiled into the kernel driver of the target device is restored to the first ciphertext through the inverse operation of salt encryption technology. The first ciphertext includes the first software licensing information and its hash digest. After obtaining the first ciphertext through the salt inverse operation, it needs to be decrypted using a public key to obtain the first software licensing information. The first software licensing information carries the product model of the application that can be licensed on the target device, i.e., the second product model.

[0038] S103: Determine whether the first product model and the second product model are consistent.

[0039] S104: If the first product model and the second product model do not match, disconnect from the application.

[0040] S105: If the first product model and the second product model match, the first ciphertext is encrypted using the random key and then sent to the application, so that the application can decrypt the encrypted first ciphertext to obtain the first software authorization information and authorize the application using the first software authorization information.

[0041] In this embodiment, the kernel driver determines whether the first product model obtained from the application matches the second product model stored internally by the kernel driver. If they match, the application is authorized so that it can run on the target device. If they do not match, the connection with the application is disconnected. After the application is disconnected, it may automatically exit, continue to run during the trial period, or restrict the application from performing some functions and prompt the user with the information that the application is not authorized.

[0042] As can be seen from the above embodiments, the method provided in this embodiment can automatically authorize applications on the target device, and not only does it have no hardware cost, but it also improves the convenience of the generation process and reduces labor costs and error risks.

[0043] In one possible implementation, the specific implementation process of S101 includes:

[0044] S201: When the application is first launched on the target device, a key exchange is performed with the application based on the key exchange algorithm to generate a random key.

[0045] Specifically, when obtaining the first product model, the kernel driver needs to complete communication security verification with the application. First, when establishing a communication connection, the kernel driver and the application exchange keys using the Diffie-Hellman key exchange algorithm to generate a random key.

[0046] In one possible implementation, the specific implementation process of S201 includes:

[0047] Obtain the first key DH-P and the second key DH-PSA sent by the application when it is first launched on the target device; wherein, the first key DH-P is a key randomly generated by the application using the Diffie-Hellman key exchange algorithm, and the second key DH-PSA is a key synthesized by the first key DH-P and the third key DH-SA, wherein the third key DH-SA is a key randomly generated by the application using the Diffie-Hellman key exchange algorithm;

[0048] A fourth key DH-SB is randomly generated according to the Diffie-Hellman key exchange algorithm, and the random key DH-PSASB is synthesized using the fourth key DH-SB and the second key DH-PSA.

[0049] The fifth key DH-PSB is synthesized using the fourth key DH-SB and the first key DH-P, and the fifth key DH-PSB is sent to the application so that the application can synthesize the random key DH-PSBSA based on the fifth key DH-PSB and the third key DH-SA.

[0050] In this embodiment, the application uses the Diffie-Hellman key exchange algorithm to randomly generate a first key DH-P and a third key DH-SA. Then, it combines the first key DH-P and the third key DH-SA to form a second key DH-PSA, and sends both keys to the kernel driver. The kernel driver also uses the Diffie-Hellman key exchange algorithm to randomly generate a fourth key DH-SB, and combines the fourth key DH-SB with the second key DH-PSA sent by the application to form a random key DH-PSASB. It then combines the fourth key DH-SB with the first key DH-P to form a fifth key DH-PSB, which is sent to the application. After obtaining the fifth key DH-PSB, the application combines it with the third key DH-SA to form a random key DH-PSBSA. Thus, both the application and the kernel driver have synthesized random keys, and according to the Diffie-Hellman proof, DH-PSASB equals DH-PSBSA, meaning both parties have synthesized the same key, denoted as the random key DHK. Even if the interaction process is eavesdropped on, a third party cannot synthesize DHK.

[0051] As can be seen from the above embodiments, during the interaction between the kernel driver and the application, messages may be eavesdropped. Moreover, since the content of each interaction is fixed, others can exploit the entire message without knowing its meaning to forge a kernel driver. The method provided in this embodiment uses the Diffie-Hellman key exchange method to ensure that the DHK cannot be obtained by a third party, thereby guaranteeing the security of the interaction process between the kernel driver and the application.

[0052] S202: Obtain the encrypted authorization request sent by the application.

[0053] S203: Decrypt the authorized request ciphertext using the random key to obtain the second ciphertext, and then decrypt the second ciphertext using the public key to obtain the product model and hash digest in the second ciphertext.

[0054] S204: If the product model in the second ciphertext matches the hash digest, then the product model in the second ciphertext shall be used as the first product model.

[0055] S205: If the product model and hash digest in the second ciphertext do not match, disconnect from the application.

[0056] Specifically, this embodiment draws on the concept of digital signatures, using an asymmetric encryption algorithm to generate a key pair. The key used for encryption is called the private key SK, and the key used for decryption is called the public key PK. A key characteristic of this encryption algorithm is that content encrypted with the private key can only be decrypted with the public key.

[0057] In one possible implementation, prior to S101, the method provided in this embodiment further includes:

[0058] The first software authorization information and its corresponding hash digest are concatenated to obtain the first information. The first information is then encrypted using a private key to obtain the first ciphertext. The private key and the public key are a pair.

[0059] The first ciphertext is compiled into the kernel driver using salt encryption technology.

[0060] In this embodiment, the application first concatenates the product model and the corresponding hash digest to obtain the second information, then encrypts the second information using a private key to obtain the second ciphertext, and then encrypts the second ciphertext using salt encryption technology and compiles it into the application as a constant.

[0061] In this embodiment, the kernel driver also needs to concatenate the first software license information and the hash digest corresponding to the first software license information in advance to obtain the first information, encrypt the first information with a private key to obtain the first ciphertext, and then compile the first ciphertext into the kernel driver after salting it.

[0062] Specifically, upon initial startup, the application decrypts the encrypted second ciphertext using a salted inverse operation to obtain the second ciphertext. It then encrypts this second ciphertext using a random key and a pre-agreed symmetric encryption algorithm with the kernel driver, resulting in the authorization request ciphertext, which is sent to the kernel driver. The kernel driver first decrypts the authorization request ciphertext using the random key DHK and the pre-agreed symmetric encryption algorithm to obtain the second ciphertext. It then decrypts the second ciphertext using the public key to obtain the product model and hash digest. If the product model and hash digest match, the second ciphertext has not been modified, and the product model is trustworthy. If they do not match, the second ciphertext has been modified. The trustworthiness of the authorization request ciphertext can be determined by checking if the decrypted product model and hash digest match. If untrustworthy, the kernel driver disconnects from the application; if trustworthy, it authorizes the application.

[0063] Among them, the symmetric encryption algorithms used in DHK encryption and decryption can be AES (Advanced Encryption Standard), DES (Data Encryption Standard), etc.

[0064] The private key SK is not stored in the kernel driver or the application, but in a separate authorization tool, which effectively prevents leakage.

[0065] In one possible implementation, prior to S102, the method provided in this embodiment further includes:

[0066] The public key compiled into the kernel driver is restored by inverse operation of salting encryption technology.

[0067] Specifically, before practical application, the public key in the asymmetric encryption algorithm can be encrypted using salting encryption technology and then compiled into the kernel driver to ensure the security of the public key.

[0068] Specifically, the public key (PK) and the encrypted software license information in the kernel driver are processed using a private method before being compiled into the kernel driver file; the encrypted product model information in the application is processed using a private method before being compiled into the application file, and then restored using a reverse operation during program execution. This method does not use a password because the password itself is still stored as a constant in the program. For example, random data is inserted at selected locations, and this inserted data is skipped during execution to restore the original data. This method is called "salting".

[0069] Specifically, in practical applications, others might analyze program files to obtain constants (such as public key (PK), encrypted authorization information in kernel drivers, and encrypted product model information in software products), and then replace them with their own generated content to achieve the purpose of cracking the code. This embodiment uses salting to prevent kernel drivers and applications from being reverse engineered, improving the security of the authorization process.

[0070] In one possible implementation, disconnecting from the application in S104 includes:

[0071] Disconnect the netlink connection from the application.

[0072] In this embodiment, netlink is a synchronous or asynchronous data transmission method. After the application and kernel driver establish a connection, full-duplex data transmission can be performed using netlink, and it supports full-duplex and asynchronous communication. The user space can use the standard socket interface for communication and supports multicast. In the kernel space, it can be used for both interrupt context and interrupt context.

[0073] In one embodiment of this application, a software licensing method is provided. This method is located on the application side, and its process is detailed below:

[0074] S301: When the application is first launched on the target device, the first product model compiled in the application is restored to the second ciphertext through the inverse operation of salt encryption technology. The second ciphertext is the ciphertext of the second information. The second information is obtained by concatenating the first product model and the hash digest corresponding to the first product model.

[0075] In this embodiment, before the application leaves the factory, the first product model and the hash digest corresponding to the first product model are concatenated to obtain the second information. Then, the second information is encrypted using a private key to obtain the second ciphertext. The second ciphertext is then encrypted using salting encryption technology and compiled into the application as a constant.

[0076] Upon detecting the first execution on the target device, the application randomly generates a first key DH-P and a third key DH-SA using the Diffie-Hellman key exchange algorithm. It then combines DH-P and DH-SA to form a second key DH-PSA and sends both to the kernel driver. The application then retrieves the fifth key DH-PSB returned by the kernel driver. It uses DH-PSB and DH-SA to synthesize a random key DH-PSBSA. Thus, both the application and the kernel driver have synthesized random keys, and according to the Diffie-Hellman proof, DH-PSBSAB is equal to DH-PSBSA, meaning both parties have synthesized the same key, denoted as the random key DHK. Even if the interaction is eavesdropped on, a third party cannot synthesize DHK.

[0077] S302: The second ciphertext is encrypted using a random key to obtain an authorization request ciphertext, and the authorization request ciphertext is sent to the kernel driver of the target device so that the kernel driver can determine whether the first product model in the authorization request ciphertext matches the second product model in the first software license information. If they match, the encrypted first ciphertext is returned; otherwise, the connection with the application is disconnected. The first ciphertext is a ciphertext that includes the first software license information.

[0078] In this embodiment, after synthesizing the random key DHK, the application reverse-engineers the first product model compiled in the application using salt encryption to restore it to the second ciphertext. Then, it encrypts the second ciphertext using the random key and a pre-agreed symmetric encryption algorithm to obtain the authorization request ciphertext, which is then sent to the kernel driver. The kernel driver decrypts the authorization request ciphertext to obtain the first product model. If the first product model matches the second product model, it returns the encrypted first ciphertext to the application. If the first and second product models do not match, the connection with the application is disconnected.

[0079] S303: If the returned encrypted first ciphertext is detected, the encrypted first ciphertext is decrypted to obtain the first software authorization information, and the application is authorized using the first software authorization information.

[0080] In one possible implementation, the specific implementation process of S303 includes:

[0081] The first ciphertext is decrypted based on the random key and symmetric encryption algorithm. The first ciphertext is then decrypted using the public key to obtain the software authorization information and hash digest.

[0082] Determine whether the software authorization information in the first ciphertext matches the hash digest. If the software authorization information in the first ciphertext matches the hash digest, then use the software authorization information in the first ciphertext as the first software authorization information.

[0083] If the software license information in the first ciphertext does not match the hash digest, the connection with the kernel driver is disconnected.

[0084] In this embodiment, the public key is compiled into the application using salt encryption technology. Therefore, before decrypting the first ciphertext, the application needs to first use the salt encryption technology to reverse the operation to restore the public key, and then use the public key to decrypt the first ciphertext to obtain the software authorization information and hash digest.

[0085] S304: When a disconnection with the kernel driver is detected, it is determined that the application is not authorized.

[0086] In this embodiment, if the connection between the application and the kernel driver is detected to be disconnected, it is determined that the application is not authorized. At this time, the application can be automatically exited, continue to run during the trial period, or have some functions of the application restricted, and the user will be prompted with the information that the application is not authorized.

[0087] like Figure 2 As shown, Figure 2The interactive flowchart of the software licensing method provided in the embodiments of this application is shown, and the process is described in detail below:

[0088] When the application detects that it is running on the target device for the first time, it randomly generates a first key and a third key according to the Diffie-Hellman key exchange algorithm, and uses the first key and the third key to synthesize a second key, and sends the first key and the second key to the kernel driver.

[0089] The kernel driver randomly generates a fourth key based on the Diffie-Hellman key exchange algorithm, synthesizes a random key using the fourth key and the second key, synthesizes a fifth key using the fourth key and the first key, and sends the fifth key to the application.

[0090] The application uses the fifth key and the third key to synthesize a random key.

[0091] The first product model compiled in the application is restored to the second ciphertext through the inverse operation of salt encryption technology. The second ciphertext is then encrypted using a random key and an agreed symmetric encryption algorithm to obtain the authorization request ciphertext, which is then sent to the kernel driver.

[0092] The kernel driver uses a random key and an agreed-upon symmetric encryption algorithm to decrypt the ciphertext of the authorization request, obtaining a second ciphertext. Then, it uses the public key to decrypt the second ciphertext, obtaining the product model and hash digest from the second ciphertext.

[0093] The kernel driver checks whether the product model in the second ciphertext matches the hash digest;

[0094] If the kernel driver determines that the product model in the second ciphertext matches the hash digest, it determines that the product model in the second ciphertext is the first product model, and restores the first ciphertext by performing the inverse operation of the first software license information in the kernel driver compiled into the target device using salt encryption technology, and decrypts the first ciphertext using the public key to obtain the first software license information; the second product model is written in the first software license information;

[0095] If the kernel driver determines that the product model in the second ciphertext does not match the hash digest, it will disconnect from the application.

[0096] The kernel driver determines whether the first product model and the second product model are the same;

[0097] If the kernel driver determines that the first product model is the same as the second product model, it uses the random key and the agreed symmetric encryption algorithm to encrypt the first ciphertext and sends the encrypted first ciphertext to the application.

[0098] If the kernel driver determines that the first product model and the second product model are inconsistent, it will disconnect from the application.

[0099] After receiving the encrypted first ciphertext, the application decrypts the encrypted first ciphertext based on the random key and symmetric encryption algorithm, and then decrypts the first ciphertext using the public key to obtain the software authorization information and hash digest.

[0100] The application determines whether the software authorization information in the first ciphertext matches the hash digest;

[0101] If the application determines that the software authorization information in the first ciphertext matches the hash digest, it uses the software authorization information in the first ciphertext as the first software authorization information and uses the first software authorization information to authorize the application.

[0102] If the application determines that the software license information in the first ciphertext does not match the hash digest, it disconnects from the kernel driver.

[0103] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0104] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0105] Figure 3 A schematic diagram of the software licensing device provided in an embodiment of the present invention is shown. For ease of explanation, only the parts related to the embodiment of the present invention are shown, and are described in detail below:

[0106] like Figure 3 As shown, the software licensing device 100 includes:

[0107] The first product model acquisition module 110 is used to acquire the first product model sent by the application when it is first launched on the target device.

[0108] The second product model acquisition module 120 is used to reverse the operation of the first software license information in the kernel driver compiled into the target device using salt encryption technology to restore the first ciphertext, and to decrypt the first ciphertext using a public key to obtain the first software license information; the first ciphertext is ciphertext including the first software license information; the first software license information includes the second product model.

[0109] The model identification module 130 is used to determine whether the first product model and the second product model are consistent;

[0110] The connection disconnection module 140 is used to disconnect the application if the first product model and the second product model do not match.

[0111] The authorization module 150 is used to encrypt the first ciphertext using the random key and send it to the application if the first product model and the second product model match, so that the application can decrypt the encrypted first ciphertext to obtain the first software authorization information and authorize the application using the first software authorization information.

[0112] In one possible implementation, the first product model acquisition module 110 includes:

[0113] A random key generation unit is used to generate a random key by exchanging keys with the application based on a key exchange algorithm when the application is first launched on the target device.

[0114] The authorization request ciphertext acquisition unit is used to acquire the authorization request ciphertext sent by the application.

[0115] The second ciphertext decryption unit is used to decrypt the authorization request ciphertext using the random key to obtain the second ciphertext, and to decrypt the second ciphertext using the public key to obtain the product model and hash digest in the second ciphertext;

[0116] The first product model acquisition unit is used to take the product model in the second ciphertext as the first product model if the product model in the second ciphertext matches the hash digest.

[0117] The connection disconnection unit is used to disconnect the application if the product model and hash digest in the second ciphertext do not match.

[0118] In one possible implementation, the random key generation unit includes:

[0119] Obtain a first key and a second key sent by the application when it is first launched on the target device; wherein, the first key is a key randomly generated by the application using the Diffie-Hellman key exchange algorithm, the second key is a key synthesized from the first key and the third key, and the third key is a key randomly generated by the application using the Diffie-Hellman key exchange algorithm;

[0120] A fourth key is randomly generated according to the Diffie-Hellman key exchange algorithm, and the random key is synthesized using the fourth key and the second key;

[0121] A fifth key is synthesized using the fourth key and the first key, and the fifth key is sent to the application so that the application can synthesize the random key based on the fifth key and the third key.

[0122] In one possible implementation, the software licensing device 100 further includes a public key salting module for:

[0123] The public key compiled into the kernel driver is restored by inverse operation of salting encryption technology.

[0124] In one possible implementation, the software licensing device 100 further includes a first ciphertext encryption module, used for:

[0125] The first software authorization information and its corresponding hash digest are concatenated to obtain the first information. The first information is then encrypted using a private key to obtain the first ciphertext. The private key and the public key are a pair.

[0126] The first ciphertext is compiled into the kernel driver using salt encryption technology.

[0127] In one possible implementation, the connection disconnection module 140 includes:

[0128] Disconnect the netlink connection from the application.

[0129] In one embodiment of this application, a software licensing device is provided, located at the software program end, comprising:

[0130] The second ciphertext acquisition module is used to restore the first product model compiled in the application to the second ciphertext through the inverse operation of salt encryption technology when the application is first launched on the target device. The second ciphertext is the ciphertext of the second information. The second information is obtained by concatenating the first product model and the hash digest corresponding to the first product model.

[0131] The authorization request ciphertext sending module is used to encrypt the second ciphertext using a random key to obtain the authorization request ciphertext, and send the authorization request ciphertext to the kernel driver of the target device, so that the kernel driver can determine whether the first product model in the authorization request ciphertext matches the second product model in the first software license information. If they match, the encrypted first ciphertext is returned; otherwise, the connection with the application is disconnected. The first ciphertext is ciphertext including the first software license information.

[0132] The authorization module is used to decrypt the encrypted first ciphertext if the returned encrypted first ciphertext is detected, to obtain the first software authorization information, and to authorize the application using the first software authorization information.

[0133] A disconnection module is used to determine that the application is not authorized when a disconnection with the kernel driver is detected.

[0134] In one possible implementation, the authorization module includes:

[0135] The first ciphertext is decrypted based on the random key and symmetric encryption algorithm. The first ciphertext is then decrypted using the public key to obtain the software authorization information and hash digest.

[0136] Determine whether the software authorization information in the first ciphertext matches the hash digest. If the software authorization information in the first ciphertext matches the hash digest, then use the software authorization information in the first ciphertext as the first software authorization information.

[0137] If the software license information in the first ciphertext does not match the hash digest, the connection with the kernel driver is disconnected.

[0138] The software licensing device provided in this embodiment can be used to execute the above-described software licensing method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0139] Figure 4 This is a schematic diagram of a terminal provided in an embodiment of the present invention. For example... Figure 4 As shown, the operating system of terminal 4 in this embodiment includes a kernel space and a user space; kernel drivers run in the kernel space; and applications run in the user space. Terminal 4 includes a processor 40, a memory 41, and a computer program 42 stored in the memory 41 and executable on the processor 40. When the processor 40 executes the computer program 42, it implements the steps in the various software licensing method embodiments described above, for example... Figure 1 Steps S101 to S105 are shown. Alternatively, when the processor 40 executes the computer program 42, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 3 The functions of modules 110 to 150 are shown.

[0140] For example, the computer program 42 may be divided into one or more modules / units, which are stored in the memory 41 and executed by the processor 40 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 42 in the terminal 4.

[0141] The terminal 4 can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. The terminal 4 may include, but is not limited to, a processor 40 and a memory 41. Those skilled in the art will understand that... Figure 4 This is merely an example of terminal 4 and does not constitute a limitation on terminal 4. It may include more or fewer components than shown, or combine certain components, or different components. For example, the terminal may also include input / output devices, network access devices, buses, etc.

[0142] The processor 40 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0143] The memory 41 can be an internal storage unit of the terminal 4, such as a hard disk or memory of the terminal 4. The memory 41 can also be an external storage device of the terminal 4, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the terminal 4. Furthermore, the memory 41 can include both internal storage units and external storage devices of the terminal 4. The memory 41 is used to store the computer program and other programs and data required by the terminal. The memory 41 can also be used to temporarily store data that has been output or will be output.

[0144] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0145] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0147] In the embodiments provided by this invention, it should be understood that the disclosed devices / terminals and methods can be implemented in other ways. For example, the device / terminal embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0149] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0150] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various software licensing method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0151] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A software licensing method, characterized in that, include: Obtain the first product model sent when the application is first launched on the target device; The first software license information in the kernel driver compiled into the target device is restored to the first ciphertext by inverse operation of salt encryption technology, and the first ciphertext is decrypted using a public key to obtain the first software license information; the first ciphertext is ciphertext including the first software license information; the first software license information includes the second product model; Determine whether the first product model and the second product model match; If the first product model and the second product model do not match, the connection with the application is disconnected; If the first product model and the second product model match, the first ciphertext is encrypted with a random key and then sent to the application, so that the application can decrypt the encrypted first ciphertext to obtain the first software authorization information and authorize the application with the first software authorization information.

2. The software licensing method according to claim 1, characterized in that, The acquisition of the first product model sent when the application is first launched on the target device includes: When the application is first launched on the target device, a key exchange is performed with the application based on the key exchange algorithm to generate a random key; Obtain the encrypted authorization request sent by the application; The authorized request ciphertext is decrypted using the random key to obtain a second ciphertext, and the second ciphertext is then decrypted using the public key to obtain the product model and hash digest in the second ciphertext; If the product model in the second ciphertext matches the hash digest, then the product model in the second ciphertext is used as the first product model; If the product model and hash digest in the second ciphertext do not match, the connection with the application is disconnected.

3. The software licensing method according to claim 2, characterized in that, When the application is first launched on the target device, a key exchange is performed with the application based on a key exchange algorithm to generate a random key, including: Obtain a first key and a second key sent by the application when it is first launched on the target device; wherein, the first key is a key randomly generated by the application using the Diffie-Hellman key exchange algorithm, the second key is a key synthesized from the first key and the third key, and the third key is a key randomly generated by the application using the Diffie-Hellman key exchange algorithm; A fourth key is randomly generated according to the Diffie-Hellman key exchange algorithm, and the random key is synthesized using the fourth key and the second key; A fifth key is synthesized using the fourth key and the first key, and the fifth key is sent to the application so that the application can synthesize the random key based on the fifth key and the third key.

4. The software licensing method according to claim 1, characterized in that, Before decrypting the first ciphertext using a public key to obtain the first software authorization information, the method further includes: The public key compiled into the kernel driver is restored by inverse operation of salting encryption technology.

5. The software licensing method according to claim 1, characterized in that, Prior to obtaining the first product model sent when the application is first launched on the target device, the method further includes: The first software authorization information and its corresponding hash digest are concatenated to obtain the first information. The first information is then encrypted using a private key to obtain the first ciphertext. The private key and the public key are a pair. The first ciphertext is compiled into the kernel driver using salt encryption technology.

6. The software licensing method according to claim 1, characterized in that, Disconnecting from the application includes: Disconnect the netlink connection from the application.

7. A software licensing method, characterized in that, include: When the application is first launched on the target device, the first product model compiled in the application is restored to the second ciphertext through the inverse operation of salt encryption technology. The second ciphertext is the ciphertext of the second information. The second information is obtained by concatenating the first product model and the hash digest corresponding to the first product model. The second ciphertext is encrypted using a random key to obtain an authorization request ciphertext, which is then sent to the kernel driver of the target device. The kernel driver determines whether the first product model in the authorization request ciphertext matches the second product model in the first software license information. If they match, the encrypted first ciphertext is returned; otherwise, the connection with the application is disconnected. The first ciphertext is an ciphertext that includes the first software license information. If the returned encrypted first ciphertext is detected, the encrypted first ciphertext is decrypted to obtain the first software authorization information, and the application is authorized using the first software authorization information; When a disconnection from the kernel driver is detected, it is determined that the application is not authorized.

8. The software licensing method according to claim 7, characterized in that, The step of decrypting the encrypted first ciphertext to obtain the first software authorization information includes: Based on the aforementioned random key and symmetric encryption algorithm, the encrypted first ciphertext is decrypted, and the first ciphertext is then decrypted using the public key to obtain the software authorization information and hash digest. Determine whether the software authorization information in the first ciphertext matches the hash digest. If the software authorization information in the first ciphertext matches the hash digest, then use the software authorization information in the first ciphertext as the first software authorization information. If the software license information in the first ciphertext does not match the hash digest, the connection with the kernel driver is disconnected.

9. The software licensing method according to claim 7, characterized in that, Before the inverse operation of restoring the first product model compiled in the application to the second ciphertext using salted encryption, the method further includes: When the application is first launched on the target device, a key exchange is performed with the kernel driver based on the Diffie-Hellman key exchange algorithm to generate a random key.

10. A device, characterized in that, The operating system of the device includes a kernel space and a user space; the kernel driver runs in the kernel space and executes the method as described in claims 1 to 6; the application runs in the user space and executes the method as described in claims 7 to 9.

Images