Electronic control device and secure boot method

Abstract

To provide a secure boot method which improves availability while securing safety.SOLUTION: An electronic control device comprises a memory, a verification information generation unit, a verification unit, and a start unit. The memory includes a firmware storing region for storing firmware. The verification information generation unit generates verification information about each of N partial regions obtained by dividing the firmware storing region, when the firmware is stored in the firmware storing region. The verification unit verifies a state of each of the N partial regions, by using the verification information generated by the verification information generation unit, when the firmware stored in the firmware storing region is started. The start unit starts the firmware stored in a normal partial region for which the verification by the verification unit has been successful in the N partial regions.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The present invention relates to an electronic control device having a secure boot function and a secure boot method. [Background technology]

[0002] If firmware implemented in an electronic control device is illegally rewritten, there is a risk that the device may perform unexpected operations. For this reason, electronic control devices equipped with a secure boot function have been proposed and put into practical use. For example, in order to ensure safety when starting up a device, a method has been proposed in which a reference value that indicates a program that is permitted to start up in a normal area is compared with a verification value calculated when the program is started to determine whether or not the program can be started up (Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2020-140665 A Summary of the Invention [Problem to be solved by the invention]

[0004] According to the above-mentioned secure boot function, the electronic control device does not start a program in which an illegal operation has been detected, so security is ensured. However, if no program is executed at the time of booting the electronic control device, availability is reduced. In other words, the conventional secure boot method creates a trade-off between security and availability.

[0005] An object of one aspect of the present invention is to provide a secure boot method that improves availability while ensuring safety. [Means for solving the problem]

[0006] An electronic control device according to one embodiment of the present invention comprises a memory including a firmware storage area for storing firmware, a verification information generation unit that generates verification information for each of N partial areas obtained by dividing the firmware storage area when firmware is stored in the firmware storage area, a verification unit that verifies the state of each of the N partial areas using the verification information generated by the verification information generation unit when starting the firmware stored in the firmware storage area, and a startup unit that starts firmware stored in a normal partial area among the N partial areas that has been successfully verified by the verification unit. Effect of the Invention

[0007] According to the above-described aspect, a secure boot is realized that improves availability while ensuring safety. [Brief description of the drawings]

[0008] [Figure 1] FIG. 2 is a diagram illustrating an example of an electronic control device according to an embodiment of the present invention. [Diagram 2] FIG. 2 illustrates an example of a memory configuration. [Diagram 3] FIG. 2 is a diagram illustrating an example of a functional configuration of an electronic control device according to an embodiment of the present invention. [Figure 4] 10 is a flowchart illustrating an example of a process for updating firmware. [Diagram 5] FIG. 13 is a diagram illustrating an example of partial areas obtained by dividing a firmware storage area. [Figure 6] FIG. 13 is a diagram illustrating an example of verification information. [Figure 7] 10 is a flowchart illustrating an example of a process performed when firmware is booted. [Figure 8] FIG. 2 is a diagram illustrating an example of firmware implemented in an electronic control device. [Figure 9] FIG. 13 is a diagram illustrating an example of an abnormality function table. [Figure 10]10 is a flowchart illustrating an example of an operation of the firmware. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] 1 shows an example of an electronic control device according to an embodiment of the present invention. In this example, the electronic control device 1 according to the embodiment of the present invention includes a processor 11, a memory 12, a communication device 13, an input device 14, and an output device 15. However, the electronic control device 1 may further include other functions, circuits, devices, etc. that are not shown in FIG. 1.

[0010] The processor 11 is a computing device that provides the functions of the electronic control device 1 by executing programs stored in the memory 12. The memory 12 stores the programs executed by the processor 11 and information referenced by the processor 11. The memory 12 is also used as a working area for the processor 11.

[0011] The communication device 13 can communicate with any or specified information processing device via a communication network. The input device 14 is an input interface that accepts instructions or input from the outside. The output device 15 is an output interface that outputs to the outside.

[0012] The electronic control device 1 is not particularly limited, but may be implemented in an embedded device, for example. The electronic control device 1 is, for example, a one-chip microcomputer. That is, the computing power of the processor 11 is not high, and the capacity of the memory 12 is relatively small.

[0013] 2 shows an example of the configuration of the memory 12. In this embodiment, the memory 12 includes a general area 20 and a protected area 30.

[0014] The general area 20 includes a download area 21 and a firmware storage area 22. The download area 21 temporarily stores programs (including firmware), data, and information that the communication device 13 receives from outside the electronic control device 1. The firmware storage area 22 stores firmware that the communication device 13 receives from outside the electronic control device 1. The downloaded firmware is temporarily stored in the download area 21, where the firmware signature is verified. Then, if there is no problem with the signature verification, the firmware is moved from the download area 21 to the firmware storage area 22.

[0015] The firmware is an example of a program executed in the electronic control device 1. Furthermore, the firmware may include, in addition to a program, data that the program references.

[0016] The protected area 30 is a memory area to which access from outside the protected area 30 is prohibited. A secure boot program, a signature verification key, and verification information are stored in the protected area 30. The secure boot program verifies the firmware stored in the firmware storage area 22 when the electronic control device 1 is started. When an abnormality (e.g., tampering, damage, etc.) of the firmware is detected, the secure boot program does not start the firmware. However, the secure boot program can also start the firmware in a degenerate mode. The degenerate mode is an operating mode in which only some of the functions or features of the firmware are executed, and will be described in detail later. The signature verification key is an encryption key for verifying the signature attached to the firmware. The verification information is used to identify an abnormal part of the firmware storage area 22 and control the degenerate mode when the signature verification fails.

[0017] Fig. 3 shows an example of the functional configuration of an electronic control device according to an embodiment of the present invention. The electronic control device 1 includes a verification information generating unit 41, a verifying unit 42, and a booting unit 43. Note that Fig. 2 shows functions related to secure boot. Also, the firmware storage area 22 is defined in the memory 12 as described above.

[0018] When firmware is stored in the firmware storage area 22, the verification information generating unit 41 generates verification information for each of N partial areas obtained by dividing the firmware storage area 22. The verification information is, for example, a hash value obtained by performing a predetermined hash calculation on bits written in the partial area. When the firmware stored in the firmware storage area 22 is started, the verifying unit 42 verifies the state of each partial area by using the verification information generated by the verification information generating unit 41. Specifically, the verifying unit 42 verifies, for example, whether bits in each partial area have been tampered with (or damaged). Note that the verification information generating unit 41 and the verifying unit 42 are realized by, for example, the processor 11 shown in FIG. 1 executing the secure boot program shown in FIG. 2. The starting unit 43 starts the firmware stored in a normal partial area that has been successfully verified by the verifying unit 42 among the N partial areas.

[0019] In this way, in the electronic control device 1, when the firmware is started, it is verified whether the firmware has been tampered with or corrupted. That is, a secure boot is executed. At this time, the entire firmware is not not started, but the firmware stored in an area that has not been tampered with or corrupted (that is, a normal partial area) is started. That is, among the multiple functions or features provided by the firmware, a function or feature that has no problem is called. Therefore, according to the embodiment of the present invention, it is possible to improve availability while ensuring safety.

[0020] 4 is a flow chart showing an example of a process for updating firmware. It is assumed that firmware previously received by the electronic control device 1 is stored in the firmware storage area 22.

[0021] In S1, the electronic control device 1 receives new firmware. A signature by the provider of the firmware is attached to this firmware. The firmware and the signature received by the electronic control device 1 are temporarily stored in the download area 21.

[0022] In S2 to S3, the verification unit 42 verifies the signature of the new firmware using the signature verification key shown in FIG. 2. The signature verification key is an encryption key prepared in advance by a legitimate firmware provider. Therefore, if the new firmware is firmware that has been generated by a legitimate firmware provider and has not been tampered with or damaged, the signature verification is successful. Then, if the signature verification is successful, the processing of the electronic control device 1 proceeds to S4. On the other hand, if the signature verification fails, the processing of the electronic control device 1 ends. In this case, the firmware stored in the firmware storage area 22 is not updated.

[0023] In S4, the electronic control device 1 replaces the firmware stored in the firmware storage area 22 with new firmware, that is, the firmware is updated.

[0024] Here, the verification information generating unit 41 defines N partial areas #0 to #N-1 by dividing the firmware storage area 22 as shown in Fig. 5. In this case, the partial areas #0 to #N-1 may be defined by dividing the firmware storage area 22 into N equal parts. For example, when the size of the firmware storage area 22 is 1 MB and N is "5", the size of each of the partial areas #0 to #N-1 is 200 KB. However, the sizes of the partial areas #0 to #N-1 do not have to be the same. Furthermore, the verification information generating unit 41 may divide the firmware storage area 22 by function.

[0025] Thereafter, the verification information generation unit 41 executes the processes of S5 to S6 for each of the partial regions #0 to #N-1. Note that in the following description, the partial region for which the processes of S5 to S6 are executed may be referred to as "partial region #i."

[0026] In S5, the verification information generating unit 41 performs a predetermined hash calculation on the bits in the partial region #i to calculate a hash value. The hash calculation is not particularly limited, and may be a keyed hash such as HMAC (Hash-based Message Authentication Code) calculated using a unique key for each electronic control device (or a common key for multiple electronic control devices).

[0027] In S6, the verification information generation unit 41 saves the hash value calculated in S5 as verification information. At this time, the verification information generation unit 41 saves information indicating the start address of the partial area #i and the size of the partial area #i together with the calculated hash value. The verification information is saved in the protection area 30 as shown in FIG. 2.

[0028] The processes of S5 to S6 are executed for each of the partial areas #0 to #N-1. As a result, the verification information shown in Fig. 6 is obtained. Note that in the case where the partial areas #0 to #N-1 are defined by dividing the firmware storage area 22 into N equal parts, the start address and size of each partial area are determined to be first, so that it is not necessary to store the start address and size of partial area #i together with the hash value.

[0029] In this way, when the firmware stored in the firmware storage area 22 is updated, verification information is generated for each of the partial areas #0 to #N-1. Here, when the firmware is updated, signature verification is performed immediately before the update. In other words, when the verification information is generated, genuine firmware that has not been tampered with or damaged is stored in the firmware storage area 22. Therefore, the verification information saved in the protected area 30 represents the state of each of the partial areas #0 to #N-1 when genuine firmware that has not been tampered with or damaged is stored in the firmware storage area 22.

[0030] 4, verification information is generated when the firmware is updated, but verification information is also generated and stored when the firmware is initially installed in the electronic control device 1. When the firmware is updated, the verification information is also updated.

[0031] 7 is a flowchart showing an example of a process for booting firmware. The process of this flowchart is executed when an instruction to start up the firmware is given in the electronic control device 1.

[0032] In S11 to S12, the verification unit 42 verifies the signature of the firmware stored in the firmware storage area 22 by using the signature verification key shown in Fig. 2. Here, if the firmware has been tampered with or if the firmware is damaged, the signature verification fails. In other words, if the signature verification is successful, the verification unit 42 determines that the firmware stored in the firmware storage area 22 has not been tampered with or damaged. In this case, in S13, the startup unit 43 starts up the entire firmware stored in the firmware storage area 22. That is, the firmware is started up in the normal mode.

[0033] If the signature verification fails, the verification unit 42 determines that the signature has been tampered with or corrupted. In this case, the process of the electronic control device 1 proceeds to S14.

[0034] In S14 to S15, the verification unit 42 executes hash verification on the partial area in which the main function of the firmware is stored. Here, the main function is a function that is called first when a program (firmware in this embodiment) is executed in C language or the like. That is, if the main function is not executed, other functions will not be executed. For this reason, the main function is basically described at the beginning of the firmware. Therefore, when the firmware is stored from the partial area #0 to the partial area #N-1 shown in FIG. 5, the main function of the firmware should be stored in the partial area #0. Therefore, in this embodiment, the verification unit 42 executes hash verification on the partial area #0. Note that the main function is an example of a function that is called first when a program is started. That is, S14 to S15 correspond to a process of executing hash verification on the partial area in which the function that is called first when the firmware is started is stored.

[0035] In hash verification for partial region #0, the verification unit 42 compares a hash value obtained by performing a predetermined hash calculation on bits in partial region #0 with the hash value of partial region #0 stored as verification information. If these hash values ​​do not match (S15: No), the electronic control device 1 ends the process without starting the firmware. On the other hand, if these hash values ​​match (S15: Yes), the electronic control device 1 executes the processes of S16 to S18 for each of partial regions #1 to #N-1 other than partial region #0. In the following description, the partial process for which the processes of S16 to S18 should be executed may be referred to as the "target partial region #i."

[0036] In S16 to S17, the verification unit 42 compares a hash value obtained by performing a predetermined hash calculation on the bits in the partial region #i with the hash value of the partial region #i stored as verification information. If these hash values ​​match, in S18 the verification unit 42 adds an argument i corresponding to the partial region #i to the argument list. The argument i is information that identifies the partial region #i, and in this embodiment, it represents the start address and size of the partial region #i.

[0037] The processes of S16 to S18 are performed for each of partial regions #1 to #N-1. As a result, arguments corresponding to partial regions for which hash verification has been successful are registered in the argument list. In other words, partial regions that have not been tampered with or corrupted are identified. Note that in cases where S16 to S18 are performed, the hash verification of partial region #0 has already been successful in S14 to S15. Therefore, in this case, it is preferable that the arguments corresponding to partial region #0 are also registered in the argument list.

[0038] In S19, the startup unit 43 starts the firmware stored in the firmware storage area 22. At this time, the startup unit 43 starts the firmware in degenerate mode. Specifically, the startup unit 43 calls a predetermined function arranged in a partial area (including partial area #0) where the hash verification has succeeded. The predetermined function to be called in the degenerate mode preferably includes an abnormality notification function for notifying that an abnormality has occurred and / or a recovery processing function for performing recovery processing from an abnormal state.

[0039] In this way, in the electronic control device 1 according to the embodiment of the present invention, even if a part of the firmware is tampered with or damaged, the functions arranged in the area where the tampering or damage has not occurred can be executed. Therefore, when a part of the firmware is tampered with or damaged, a situation in which "the electronic control device 1 does not operate at all" is avoided. In other words, the secure boot method according to the embodiment of the present invention improves availability while ensuring safety.

[0040] <Example> Fig. 8 shows an example of firmware implemented in the electronic control device 1. In this embodiment, the firmware FW includes a main function, abnormality functions F0 to F2, and an abnormality function table, as shown in Fig. 8(a). Furthermore, the firmware FW includes other functions not shown.

[0041] As described above, in C language or the like, the main function is the function that is called first when a program (in this embodiment, the firmware FW) is started. In other words, if the main function is not executed, other functions in the firmware FW will not be executed either. The abnormality functions F0 to F2 are functions that should be called when an abnormality in the firmware FW is detected. In other words, the abnormality functions F0 to F2 correspond to abnormality notification functions and / or recovery processing functions that should be called in degenerate mode. For example, the abnormality function F0 outputs a predetermined message when an abnormality in the firmware FW is detected. The abnormality function F1 controls the lighting of an LED connected to the equipment in which the electronic control device 1 is implemented when an abnormality in the firmware FW is detected.

[0042] As shown in FIG. 9, the abnormality function table registers information related to each abnormality function described in the firmware FW. In this example, the address, size, and parameters of each abnormality function are registered. That is, the abnormality function table is an example of abnormality function information that indicates the address at which the abnormality function is stored in the firmware storage area 22 and the size of the abnormality function. The address indicates the address at which the function is placed when the firmware FW is stored in the memory 12 of the electronic control device 1. This address can be determined when the firmware FW is created and compiled. That is, when the firmware FW is stored in the firmware storage area 22, the address of the position at which each function, including the abnormality function described above, is placed is known. The size indicates the size of the function. Here, the size of each function, including the abnormality function described above, is also known. The parameter is an instruction or data given to the function. For example, the content of a message to be output when an abnormality in the firmware FW is detected is registered as a parameter of the abnormality function F0, which is a log output function. Also, the LED lighting pattern "blinking at 1 second intervals" is registered as a parameter of the abnormality function F1, which is an LED control function.

[0043] When the electronic control device 1 receives the firmware FW shown in Fig. 8(a), it executes the process of the flowchart shown in Fig. 4. At this time, if the signature verification is successful, the firmware FW is stored in the firmware storage area 22 as shown in Fig. 8(b). If the firmware storage area 22 is composed of a program area and a data area, the part of the firmware FW related to the program is stored in the program area, and the part of the firmware FW related to the data is stored in the data area. As described above, N partial areas #0 to #N-1 are defined in the firmware storage area 22. Then, a hash value of each partial area #0 to #N-1 is calculated and stored as verification information.

[0044] In this embodiment, the main function is placed in sub-area #0. The abnormality function F0 is placed in sub-area #1. The abnormality function F1 is placed in sub-area #2. The abnormality function F2 is placed across sub-area #2 and sub-area #3. The abnormality function table is placed in sub-area #N-1. After this, the electronic control device 1 waits for an instruction to start the firmware FW.

[0045] When the firmware FW is started, the electronic control device 1 executes the process of the flowchart shown in Fig. 7. In this embodiment, it is assumed that a part of the firmware FW is tampered with, and the signature verification fails. In this case, the verification unit 42 executes hash verification of each of the partial areas #0 to #N-1.

[0046] 7, the processes of S16 to S19 are executed when hash verification of the partial area in which the main function is placed (i.e., partial area #0) is successful in S14. However, in this embodiment, the processes of S16 to S19 are executed when hash verification of both the partial area in which the main function is placed (i.e., partial area #0) and the partial area in which the abnormality function table is placed (i.e., partial area #N-1) is successful.

[0047] In the above-mentioned hash verification, as shown in FIG. 8(b), it is assumed that only the hash verification for partial area #2 has failed. In other words, it is assumed that the hash verification for partial areas #0, #1, #3 to #N-1 has succeeded. In this case, arguments corresponding to partial areas #0, #1, #3 to #N-1 are registered in the argument list. Then, the electronic control device 1 starts up the firmware FW in degenerate mode based on this argument list.

[0048] 10 is a flowchart showing an example of the operation of the firmware FW. The process of this flowchart corresponds to S13 or S19 shown in FIG.

[0049] In S21, the startup unit 43 determines whether an argument is registered in the argument list. In this embodiment, when the signature verification shown in FIG. 7 is successful (S12: Yes), hash verification is not performed and no argument is registered. In this case, the startup unit 43 starts the firmware FW in normal mode in S13. When the signature verification fails and the hash verification for at least one of the partial area #0 or the partial area #N-1 fails, the electronic control device 1 ends the process without starting the firmware FW.

[0050] In this embodiment, it is assumed that the signature verification of the firmware FW fails, but the hash verification of both partial area #0 and partial area #N-1 is successful. In this case, the arguments corresponding to the partial areas for which the hash verification was successful are registered in the argument list. In the embodiment shown in FIG. 8(b), the hash verification of partial areas #0, #1, #3 to #N-1 is successful, and the arguments corresponding to them are registered in the argument list.

[0051] In S22, the startup unit 43 acquires an abnormality function table from the firmware FW. The abnormality function table is arranged in the partial area #N-1 where the hash verification has been successful, as shown in FIG. 8(b). Therefore, the information in the abnormality function table is normal. After that, the startup unit 43 executes the processes of S23 to S25 for each abnormality function registered in the abnormality function table. In the embodiment shown in FIG. 8, the processes of S23 to S25 are executed for the abnormality functions F0 to F2. Hereinafter, the abnormality function for which the processes of S23 to S25 are executed may be referred to as "abnormality function m."

[0052] In S23 to S24, the activation unit 43 performs a live / dead check on the abnormality function m. Specifically, the activation unit 43 determines whether the abnormality function m is placed in a normal partial region (i.e., a partial region where hash verification has been successful). If the abnormality function m is placed in a normal partial region, the activation unit 43 calls the abnormality function m in S25. On the other hand, if the abnormality function m is not placed in a normal partial region, the activation unit 43 does not call the abnormality function m.

[0053] In the embodiment shown in FIG. 8, the abnormality function F0 is placed in the partial area #1 where the hash verification is successful. In this case, it is determined that the abnormality function F0 can operate normally. Therefore, the startup unit 43 calls the abnormality function F0. At this time, the startup unit 43 refers to the parameters registered in the abnormality function table shown in FIG. 9. Therefore, the electronic control device 1 outputs a log message indicating that the firmware FW has been tampered with according to the parameters.

[0054] The abnormality function F1 is placed in the partial area #2 where the hash verification has failed. In this case, it is determined that there is a possibility that the abnormality function F1 does not operate correctly. Therefore, the startup unit 43 does not call the abnormality function F1. A part of the abnormality function F2 is placed in the partial area #2 where the hash verification has failed. In this case, it is determined that there is a possibility that the abnormality function F2 does not operate normally either. Therefore, the startup unit 43 does not call the abnormality function F2 either.

[0055] In this way, according to the secure boot method of the embodiment of the present invention, even if a part of the firmware implemented in the electronic control device is tampered with or damaged, the functions arranged in the storage area determined to be normal can be executed. In this case, as one example, notification of an abnormal state and / or recovery processing is executed. Therefore, compared with the conventional secure boot method in which the entire firmware is not started due to tampering or damage of the firmware, the secure boot method of the embodiment of the present invention improves availability.

[0056] Furthermore, according to the secure boot method of the embodiment of the present invention, hash verification is performed on each partial area obtained by dividing the firmware storage area, so that the location where tampering or damage has occurred can be identified. [Explanation of symbols]

[0057] 1. Electronic Control Device 11 Processors 12. Memory 20 General area 21 Download Area 22 Firmware storage area 30 Protected area 41 Verification information generation unit 42 Verification Department 43 Starting part

Claims

1. a memory including a firmware storage area for storing firmware; a verification information generating unit that generates verification information for each of N partial areas obtained by dividing the firmware storage area when firmware is stored in the firmware storage area; a verification unit that verifies a state of each of the N partial areas by using the verification information generated by the verification information generation unit when the firmware stored in the firmware storage area is started; a booting unit that boots firmware stored in a normal partial area that has been successfully verified by the verification unit among the N partial areas; An electronic control device comprising:

2. The firmware is signed; The verification unit verifies a state of each of the N partial regions when the verification of the signature fails.

2. The electronic control device according to claim 1 .

3. the verification information generation unit calculates a first hash value as the verification information for each of the N partial regions; the verification unit calculates a second hash value for each of the N partial areas when the firmware stored in the firmware storage area is started; The verification unit compares the first hash value with the second hash value for each of the N partial regions to determine whether or not the partial region is a normal partial region.

2. The electronic control device according to claim 1 .

4. When the verification of a first partial area of ​​the N partial areas in which the beginning part of the firmware is stored is successful, the startup unit starts the firmware stored in the normal partial area.

2. The electronic control device according to claim 1 .

5. The firmware is signed; The firmware includes: an error function to be called by the invocation unit when verification of the signature fails; and an error function information indicating an address at which the error function is stored in the firmware storage area and a size of the error function; When the firmware is started, the verification unit verifies the signature; The startup unit calls the abnormality function stored in the normal portion area when the signature verification fails.

2. The electronic control device according to claim 1 .

6. When firmware is stored in a firmware storage area, verification information is generated for each of N partial areas obtained by dividing the firmware storage area; verifying a state of each of the N partial areas using the verification information when the firmware stored in the firmware storage area is started; Activating firmware stored in the normal partial area that has been successfully verified among the N partial areas. A secure boot method comprising:

Images