Software tamper-proofing method and lightweight electronic equipment

Abstract

The embodiment of the invention provides a software tamper-proofing method and lightweight electronic equipment, and relates to the field of digital integrated circuit design and software security anti-counterfeiting, the method comprises the following steps: when software authorizes the current lightweight electronic equipment, initiating a challenge to a PUF chip based on a preset initial value, receiving a first response value obtained by the PUF chip in response, taking the first response value as a secret key, and performing cryptographic operation on the secret key and first specific information representing software uniqueness to obtain an authentication message; in the initialization loading process of any software to be operated in the current lightweight electronic equipment, execution is completed according to verification steps set by the software to be operated, and an execution result is obtained; and determining whether the to-be-operated software continues to be loaded or not based on the execution result and the authentication message. The to-be-run software continues to run normally after verification; and if the verification is not passed, stopping operation. The loaded and operated software is ensured not to be tampered, and the authenticity, legality and integrity of the operated software are verified.

Description

Technical Field

[0001] The present invention relates to the fields of digital integrated circuit design and software security anti-counterfeiting, and particularly relates to a software anti-tampering method and a lightweight electronic device. Background Art

[0002] During the use of software, there are risks that the program is tampered with and invaded, malicious code is injected, the normal operation of the device is interfered with, and sensitive data and user privacy data are stolen. Some security protection measures need to be adopted to prevent the risk of program invasion and tampering and maintain the security and integrity of the software. To protect the security of software use and prevent malicious tampering and invasion, the commonly used method at present is the digital signature technology implemented by using the asymmetric algorithm to prevent the application software from being tampered with.

[0003] In the process of implementing the present invention, the applicant found that there are at least the following problems in the prior art:

[0004] 1. The asymmetric algorithm system is huge and requires the support of a matching CA to implement the verification of the identity of the digital certificate, and the digital certificate also needs to be paid annually for use; 2. For the asymmetric algorithm, the resource overhead of the password calculation process is too large and is not suitable for lightweight electronic devices with limited hardware resources, such as Internet of Things terminals; Therefore, for lightweight electronic devices with limited hardware resources, how to use their limited hardware resources to ensure the security of digital certificates, and how to prevent digital certificates from being tampered with or replaced with forged signature information and verify the legality of the certificate verification program are the current technical problems. Summary of the Invention

[0005] The embodiments of the present invention provide a software anti-tampering method and a lightweight electronic device, which can solve the technical problems in the prior art of how to use the limited hardware resources of lightweight electronic devices with limited hardware resources to ensure the security of the secret key, and how to prevent the secret key from being tampered with or replaced with forged signature information and verify the legality of the certificate verification program.

[0006] To achieve the above object, on the one hand, the embodiments of the present invention provide a software anti-tampering method, the software is applied in a lightweight electronic device in an open network environment, the types of the lightweight electronic devices include Internet of Things terminals and / or embedded terminals, the lightweight electronic device is built-in with a PUF chip, and the software anti-tampering method includes:

[0007] Authorization stage: For the software applied in the current lightweight electronic device, when the software is authorized to the current lightweight electronic device, a challenge is initiated to the PUF chip built into the current lightweight electronic device based on a preset initial value in the software, a first response value obtained by the PUF chip in response based on the preset initial value in the software is received, the first response value is used as a secret key, and a password operation is performed on the secret key and a first specific information representing the uniqueness of the software to obtain an authentication message, and the authentication message is saved in the non-volatile memory of the current lightweight electronic device; wherein, the PUF chip has the characteristics of an unclonable physical function, and when the same challenge value is challenged to different PUF chips, the response values obtained by each PUF chip in response to the challenge are all different;

[0008] Verification stage: During the initialization and loading process of any software to be run in the current lightweight electronic device, according to the verification steps set by the software to be run, a challenge is initiated to the PUF chip based on a preset initial value in the software to be run, a second response value obtained by the PUF chip in response based on the preset initial value in the software to be run is received, and a step of performing a password operation on the second response value and a second specific information representing the uniqueness of the software to be run is executed, and the execution result is obtained after the execution is completed;

[0009] Based on the execution result and the authentication message, it is determined whether the software to be run continues to be loaded.

[0010] On the other hand, an embodiment of the present invention provides a lightweight electronic device. The lightweight electronic device is in an open network environment. The types of the lightweight electronic device include Internet of Things terminals and / or embedded terminals. The lightweight electronic device is built with a PUF chip and a non-volatile memory, and there is an authorized software for authorizing the use of the lightweight electronic device in the lightweight electronic device; wherein:

[0011] The authorized software, when applied to the current lightweight electronic device and authorized to the current lightweight electronic device, initiates a challenge to the PUF chip based on a preset initial value in the authorized software, receives a first response value obtained by the PUF chip in response based on the preset initial value in the software, uses the first response value as a secret key, and performs a password operation on the secret key and a first specific information representing the uniqueness of the authorized software to obtain an authentication message;

[0012] The PUF chip is used to obtain a first response value in response based on a preset initial value in the authorized software when the authorized software authorizes the current lightweight electronic device; wherein, the PUF chip has the characteristics of an unclonable physical function, and when the same challenge value is challenged to different PUF chips, the response values obtained by each PUF chip in response to the challenge are all different;

[0013] The non-volatile memory is used to store the authentication message of the authorized software;

[0014] Any software to be run is used to, during the process of initializing and loading in the current lightweight electronic device, according to the verification steps set by the software to be run, initiate a challenge to the PUF chip based on a preset initial value in the software to be run, receive a second response value obtained by the PUF chip in response based on the preset initial value in the software to be run, and perform a cryptographic operation on the second response value and a second specific information characterizing the uniqueness of the software to be run, and obtain an execution result after completion;

[0015] The PUF chip is further used to, during the process of initializing and loading the software to be run in the current lightweight electronic device, obtain a second response value in response based on the preset initial value in the software to be run;

[0016] The software to be run determines whether to continue loading based on the execution result and the authentication message.

[0017] The above technical solution has the following beneficial effects: A PUF chip is built into the lightweight electronic device, and the physical non-replicable and non-clonable characteristics of the PUF chip are utilized as the trust root (trusted root) of the lightweight electronic device hardware to generate a unique and invisible encryption key. During the software design process, a trusted integrity and authenticity check mechanism is introduced to generate the proprietary authentication information of each software application in the lightweight electronic device. The authentication information of the same software in different individual lightweight electronic devices is also different. During the process of initializing and loading the software in the lightweight electronic device, it is necessary to perform calculations through a matching PUF chip, perform a cryptographic operation with the specific information characterizing the software uniqueness in the software to be run to obtain verification information. After comparing the verification information and the verification information passes, the software to be run continues to run normally; if the trusted verification fails, the software to be run terminates. It realizes the verification of the authenticity, legality and integrity of the running software, ensures that the software can run normally, ensures that the loaded and running software has not been tampered with, and prevents the software implanted with a Trojan from running. Generating the encryption key and authentication information does not require a large amount of hardware resources, can prevent the key from being tampered with by others, and can also prevent the key from being replaced and used with forged signature information to pass the verification. Description of the Drawings

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0019] Figure 1 is a flowchart of a software anti-tampering method according to an embodiment of the present invention;

[0020] Figure 2 is a logical structure diagram of a lightweight electronic device according to an embodiment of the present invention;

[0021] Figure 3 is a logical flowchart of generating authentication information in the authorization stage of the software anti-tampering method according to an embodiment of the present invention;

[0022] Figure 4 is a logical flowchart of generating verification information in the verification stage of the software anti-tampering method according to an embodiment of the present invention. Specific embodiments

[0023] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0024] As Figure 1 shown, in combination with the embodiments of the present invention, a software anti-tampering method is provided. The software is applied to a lightweight electronic device in an open network environment. The types of lightweight electronic devices include Internet of Things terminals and / or embedded terminals. The lightweight electronic device is built-in with a PUF chip. The software anti-tampering method includes:

[0025] Authorization stage: For the software applied to the current lightweight electronic device, when the software authorizes to the current lightweight electronic device, a challenge is initiated to the PUF chip built into the current lightweight electronic device based on a preset initial value in the software. The first response value obtained by the PUF chip in response to the preset initial value in the software is received. The first response value is used as the secret key. The secret key and the first specific information representing the uniqueness of the software are subjected to a cryptographic operation to obtain an authentication message, and the authentication message is saved in the non-volatile memory of the current lightweight electronic device; wherein, the PUF chip has the characteristics of an unclonable physical function. When the same challenge value is initiated to different PUF chips, the response values obtained by each PUF chip in response to the challenge are all different.

[0026] Verification phase: During the initialization and loading process of any software to be run in the current lightweight electronic device, in accordance with the verification steps set by the software to be run, a challenge is sent to the PUF chip based on the preset initial value in the software to be run, and the second response value obtained by the PUF chip in response based on the preset initial value in the software to be run is received. The step of performing cryptographic operations on the second response value and the second specific information characterizing the uniqueness of the software to be run is executed, and the execution result is obtained after completion.

[0027] Determine whether the software to be run continues to be loaded based on the execution result and the authentication message.

[0028] A software anti-tampering method according to an embodiment of the present invention is applicable to software anti-tampering authorization in lightweight electronic devices in an open network environment. Lightweight mainly means that the quantity or capacity of the own hardware resources of the electronic device is limited and the security protection ability is relatively weak. Limited by its own resources, the types of lightweight electronic devices include Internet of Things terminals and / or embedded terminals.

[0029] A PUF chip is built into the lightweight electronic device. Utilizing the physical non-replicable and non-clonable characteristics of the PUF chip, as the trust root (trusted root) of the lightweight electronic device hardware, a unique and invisible encryption key is generated. During the software design process, a trusted integrity and authenticity check mechanism is introduced to generate the proprietary authentication information for each software application in the lightweight electronic device. The authentication information of the same software in different individual lightweight electronic devices is also different. During the initialization and loading process of the software in the lightweight electronic device, calculations need to be performed through the matching PUF chip, and cryptographic operations are performed with the specific information characterizing the uniqueness of the software to be run to obtain verification information. After comparing the verification information and the verification information passes, the software to be run continues to run normally; if the trusted verification fails, the software to be run terminates. Realize the authenticity, legality and integrity of the verified running software, ensure that the software can run normally, ensure that the loaded and running software has not been tampered with, and prevent the software implanted with Trojans from running. Generating encryption keys and authentication information does not require a large amount of hardware resources, can prevent the keys from being tampered with by others, and can also prevent the keys from being replaced with forged signature information to pass the verification.

[0030] Preferably, the initial preset value is agreed upon before the software is released, and the initial preset values of the same software installed in different lightweight electronic devices are the same.

[0031] Preferably, as Figure 3As shown in the figure, authorization stage: When the software authorizes the current lightweight electronic device, it collects the first digest corresponding to the first file in each software directory level by level according to the software directory, and forms the first specific information based on each first digest; The authorization stage occurs at the software factory stage and runs once during the software life cycle to generate an authentication message. The verification stage occurs during the running stage of each software startup. At this time, the authentication information generated during authorization is used as the benchmark reference for dynamic trusted verification calculation and comparison of the software during the software startup process. According to the directory file generated during software installation, the digest (hash calculation result) of each file (i.e., the first file, also known as the original text for authentication calculation, where the first is to distinguish from the second in the second file during the verification stage) in each software directory is collected level by level. The first specific information formed based on each first digest is also unique and difficult to repeat, which can ensure the uniqueness and distinctiveness of the authentication information and provide protection for software anti-tampering; All digests are unique and relatively complex, but can be implemented with fewer hardware resources; It serves two purposes at once.

[0032] Among them, when the first file includes the first log file and / or the first configuration file, the corresponding first digest is not collected for the first log file, and the corresponding first digest is not collected for the first configuration file; Because the log file is uncertain, and the configuration file is also uncertain. As long as one of them is used, it will cause the non-uniqueness of the authentication information, and it will also cause the verification in the verification stage to be non-unique due to the non-uniqueness of the information; This will result in software that has been authorized unable to pass the verification, which is obviously unreasonable. Therefore, the first file does not include any of the two.

[0033] As Figure 4 shown, verification stage: During the initialization and loading process of any software to be run in the current lightweight electronic device, according to the verification steps set by the software to be run, it executes the collection of the second digest corresponding to each second file in each directory of the software to be run level by level according to the software directory, and forms the second specific information based on each second digest in the same way as forming the first specific information; Among them, when the second file includes the second log file and / or the second configuration file, the corresponding second digest is not collected for the second log file, and the corresponding second digest is not collected for the second configuration file. Forming the second specific information based on each second digest in the same way as forming the first specific information aims to ensure that for the software authorized in the current lightweight electronic device, during the verification stage, the verification information formed is naturally consistent with the authentication information so that it can pass the verification.

[0034] Preferably, as Figure 3 shown, in the authorization stage, forming the first specific information based on each first digest specifically includes:

[0035] Calculate each first digest separately and convert it into the BASE64 encoding form or the hexadecimal character form to obtain the corresponding first digest conversion value. Concatenate all the first digest conversion values to obtain the first digest concatenation value. Sort all the characters of the first digest concatenation value in the order of ASCII code to form the first specific information. Since the first digest is a hashing result and the concatenation order of all the first digests may be different, calculating and converting each first digest into the BASE64 encoding form or the hexadecimal character form separately reduces the types of characters in the first digest concatenation value. Sorting all the characters in the order of ASCII code makes the arrangement of all the characters in the first specific information regular, ensuring that for the software authorized in the current lightweight electronic device, during the verification phase, the verification information formed naturally has to be consistent with the authentication information so as to pass the verification.

[0036] As Figure 4 shown, during the verification phase, based on each second digest, form the second specific information in the manner of forming the first specific information, specifically including:

[0037] Calculate each second digest separately and convert it into the BASE64 encoding form or the hexadecimal character form to obtain the corresponding second digest conversion value. Concatenate all the second digest conversion values to obtain the second digest concatenation value. Sort all the characters of the second digest concatenation value in the order of ASCII code to form the second specific information.

[0038] Preferably, as Figure 3 shown, during the authorization phase, perform a cryptographic operation on the secret key and the first specific information representing the uniqueness of the software to obtain the authentication message, specifically including:

[0039] Perform HMAC calculation on the encrypted secret key and the first specific information representing the uniqueness of the software to obtain the authentication message. Performing HMAC calculation is a cryptographic operation and is irreversible, which avoids the authentication message from being cracked.

[0040] As Figure 4 shown, during the verification phase, according to the verification steps set for the software to be run, execute the step of initiating a challenge to the PUF chip based on the preset initial value in the software to be run to obtain the second response value, and perform a cryptographic operation on the second response value and the second specific information representing the uniqueness of the software to be run. After the execution is completed, obtain the execution result, specifically including:

[0041] If the software to be run has a preset initial value, perform the step of initiating a challenge to the PUF chip based on the preset initial value in the software to be run, obtaining a second response value, performing HMAC calculation on the second response value and the second specific information characterizing the uniqueness of the software to be run to obtain a verification message, and using the verification message as the execution result; if the software to be run has a preset initial value, the verification step can be executed, performing the same HMAC calculation as generating the authentication message to generate a verification message for authenticating the software to be run. After comparing the verification message and the verification message passes, the software to be run continues to run normally; if the trusted verification fails, the software to be run terminates. Realize the authenticity, legality, and integrity of the verified software, ensure that the software can run normally, ensure that the loaded and running software has not been tampered with, and prevent the software from being implanted with Trojans and unable to run.

[0042] Alternatively, if the software to be run does not have a preset initial value, report an error when initiating a challenge to the PUF chip based on the preset initial value in the software to be run, and use the error as the execution result; naturally terminate the software to be run according to the error; realize the authenticity, legality, and integrity of the verified software, ensure that the software can run normally, ensure that the loaded and running software has not been tampered with, and prevent the software from being implanted with Trojans and unable to run.

[0043] Preferably, in the authorization phase, initiating a challenge to the PUF chip built into the current lightweight electronic device based on the preset initial value in the software specifically includes:

[0044] Use the preset initial value in the software as a challenge value to initiate a challenge to the PUF chip built into the current lightweight electronic device to obtain a first intermediate value. Loop a preset number of times and use the first intermediate value as the challenge value to initiate a challenge to the PUF chip to obtain a first response value; that is, use each response value as the challenge value to challenge the PUF chip again. After looping a preset number of times like this, obtain the response value as the first response value, increasing the randomness of the challenge value and increasing the difficulty of authentication verification. In the verification phase, initiating a challenge to the PUF chip based on the preset initial value in the software to be run to obtain a second response value specifically includes:

[0045] When it is determined that the software to be run has a preset initial value, the preset initial value in the software to be run is used as a challenge value to initiate a challenge to the PUF chip to obtain a second intermediate value. The second intermediate value is used as a challenge value to initiate a challenge to the PUF chip for a preset number of times to obtain a second response value. That is, each response value is used as a challenge value to challenge the PUF chip again. After such a cycle for a preset number of times, the obtained response value is used as the second response value. The number of cycles is the same as that during authorization. When the authorized software is running, it will naturally make the verification information the same as the authentication information and pass the verification. For unauthorized software or tampered software, the randomness of the challenge value is increased to prevent the tampered software from passing the verification and being loaded and run.

[0046] Preferably, in the verification stage:

[0047] When the execution result is the verification information, the verification information is compared with the authentication message. If the verification information is consistent with the authentication message, it indicates that the software to be run is the authorized software in the current lightweight electronic device, and the software to be run has been authorized and authorized successfully based on the PUF chip method verification in the current lightweight electronic device, and the software to be run continues to be loaded. If the verification information is inconsistent with the authentication message, it indicates that the software to be run has been modified, or the PUF chip is damaged, or the PUF chip has been replaced, and the software to be run terminates loading and exits automatically. Specifically, the inconsistency between the verification information and the authentication message indicates that the integrity, legality, and authenticity of the software have been damaged and are inconsistent with the application signature information generated when the software was released. There are two reasons: 1. The software has been modified, resulting in different calculated digests, and the authentication original text participating in the HMAC calculation has changed; 2. The PUF chip has been damaged or replaced, resulting in an inconsistent key generated with the key generated when the software was authorized and released. For authorized software during use, after being invaded and malicious code is injected, if it runs, it may steal user privacy data and sensitive data, or forge a legitimate device identity to attack the cloud system and cause damage. By preventing the maliciously tampered software from being loaded and run in the verification stage, the security of software use is guaranteed.

[0048] When the execution result is an error message, it indicates that the software to be run is not the authorized software in the current lightweight electronic device, and the software to be run has not been authorized based on the PUF chip method verification in the current lightweight electronic device. The software to be run terminates loading and exits automatically, which can very quickly prevent unauthorized illegal software from being loaded and run, thereby preventing illegal software from running on the current lightweight electronic device and performing illegal operations, such as stealing user privacy data and sensitive data.

[0049] Such as Figure 2As shown, in combination with an embodiment of the present invention, a lightweight electronic device is provided, the lightweight electronic device is in an open network environment, the type of the lightweight electronic device includes an Internet of Things terminal and / or an embedded terminal, the lightweight electronic device has a built-in PUF chip and a non-volatile memory, and the lightweight electronic device has an authorized software authorized to use the lightweight electronic device; wherein:

[0050] The authorization software is applied to the current lightweight electronic device and when authorizing the current lightweight electronic device, it challenges the PUF chip based on the preset initial value in the authorized software, receives the first response value obtained by the PUF chip responding based on the preset initial value in the software, uses the first response value as a secret key, performs a cryptographic operation on the secret key and the first specific information representing the uniqueness of the authorized software, and obtains an authentication message.

[0051] The PUF chip is used to respond to a first response value based on a preset initial value in the authorization software when the authorization software authorizes the current lightweight electronic device; wherein the PUF chip has the characteristic of an unclonable physical function, and when the same challenge value is challenged to different PUF chips, the response values ​​obtained by each PUF chip in response to the challenge are different.

[0052] Non-volatile memory, used to store authentication information of authorized software.

[0053] Any software to be run is used to, during the process of initialization loading in the current lightweight electronic device, execute the steps of challenging the PUF chip based on the preset initial value in the software to be run according to the verification steps set by the software to be run, receiving the second response value obtained by the PUF chip responding based on the preset initial value in the software to be run, performing a cryptographic operation on the second response value and the second specific information representing the uniqueness of the software to be run, and obtaining the execution result after completion.

[0054] The PUF chip is also used to respond to obtain a second response value based on a preset initial value in the software to be run during the process of initializing and loading the software to be run in the current lightweight electronic device.

[0055] The software to be run determines whether to continue loading the software to be run based on the execution result and the authentication message.

[0056] A PUF chip is built into the lightweight electronic device. By leveraging the physical non-replicability and non-clonability characteristics of the PUF chip, it serves as the trust root (trusted root) of the lightweight electronic device's hardware, generating a unique and invisible encryption key. During the software design process, a trusted integrity and authenticity check mechanism is introduced. When software is authorized within the lightweight electronic device, proprietary authentication information for each software application within the lightweight electronic device is generated. The authentication information for the same software in different individuals' lightweight electronic devices is also different. During the initialization and loading process of the software within the lightweight electronic device, calculations need to be performed through a matching PUF chip. Cryptographic operations are carried out with specific information representing the uniqueness of the software within the software to be run, obtaining verification information. After comparing the verification information and passing the verification, the software to be run continues to operate normally, and this software to be run is authorized software. If the trusted verification fails, the software to be run terminates. It realizes the verification of the authenticity, legality, and integrity of the running software, ensures that the software can operate normally, and ensures that the loaded and running software has not been tampered with and that software implanted with Trojans cannot run. Generating the encryption key and authentication information does not require a large amount of hardware resources, can prevent the key from being tampered with by others, and can also prevent the key from being replaced and used with forged signature information to pass the verification.

[0057] Preferably, the authorized software is also used to, when authorizing the current lightweight electronic device, collect the first digest corresponding to the first file in each directory of the authorized software level by level according to the software directory, and form the first specific information based on each first digest; the authorization stage occurs during the software factory stage and runs once during the software life cycle, generating an authentication message. The verification stage occurs during the running stage of each software startup. At this time, the authentication information generated during authorization is used as the reference benchmark for dynamic trusted verification calculations and comparisons during the software startup process. According to the directory files generated during software installation, the digest (hash calculation result) of each file (i.e., the first file, also known as the original text for authentication calculation, where the first is to distinguish it from the second in the second file during the verification stage) in each directory of the software is collected level by level. The first specific information formed based on each first digest is also unique and difficult to repeat, which can ensure the uniqueness and distinctiveness of the authentication information and provide protection against software tampering; all digests are unique and relatively complex, but can be implemented with less hardware resources; killing two birds with one stone.

[0058] Among them, when the first file includes a first log file and / or a first configuration file, the corresponding first digest is not collected for the first log file, and the corresponding first digest is not collected for the first configuration file. Because the log file has uncertainty, and the configuration file also has uncertainty, using either of them will cause the non-uniqueness of the authentication information, and will also cause the verification in the verification stage due to the non-uniqueness of the information. As a result, software that has been authorized cannot pass the verification, which is obviously unreasonable. Therefore, the first file does not include any of the two.

[0059] The software to be run is also used to execute the step of collecting the second digest corresponding to each second file in each directory of the software to be run level by level according to the software directory during the initialization and loading process in the current lightweight electronic device, and form the second specific information based on each second digest in the same way as forming the first specific information. Forming the second specific information based on each second digest in the same way as forming the first specific information aims to ensure that for the software authorized in the current lightweight electronic device, the verification information formed during the verification stage is naturally consistent with the authentication information so that it can pass the verification. Among them, when the second file includes a second log file and / or a second configuration file, the corresponding second digest is not collected for the second log file, and the corresponding second digest is not collected for the second configuration file.

[0060] The authorized software is also used to calculate and convert each first digest into the BASE64 encoding form or the hexadecimal character form respectively when authorizing the current lightweight electronic device, obtain the corresponding first digest conversion value, splice all the first digest conversion values to obtain the first digest splicing value, and sort all the characters of the first digest splicing value in the order of ASCII code to form the first specific information. Because the first digest is a hashing result, and the splicing order of all first digests may be different; calculating and converting each first digest into the BASE64 encoding form or the hexadecimal character form respectively reduces the types of characters in the first digest splicing value; sorting all the characters in the order of ASCII code makes the arrangement of all characters in the first specific information regular, ensuring that for the software authorized in the current lightweight electronic device, the verification information formed during the verification stage is naturally consistent with the authentication information so that it can pass the verification.

[0061] The software to be run is also used to calculate and convert each second digest into the BASE64 encoding form or the hexadecimal character form respectively during the initialization and loading process in the current lightweight electronic device of the software to be run, obtain the corresponding second digest conversion value, splice all the second digest conversion values to obtain the second digest splicing value, and sort all the characters of the second digest splicing value in the order of ASCII code to form the second specific information.

[0062] Preferably, the authorized software is specifically used to perform HMAC calculation on the encryption key and the first specific information representing the uniqueness of the software when authorizing the current lightweight electronic device to obtain an authentication message. The use of HMAC calculation is a cryptographic operation with irreversibility, which can prevent the authentication message from being cracked.

[0063] The software to be run is specifically used to, when there is a preset initial value in the software to be run, initiate a challenge to the PUF chip based on the preset initial value in the software to be run, receive the second response value obtained by the PUF chip in response to the preset initial value in the software to be run, perform HMAC calculation on the second response value and the second specific information representing the uniqueness of the software to be run to obtain a verification message, and use the verification message as the execution result. If there is a preset initial value in the software to be run, the verification step can be executed. The same HMAC calculation as that for generating the authentication message is performed to generate a verification message for authenticating the software to be run. After comparing the verification message and the verification message passes, the software to be run continues to run normally. If the trusted verification fails, the software to be run terminates. This realizes the verification of the authenticity, legality, and integrity of the software, ensures that the software can run normally, and ensures that the loaded and running software has not been tampered with and that software implanted with Trojans cannot run.

[0064] Alternatively, when there is no preset initial value in the software to be run, an error is reported when initiating a challenge to the PUF chip based on the preset initial value in the software to be run, and the error is used as the execution result. The software to be run can be terminated naturally according to the error. This realizes the verification of the authenticity, legality, and integrity of the software, ensures that the software can run normally, and ensures that the loaded and running software has not been tampered with and that software implanted with Trojans cannot run.

[0065] When the execution result is verification information, compare the verification information with the authentication message; if the verification information is consistent with the authentication message, it indicates that the software to be run is the authorized software in the current lightweight electronic device, and the software to be run has been authorized and authorized successfully based on the PUF chip method verification in the current lightweight electronic device, and the software to be run continues to be loaded; if the verification information is inconsistent with the authentication message, it indicates that the software to be run has been modified, or the PUF chip is damaged, or the PUF chip has been replaced, and the software to be run terminates loading and exits automatically; specifically, the inconsistency between the verification information and the authentication message indicates that the integrity, legality, and authenticity of the software have been damaged, which is inconsistent with the application signature information generated when the software was released. There are two reasons: 1. The software has been modified, resulting in different calculated digests, and the original authentication text participating in the HMAC calculation has changed; 2. The PUF chip has been damaged or replaced, resulting in the generated key being inconsistent with the key generated when the software was authorized and released. For the authorized software during use, after being invaded and malicious code is injected, if it runs, it may steal user privacy data and sensitive data, or forge the identity of a legitimate device to attack the cloud system and cause damage. By preventing the maliciously tampered software from being loaded and run during the verification stage, the security of software use is ensured.

[0066] When the execution result is an error, it indicates that the software to be run is not the authorized software in the current lightweight electronic device, and the software to be run has not been authorized based on the PUF chip method verification in the current lightweight electronic device. The software to be run terminates loading and exits automatically, which can very quickly prevent the unauthorized illegal software from being loaded and run, thereby preventing the illegal software from running on the current lightweight electronic device and performing illegal operations, such as stealing user privacy data and sensitive data.

[0067] Preferably, the PUF chip is also used to respond to the preset initial value in the authorized software when the authorized software authorizes the current lightweight electronic device, obtain the first intermediate value, and respond based on the first intermediate value as the challenge value for a preset number of times to obtain the first response value; that is, use each response value as the challenge value to challenge the PUF chip again. After such a cycle for a preset number of times, the obtained response value is used as the first response value, increasing the randomness of the challenge value and being used to increase the difficulty of authentication verification.

[0068] During the initialization and loading process within the current lightweight electronic device, when it is determined that the software to be run has a preset initial value, the preset initial value within the software to be run is responded to obtain a second intermediate value. The preset number of times is looped, and responses are made based on the second intermediate value as the challenge value to obtain a second response value. That is, each response value is used as the challenge value to challenge the PUF chip. After looping the preset number of times, the response value obtained is used as the second response value. The number of loops is the same as the number of times during authorization. When running authorized software, it will naturally make the verification information the same as the authentication information and pass the verification. For unauthorized software or tampered software, the randomness of the challenge value is increased to prevent the tampered software from passing the verification and being loaded and run.

[0069] In summary, for the software within the current lightweight electronic device, the complete, trustworthy, and authenticity verification is the core of the anti-tampering mechanism, the foundation of identity authentication and communication security, and the prerequisite for software usage security. The authenticity, integrity, and credibility of the software depend on the root trust and key security.

[0070] In the embodiments of the present invention, trusted root verification and inspection are adopted. The principle of trusted root verification and inspection is as follows: For the software applied to the current lightweight electronic device, the lightweight electronic device is built-in with a PUF chip, which serves as the trust root (trusted root) of the lightweight electronic device hardware. By utilizing the physical non-clonable function of the PUF chip, which has the characteristics of physical non-replicability and non-clonability, a unique, random, and invisible key is created as the key for HMAC calculation. This key is used to perform HMAC calculation with the specific information representing the uniqueness of the software to generate authentication information, which is then stored in the non-volatile memory of the device. During the initialization process of any software running in the current lightweight electronic device, the same cryptographic operation needs to be performed and compared with the authentication information pre-stored in the non-volatile memory. The verification information is compared with the authentication message. If the verification information is consistent with the authentication message, it indicates that the software to be run is the authorized software in the current lightweight electronic device, and the software to be run has been authorized and authorized successfully based on the PUF chip method in the current lightweight electronic device, and the software to be run continues to be loaded. If the verification information is inconsistent with the authentication message, it indicates that the software to be run has been modified, or the PUF chip is damaged, or the PUF chip has been replaced, and the software to be run terminates loading and exits automatically. For the authorized software during use, after being invaded and malicious code is injected, if it runs, it may steal user privacy data and sensitive data, or forge the identity of a legitimate device to attack the cloud system and cause damage. Through the verification stage, the software that has been maliciously tampered with is prevented from being loaded and run, ensuring the security of software use. When the execution result is an error, it indicates that the software to be run is not the authorized software in the current lightweight electronic device, and the software to be run has not been authorized based on the PUF chip method in the current lightweight electronic device. The software to be run terminates loading and exits automatically, which can very quickly prevent the unauthorized illegal software from being loaded and run, thereby preventing the illegal software from running on the current lightweight electronic device and performing illegal operations, such as stealing user privacy data and sensitive data.

[0071] The lightweight electronic device of the embodiments of the present invention binds the software with the PUF chip, turning the original general software into a proprietary program software bound with the PUF chip, enabling the electronic device to have the capabilities of anti-counterfeiting authentication, preventing product replication and plagiarism. By utilizing the physical non-clonable characteristics of the PUF chip, it solves the problem of insecure storage of the root key and hardware identifier of electronic products, simplifies the key management and usage process, strengthens the verification of the authenticity, legality, and integrity of the software, improves the security of software operation, and lays a true and trustworthy foundation for subsequent identity authentication and communication security. Only the electronic device with the PUF chip and exclusive authentication information used for signing can run the software securely.

[0072] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of an exemplary method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process can be rearranged without departing from the scope of the present disclosure. The appended method claims present the elements of the various steps in an exemplary order and are not intended to be limited to the specific order or hierarchy recited.

[0073] In the foregoing detailed description, various features are combined in a single embodiment to simplify the present disclosure. This method of disclosure should not be interpreted as reflecting an intention that the embodiments of the claimed subject matter require more features than are expressly recited in each claim. Rather, as reflected in the appended claims, the invention lies in less than all of the features of a single disclosed embodiment. Accordingly, the appended claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

[0074] The above-described disclosed embodiments are described to enable any person skilled in the art to make or use the present invention. For those skilled in the art, various modifications to these embodiments are obvious, and the general principles defined herein can be applied to other embodiments without departing from the spirit and scope of the present disclosure. Therefore, the present disclosure is not limited to the embodiments given herein, but is consistent with the broadest scope of the principles and novel features disclosed in this application.

[0075] The foregoing description includes examples of one or more embodiments. Of course, it is not possible to describe all possible combinations of components or methods for the purpose of describing the above embodiments, but those of ordinary skill in the art should recognize that each embodiment can be further combined and arranged. Accordingly, the embodiments described herein are intended to cover all such changes, modifications, and variations that fall within the scope of the appended claims. In addition, with respect to the term "comprising" used in the specification or claims, this term is inclusive in a manner similar to the term "including" as interpreted when used as a transitional word in a claim. In addition, any use of the term "or" in the claims or specification is intended to mean "non-exclusive or."

[0076] Those skilled in the art can also understand that the various illustrative logical blocks, units, and steps listed in the embodiments of the present invention can be implemented by electronic hardware, computer software, or a combination of both. To clearly show the interchangeability of hardware and software, the above various illustrative components, units, and steps have been generally described in terms of their functions. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art can use various methods to implement the described functions for each specific application, but such implementation should not be construed as exceeding the scope of protection of the embodiments of the present invention.

[0077] In the embodiments of the present invention, the various illustrative logical blocks or units can be implemented or operated to perform the described functions by a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of the above designs. The general-purpose processor can be a microprocessor, and optionally, the general-purpose processor can also be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0078] The steps of the methods or algorithms described in the embodiments of the present invention can be directly embedded in hardware, software modules executed by a processor, or a combination of both. The software modules can be stored in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and the storage medium can be disposed in an ASIC, and the ASIC can be disposed in a user terminal. Optionally, the processor and the storage medium can also be disposed in different components of the user terminal.

[0079] In one or more exemplary designs, the functions described in embodiments of the present invention may be implemented in hardware, software, firmware, or any combination of the three. If implemented in software, these functions may be stored on a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. A computer-readable medium includes both computer storage media and communication media that facilitate transfer of a computer program from one place to another. The storage media may be any available media that can be accessed by a general or special purpose computer. By way of example, and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store program code in the form of instructions or data structures and that can be accessed by a general or special purpose computer, or a general or special purpose processor. Additionally, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless means such as infrared, radio, and microwave, it is included in the definition of computer-readable medium. Disk and disc include compact disk, laser disk, optical disk, DVD, floppy disk, and Blu-ray disk, where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0080] The specific embodiments described above further elaborate on the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above description is only for the specific embodiments of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A software anti-tampering method, characterized in that, the software is applied to a lightweight electronic device in an open network environment, the types of the lightweight electronic devices include Internet of Things terminals and / or embedded terminals, a PUF chip is built in the lightweight electronic device, and the software anti-tampering method includes: Authorization stage: For the software applied to the current lightweight electronic device, when the software authorizes the current lightweight electronic device, a challenge is initiated to the PUF chip built in the current lightweight electronic device based on a preset initial value in the software, a first response value obtained by the PUF chip in response to the preset initial value in the software is received, the first response value is used as a secret key, a password operation is performed on the secret key and a first specific information representing the uniqueness of the software to obtain an authentication message, and the authentication message is saved in the non-volatile memory of the current lightweight electronic device; wherein, the PUF chip has the characteristic of an unclonable physical function, and when the same challenge value is initiated to different PUF chips, the response values obtained by each PUF chip in response to the challenge are all different; Verification stage: During the initialization and loading process of any software to be run in the current lightweight electronic device, according to the verification steps set by the software to be run, a challenge is initiated to the PUF chip based on a preset initial value in the software to be run, a second response value obtained by the PUF chip in response to the preset initial value in the software to be run is received, and the steps of performing a password operation on the second response value and a second specific information representing the uniqueness of the software to be run are executed, and an execution result is obtained after completion; Based on the execution result and the authentication message, it is determined whether the software to be run continues to be loaded.

2. The software anti-tampering method according to claim 1, characterized in that, it includes: In the authorization stage: when the software authorizes the current lightweight electronic device, the first digest corresponding to the first file in each directory of the software is collected level by level according to the software directory, and the first specific information is formed based on each of the first digests; wherein, when the first file includes a first log file and / or a first configuration file, the corresponding first digest is not collected for the first log file, and the corresponding first digest is not collected for the first configuration file; In the verification stage: during the initialization and loading process of any software to be run in the current lightweight electronic device, according to the verification steps set by the software to be run, the second digest corresponding to each second file in each directory of the software to be run is collected level by level according to the software directory, and the second specific information is formed based on each of the second digests in the same way as the first specific information is formed; wherein, when the second file includes a second log file and / or a second configuration file, the corresponding second digest is not collected for the second log file, and the corresponding second digest is not collected for the second configuration file.

3. The software anti-tampering method according to claim 2, characterized in that, in the authorization stage, the forming of the first specific information based on each of the first digests specifically includes: Calculate each of the first digests and convert them into BASE64 encoding form or hexadecimal character form to obtain corresponding first digest conversion values. Concatenate all the first digest conversion values to obtain a first digest concatenated value. Sort all the characters of the first digest concatenated value in ASCII code order to form a first specific information; In the verification stage, forming the second specific information based on each of the second digests in the same way as forming the first specific information specifically includes: Calculate each of the second digests and convert them into BASE64 encoding form or hexadecimal character form to obtain corresponding second digest conversion values. Concatenate all the second digest conversion values to obtain a second digest concatenated value. Sort all the characters of the second digest concatenated value in ASCII code order to form a second specific information.

4. The software anti-tampering method according to claim 1, characterized in that, In the authorization stage, performing a cryptographic operation on the secret key and the first specific information representing the uniqueness of the software to obtain an authentication message, specifically including: Performing HMAC calculation on the encrypted secret key and the first specific information representing the uniqueness of the software to obtain an authentication message; In the verification stage, following the verification steps set for the software to be run, performing the step of initiating a challenge to the PUF chip based on a preset initial value in the software to be run to obtain a second response value, and performing a cryptographic operation on the second response value and the second specific information representing the uniqueness of the software to be run. After completion, the execution result is obtained, specifically including: If there is a preset initial value in the software to be run, perform the step of initiating a challenge to the PUF chip based on the preset initial value in the software to be run to obtain a second response value. Perform HMAC calculation on the second response value and the second specific information representing the uniqueness of the software to be run to obtain a verification message, and use the verification message as the execution result; Or, If there is no preset initial value in the software to be run, then report an error when initiating a challenge to the PUF chip based on the preset initial value in the software to be run, and use the error as the execution result.

5. The software anti-tampering method according to claim 1, characterized in that, In the authorization stage, initiating a challenge to the PUF chip built into the current lightweight electronic device based on the preset initial value in the software, specifically including: Using the preset initial value in the software as a challenge value to initiate a challenge to the PUF chip built into the current lightweight electronic device to obtain a first intermediate value. Use the first intermediate value as a challenge value to initiate a challenge to the PUF chip for a preset number of times to obtain a first response value; In the verification stage, initiating a challenge to the PUF chip based on the preset initial value in the software to be run to obtain a second response value, specifically including: When it is determined that the software to be run has a preset initial value, the preset initial value in the software to be run is used as a challenge value to initiate a challenge to the PUF chip to obtain a second intermediate value. The second intermediate value is used as a challenge value to initiate a challenge to the PUF chip for a preset number of times to obtain a second response value.

6. The software anti-tampering method according to claim 4, characterized in that in the verification stage: When the execution result is the verification information, the verification information is compared with the authentication message; if the verification information is consistent with the authentication message, it indicates that the software to be run is the authorized software in the current lightweight electronic device, and the software to be run is authorized and authorized successfully based on the PUF chip method verification in the current lightweight electronic device, and the software to be run continues to be loaded; if the verification information is inconsistent with the authentication message, it indicates that the software to be run has been modified or the PUF chip is damaged or the PUF chip has been replaced, and the software to be run terminates loading and exits automatically; When the execution result is the error message, it indicates that the software to be run is not the authorized software in the current lightweight electronic device, and the software to be run is not authorized based on the PUF chip method verification in the current lightweight electronic device, and the software to be run terminates loading and exits automatically.

7. A lightweight electronic device, characterized in that the lightweight electronic device is in an open network environment, the type of the lightweight electronic device includes an Internet of Things terminal and / or an embedded terminal, the lightweight electronic device is built-in with a PUF chip and a non-volatile memory, and the lightweight electronic device has authorized software for the lightweight electronic device to use; wherein: The authorized software, when applied to the current lightweight electronic device and authorized to the current lightweight electronic device, initiates a challenge to the PUF chip based on a preset initial value in the authorized software, receives a first response value obtained by the PUF chip in response to the preset initial value in the software, uses the first response value as a secret key, and performs a cryptographic operation on the secret key and a first specific information representing the uniqueness of the authorized software to obtain an authentication message; The PUF chip is used to obtain a first response value based on a preset initial value in the authorized software when the authorized software authorizes the current lightweight electronic device; wherein, the PUF chip has the characteristics of an unclonable physical function, and when the same challenge value is initiated to different PUF chips, the response values obtained by each PUF chip in response to the challenge are all different; The non-volatile memory is used to store the authentication message of the authorized software; Any software to be run is used to execute the steps of challenging the PUF chip based on a preset initial value in the software to be run according to the verification steps set by the software to be run during the initialization and loading process in the current lightweight electronic device, receiving a second response value obtained by the PUF chip in response based on the preset initial value in the software to be run, and performing a cryptographic operation on the second response value and second specific information representing the uniqueness of the software to be run, and obtaining an execution result after completion; The PUF chip is further used to obtain a second response value in response based on a preset initial value in the software to be run during the initialization and loading process of the software to be run in the current lightweight electronic device; The software to be run determines whether to continue loading based on the execution result and the authentication message.

8. The lightweight electronic device according to claim 7, wherein, The authorized software is further used to collect first digests corresponding to first files in each directory of the authorized software level by level according to the software directory when authorizing the current lightweight electronic device, and form first specific information based on each of the first digests; wherein, when the first file includes a first log file and / or a first configuration file, the corresponding first digest is not collected for the first log file, and the corresponding first digest is not collected for the first configuration file; The software to be run is further used to collect second digests corresponding to each second file in each directory of the software to be run level by level according to the software directory during the initialization and loading process of the software to be run in the current lightweight electronic device, and form second specific information based on each of the second digests in the same way as forming the first specific information; wherein, when the second file includes a second log file and / or a second configuration file, the corresponding second digest is not collected for the second log file, and the corresponding second digest is not collected for the second configuration file; The authorized software is further used to calculate and convert each of the first digests into a BASE64 encoded form or a hexadecimal character form when authorizing the current lightweight electronic device, obtain corresponding first digest conversion values, splice all the first digest conversion values to obtain a first digest splicing value, and sort all the characters of the first digest splicing value in ASCII code order to form first specific information; The software to be run is further used to calculate and convert each of the second digests into a BASE64 encoded form or a hexadecimal character form during the initialization and loading process of the software to be run in the current lightweight electronic device, obtain corresponding second digest conversion values, splice all the second digest conversion values to obtain a second digest splicing value, and sort all the characters of the second digest splicing value in ASCII code order to form second specific information.

9. The lightweight electronic device according to claim 7, wherein, The authorized software is specifically used for performing HMAC calculation on the encryption key and the first specific information representing the uniqueness of the software when authorizing the current lightweight electronic device, so as to obtain an authentication message; The software to be run is specifically used for, when there is a preset initial value in the software to be run, initiating a challenge to the PUF chip based on the preset initial value in the software to be run, receiving a second response value obtained by the PUF chip in response based on the preset initial value in the software to be run, performing HMAC calculation on the second response value and the second specific information representing the uniqueness of the software to be run, so as to obtain a verification information, and using the verification information as an execution result; or, when there is no preset initial value in the software to be run, reporting an error when initiating a challenge to the PUF chip based on the preset initial value in the software to be run, and using the reported error as an execution result; When the execution result is the verification information, comparing the verification information with the authentication message; if the verification information is consistent with the authentication message, it indicates that the software to be run is the authorized software in the current lightweight electronic device, and the software to be run has been authorized and authorized successfully based on the PUF chip method verification in the current lightweight electronic device, and the software to be run continues to be loaded; if the verification information is inconsistent with the authentication message, it indicates that the software to be run is not the authorized software in the current lightweight electronic device, and the software to be run terminates loading and exits automatically; When the execution result is the reported error, it indicates that the software to be run has been modified or the PUF chip is damaged or the PUF chip has been replaced, and the software to be run has not been authorized based on the PUF chip method verification in the current lightweight electronic device, and the software to be run terminates loading and exits automatically.

10. The lightweight electronic device according to claim 7, wherein, The PUF chip is further used for, when the authorized software authorizes the current lightweight electronic device, responding to the preset initial value in the authorized software to obtain a first intermediate value, and responding based on the first intermediate value as a challenge value for a preset number of times to obtain a first response value; During the process of initializing and loading in the current lightweight electronic device, when it is determined that there is a preset initial value in the software to be run, responding to the preset initial value in the software to be run to obtain a second intermediate value, and responding based on the second intermediate value as a challenge value for a preset number of times to obtain a second response value.

Images