CN117009976A

CN117009976A - Firmware loading control method, device and chip

Info

Publication number: CN117009976A
Application number: CN202310804343.2A
Authority: CN
Inventors: 王芹玉; 马超
Original assignee: Dingdao Zhixin Shanghai Semiconductor Co ltd
Current assignee: Dingdao Zhixin Shanghai Semiconductor Co ltd
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2023-11-07

Abstract

The application discloses a control method, a device and a chip for firmware loading, wherein the chip comprises a one-time programmable memory, and at least two flag bits are reserved in the one-time programmable memory; the one-time programmable memory also stores signature public keys corresponding to the states of the at least two flag bits; the states of the at least two flag bits are used to characterize the version type of the loadable firmware within the chip.

Description

Firmware loading control method, device and chip

Technical Field

The present application relates to the field of program development technologies, and in particular, to a method, an apparatus, and a chip for controlling firmware.

Background

Firmware typically has multiple version types, such as developed version, commercial version.

Currently, there are cases of internal attacks on chips. For example, after loading commercial versions of firmware in a chip, a development stage staff may attack the chip with vulnerable firmware, resulting in lower chip security.

Therefore, a technical solution capable of avoiding internal attacks in a chip is needed.

Disclosure of Invention

In view of this, the present application provides a firmware loading control method, device and chip, as follows:

The chip comprises a one-time programmable memory, wherein at least two flag bits are reserved in the one-time programmable memory; the one-time programmable memory also stores signature public keys corresponding to the states of the at least two flag bits; the states of the at least two flag bits are used to characterize the version type of the loadable firmware within the chip.

Preferably, a target signature is reserved in loadable firmware corresponding to the chip, and the target signature corresponds to a version type of the loadable firmware;

the target signature is used for being verified by the signature public keys corresponding to the states of the at least two flag bits when the loadable firmware is loaded.

In the above chip, preferably, other signatures are reserved in the loadable firmware, where the other signatures correspond to version types that the loadable firmware has undergone.

Preferably, the chip is configured such that the target signature is located at a designated location in the loadable firmware.

In the above chip, preferably, in a case that a version type of the loadable firmware in the chip changes to a target type, there is at least one flag bit change in the at least two flag bits, so that a state of the at least two flag bits can characterize that the loadable firmware corresponds to the target type.

A method for controlling firmware loading, comprising:

obtaining a loading instruction aiming at firmware to be loaded; the loading instruction is used for indicating loading the firmware to be loaded in a chip, the chip comprises a one-time programmable memory, at least two flag bits are reserved in the one-time programmable memory, and signature public keys corresponding to states of the at least two flag bits are also stored in the one-time programmable memory; the states of the at least two flag bits are used for representing the version type of the loadable firmware in the chip;

responding to the loading instruction, and obtaining a target public key in the one-time programmable memory according to the states of the at least two flag bits;

and determining whether the firmware to be loaded is allowed to be loaded in the chip or not at least according to the target public key.

The above method, preferably, determines whether to allow loading of the firmware to be loaded in the chip at least according to the target public key, including:

obtaining a target signature of the firmware to be loaded, wherein the target signature corresponds to the version type of the firmware to be loaded;

verifying the target signature by using the target public key to obtain a verification result;

Allowing the firmware to be loaded in the chip under the condition that the verification result characterizes that the target signature passes verification;

and under the condition that the verification result represents that the target signature verification is not passed, the firmware to be loaded is not allowed to be loaded in the chip.

In the above method, preferably, the target signature is located at a designated position in the firmware to be loaded;

the obtaining the target signature of the firmware to be loaded includes:

and reading the target signature of the firmware to be loaded from the appointed position in the firmware to be loaded.

In the above method, preferably, the firmware to be loaded has a current version code on a version type thereof, and the version type corresponds to one or more version codes;

wherein, in a case where the verification result characterizes that the target signature verification passes, before allowing the firmware to be loaded in the chip, the method further includes:

judging whether the current version code of the firmware to be loaded meets a loading rule, if so, executing the following steps: allowing the firmware to be loaded in the chip.

A firmware loading control device, comprising:

An instruction obtaining unit for obtaining a load instruction for firmware to be loaded; the loading instruction is used for indicating loading the firmware to be loaded in a chip, the chip comprises a one-time programmable memory, at least two flag bits are reserved in the one-time programmable memory, and signature public keys corresponding to states of the at least two flag bits are also stored in the one-time programmable memory; the states of the at least two flag bits are used for representing the version type of the loadable firmware in the chip;

the public key obtaining unit is used for responding to the loading instruction and obtaining a target public key in the one-time programmable memory according to the states of the at least two flag bits;

and the loading control unit is used for determining whether the firmware to be loaded is allowed to be loaded in the chip or not at least according to the target public key.

According to the technical scheme, in the control method, the device and the chip for firmware loading disclosed by the application, the one-time programmable memory is configured in the chip, at least two flag bits and signature public keys corresponding to the states of the flag bits are reserved in the one-time programmable memory, and the states of the flag bits represent the version types of the firmware which can be loaded in the chip, so that the one-time programmable memory in the chip can be used for verifying the firmware to be loaded by using the public keys corresponding to the version types of the firmware which can be loaded in the chip, if verification is passed, the firmware to be loaded is allowed to be loaded in the chip, and if verification is not passed, the firmware to be loaded is not allowed to be loaded in the chip. Therefore, if the version types of the firmware to be loaded and the loadable firmware in the chip are not matched, the firmware is not allowed to be loaded in the chip, so that internal attacks caused by loading the firmware of the non-matched version type on the chip can be avoided, for example, the chip in the commercial stage can not be attacked by a developer by using the firmware of the development version with the vulnerability, and the safety of the chip is further improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic structural diagram of a chip according to a first embodiment of the present application;

fig. 2 and fig. 3 are respectively exemplary diagrams of signature public keys corresponding to flag bits in the embodiments of the present application;

FIG. 4 is an exemplary diagram of storing signatures within loadable firmware within a chip in an embodiment of the application;

FIG. 5 is a flowchart of a firmware loading control method according to a second embodiment of the present application;

FIG. 6 is an exemplary diagram of verifying a signature in firmware to be loaded with an on-chip public key in an embodiment of the application;

fig. 7 is a partial flowchart of a firmware loading control method according to a second embodiment of the present application;

FIG. 8 is a flow chart of another part of a firmware loading control method according to the second embodiment of the present application;

fig. 9 is a schematic structural diagram of a firmware loading control device according to a third embodiment of the present application;

Fig. 10 is a schematic structural diagram of a chip according to a first embodiment of the present application;

FIG. 11 is an exemplary diagram of reserved flag bits within eFuses and storing Chu Gong keys in accordance with an embodiment of the present application;

FIG. 12 is an exemplary diagram of developing firmware in an embodiment of the application;

FIG. 13 is an exemplary diagram of commercial firmware in an embodiment of the present application;

FIG. 14 is a flowchart of verifying a signature during firmware loading in an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Referring to fig. 1, a schematic structural diagram of a chip according to a first embodiment of the present application is provided, where the chip is capable of loading firmware, and the chip is capable of implementing corresponding functions by loading firmware, and the chip may be configured in an electronic device, such as a computer or a server, so that the electronic device can provide corresponding services through the chip. The technical scheme in the embodiment is mainly used for avoiding internal attack of the chip so as to improve the safety of the chip.

Specifically, the chip in this embodiment may include a one-time programmable memory, such as eFuses.

At least two flag bits, such as a flag bit A, a flag bit B, a flag bit C and the like, are reserved in the one-time programmable memory.

And the one-time programmable memory also stores signature public keys corresponding to the states of at least two flag bits.

It should be noted that the otp memory may include one or more public signature keys, where each public signature key corresponds to a state that can be represented by a flag bit in the otp memory.

Wherein the signature public key is a public key that signs the firmware. For example, the public key of the firmware is used to perform hash computation on the program content of the firmware to obtain the signature of the firmware.

In particular, the public signature key may be stored in a specific location in the one-time programmable memory.

For example, as shown in FIG. 2, two flag bits are reserved in eFuses: the eFuses store two signature public keys: signature public key 1 and signature public key 2. Wherein, signature public key 1 corresponds to the state that flag bit a is 1 and flag bit B is 0, signature public key 2 corresponds to the state that flag bit a is 1 and flag bit B is 1. The flag bits 1 and 0 may correspond to two storage states, respectively, and specifically, in eFuses, to a flag bit blown or non-blown state.

As another example, as shown in fig. 3, three flag bits are reserved in the eFuse: the eFuses store three signature public keys: public signature key 1, public signature key 2, and public signature key 3. The signature public key 1 corresponds to the state that the flag bit a is 1, the flag bit B is 0 and the flag bit C is 0, the signature public key 2 corresponds to the state that the flag bit a is 1, the flag bit B is 1 and the flag bit C is 0, and the signature public key 3 corresponds to the state that the flag bit a is 1, the flag bit B is 1 and the flag bit C is 1.

The states of at least two flag bits in the one-time programmable memory are used for representing the version type of the loadable firmware in the chip.

The version type may include: a developed version of firmware, a tested version of firmware, a commercial version of firmware, etc., each development stage of firmware may correspond to a version type.

It should be noted that the on-chip loadable firmware refers to firmware that is allowed to be loaded on the chip or firmware that is already loaded on the chip. That is, the states of at least two flag bits in the one-time programmable memory are used to characterize the version type of the firmware that is allowed to be loaded on the chip, and if the version type of the firmware that is required to be loaded on the chip is not the version type characterized by the states of at least two flag bits in the one-time programmable memory, then the firmware is not allowed to be loaded on the firmware, thereby avoiding that an illegal version of the firmware is loaded on the chip.

As can be seen from the above technical solution, in the chip of the first embodiment of the present application, a one-time programmable memory is configured in the chip, at least two flag bits and signature public keys corresponding to the states of the flag bits are reserved in the one-time programmable memory, and the states of the flag bits represent version types of firmware loadable in the chip, so that, through the one-time programmable memory in the chip, the firmware to be loaded can be verified by using the public key corresponding to the version types of firmware loadable in the chip, if verification is passed, the firmware to be loaded is allowed to be loaded into the chip, and if verification is not passed, the firmware to be loaded is not allowed to be loaded into the chip. Therefore, in this embodiment, if the version types of the firmware to be loaded and the loadable firmware in the chip are not matched, the firmware is not allowed to be loaded in the chip, so that an internal attack caused by loading the firmware of the non-matched version type on the chip can be avoided, for example, the chip in the commercial stage cannot be attacked by a developer using the firmware of the vulnerable development version, and the security of the chip is further improved.

In one implementation, a target signature is retained within the loadable firmware corresponding to the chip, the target signature corresponding to a version type of the loadable firmware. The target signature may be a signature obtained by processing, for example, hash calculation, of program content of the loadable firmware by using a signature public key corresponding to states of at least two flag bits in the one-time programmable memory in the chip.

Based on this, the target signature is used to be able to be verified by the signature public key corresponding to the state of at least two flag bits in the on-chip one-time programmable memory when the loadable firmware of the chip is loaded.

Therefore, the target signature corresponding to the firmware version type can be reserved in the firmware to be loaded, and when the firmware to be loaded is loaded, the target signature in the firmware to be loaded is verified by using the signature public keys corresponding to the states of at least two flag bits in the one-time programmable memory in the chip.

If the verification passes, then the following is stated: the version type of the state representation of at least two flag bits in the one-time programmable memory in the chip is consistent with the version type of the firmware to be loaded, and the firmware to be loaded is loadable firmware of the chip, so that the firmware can be loaded into the chip.

If the verification is not passed, then the following is stated: the version type of the state representation of at least two flag bits in the one-time programmable memory in the chip is inconsistent with the version type of the firmware to be loaded, and the firmware to be loaded is the non-loadable firmware of the chip, so that the firmware is not allowed to be loaded to the chip.

Specifically, the target signature is located at a designated location in the loadable firmware. The specified position refers to: a specified location in the program content of the firmware, such as a starting location of the program content, such as a first row, an ending location, such as a last row or last bit, or a particular row or bit in between, may be loaded. Based on this, when it is necessary to read a target signature that characterizes the version type of firmware, it is necessary to read the target signature from a specified location of the firmware, and the signatures at other locations cannot correspond to the version type of firmware.

For example, as shown in FIG. 4, the target signature is located at the end of the program content of the loadable firmware.

In addition, other signatures are maintained within the loadable firmware, which correspond to the version types that the loadable firmware has experienced. The location of these other signatures in the loadable firmware is related to the specified location of the target signature. For example, the location of the other signature in the loadable firmware is adjacent to the specified location of the target signature in the loadable firmware.

For example, as shown in FIG. 4, in addition to retaining the target signature of the commercial version, the signature of the development version and the signature of the test version may be retained within the loadable firmware. And the commercial version is signed on the last line of the loadable firmware, the test version is signed on the last-to-last line of the loadable firmware, and the development version is signed on the last-to-last line of the loadable firmware. That is, the latest version of the signature is written in the last row of the firmware.

In one implementation, in the case where the version type of the loadable firmware within the chip changes to the target type, there is at least one flag change in at least two flags of the one-time programmable memory such that the state of the at least two flags of the one-time programmable memory is capable of characterizing that the loadable firmware corresponds to the target type.

For example, when the version type of the loadable firmware in the chip is a development version, flag bit A in eFuse is blown, the value is set to 1, and flag bit B and flag bit C are unchanged; when the version type of the loadable firmware in the chip is changed from a development version to a test version, the flag bit B in the eFuse is blown, the value is set to be 1, and the flag bit A and the flag bit C are unchanged; when the version type of the firmware which can be loaded in the chip is changed from a test version to a commercial version, the flag bit C in the eFuse is blown, the value is set to be 1, and the flag bit A and the flag bit B are unchanged, so that when the firmware of the specific version type can be loaded in the chip, the version type of the firmware which can be loaded in the chip is recorded through blowing the corresponding flag bit in the eFuse.

Referring to fig. 5, a flowchart of a firmware loading control method provided in the second embodiment of the present application is implemented, where the method may be applied to a chip capable of loading firmware, where the chip is capable of implementing a corresponding function by loading firmware, and the chip may be configured in an electronic device, such as a computer or a server, so that the electronic device may provide a corresponding service through the chip. The technical scheme in the embodiment is mainly used for avoiding internal attack of the chip so as to improve the safety of the chip.

Specifically, the method in this embodiment may include the following steps:

step 501: a load instruction for firmware to be loaded is obtained.

The loading instruction is used for indicating that corresponding firmware to be loaded is loaded in a chip, and the chip comprises a one-time programmable memory, as shown by eFuses in FIG. 1. At least two flag bits are reserved in the one-time programmable memory, and the one-time programmable memory also stores signature public keys corresponding to the states of the at least two flag bits, as shown in fig. 2 or fig. 3; and, the states of at least two flag bits in the one-time programmable memory are used to characterize the version type of the loadable firmware in the chip.

For example, when a certain version type of firmware needs to be loaded, a load instruction is generated based on the firmware, and thus, the load instruction is acquired in this embodiment.

Step 502: in response to a load instruction, a target public key in the one-time programmable memory is obtained in accordance with the state of the at least two flag bits.

The signature public key is a public key for signing the firmware. For example, the public key of the firmware is used to perform hash computation on the program content of the firmware to obtain the signature of the firmware.

In particular, the public signature key may be stored in a specific location in the one-time programmable memory. Based on this, in this embodiment, according to the states of at least two flag bits in the otp memory, at a specific location in the otp memory, a corresponding signature public key, that is, a target public key corresponding to the version type of the loadable firmware in the chip, is read.

For example, as shown in FIG. 6, an on-chip eFuse has three flag bits: the states of the flag bit A, the flag bit B and the flag bit C, wherein the three flag bits are all 1, the version type of loadable firmware in the characterization chip is commercial version, and three signature public keys are stored in eFuses: public signature key 1, public signature key 2, and public signature key 3. The signature public key 1 corresponds to the state that the flag bit a is 1, the flag bit B is 0 and the flag bit C is 0, the signature public key 2 corresponds to the state that the flag bit a is 1, the flag bit B is 1 and the flag bit C is 0, and the signature public key 3 corresponds to the state that the flag bit a is 1, the flag bit B is 1 and the flag bit C is 1. Based on this, in this embodiment, after receiving the load instruction, the signature public key 3, that is, the target public key corresponding to the commercial version, is read from the efuses according to the state that all the three flag bits in the chip are 1.

Step 503: it is determined whether the firmware to be loaded is allowed to be loaded in the chip based at least on the target public key.

In this embodiment, the target public key is used to verify the firmware to be loaded, and if the verification is passed, the firmware to be loaded is allowed to be loaded in the chip, and if the verification is not passed, the firmware to be loaded is not allowed to be loaded in the chip.

As can be seen from the above technical solution, in the control method for firmware loading provided in the second embodiment of the present application, a one-time programmable memory is configured in a chip, at least two flag bits and signature public keys corresponding to the states of the flag bits are reserved in the one-time programmable memory, and the states of the flag bits represent version types of firmware loadable in the chip, so that the one-time programmable memory in the chip can be used to verify firmware to be loaded, if verification is passed, the firmware to be loaded is allowed to be loaded into the chip, and if verification is not passed, the firmware to be loaded is not allowed to be loaded into the chip. Therefore, in this embodiment, if the version types of the firmware to be loaded and the loadable firmware in the chip are not matched, the firmware is not allowed to be loaded in the chip, so that an internal attack caused by loading the firmware of the non-matched version type on the chip can be avoided, for example, the chip in the commercial stage cannot be attacked by a developer using the firmware of the vulnerable development version, and the security of the chip is further improved.

In one implementation, in determining whether to allow loading of firmware to be loaded on-chip based at least on the target public key in step 503, this may be accomplished as shown in fig. 7 by:

step 701: a target signature of the firmware to be loaded is obtained, the target signature corresponding to a version type of the firmware to be loaded.

The target signature may be a signature obtained by processing, for example, hash calculation, the program content of the firmware to be loaded by using a signature public key corresponding to the version type of the firmware to be loaded. For example, when the firmware to be loaded is a development version, the target signature is a signature obtained by performing hash calculation on the program content of the firmware to be loaded by using a signature public key corresponding to the development version; for another example, when the firmware to be loaded is a test version, the target signature is a signature obtained by performing hash calculation on the program content of the firmware to be loaded by using a signature public key corresponding to the test version; for another example, when the firmware to be loaded is a commercial version, the target signature is a signature obtained by performing hash calculation on the program content of the firmware to be loaded by using a signature public key corresponding to the commercial version.

Specifically, the target signature is located at a designated location in the firmware to be loaded. The specified position refers to: a specified location in the program content of the firmware, such as the first row, the last row, or a particular row in between, of the program content may be loaded. Based on this, the target signature is read from a specified location of the firmware to be loaded, such as the last line of the program content in the present embodiment.

Step 702: and verifying the target signature by using the target public key to obtain a verification result.

Specifically, in this embodiment, the target public key may be used to process the program content of the firmware to be loaded, such as hash calculation, so as to obtain target information, and then the target signature is compared with the target information to obtain a comparison result. Under the condition that the comparison result represents that the target signature is consistent with the target information, obtaining a verification result that the representation target signature passes verification; and under the condition that the comparison result represents that the target signature is inconsistent with the target information, obtaining a verification result that the verification of the representation target signature is not passed.

Step 703: judging whether the verification result represents that the target signature passes verification, executing step 704 when the verification result represents that the target signature passes verification, and executing step 705 when the verification result represents that the target signature does not pass verification.

Step 704: allowing the firmware to be loaded on-chip.

Step 705: the firmware to be loaded is not allowed to be loaded in the chip.

Therefore, in this embodiment, the target public key may be used to verify the target signature in the firmware to be loaded, if verification is passed, it indicates that the version type of the firmware to be loaded is consistent with the version type of the firmware loadable in the chip, and then the firmware to be loaded is allowed to be loaded in the chip, and if verification is not passed, it indicates that the version type of the firmware to be loaded is inconsistent with the version type of the firmware loadable in the chip, and then the firmware to be loaded is not allowed to be loaded in the chip.

For example, taking fig. 6 as an example, in this embodiment, the signature public key 3 is read, the target signature recorded in the last line of the firmware to be loaded corresponds to the development version of the firmware to be loaded, based on this, in this embodiment, hash calculation is performed on the program content of the firmware to be loaded by using the signature public key 3 to obtain target information, the target information is compared with the target signature of the firmware to be loaded, and the comparison is found to be inconsistent, and at this time, a verification result indicating that the verification of the target signature is not passed is obtained, so that the development version of the firmware to be loaded is not allowed to be loaded to the chip.

For another example, taking fig. 6 as an example, the signature public key 3 is read in this embodiment, the target signature recorded in the last line of the firmware to be loaded corresponds to the commercial version of the firmware to be loaded, based on this, in this embodiment, hash computation is performed on the program content of the firmware to be loaded by using the signature public key 3 to obtain target information, the target information is compared with the target signature of the firmware to be loaded, and the comparison is found to be consistent, and at this time, a verification result indicating that the verification of the target signature passes is obtained, so that the firmware to be loaded of the commercial version is not allowed to be loaded on the chip.

The above specific signature verification method is merely exemplary, and those skilled in the art may perform verification according to different signature algorithms by using a suitable verification method, which is not limited herein.

Based on the above implementation, the firmware to be loaded has a current version code on its version type, with each version type corresponding to one or more version codes. For example, the development version corresponds to version codes of V1.1, V1.2, V1.3, etc., and the commercial version corresponds to version codes of V2.1, V2.2, V2.3, etc. For example, the firmware to be loaded is a commercial version, and its current version is encoded as V2.3.

In practical applications, there may be situations where a security hole exists in a certain version of encoded firmware that does not allow reloading to the chip. For example, commercial versions of V2.1 have significant security vulnerabilities that, if loaded into a chip, can cause the chip to crash. Based on this, in the case where it is determined in step 703 that the verification result characterizes that the target signature verification is passed, before the firmware to be loaded is allowed to be loaded in the chip in step 704, the following steps may be further included in the present embodiment, as shown in fig. 8:

step 706: it is determined whether the current version code of the firmware to be loaded satisfies the loading rule, if yes, step 704 is executed, and if not, step 705 is executed.

That is, in this embodiment, in addition to determining whether the version type of the firmware to be loaded is consistent with the version type of the firmware to be loaded, if the version type of the firmware to be loaded is consistent with the version type of the firmware to be loaded, it is further required to determine whether the current version code of the firmware to be loaded on the version type of the firmware to be loaded meets the loading rule, and only if the version type of the firmware to be loaded is consistent with the version type of the firmware to be loaded on the chip and the current version code of the firmware to be loaded on the version type of the firmware to be loaded meets the loading rule, loading of the firmware to be loaded on the chip is allowed.

In one implementation, loading rules includes: the current version code does not match each version code in the preset set of prohibited loads.

The loading prohibition set comprises at least one version code corresponding to each version type, and the version codes in the loading prohibition set are version codes which are not allowed to be loaded on the corresponding version types. For example, the forbidden load set contains V1.2 of the developed version and V2.1 of the commercial version. If the firmware to be loaded is a commercial version and the current version code V2.1 is matched with one version code in the forbidden loading set, the current version code of the firmware to be loaded on the version type does not meet the loading rule, and the firmware to be loaded is not allowed to be loaded in the chip; if the firmware to be loaded is a commercial version and the current version code V2.2 does not match all the version codes in the forbidden loading set, then the current version code of the firmware to be loaded on its version type is said to satisfy the loading rule, and the loading of the firmware to be loaded in the chip is allowed.

In another implementation, loading the rule includes: the preset allowed loading set has version codes matched with the current version codes.

The version codes in the allowed loading set are version codes or version code ranges which are allowed to be loaded on the corresponding version types. For example, V1.1, V1.2 of the development version and V2.2 of the commercial version are allowed to be contained in the loading set. If the firmware to be loaded is a commercial version and the current version code V2.1 does not have a matched version code in the allowed loading set, the current version code of the firmware to be loaded on the version type does not meet the loading rule, and the firmware to be loaded is not allowed to be loaded in the chip; if the firmware to be loaded is a commercial version and the current version code V2.2 has a matching version code in the allowed loading set, then the current version code on its version type is said to satisfy the loading rule, then the firmware to be loaded is allowed to be loaded on-chip.

Therefore, in the embodiment, under the condition that the version type of the firmware to be loaded is verified to be consistent with the version type of the firmware loadable in the chip, it is further required to verify whether the current version code of the firmware to be loaded on the version type meets the loading rule, so that the situation that the security-vulnerable firmware matched with the version type of the firmware loadable in the chip can still be loaded on the chip, thereby causing lower security of the chip, and further improving the security of the chip.

Referring to fig. 9, a schematic structural diagram of a firmware loading control device according to a third embodiment of the present application may be applied to a chip capable of loading firmware, where the chip is capable of implementing a corresponding function by loading firmware, and the chip may be configured in an electronic device, such as a computer or a server, so that the electronic device may provide a corresponding service through the chip. The technical scheme in the embodiment is mainly used for avoiding internal attack of the chip so as to improve the safety of the chip.

Specifically, the apparatus in this embodiment may include the following units:

an instruction obtaining unit 901, configured to obtain a load instruction for firmware to be loaded; the loading instruction is used for indicating loading the firmware to be loaded in a chip, the chip comprises a one-time programmable memory, at least two flag bits are reserved in the one-time programmable memory, and signature public keys corresponding to states of the at least two flag bits are also stored in the one-time programmable memory; the states of the at least two flag bits are used for representing the version type of the loadable firmware in the chip;

a public key obtaining unit 902, configured to obtain, in response to the load instruction, a target public key in the otp memory according to the states of the at least two flag bits;

The loading control unit 903 is configured to determine whether to allow loading of the firmware to be loaded in the chip at least according to the target public key.

As can be seen from the above technical solution, in the firmware loading control device provided in the third embodiment of the present application, a one-time programmable memory is configured in a chip, at least two flag bits and signature public keys corresponding to the states of the flag bits are reserved in the one-time programmable memory, and the states of the flag bits represent version types of firmware loadable in the chip, so that the firmware to be loaded can be verified by using the public key corresponding to the version types of firmware loadable in the chip in the one-time programmable memory in the chip, if verification is passed, the firmware to be loaded is allowed to be loaded in the chip, and if verification is not passed, the firmware to be loaded is not allowed to be loaded in the chip. Therefore, in this embodiment, if the version types of the firmware to be loaded and the loadable firmware in the chip are not matched, the firmware is not allowed to be loaded in the chip, so that an internal attack caused by loading the firmware of the non-matched version type on the chip can be avoided, for example, the chip in the commercial stage cannot be attacked by a developer using the firmware of the vulnerable development version, and the security of the chip is further improved.

In one implementation, the load control unit 903 is specifically configured to: obtaining a target signature of the firmware to be loaded, wherein the target signature corresponds to the version type of the firmware to be loaded; verifying the target signature by using the target public key to obtain a verification result; allowing the firmware to be loaded in the chip under the condition that the verification result characterizes that the target signature passes verification; and under the condition that the verification result represents that the target signature verification is not passed, the firmware to be loaded is not allowed to be loaded in the chip.

In one implementation, the target signature is located at a designated location in the firmware to be loaded;

the load control unit 903 is specifically configured to, when obtaining the target signature of the firmware to be loaded: and reading the target signature of the firmware to be loaded from the appointed position in the firmware to be loaded.

In one implementation, the firmware to be loaded has a current version code on its version type, the version type corresponding to one or more version codes;

wherein, in case the verification result characterizes the target signature verification passing, the load control unit 903 is further configured to, before allowing the firmware to be loaded in the chip: judging whether the current version code of the firmware to be loaded meets a loading rule, if so, executing the following steps: allowing the firmware to be loaded in the chip.

It should be noted that, the specific implementation of each unit in this embodiment may refer to the corresponding content in the foregoing, which is not described in detail herein.

Referring to fig. 10, a schematic structural diagram of an electronic device according to a fourth embodiment of the present application may include the following structure:

The specific structure of the chip may refer to the corresponding content of fig. 1, and will not be described in detail herein.

As can be seen from the above technical solution, in the electronic device provided in the fourth embodiment of the present application, a one-time programmable memory is configured in a chip, at least two flag bits and signature public keys corresponding to the states of the flag bits are reserved in the one-time programmable memory, and the states of the flag bits represent version types of firmware loadable in the chip, so that, through the one-time programmable memory in the chip, the firmware to be loaded can be verified by using the public key corresponding to the version types of firmware loadable in the chip, if verification is passed, the firmware to be loaded is allowed to be loaded into the chip, and if verification is not passed, the firmware to be loaded is not allowed to be loaded into the chip. Therefore, in this embodiment, if the version types of the firmware to be loaded and the loadable firmware in the chip are not matched, the firmware is not allowed to be loaded in the chip, so that an internal attack caused by loading the firmware of the non-matched version type on the chip can be avoided, for example, the chip in the commercial stage cannot be attacked by a developer using the firmware of the vulnerable development version, and the security of the chip is further improved.

Taking the example that the chip firmware in the computer has a development stage and a commercial stage, the current electronic consumer firmware upgrading scene generally uses digital signatures to ensure the integrity and non-repudiation of the device firmware. In order to load tampered malicious firmware, an attacker typically has two approaches: one is a vulnerability that utilizes signature verification procedures; another approach is to access a legitimate signing key to sign malicious firmware. Signature verification procedures are relatively independent, small in size, and subject to rigorous inspection, and therefore difficult to utilize.

In the process of developing firmware, a developer is required to sign the firmware by using a secret key frequently in development and debugging. In this case it is difficult to avoid that the developer constructs malicious firmware and signs it before loading it into the user device. It is necessary to protect against internal attacks from the firmware development process.

In order to solve the problems and the defects of the prior solution, the application provides the following scheme:

1. according to different use scenes, a research and development key and a commercial key are respectively established, the research and development key is used for a developer to issue research and development firmware, and the research and development environment is not limited; the commercial key is only used by the publisher and commercial firmware and is stored by the encryptor.

2. The device firmware is signed by using the research and development key and the commercial key respectively, and the two signatures are built in the firmware.

3. In the firmware installation and upgrading process, the version flag bit on the eFuse is burned according to the firmware version.

4. The device burns the public key of the development key and the public key of the commercial key to the eFuse at the time of production.

5. The firmware verifies the signature using the corresponding public key according to the version flag bit.

The specific scheme is as follows:

1. the chip is produced by burning the research and development signature public key and the commercial signature public key to eFuses in the factory in advance, and reserving firmware version flag bits A and B as shown in FIG. 11.

2. During the development phase, the firmware is signed by a development key, firmware Version 1, as shown in fig. 12; when the firmware development is completed requiring commercial release, the development firmware to be signed by the development is signed again using the commercial key, becomes commercial firmware, and firmware Version is set to 2, as shown in fig. 13.

3. Before loading the firmware, the corresponding flag bit is fused first. When the firmware version is 1, the A mark is set to be 1 (namely, fusing); when firmware version bit 2, both A and B are set to 1.

4. The firmware will verify the signature according to the flow shown in fig. 14 when loading, and only the tail signature is taken for each signature verification. When the eFuse version is A, verifying the signature using the development public key; when eFuse versions A and B, verifying the signature using the commercial public key; if the signature verification is successful, the firmware is normally loaded and successfully started, and if the signature verification is failed, the firmware cannot be loaded, so that the firmware is failed to start.

The above process is a normal loading process, and when the device loaded with commercial firmware is backed up to the research and development firmware version, the backup cannot be successful.

It can be seen that when commercial firmware is loaded, flag bits a and B in efuses are set at the same time, if research and development firmware is loaded at this time, according to software logic, a commercial public key is used to verify the signature of firmware when a and B are set at the same time, and the signature of firmware is research and development signature, because the signature and the key used for verification are unpaired, signature verification fails, and research and development firmware cannot be loaded.

Advantages after the technical scheme of the application are adopted include:

1. the method can prevent the attack of an internal person from firmware development on the device, and solves the problem that the developed firmware cannot be loaded again after the device loads the commercial firmware. The measures can reduce the attack surface of the firmware, improve the attack difficulty and avoid internal attack.

2. According to the scheme, the use scenes (research and development or commercial) of the equipment do not need to be specially distinguished during production, the loading mode of the firmware can be limited only by using the signature, and the use mode of the equipment is more flexible.

In the present specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, and identical and similar parts between the embodiments are all enough to refer to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant points refer to the description of the method section.

Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. The chip comprises a one-time programmable memory, wherein at least two flag bits are reserved in the one-time programmable memory; the one-time programmable memory also stores signature public keys corresponding to the states of the at least two flag bits; the states of the at least two flag bits are used to characterize the version type of the loadable firmware within the chip.

2. The chip of claim 1, wherein a target signature is retained in loadable firmware corresponding to the chip, the target signature corresponding to a version type of the loadable firmware;

3. The chip of claim 2, further having retained within the loadable firmware other signatures corresponding to version types that the loadable firmware has experienced.

4. The chip of claim 2, the target signature being located at a specified location in the loadable firmware.

5. The chip of claim 1 or 2, in case a version type of loadable firmware within the chip changes to a target type, there is at least one flag bit change in the at least two flag bits such that a state of the at least two flag bits is able to characterize that the loadable firmware corresponds to the target type.

6. A method for controlling firmware loading, comprising:

7. The method of claim 6, determining whether to allow loading of the firmware to be loaded within the chip based at least on the target public key, comprising:

8. The method of claim 7, the target signature being located at a specified location in the firmware to be loaded;

the obtaining the target signature of the firmware to be loaded includes:

9. The method of claim 7, the firmware to be loaded having a current version code on its version type, the version type corresponding to one or more version codes;

10. A firmware loading control device, comprising: