Method for evolving trusted root and electronic device using the method

Abstract

The embodiment of the present invention provides a method for evolving a trusted root and an electronic device using the method. Through the present invention, the trusted root can be evolved several times to enhance its security verification capability of secure boot. Different from the traditional method of burning the trusted root into a read-only memory, the present case uses a block protection storage device to write the verification firmware to be added to the trusted root into an unprotected block of the block protection storage device, and after the writing is completed, the unprotected block where the verification firmware is written becomes a protected block, so that the evolved trusted root is safe and trustworthy, and the purpose of evolving the trusted root can be achieved.

Description

Technical Field

[0001] The present invention relates to a root of trust technology in the field of security, and in particular to a method for evolving a root of trust and an electronic device using the same. Background Art

[0002] In today's computer information systems, protecting the security of the system is a very important link. For example, how to ensure the integrity of the system, how to detect whether the system is contaminated, how to rescue the contaminated system, and how to back up important system information, etc., all these actions must rely on a fully trustworthy root of trust. The root of trust is designed to be the bottom-level trusted verification firmware in a chain of trust in a series of verification processes, so its integrity cannot be confirmed. Based on security, the existing technology burns the root of trust into a read-only memory (ROM). However, the practice of replacing the root of trust by re-manufacturing the read-only memory means that the mask must be re-opened, which increases the manufacturing cost and time cost. Summary of the invention

[0003] According to the purpose of the present invention, an embodiment of the present invention proposes a method for evolving a trusted root, which is implemented by using a block protection storage device and includes: writing a first verification firmware to a first block, wherein a block protection fuse bit and a block protection bit of the first block are set to not true; setting the block protection fuse bit and the block protection bit of the first block written with the first verification firmware to true, so that the first block written with the first verification firmware becomes a protected block; writing first verification information into a second block, wherein the block protection fuse bit and the block protection bit of the second block are set to not true, the first verification information and the first verification firmware are used to verify the user firmware, and the first verification information is encrypted based on the encryption algorithm of the first verification firmware; and setting the block protection bit of the second block written with the first verification information to true.

[0004] In addition, according to the purpose of the present invention, an embodiment of the present invention provides an electronic device for executing the above-mentioned method for evolving a root of trust.

[0005] Optionally, the security verification chip of the electronic device is packaged together with the security function chip of the electronic device through multi-chip packaging.

[0006] In summary, the embodiments of the present invention provide a method for evolving a root of trust and an electronic device using the method. Through the present invention, the root of trust can be evolved several times to enhance the security verification capability of its secure boot. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings are provided to enable those with ordinary knowledge in the technical field to which the present invention belongs to further understand the present invention, and are incorporated into and constitute a part of the specification of the present invention. The accompanying drawings illustrate exemplary embodiments of the present invention, and together with the description of the present invention, are used to explain the principles of the present invention.

[0008] Figure 1 4 is a block diagram of an electronic device with an evolvable root of trust according to an embodiment of the present invention.

[0009] Figure 2 It is a schematic diagram of the relationship between blocks, block protection bits and block protection fuse bits of a block protection storage device of an electronic device according to an embodiment of the present invention.

[0010] Figure 3A It is a schematic diagram of the first evolution of the root of trust of the electronic device according to the embodiment of the present invention.

[0011] Figure 3B It is a schematic diagram of performing a second evolution of the root of trust of the electronic device according to an embodiment of the present invention.

[0012] Figure 3C It is a schematic diagram of the third evolution of the root of trust of the electronic device of the embodiment of the present invention.

[0013] Figure 4 It is a flow chart of the method for evolving a root of trust according to an embodiment of the present invention.

[0014] The symbols indicated in the diagram are explained as follows: 2 security verification chip; 21 security processor; 22 block protection storage device; 221 trusted root; 9 functional chip; BL[0]~BL[K] blocks; BPB[0]~BPB[K] block protection bits; BPBFB[0]~BPBFB[K] block protection fuse bits; S51, S52 steps; VFW1~VFW3 verification firmware; UFWH1~UFWH3 verification information. DETAILED DESCRIPTION

[0015] Reference will now be made in detail to exemplary embodiments of the present invention, which are illustrated in the accompanying drawings. Where possible, the same component symbols are used in the drawings and the specification to refer to the same or similar components. In addition, the exemplary embodiments are only one way of implementing the design concept of the present invention, and the following examples are not intended to limit the present invention.

[0016] The embodiment of the present invention provides a method for evolving a trusted root, which is mainly implemented through a block protection storage device. After writing verification firmware other than the original verification firmware of the trusted root to an unprotected block in the block protection storage device, the block protection fuse bit and the block protection bit are both set to true to make the unprotected block become a protected block, so that the written verification firmware serves as part of the trusted root, wherein the block of the written verification firmware is a protected block, and therefore the written verification firmware can no longer be rewritten, so that the trusted root is still secure and trustworthy after the upgrade. In addition, the information of the user firmware to be authenticated by the trusted root can be encrypted with the encryption algorithm of the written verification firmware as a header, and the header is written to the next unprotected block of the block where the verification firmware is written, wherein the information of the user firmware includes a pointer or size of the user firmware, which after encryption can be used as a basis for subsequent integrity verification of the user firmware.

[0017] Although the above-mentioned method is to encrypt the information of the user firmware as a header, the present invention is not limited to this. The information of the user firmware can also be used as a tailer or placed in other locations after encryption, but the prerequisite is that the verification firmware and the original verification firmware of the trust root written into the block protection storage device must be specifically designed to capture the encrypted user firmware information at a specific location, and after verifying the user firmware, the original verification firmware of the trust root knows how to execute the user firmware. Furthermore, in addition to the pointer and size of the user firmware, the information of the user firmware that will be encrypted and used for verification can also be a part of the user firmware's own data, or other information related to the user firmware, and the present invention is not limited to this. Simply put, the above-mentioned encrypted information serves as the verification information of the user firmware, and can be a header, a tailor, or stored in other locations (not necessarily immediately after the written verification firmware).

[0018] Furthermore, each block of the block protection storage device has a corresponding block protection fuse bit and a block protection bit. When the block protection bit is set to true, the corresponding block cannot be written, and the corresponding block can only be written when the block protection bit is set to false. When the block protection fuse bit is false, the block protection bit can be set to false or true, but when the block protection fuse bit is true, the block protection bit is no longer allowed to be set from true to false or from false to true. The block protection fuse bit is a one-time program bit. When the block protection fuse bit is changed from false to true, the block protection fuse bit is no longer allowed to be changed from true to false.

[0019] In the present invention, the original verification firmware of the trusted root is written into the protected block or read-only memory when the product leaves the factory, so that it cannot be deleted or changed. The present invention writes the verification firmware other than the original verification firmware into the unprotected block, and then sets the block protection fuse bit and the block protection bit to true, so that the unprotected block becomes a protected block. After the original verification firmware of the trusted root is executed, the verification firmware written into the protected block is then executed. Therefore, the verification firmware written into the protected block can be regarded as part of the trusted root, so the trusted root can be evolved through the method of the present invention. In addition, since the verification firmware in the protected block is not allowed to be deleted or changed, the upgraded and evolved trusted root is still safe and reliable.

[0020] After explaining the basic concept of the present invention, the details of the present invention are further explained. Figure 1 , Figure 1 : is a block diagram of an electronic device with an evolvable root of trust according to an embodiment of the present invention. The electronic device includes a security verification chip 2 and at least one functional chip 9, wherein the security verification chip 2 is electrically connected to the functional chip 9. The security verification chip 2 includes a security processor 21 and a block protection storage device 22, and the block protection storage device 22 stores a root of trust 221. The security verification chip 2 is packaged together with the functional chip 9 through a multi-chip package (MCP), and in one embodiment, the functional chip 9 can only access the block protection storage device 22 through the security processor 21 of the security verification chip 2. In another embodiment, if a higher specification of security is not considered, the security verification chip 2 and the functional chip 9 are not packaged together through a multi-chip package, and the block protection storage device 22 of the security verification chip 2 can be moved out of the security verification chip 2 to allow the security verification chip 2 and the functional chip 9 to access through a bus.

[0021] Please also refer to Figure 1 and Figure 2 , Figure 2 Schematic diagram of the relationship between blocks, block protection bits and block protection fuse bits of a block protection storage device of an electronic device according to an embodiment of the present invention. The block protection storage device 21 has a plurality of blocks, for example, the first row has a total of K+1 blocks BL[0] to BL[K], and each block has a corresponding block protection fuse bit and block protection bit, for example, the K+1 blocks BL[0] to BL[K] respectively correspond to block protection bits BPB[0] to BPB[K], and respectively correspond to block protection fuse bits BPBFB[0] to BPBFB[K].

[0022] When the block protection bit is set to true, the corresponding block cannot be written. Only when the block protection bit is set to false, the corresponding block is allowed to be written. For example, if the block protection bit BPB[0] of block BL[0] is false, block BL[0] is allowed to be written. The block protection fuse bit is a one-time program bit. Once the fuse is blown and it changes from false to true, it cannot be changed back to false. The block protection bit is only allowed to be changed from false to true or from true to false when the corresponding block protection fuse bit is false. For example, the block protection bit BPB[1] can only be changed from false to true or from true to false when the block protection fuse bit BPBFB[1] is false.

[0023] In addition, when both the block protection bit and the block protection fuse bit are true, the corresponding block is a protected block. Conversely, in other cases, as long as the block protection fuse bit is not true, the corresponding block is an unprotected block. For example, when the block protection fuse bit BPBFB[1] is not true, but the block protection bit BPB[1] is true, the block BL[1] is an unprotected block. The purpose of setting the block protection bit BPB[1] to true is only to prevent the block BL[1] from being written by mistake, but the block protection bit BPB[1] can still be changed to not true, so the block BL[1] is not classified as a protected block.

[0024] Next, please continue to refer to Figure 1 When the electronic device leaves the factory, the original verification firmware of the root of trust 221 is written into the protected block of the block protection storage device 22, or, in another example, the original verification firmware of the root of trust 221 can be written into the read-only memory (not shown) of the security verification chip 2 or the block protection storage device 22. To further evolve the root of trust 221, the newly added verification firmware can be written into the unprotected block of the block protection storage device 22 as a part of the root of trust 221, and after writing the newly added verification firmware into the unprotected block, the unprotected block will become a protected block by setting the corresponding block protection fuse bit and block protection bit to true.

[0025] Please refer to Figure 1 and Figure 3A ,in Figure 3A FIG. 1 is a schematic diagram of the first evolution of the root of trust of the electronic device of the embodiment of the present invention. Figure 3AIn the upper part, the trusted root 221 only has the original verification firmware, and this original verification firmware may not have any secure boot capability. It simply reads the user firmware of the block protection storage device 22 without performing security verification. In order to increase the security verification capability, the verification firmware VFW1 (for example, the verification firmware for security verification based on CRC 32) can be obtained through the security processor 21 of the security verification chip 2, and the block protection bits BPB[0] and BPB[1] of the unprotected blocks BL[0] and BL[1] of the block protection storage device 22 are set from true to false (it is also possible that the block protection bits BPB[0] and BPB[1] are initially false without such setting action), so as to write the verification firmware VFW1 into the block BL[0], and write the verification information UFWH1 into the block BL[1], wherein the verification information UFWH1 includes information to be used to verify the user firmware, which is encrypted based on the encryption algorithm of the verification firmware VFW1, such as the integrity value of the pointer and size of the user firmware encrypted based on CRC 32. In this way, the verification firmware VFW1 can calculate the integrity value of the user firmware, and compare the integrity value included in the verification information UFWH1 to achieve the effect of security verification.

[0026] After the verification firmware VFW1 is written to block BL[0], the security processor 21 will set the block protection fuse bit BPBFB[0] of the block protection storage device 22 from not true to true, so that block BL[0] changes from a protected block to a protected block. After the verification information UFWH1 is written to block BL[1], the security processor 21 will set the block protection bit BPB[1] of the block protection storage device 22 from not true to true, but the block protection fuse bit BPBFB[1] is still not true, so block BL[1] is still an unprotected block, but it can prevent others from mistakenly writing the verification information UFWH1.

[0027] Thus, in the embodiment of the present invention, in addition to the original verification firmware, the trusted root 221 further has, for example, a verification firmware VFW1 based on CRC 32. When the trusted root 221 is executed, the verification firmware VFW1 will poll each user firmware to verify each user firmware. In order to speed up the verification speed, the security verification chip 2 may further have a hardware acceleration circuit. In addition, it is mentioned that if the verification firmware VFW1 exceeds the capacity of a block, it can be written into multiple blocks. Similarly, if the verification information UFWH1 exceeds the capacity of a block, it can be written into multiple blocks. Furthermore, the verification firmware VFW1 is usually not too large, only about a few thousand bits, so it does not take too much time to read the verification firmware VFW1, and the verification firmware VFW1 does not occupy too many blocks. Therefore, the design does not need to use a block with too large storage capacity to protect the storage device 22, and the evolution of the trusted root 221 can be performed several times.

[0028] Please refer to Figure 1 and Figure 3B , Figure 3B 2 is a schematic diagram of a second evolution of the root of trust of an electronic device of an embodiment of the present invention. When the security verification capability of CRC 32 is still insufficient, the root of trust 221 can be further evolved to have a higher security verification capability, such as SHA 256. The security processor 21 of the security verification chip 2 obtains the verification firmware VFW2 (for example, the verification firmware based on 256 for security verification), and sets the block protection bits BPB[1] and BPB[2] of the unprotected blocks BL[1] and BL[2] of the block protection storage device 22 from true to false (it is also possible that the block protection bits BPB[1] and BPB[2] are initially false and there is no such setting action), so as to write the verification firmware VFW2 into the block BL[1], and write the verification information UFWH2 into the block BL[2], wherein the verification information UFWH2 includes information to be used to verify the user firmware, which is encrypted based on the encryption algorithm of the verification firmware VFW2, such as the integrity value of the pointer and size of the user firmware encrypted based on SHA 256.

[0029] After the verification firmware VFW2 is written to block BL[1], the security processor 21 will set the block protection fuse bit BPBFB[1] of the block protection storage device 22 from not true to true, so that block BL[1] changes from a protected block to a protected block. After the verification information UFWH2 is written to block BL[2], the security processor 21 will set the block protection bit BPB[2] of the block protection storage device 22 from not true to true, but the block protection fuse bit BPBFB[2] is still not true, so block BL[2] is still an unprotected block, but it can prevent others from mistakenly writing the verification information UFWH2. In this embodiment, after the original verification firmware of the trusted root is executed, the verification firmware and VFW1 and VFW2 can be executed in sequence to verify the user firmware respectively, but in other embodiments of the present invention, it can also be designed that after the original verification firmware of the trusted root is executed, only the verification firmware VFW2 is executed to verify the user firmware, but the execution of the verification firmware VFW1 is skipped.

[0030] Please refer to Figure 1 and Figure 3C , Figure 3C2 is a schematic diagram of the third evolution of the root of trust of the electronic device of the embodiment of the present invention. When the security verification capability of SHA 256 is still insufficient, the root of trust 221 can be further evolved to have a higher security verification capability, such as ECDSA. The security processor 21 of the security verification chip 2 obtains the verification firmware VFW3 (for example, the verification firmware based on ECDSA for security verification), and sets the block protection bits BPB[2] and BPB[3] of the unprotected blocks BL[2] and BL[3] of the block protection storage device 22 from true to false (it is also possible that the block protection bits BPB[2] and BPB[3] are initially false and there is no such setting action), so as to write the verification firmware VFW3 into the block BL[2], and write the verification information UFWH3 into the block BL[3], wherein the verification information UFWH3 includes information to be used to verify the user firmware, which is encrypted based on the encryption algorithm of the verification firmware VFW3, such as the integrity value of the pointer and size of the user firmware encrypted based on ECDSA.

[0031] After the verification firmware VFW3 is written to block BL[2], the security processor 21 will set the block protection fuse bit BPBFB[2] of the block protection storage device 22 from not true to true, so that block BL[2] changes from a protected block to a protected block. After the verification information UFWH3 is written to block BL[3], the security processor 21 will set the block protection bit BPB[3] of the block protection storage device 22 from not true to true, but the block protection fuse bit BPBFB[3] is still not true, so block BL[3] is still an unprotected block, but it can prevent others from mistakenly writing the verification information UFWH3.

[0032] Continue back Figure 1 ,because Figure 1 The electronic device adopts a multi-chip package, so the block protection storage device 22 is located inside the chip. Unless the chip is destroyed, the block protection storage device 22 cannot be replaced. Furthermore, even if the block protection storage device 22 is replaced by others by destroying the chip, there is a native protection verification mechanism built into the original verification firmware in its read-only memory (not shown) to protect it.

[0033] Please refer to Figure 4 , Figure 4 It is a flow chart of the method for evolving a root of trust according to an embodiment of the present invention. Figure 4This is a flowchart for evolving a trusted root once, but the present invention is not based on the number of times the trusted root is evolved. First, in step S51, write the first verification firmware to at least one first block whose block protection fuse bit and block protection bit are both false, and set the block protection fuse bit and block protection bit of the first block written with the first verification firmware to true, so as to turn the first block written with the first verification firmware into a protected block. In step S52, write the first verification information having information of at least one user firmware to be verified after the protected block and at least one second block whose block protection fuse bit and block protection bit are both false, and set the block protection bit of the second block written with the first verification information to true, wherein the first verification information and the first verification firmware are used to verify the user firmware, and the first verification information is encrypted based on the encryption algorithm of the first verification firmware.

[0034] In summary, the embodiment of the present invention provides a method for evolving a trusted root and an electronic device using the method. Through the present invention, the trusted root can be evolved several times to enhance its security verification capability of secure booting. Different from the traditional practice of burning the trusted root into a read-only memory, the present case uses a block protection storage device to write the verification firmware to be added to the trusted root into an unprotected block of the block protection storage device, and after the writing is completed, the block protection fuse bit and the block protection bit are both set to true, so that the unprotected block where the verification firmware is written becomes a protected block, so that the evolved trusted root is safe and reliable, and the purpose of evolving the trusted root can be achieved. Compared with the traditional technology, if the trusted root is to be replaced, a new mask must be opened to manufacture a new read-only memory. The method of the present invention can further reduce the time cost, manufacturing cost and re-manufacturing risk of replacing the trusted root. Furthermore, the current computer capabilities are rapidly increasing, and the security verification capability of the trusted root may be increased more and more frequently. Therefore, compared with the traditional method, the method of the present invention is more in line with the current market demand. In addition, if the algorithm has been determined and the relevant security chip is to be mass-produced, all other block protection fuse bits can be set to true to fix the range of the trusted root and the unprotected block to determine the relevance of its trusted root security algorithm to the product. In addition, the electronic device of the present invention can adopt a multi-chip package, so the block protection storage device is located inside the chip, and the block protection storage device cannot be replaced unless the chip is destroyed. Furthermore, even if the block protection storage device is replaced by others by destroying the chip, a native protection verification mechanism is built into the original verification firmware in its read-only memory (not shown) for protection.

[0035] It should be understood that the examples and embodiments described herein are for illustrative purposes only and that various modifications or changes in light of them will be suggested to those skilled in the art and are to be included within the spirit and scope of the present application and the scope of the appended claims.

Claims

1. A method for evolving a root of trust, characterized in that: An electronic device is implemented by using a block protection storage device, wherein the block protection storage device has a plurality of blocks including a first block and a second block, and each of the blocks has a corresponding block protection fuse bit and a block protection bit, wherein when the block protection bit is set to true, the corresponding block cannot be written, and the block protection fuse bit is a one-time program bit, and after the block protection fuse bit is set from false to true, the block protection bit can no longer be rewritten, and the method includes: Writing a first verification firmware to the first block, wherein the block protection fuse bit and the block protection bit of the first block are set to be false; Setting the block protection fuse bit and the block protection bit of the first block in which the first verification firmware is written to true, so that the first block in which the first verification firmware is written becomes a protected block; Writing first verification information into the second block, wherein the block protection fuse bit and the block protection bit of the second block are set to be false, the first verification information and the first verification firmware are used to verify user firmware, and the first verification information is encrypted based on an encryption algorithm of the first verification firmware; and The block protection bit of the second block in which the first verification information is written is set to true.

2. The method according to claim 1, characterized in that The second block is a next area of ​​the first block, and the first verification information is a first header used to verify the user firmware.

3. The method according to claim 1, characterized in that The plurality of blocks further include a third block, and the method further includes: Setting the block protection bit of the second block to false, and writing a second verification firmware to the second block; Setting the block protection fuse bit and the block protection bit of the second block in which the second verification firmware is written to true, so that the second block in which the second verification firmware is written becomes another protected block; and Writing second verification information into the third block, wherein the block protection fuse bit and the block protection bit of the third block are set to be false, the second verification information and the second verification firmware are used to verify the user firmware, and the second verification information is encrypted based on an encryption algorithm of the second verification firmware; and The block protection bit of the third block written into the second header is set to true.

4. The method according to claim 3, characterized in that The original verification firmware of the trusted root, the first verification firmware and the second verification firmware are executed in sequence to verify the user firmware.

5. The method according to claim 3, characterized in that The original verification firmware of the trusted root and the second verification firmware are executed in sequence, and the execution of the first verification firmware is skipped to verify the user firmware.

6. The method according to claim 3, characterized in that The security verification capability of the first verification firmware is higher than the security verification capability of the original verification firmware of the trusted root, and the security verification capability of the second verification firmware is higher than the security verification capability of the first verification firmware.

7. The method according to claim 3, characterized in that The first verification information includes a first integrity value obtained by encrypting the pointer and / or size of the user firmware using the encryption algorithm of the first verification firmware, and the second verification information includes a second integrity value obtained by encrypting the pointer and / or size of the user firmware using the encryption algorithm of the second verification firmware.

8. An electronic device, characterized in that: include: Functional chips; as well as The security verification chip is electrically connected to the functional chip and stores the original verification firmware of the trusted root, including: Security processor; A block protection storage device, comprising a plurality of blocks including a first block and a second block, each of the blocks having a corresponding block protection fuse bit and a block protection bit, wherein when the block protection bit is set to true, the corresponding block cannot be written, and the block protection fuse bit is a one-time program bit, and after the block protection fuse bit is rewritten from false to true, the block protection bit can no longer be rewritten; The security processor controls the block protection storage device to evolve the trusted root, wherein the process of evolving the trusted root includes: Writing a first verification firmware to the first block, wherein the block protection fuse bit and the block protection bit of the first block are set to be false; Setting the block protection fuse bit and the block protection bit of the first block in which the first verification firmware is written to true, so that the first block in which the first verification firmware is written becomes a protected block; Writing first verification information into the second block, wherein the block protection fuse bit and the block protection bit of the second block are set to be false, the first verification information and the first verification firmware are used to verify user firmware, and the first verification information is encrypted based on an encryption algorithm of the first verification firmware; and The block protection bit of the second block in which the first verification information is written is set to true.

9. The electronic device as claimed in claim 8, characterized in that: The original verification firmware of the trusted root is written into at least one protected block of the block protection storage device; or, the security verification chip further includes a read-only memory, and the original verification firmware of the trusted root is burned into the read-only memory.

10. The electronic device as claimed in claim 8, characterized in that The security verification chip is packaged together with the functional chip through a multi-chip package, and the functional chip accesses the block protection storage device through the security processor of the security verification chip.

Images